流媒体传输 - RTSP 协议
概述
协议简介
RTSP
RTSP(Real-Time Stream Protocol)是一种专门设计为协调媒体流信息传递的应用层协议,在实际应用中广泛被用来 管理媒体流传输过程 。该协议主要采用C/S架构模式,并且完全依赖于文本信息来进行操作,在客户端与服务器端之间建立了稳定的实时通信渠道。
RTP
RTP (Real-time Transport Potocol) 实时传输协议,用于 实时数据的传输 。
详见:下一篇
RTCP
实时传输控制协议(Real-time Transport Control Protocol, RTCP)作为互联网通信的标准协议之一,在网络实时数据传输领域发挥着关键作用。该协议通过建立独立于网络层的信道管理机制来实现对 RTP 数据流的有效控制,并通过动态调整参数以适应实时性要求较高的应用场景需求。实时传输控制协议的核心职能是确保数据传输质量的同时提供及时有效的服务反馈信息。
详见:下一篇
传输渠道
| 协议名称 | 协议文档 | 传输层协议 | 功能 |
|---|---|---|---|
| RTSP | RFC 2326 RFC 7836 | TCP/UDP | 控制媒体流的传输 |
| RTP | RFC 3550 RFC 3551 RFC 6184 | UDP/TCP | 媒体流的传输 |
| RTCP | RFC 3550 | UDP/TCP | 传输质量反馈 |
RTSP 协议
RTSP URL
rtsp_URL = "rtsp://" host [":" port] [ abs_path ]
rtsp://media.example.com:554/twister/audiotrack
以海康摄像机为例,其 RTSP URL 格式为:
rtsp://[username]:[password]@[ip]:[port]/[channel]/[subtype]/av_stream
rtsp://admin:12345@192.168.1.67:554/h264/ch1/main/av_stream
rtsp://admin:12345@192.168.1.67/mpeg4/ch1/sub/av_stream
RTSP 报文
RTSP 是一种以文本为基础的协议,并采用 CRLF(回车换行)作为每行末尾的标准标识符。其主要优势在于,在实际应用中能够便捷地添加自定义参数,并且这种特性也使得相关操作更加高效可靠;同时便于进行抓包分析与数据解析工作。消息传送方向上可分为两种类型:请求报文和应答报文;其中通常指客户端向服务器发出的请求信息(偶尔也会有服务器向客户端发送的相关指令)。
RTSP 请求报文的常用方法:
| 方法 | 方向 | 对象 | 是否必要 | 作用 |
|---|---|---|---|---|
| DESCRIBE | C->S | P, S | 推荐 | 得到会话描述信息 |
| ANNOUNCE | C->S, S->C | P, S | 可选 | |
| GET_PARAMETER | C->S, S->C | P, S | 可选 | |
| OPTIONS | C->S, S->C | P, S | 必须 (S->C: 可选) | 获得服务器提供的可用方法 |
| PAUSE | C->S | P, S | 推荐 | 客户端发起暂停播放请求 |
| PLAY | C->S | P, S | 必须 | 客户端发起播放请求 |
| RECORD | C->S | P, S | 可选 | |
| REDIRECT | S->C | P, S | 可选 | |
| SETUP | C->S | S | 必须 | 客户端请求建立会话 |
| SET_PARAMETER | C->S, S->C | P, S | 可选 | |
| TEARDOWN | C->S | P, S | 必须 | 客户端发起关闭会话 |
通过 VLC 播放 RTSP 网络流,经抓包得以下内容:
OPTIONS rtsp://192.168.199.152:554/live/test RTSP/1.0
CSeq: 2
User-Agent: LibVLC/3.0.8 (LIVE555 Streaming Media v2016.11.28)
RTSP/1.0 200 OK
CSeq: 2
Date: Mon, Jul 27 2020 15:32:38 GMT
Public: OPTIONS, DESCRIBE, SETUP, TEARDOWN, PLAY, PAUSE, ANNOUNCE, RECORD, SET_PARAMETER, GET_PARAMETER
Server: ZLMediaKit-5.0(build in Jul 12 2020 14:02:13)
DESCRIBE rtsp://192.168.199.152:554/live/test RTSP/1.0
CSeq: 3
User-Agent: LibVLC/3.0.8 (LIVE555 Streaming Media v2016.11.28)
Accept: application/sdp
RTSP/1.0 200 OK
Content-Base: rtsp://192.168.199.152:554/live/test/
Content-Length: 544
Content-Type: application/sdp
CSeq: 3
Date: Mon, Jul 27 2020 15:32:38 GMT
Server: ZLMediaKit-5.0(build in Jul 12 2020 14:02:13)
Session: hEu0JzMKcfK2
x-Accept-Dynamic-Rate: 1
x-Accept-Retransmit: our-retransmit
v=0
o=- 0 0 IN IP4 127.0.0.1
c=IN IP4 127.0.0.1
t=0 0
s=Streamed by ZLMediaKit-5.0(build in Jul 12 2020 14:01:57)
a=tool:libavformat 58.29.100
m=video 0 RTP/AVP 96
a=fmtp:96 packetization-mode=1; sprop-parameter-sets=Z2QAHqzZQNg95f/wFAAUEQAAAwABAAADADIPFi2W,aOvjyyLA; profile-level-id=64001E
a=rtpmap:96 H264/90000
a=control:streamid=0
m=audio 0 RTP/AVP 97
b=AS:128
a=fmtp:97 profile-level-id=1;mode=AAC-hbr;sizelength=13;indexlength=3;indexdeltalength=3; config=121056E500
a=rtpmap:97 MPEG4-GENERIC/44100/2
a=control:streamid=1
SETUP rtsp://192.168.199.152:554/live/test/streamid=0 RTSP/1.0
CSeq: 4
User-Agent: LibVLC/3.0.8 (LIVE555 Streaming Media v2016.11.28)
Transport: RTP/AVP;unicast;client_port=60836-60837
RTSP/1.0 200 OK
CSeq: 4
Date: Mon, Jul 27 2020 15:32:38 GMT
Server: ZLMediaKit-5.0(build in Jul 12 2020 14:02:13)
Session: hEu0JzMKcfK2
Transport: RTP/AVP/UDP;unicast;client_port=60836-60837;server_port=41070-41071;ssrc=50E36E3B
SETUP rtsp://192.168.199.152:554/live/test/streamid=1 RTSP/1.0
CSeq: 5
User-Agent: LibVLC/3.0.8 (LIVE555 Streaming Media v2016.11.28)
Transport: RTP/AVP;unicast;client_port=60838-60839
Session: hEu0JzMKcfK2
RTSP/1.0 200 OK
CSeq: 5
Date: Mon, Jul 27 2020 15:32:38 GMT
Server: ZLMediaKit-5.0(build in Jul 12 2020 14:02:13)
Session: hEu0JzMKcfK2
Transport: RTP/AVP/UDP;unicast;client_port=60838-60839;server_port=58452-58453;ssrc=3463B21F
PLAY rtsp://192.168.199.152:554/live/test/ RTSP/1.0
CSeq: 6
User-Agent: LibVLC/3.0.8 (LIVE555 Streaming Media v2016.11.28)
Session: hEu0JzMKcfK2
Range: npt=0.000-
RTSP/1.0 200 OK
CSeq: 6
Date: Mon, Jul 27 2020 15:32:38 GMT
Range: npt=42535.41
RTP-Info: url=rtsp://192.168.199.152:554/live/test/streamid=0;seq=3889;rtptime=-466780396,url=rtsp://192.168.199.152:554/live/test/streamid=1;seq=1155;rtptime=-179511072
Server: ZLMediaKit-5.0(build in Jul 12 2020 14:02:13)
Session: hEu0JzMKcfK2
TEARDOWN rtsp://192.168.199.152:554/live/test/ RTSP/1.0
CSeq: 7
User-Agent: LibVLC/3.0.8 (LIVE555 Streaming Media v2016.11.28)
Session: hEu0JzMKcfK2
RTSP/1.0 200 OK
CSeq: 7
Date: Mon, Jul 27 2020 15:32:41 GMT
Server: ZLMediaKit-5.0(build in Jul 12 2020 14:02:13)
Session: hEu0JzMKcfK2
从上述抓包中分析得出,在解析RTSP网络流数据时(或:在解析RTSP网络流信息时),客户端与服务端进行了6次通信互动:
| 序号 | 方向 | 方法 | 消息内容 |
|---|---|---|---|
| 1 | C->S | OPTIONS | Client 询问 Server 有哪些方法可用 |
| 1 | S->C | OPTIONS | Server 回应所有可用的方法 |
| 2 | C->S | DESCRIBE | Client 请求得到 Server 提供的媒体初始化描述信息 |
| 2 | S->C | DESCRIBE | Server 回应媒体初始化信息,主要是 SDP (会话描述协议) |
| 3 | C->S | SETUP | 设置视频会话属性以及传输模式,请求建立会话 |
| 3 | S->C | SETUP | Server 建立会话,返回会话标识以及会话相关信息 |
| 4 | C->S | SETUP | 设置音频会话属性以及传输模式,请求建立会话 |
| 4 | S->C | SETUP | Server 建立会话,返回会话标识以及会话相关信息 |
| 5 | C->S | PLAY | Client 请求播放 |
| 5 | S->C | PLAY | Server 回应播放请求 |
| 6 | C->S | TEARDOWN | Client 请求关闭会话 |
| 6 | S->C | TEARDOWN | Server 回应关闭会话请求 |
下面我们一步一步了解 RTSP 会话建立流程:
学习地址
学习地址
文章福利
学习入口

**

OPTIONS
OPTIONS 选项请求可以在任何时候被提交,并且不会干扰服务器的状态,例如:
C->S: OPTIONS * RTSP/1.0
CSeq: 1
Require: implicit-play
Proxy-Require: gzipped-messages
S->C: RTSP/1.0 200 OK
CSeq: 1
Public: DESCRIBE, SETUP, TEARDOWN, PLAY, PAUSE
DESCRIBE
客户端发起对服务器的媒体资源描述请求; server end then responds to the client s request by using the SDP protocol format; in the resource description it will list the requested media and its related information; in typical scenarios audio and video are generally transmitted as separate media streams respectively
C->S: DESCRIBE rtsp://server.example.com/fizzle/foo RTSP/1.0
CSeq: 312
Accept: application/sdp, application/rtsl, application/mheg
S->C: RTSP/1.0 200 OK
CSeq: 312
Date: 23 Jan 1997 15:35:06 GMT
Content-Type: application/sdp
Content-Length: 376
v=0
o=mhandley 2890844526 2890842807 IN IP4 126.16.64.4
s=SDP Seminar
i=A Seminar on the session description protocol
u=http://www.cs.ucl.ac.uk/staff/M.Handley/sdp.03.ps
e=mjh@isi.edu (Mark Handley)
c=IN IP4 224.2.17.12/127
t=2873397496 2873404696
a=recvonly
m=audio 3456 RTP/AVP 0
m=video 2232 RTP/AVP 31
m=whiteboard 32416 UDP WB
a=orient:portrait
媒体流及其相关数据通过 SDP (Session Description Protocol) 格式传递,在具体解释 SDP 的机制时,请参考拓展阅读 5。
SETUP
SETUP 请求指定了媒体流的具体传输方式, 此请求必须在随后发出的PLAY请求之前被发送出去. 该请求包含了媒体流对应的URL地址, 客户端用来接收实时音视频数据(RTP)所需的端口以及用于接收实时元数据(RTCP)所需使用的端口信息. 服务器通常会在返回给客户端时不仅确认收到相关参数还会补充可能缺少的信息. 每个媒体流都需要先通过SETUP请求数字完成必要的配置工作之后才能随后发出PLAY请求数字.
C->S: SETUP rtsp://example.com/foo/bar/baz.rm RTSP/1.0
CSeq: 302
Transport: RTP/AVP;unicast;client_port=4588-4589
S->C: RTSP/1.0 200 OK
CSeq: 302
Date: 23 Jan 1997 15:35:06 GMT
Session: 47112344
Transport: RTP/AVP;unicast;client_port=4588-4589;server_port=6256-6257
PLAY
客户端可向系统提交 PLAY 请求以启动多个媒体流(单个或多组)。每次提交均可选择单独发送或批量处理(单次请求对应多个输出口)。当执行单次请求操作时会生成包含所有待传输出口地址的一个完整 URL;而当采用分批处理的方式每次请求仅涉及单一输出口地址(即每个 play request 包含一组输出地址)。此外在 play request 中支持设置 range 参数允许用户定义起始点与结束点(若无范围参数则默认从头开始至尾部结束);如果在传输过程中出现中断情况系统将自动将 play 操作暂停并等待确认响应;一旦确认无误即可继续从上次停播位置重新发起 play 流程
C->S: PLAY rtsp://example.com/media.mp4 RTSP/1.0
CSeq: 4
Range: npt=5-20
Session: 12345678
S->C: RTSP/1.0 200 OK
CSeq: 4
Session: 12345678
RTP-Info: url=rtsp://example.com/media.mp4/streamid=0;seq=9810092;rtptime=3450012
当服务器接收到客户端发出的 PLAY 请求时
就会立即响应并开始向客户端传输媒体数据
通常会采用 RTP 协议来进行这种传输
并有关于 RTP 协议的详细说明
请参见拓展阅读 6
TEARDOWN
发起并完成一个会话终止请求后端服务将阻止所有媒体流的接收同时释放服务器上相关的会话数据
C->S: TEARDOWN rtsp://example.com/media.mp4 RTSP/1.0
CSeq: 8
Session: 12345678
S->C: RTSP/1.0 200 OK
CSeq: 8
