Live555源码解析(2) - RTSP协议概述
上一篇Live555源码解析(1) - Main 寻根问祖,留其筋骨将main()函数脉络做了整体分析,通常来讲本篇应从服务器的创建开始讲起,但如前文所述,Live555媒体服务器是基于RTSP协议实现,为了便于源码阅读, 在这里有必要先整体介绍下RTSP协议及相关协议内容。如读者已掌握RTSP内容,则可跳过本篇,继续下一篇Live555源码解析(3) - 服务开启,愿者上钩的阅读。
编写本篇前,尽可能详细地翻译了RTSP Sepc,如有兴趣,可同时阅读RTSP Spec中文版。
1. RTSP简史
RTSP出现以前,最热的大概就是HTTP协议。想象一下,当你需要欣赏网络中的某一段视频,通过HTTP协议访问其URL、开始下载、下载完成后播放。对于早期的视频采集设备、网络带宽或是负责渲染的显示器而言,似乎多给予一点耐心、多重连几次断开的HTTP连接、甚至多校验几次下载后文件的完整性,体验上也还能过得去。毕竟那时候的分辨率、帧率、带宽限制了互联网途径传播媒体文件的大小,信息的分享只能通过各种硬盘、U盘、光盘以存储后文件的形式进行传输。
随着硬件设备技术的发展,采集设备分辨率在提升,显示器支持了更高的帧率,网络带宽也指数增长,这都为更好的观影体验提供了基础支持。随着网络资源的日益丰富,用户时间的稀缺性日益凸显,为了快速观看、判别视讯本身是否符合自身口味,在线实时观看成了一大述求。而传统的HTTP下载显然不能够匹配该需求,因此在寻求streaming的道路上,RTSP脱颖而出。
RTSP全称实时流协议(Real Time Streaming Protocol),它是一个网络控制协议,设计用于娱乐、会议系统中控制流媒体服务器。RTSP用于在希望通讯的两端建立并控制媒体会话(session),客户端通过发出VCR-style命令如play、record和pause等来实时控制媒体流。
RTSP处理流时会根据端点间可用带宽大小,将音视频等数据切割成小分组(packet)进行传输,使得客户端在播放一个分组的同时,可以解压缓存中第二个甚至下载第三个分组。通过缓存和多码率流技术,用户将不会感觉到数据间存在停顿。至于RTSP的特性,则主要体现在如下方面:
- 多服务器兼容 :媒体流可来自不同服务器
- 可协商:客户端和服务器可协商feature支持程度
- HTTP亲和性:尽可能重用HTTP概念,包括认证、状态码、解析等
- 易解析:HTML或MIME解析器均可在RTSP中适用
- 易扩展:新的方法或参数甚至协议本身均可添加或定制
- 防火墙亲和性:传输层或应用层防火墙均可被协议较好处理
- 服务器控制:控制概念易于理解,服务器不允许向客户端传输不能被客户端关闭的流
- 多场景适用:RTSP提供帧级别精度,适用于更多媒体应用场景
1.1 相关协议介绍
RTSP组合使用了可靠传输协议TCP(控制)和高效传输协议UDP(内容)来串流(streaming)内容给用户。它支持点播(Video-On-Demand)以及直播(Live Streaming)服务。
RTSP协议本身并不负责数据传输,通常(非必须)是通过RTP(Real-time Transport Protocol)配合RTCP(Real-time Control Protocol)完成数据流和控制命令(同步、QOS管理等)的传输。具体应用中,三者的关系如下图所示:
RTSP RTCP RTP2. RTSP方法
RTSP中并没有连接的概念,而是通过会话(Session)进行管理。每个会话有对应的会话ID,会话中可能可能涉及一至多个流,会话生命周期中,客户端也可能切换连接(如TCP)来传递RTSP请求(request)。
method | direction | object | requirement |
---|---|---|---|
DESCRIBE | C->S | P,S | recommended |
ANNOUNCE | C->S, S->C | P,S | optional |
GET_PARAMETER | C->S, S->C | P,S | optional |
OPTIONS | C->S, S->C | P,S | required(S->C:optional) |
PAUSE | C->S | P,S | recommended |
PLAY | C->S | P,S | required |
RECORD | C->S | P,S | optional |
REDIRECT | S->C | P,S | optional |
SETUP | C->S | S | required |
SET_PARAMETER | C->S,S->C | P,S | optional |
TEARDOWN | C->S | P,S | required |
P: 呈现(Presentation),S:流(Stream)
一个RTSP应用(如点播)生命周期内,通常会话(所有交互)过程如下图所示:
2.1 必选方法
对于上述交互中涉及的RTSP方法,说明如下:
-
OPTIONS
用于请求服务器所支持的所有方法C->S OPTIONS rtsp://video.foocorp.com:554 RTSP/1.0 CSeq: 1 S->C RTSP/1.0 200 OK CSeq: 1 Public: DESCRIBE, SETUP, TEARDOWN, PLAY, PAUSE, RECORD
-
DESCRIBE(推荐级别)
用于请求URL指定对象的描述信息,通常描述信息使用SDP(Session Description Protocol)格式。C->S DESCRIBE rtsp://video.foocorp.com:554/streams/example.rm RTSP/1.0 CSeq: 2 S->C RTSP/1.0 200 OK CSeq: 2 Content-Type: application/sdp Content-Length: 210 m=video 0 RTP/AVP 96 a=control:streamid=0 a=range:npt=0-7.741000 a=length:npt=7.741000 a=rtpmap:96 MP4V-ES/5544 a=mimetype:string;"video/MP4V-ES" a=AvgBitRate:integer;304018 a=StreamName:string;"hinted video track" m=audio 0 RTP/AVP 97 a=control:streamid=1 a=range:npt=0-7.712000 a=length:npt=7.712000 a=rtpmap:97 mpeg4-generic/32000/2 a=mimetype:string;"audio/mpeg4-generic" a=AvgBitRate:integer;65790 a=StreamName:string;"hinted audio track"
SDP协议格式
SDP(Session Description Protocol)是一个用来描述多媒体会话的应用层控制协议,是一个基于文本的协议,用于会话建立过程中的媒体类型和编码方案的协商等。SDP描述由许多文本行组成,文本行的格式为<类型>=<值>
,<类型>
是一个字母,<值>
是结构化的文本串,其格式依<类型>
而定。<type>=<value>[CRLF]
sdp的格式:
v=<version> (协议版本) o=<username> <session id> <version> <network type> <address type> <address> (所有者/创建者和会话标识符) s=<session name> (会话名称) i=<session description> (会话信息) u=<URI> (URI 描述) e=<email address> (Email 地址) p=<phone number> (电话号码) c=<network type> <address type> <connection address> (连接信息) b=<modifier>:<bandwidth-value> (带宽信息) t=<start time> <stop time> (会话活动时间) r=<repeat interval> <active duration> <list of offsets from start-time>(0或多次重复次数) z=<adjustment time> <offset> <adjustment time> <offset> .... k=<method> k=<method>:<encryption key> (加密密钥) a=<attribute> (0 个或多个会话属性行) a=<attribute>:<value> m=<media> <port> <transport> <fmt list> (媒体名称和传输地址)
-
SETUP
用于请求URL使用指定传输格式,必须在PLAY前发出。C->S SETUP rtsp://video.foocorp.com:554/streams/example.rm RTSP/1.0 CSeq: 3 Transport: rtp/udp;unicast;client_port=5067-5068 S->C RTSP/1.0 200 OK CSeq: 3 Session: 12345678 Transport: rtp/udp;client_port=5067-5068;server_port=6023-6024
客户端请求中,指明了用于接收RTP数据(音视频)的本地端口5067,以及RTCP数据(元信息)的端口5068。这里图示说明下RTSP(554/8554)、RTP、RTCP端口关系。
可以看到,RTCP端口是基于RTP的,且始终为其端口值+1。服务器回复中,确认了客户端所请求的端口,并给出服务器端对应开辟的端口值6023/6024。
-
PLAY
用于请求服务器使用SETUP中确认的机制开始传输数据,客户端不应在SETUP请求未被确认应答成功前发出PLAY请求。另外需要注意,PLAY请求是需要排队的,其中可携带Range域以指明区间。C->S PLAY rtsp://video.foocorp.com:554/streams/example.rm RTSP/1.0 CSeq: 4 Range: npt=5-20 Session: 12345678 S->C RTSP/1.0 200 OK CSeq: 4 Session: 12345678
-
TEARDOWN
用于请求终止会话,将停止会话中所有相关流,并释放资源。C->S TEARDOWN rtsp://video.foocorp.com:554/streams/example.rm RTSP/1.0 CSeq: 5 Session: 12345678 S->C RTSP/1.0 200 OK CSeq: 5
2.2 可选方法
除了上一小节中提到的5种必选方法外,还有如下方法是可选的。
-
ANNOUNCE
ANNOUNCE方法有两个用途:- 从服务器发送给客户端时:用于更新实时会话描述
- 从客户端发送给服务器时:推送URL指定的呈现或媒体对象的描述
如果呈现途中插入新流,应重发完整描述,而不仅仅是增量。这样一来,也就支持了动态移除组件。
C->S: ANNOUNCE rtsp://video.foocorp.com:554/streams/example.rm RTSP/1.0 CSeq: 10 Session: 47112344 Content-Type: application/sdp Content-Length: 332 v=0 o=mhandley 2890844526 2890845468 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 S->C: RTSP/1.0 200 OK CSeq: 10
-
GET_PARAMETER
用于请求URI指定呈现或流的参数值。回复的内容有待实现,不带任何实体主体的GET_PARAMETER可用于测试客户端或服务器是否在线(类似“ping”程序)。S->C: GET_PARAMETER rtsp://example.com/fizzle/foo RTSP/1.0 CSeq: 431 Content-Type: text/parameters Session: 12345678 Content-Length: 15 packets_received jitter C->S: RTSP/1.0 200 OK CSeq: 431 Content-Length: 46 Content-Type: text/parameters packets_received: 10 jitter: 0.3838
-
SET_PARAMETER
SET_PARAMETER请求用于设置URI指定呈现或流的参数值。
每条请求应当只包含一个参数以允许客户端确定失败原因,如果请求中包含多个参数,服务器必须只在所有参数都能成功设置情况下生效。服务器应当允许同一参数多次设置同一值,但可拒绝设置为不同值。
注意:媒体流传输参数必须通过SETUP请求来设置C->S: SET_PARAMETER rtsp://example.com/fizzle/foo RTSP/1.0 CSeq: 421 Content-Length: 20 Content-type: text/parameters barparam: barstuff S->C: RTSP/1.0 451 Invalid Parameter CSeq: 421 Content-Length: 10 Content-type: text/parameters barparam
-
PAUSE
PAUSE请求会临时中断流传输,如果URL指定的是某一个流,则该流的播放和录制会被暂停。例如,对于音频而言,相当于静音操作。如果URL指定的是一组流,则呈现或组中所有活动流将会被暂停。当恢复播放或录制时,所有轨道的流必须进行同步。
此过程中,所有服务器资源均会保留,除非SETUP时,头中有参数指定延时,那么服务器可能在触发延时后关闭会话并释放资源。C->S: PAUSE rtsp://example.com/fizzle/foo RTSP/1.0 CSeq: 834 Session: 12345678 S->C: RTSP/1.0 200 OK CSeq: 834 Date: 23 Jan 1997 15:35:06 GMT
-
RECORD
RECORD方法用于开始录制当前呈现描述中的一段媒体数据,UTC格式时间戳包含开始点和结尾点。如未给出时间范围,则使用呈现描述中的开始点和结尾点。如会话已处于运行中,则立即开始录制。
服务器决定将录制数据保存在请求URI或其他URI,如使用其他URI,需回复“201(Created)”并包含实体以描述请求状态和新资源位置信息。
一个支持直播情境下录制的服务器必须支持clock格式,这里smpte格式并没有意义。C->S: RECORD rtsp://example.com/meeting/audio.en RTSP/1.0 CSeq: 954 Session: 12345678 Conference: 128.16.64.19/32492374
-
REDIRECT
REDIRECT请求用于提示客户端它必须连接至另一个服务器,其中强制包含了Location头,以指明新的服务器URL。其中还可能包含Range参数,指明何时重定向将生效。如果客户端希望向该URI发送和接收媒体,则客户端必须先对当前会话发出TEARDOWN请求,然后向目标主机发出SETUP请求新的会话。S->C: REDIRECT rtsp://example.com/fizzle/foo RTSP/1.0 CSeq: 732 Location: rtsp://bigserver.com:8001 Range: clock=19960213T143205Z-
2.3 RTSP状态机
RTSP Status Machine2.4 嵌入式二进制数据(Embedded (Interleaved) Binary Data)
某些防火墙设计或其他环境因素可能迫使服务器将RTSP方法交错进流数据中。该种交错操作应尽可能避免,因为它提高了客户端和服务器操作的复杂度,也增加了额外的开销。嵌入式二进制数据应当只在RTSP通过TCP传输时使用。
C->S SETUP rtsp://example.com/media.mp4 RTSP/1.0
CSeq: 3
Transport: RTP/AVP/TCP;interleaved=0-1
S->C RTSP/1.0 200 OK
CSeq: 3
Date: 05 Jun 1997 18:57:18 GMT
Transport: RTP/AVP/TCP;interleaved=0-1
Session: 12345678
C->S PLAY rtsp://example.com/media.mp4 RTSP/1.0
CSeq: 4
Session: 12345678
S->C RTSP/1.0 200 OK
CSeq: 4
Session: 12345678
Date: 05 Jun 1997 18:59:15 GMT
RTP-Info: url=rtsp://example.com/media.mp4;
seq=232433;rtptime=972948234
S->C $\000{2 byte length}{"length" bytes data, w/RTP header}
$\000{2 byte length}{"length" bytes data, w/RTP header}
$\001{2 byte length}{"length" bytes RTCP packet}
3. Live555 openRTSP
openRTSP a command-line RTSP client
openRTSP是用于打开、串流、接收以及可选地录制媒体流的命令行客户端,媒体流通过RTSP URL指定,URL前缀为"rtsp://"。
本系列只以MediaServer源码为分析对象,因此对openRTSP不做讨论。
4. 实践检验
4.1 RTSP测试源
由于Windows真机环境负责,进程较多,进行抓包分析时干扰项很多,因此测试时创建了虚拟机,在发行版Ubuntu上进行了搭建。 Live555MediaServer Ubuntu可以直接下载,下载后在相同目录下放置媒体文件进行测试即可。
4.2 Wireshark抓包分析
下面就对应Wireshark抓包以及前述会话过程进行验证。
服务器地址:192.168.63.130:8554
客户端地址:192.168.63.1 :9571
4.2.1 TCP 三路握手
没有太多好说的,TCP标准三路握手,确定了窗口大小(Win),MSS等选项。
4.2.2 OPTIONS
OPTIONS请求、回复,有如下几个注意点:
- 中间有夹杂一个TCP协议的ACK用于确认收到请求,且ACK=141。为什么是141,因为OPTIONS请求中TCP Segment长度为140,所以下一个为141
- 回复中 Public域中明确给出了所支持的方法
4.2.3 DESCRIBE
DESCRIBE请求、回复,没有夹杂ACK。回复中以SDP协议格式给出了会话ID及其他会话属性。注意最后一个字段Meida Attribute中表明了control:track1,该值将在下一步SETUP中使用到。
4.2.4 SETUP
服务器在回复SETUP请求后,注意客户端有连续发出4个RTP/RTCP请求给服务器。
4.2.5 PLAY
PLAY请求中使用聚合控制URL,针对呈现本身,可同时作用于其中的多个流。Range值为从0开始到结束。
紧跟其后的是MPEG TS协议包,实际上是RTP协议通过UDP在传递TS流信息。
4.2.6 GET_PARAMETER
4.2.7 PAUSE
PAUSE中未携带Range域,表示立即暂停。客户端在收到服务器回复后,进行了额外ACK。
4.2.8 TEARDOWN
客户端请求关闭会话,Receiver Report属于客户端发往服务器的RTCP控制命令。
4.2.9 TCP四路断开
为什么不是四条,因为该种情况下两端同时断开,只需要将ACK放入发出的FIN中即可,不需要单独发送一条消息。