rtsp协议分析

shenhuxi_yu

已于 2024-09-26 09:30:59 修改

阅读量456

点赞数 1

分类专栏：多媒体文章标签：音视频

于 2024-05-26 12:57:37 首次发布

本文链接：https://blog.csdn.net/shenhuxi_yu/article/details/139213459

版权

多媒体专栏收录该内容

3 篇文章

订阅专栏

rtsp概述

rtsp (real-time stream protocol)实时流媒体控制协议。RFC2326：这是RTSP的初始定义版本v1.0，由哥伦比亚大学、网景和RealNetworks公司提交给互联网工程任务组（IETF）作为RFC标准。RFC7826：这是RTSP的后续更新版本v2.0，对RFC2326中的RTSP进行了扩展和更新。

rtsp协议属于基于文本的应用层协议，rtsp的底层协议可以是udp也可以是tcp

ffmpeg 参数-rtsp_transport tcp 用于指定RTSP会话底层传输协议为TCP，实现 RTSP 的系统必须支持通过 TCP 承载 RTSP，并且可以支持 UDP。 RTSP 服务器的默认端口对于 UDP 和 TCP 都是 554

本身并不传输流媒体数据，只是提供流媒体的控制，实际流媒体的传输使用rtp协议，协议文档可以从资源链接下载rtsp协议中英双文https://download.csdn.net/download/shenhuxi_yu/89358966

使用wireshark rtsp筛选器既可以比较容易的分析rtsp协议内容

如上图是本地使用vlc工具打开远程流的过程中抓到的rtsp包，rtsp报文包括request和response，服务端和客户端都可以法request和response

request 报文分析

以第一个报文为例rtsp报文的格式如下

一个client请求sever的options request的消息格式如下，request-line是request的第一行，CRLF作为行结束符，CSeq 字段指定 RTSP 请求-响应对的序列号。该字段必须出现在所有请求和响应中。对于每个包含给定序列号的 RTSP 请求，都会有一个具有相同编号的相应响应。任何重传的请求必须包含与原始请求相同的序列号（即，序列号不会因相同请求的重传而增加）。SP分隔符具体是指空格字符（Space Character）

C->S:  OPTIONS * RTSP/1.0 
CSeq: 1 
Require: implicit-play 
Proxy-Require: gzipped-messages

Request = Request-Line     ; Section 6.1 
*( general-header ; Section 5  
| request-header  ; Section 6.2
| entity-header ) ; Section 8.1 
CRLF 
[ message-body ] ; Section 4.3 

Request-Line = Method SP Request-URI SP RTSP-Version CRLF 
Method = "DESCRIBE"       ; Section 10.2 
| "ANNOUNCE"       ; Section 10.3 
| "GET_PARAMETER" ; Section 10.8 
| "OPTIONS"        ; Section 10.1 
| "PAUSE"          ; Section 10.6 
| "PLAY"           ; Section 10.5 
| "RECORD"         ; Section 10.11 
| "REDIRECT"      ; Section 10.10 
| "SETUP"          ; Section 10.4 
| "SET_PARAMETER" ; Section 10.9 
| "TEARDOWN"       ; Section 10.7 
| extension-method 

extension-method = token 

Request-URI = "*" | absolute_URI 

RTSP-Version = "RTSP" "/" 1*DIGIT "." 1*DIGIT 

request-header    = Accept             ; Section 12.1 
| Accept-Encoding  ; Section 12.2 
| Accept-Language  ; Section 12.3 
| Authorization     ; Section 12.5 
| From                ; Section 12.20 
| If-Modified-Since ; Section 12.23 
| Range               ; Section 12.29 
| Referer             ; Section 12.30 
| User-Agent          ; Section 12.41

response 报文分析

第二条报文时response报文类型CSeq与第一个报文相同，因此是对第一个报文的回复

Response  =    Status-Line       ; Section 7.1 
*(  general-header   ; Section 5 
|   response-header  ; Section 7.1.2 
|    entity-header ) ; Section 8.1 
CRLF 
[message-body ] ; Section 4.3 

Status-Line = RTSP-Version SP Status-Code SP Reason-Phrase CRLF

response-header = Location            ; Section 12.25 
| Proxy-Authenticate ; Section 12.26 
| Public               ; Section 12.28 
| Retry-After         ; Section 12.31 
| Server               ; Section 12.36 
| Vary                 ; Section 12.42 
| WWW-Authenticate   ; Section 12.44

Status-Code状态表如下

客户端使用 OPTIONS 方法查询服务器支持的方法。服务器使用Public响应头列出它支持的方法。并使用Server响应头报告服务器信息。

rtsp连接过程

从如上的抓包可以看到vlc打开并播放rtsp流的过程的报文以此是OPTIONS-->DESCRIBE-->SETUP-->PLAY，，开始播放后每隔58s通信一次GET_PARAMETER消息。当客户端关闭VLC的时候发送TEARDOWN报文。

这个过程的解释如下

1. OPTIONS
目的：此请求用于探测服务器支持的方法。客户端发送一个OPTIONS请求到服务器，询问服务器支持哪些RTSP操作。
响应：服务器会回复一个包含它支持的所有RTSP方法的列表。
2. DESCRIBE
目的：此请求用于获取媒体播放的描述信息，通常是SDP（Session Description Protocol）格式。SDP文件描述了媒体流的属性，如编码、格式、带宽要求等。
请求：客户端发送一个带有媒体播放URL的DESCRIBE请求。
响应：服务器返回SDP文件，客户端根据此文件来设置播放环境。
3. SETUP
目的：此请求用于设置媒体流传输的参数，如传输模式（单播或多播）、端口号、传输协议（RTP/UDP或RTP/TCP）等。
请求：客户端根据SDP文件中的信息，对每个媒体流发送一个或多个SETUP请求。
响应：服务器确认设置并返回用于实际传输的端口和传输参数。
4. PLAY
目的：此请求用于启动媒体流的播放。
请求：客户端发送PLAY请求，可能包含播放范围（如从某个时间点开始播放）。
响应：服务器确认播放请求，并开始发送媒体数据。
5. GET_PARAMETER
目的：虽然RTSP标准协议中并没有直接命名为GET_PARAMETER的明确方法，但类似的功能可以通过RTSP的OPTIONS或INFO等方法实现，用于查询会话或流的当前状态或参数。
请求：客户端发送请求以获取特定参数或状态信息。
响应：服务器返回请求的参数值或状态信息。
6. TEARDOWN 或 BYE
目的：此请求用于终止RTSP会话，关闭媒体流。
请求：客户端发送TEARDOWN或BYE请求来结束会话。
响应：服务器确认会话终止，并释放相关资源。

另外在DESCRIBE报文的回复报文中使用了SDP协议报文描述会话信息，在RTSP中，会话指的是客户端和服务器之间建立的一个连接，用于控制多媒体流的传输。这个连接通过一系列的RTSP请求和响应来维护，包括设置参数、播放、暂停、停止等操作。会话的关闭动作是客户端发送TEARDOWN报文发起的。