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 RTP

2. 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 Machine

2.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中即可,不需要单独发送一条消息。

最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 194,390评论 5 459
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 81,821评论 2 371
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 141,632评论 0 319
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 52,170评论 1 263
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 61,033评论 4 355
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 46,098评论 1 272
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 36,511评论 3 381
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 35,204评论 0 253
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 39,479评论 1 290
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 34,572评论 2 309
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 36,341评论 1 326
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 32,213评论 3 312
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 37,576评论 3 298
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 28,893评论 0 17
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 30,171评论 1 250
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 41,486评论 2 341
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 40,676评论 2 335

推荐阅读更多精彩内容

  • RTSP SDP RTP/RTCP 介绍应用层 RTSP、SDP; 传输层 RTP、TCP、UDP; 网络层 IP...
    Atom_Woo阅读 3,787评论 0 7
  • 第一部分:RTSP协议 一、RTSP协议概述 RTSP(Real-TimeStream Protocol )是一种...
    小鱼儿喜欢花无缺阅读 2,611评论 1 6
  • RFC 2326RTSP Spec中文版(1-11)RTSP Spec中文版(12-16)RTSP Spec中文版...
    SniperPan阅读 5,416评论 3 10
  • RTSP简介 RTSP(Real Time Streaming Protocol)是由Real Network和N...
    lory17阅读 31,685评论 0 12
  • 回望 从原始的路上 土金色的八月 我看见 树上长满了翅膀 是谁 扑过它柔嫩的羽毛 我想在潮湿的空气里 和你聊聊 那...
    常青藤青藤阅读 391评论 3 6