RTSP协议详解和分析

转载：https://www.jianshu.com/p/b0474f65e729

1. RTSP简史

RTSP出现以前，最热的大概就是HTTP协议。想象一下，当你需要欣赏网络中的某一段视频，通过HTTP协议访问其URL、开始下载、下载完成后播放。对于早期的视频采集设备、网络带宽或是负责渲染的显示器而言，似乎多给予一点耐心、多重连几次断开的HTTP连接、甚至多校验几次下载后文件的完整性，体验上也还能过得去。毕竟那时候的分辨率、帧率、带宽限制了互联网途径传播媒体文件的大小，信息的分享只能通过各种硬盘、U盘、光盘以存储后文件的形式进行传输。

随着硬件设备技术的发展，采集设备分辨率在提升，显示器支持了更高的帧率，网络带宽也指数增长，这都为更好的观影体验提供了基础支持。随着网络资源的日益丰富，用户时间的稀缺性日益凸显，为了快速观看、判别视讯本身是否符合自身口味，在线实时观看成了一大述求。而传统的HTTP下载显然不能够匹配该需求，因此在寻求streaming的道路上，RTSP脱颖而出。

RTSP全称实时流协议（Real Time Streaming Protocol），它是一个网络控制协议，设计用于娱乐、会议系统中控制流媒体服务器。RTSP用于在希望通讯的两端建立并控制媒体会话（session），客户端通过发出VCR-style命令如play、record和pause等来实时控制媒体流。可以参考RTSP 2326 中文版

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管理等）的传输。具体应用中，三者的关系如下图所示：

image

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应用（如点播）生命周期内，通常会话（所有交互）过程如下图所示：

image

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端口关系。

    image

    可以看到，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状态机

image

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等选项。

image

4.2.2 OPTIONS

image

OPTIONS请求、回复，有如下几个注意点：

  • 中间有夹杂一个TCP协议的ACK用于确认收到请求，且ACK=141。为什么是141，因为OPTIONS请求中TCP Segment长度为140，所以下一个为141
  • 回复中 Public域中明确给出了所支持的方法

4.2.3 DESCRIBE

image

DESCRIBE请求、回复，没有夹杂ACK。回复中以SDP协议格式给出了会话ID及其他会话属性。注意最后一个字段Meida Attribute中表明了control:track1，该值将在下一步SETUP中使用到。

4.2.4 SETUP

image

服务器在回复SETUP请求后，注意客户端有连续发出4个RTP/RTCP请求给服务器。

4.2.5 PLAY

image

PLAY请求中使用聚合控制URL，针对呈现本身，可同时作用于其中的多个流。Range值为从0开始到结束。

image

紧跟其后的是MPEG TS协议包，实际上是RTP协议通过UDP在传递TS流信息。

4.2.6 GET_PARAMETER

image

4.2.7 PAUSE

image

PAUSE中未携带Range域，表示立即暂停。客户端在收到服务器回复后，进行了额外ACK。

4.2.8 TEARDOWN

image

客户端请求关闭会话，Receiver Report属于客户端发往服务器的RTCP控制命令。

4.2.9 TCP四路断开

image

为什么不是四条，因为该种情况下两端同时断开，只需要将ACK放入发出的FIN中即可，不需要单独发送一条消息。

©著作权归作者所有,转载或内容合作请联系作者
  • 人面猴
    序言：七十年代末，一起剥皮案震惊了整个滨河市，随后出现的几起案子，更是在滨河造成了极大的恐慌，老刑警刘岩，带你破解...
    沈念sama阅读 205,386评论 6赞 479
  • 死咒
    序言：滨河连续发生了三起死亡事件，死亡现场离奇诡异，居然都是意外死亡，警方通过查阅死者的电脑和手机，发现死者居然都...
    沈念sama阅读 87,939评论 2赞 381
  • 救了他两次的神仙让他今天三更去死
    文/潘晓璐 我一进店门，熙熙楼的掌柜王于贵愁眉苦脸地迎上来，“玉大人，你说我怎么就摊上这事。” “怎么了？”我有些...
    开封第一讲书人阅读 151,851评论 0赞 341
  • 道士缉凶录：失踪的卖姜人
    文/不坏的土叔 我叫张陵，是天一观的道长。 经常有香客问我，道长，这世上最难降的妖魔是什么？ 我笑而不...
    开封第一讲书人阅读 54,953评论 1赞 278
  • 港岛之恋（遗憾婚礼）
    正文 为了忘掉前任，我火速办了婚礼，结果婚礼上，老公的妹妹穿的比我还像新娘。我一直安慰自己，他们只是感情好，可当我...
    茶点故事阅读 63,971评论 5赞 369
  • 恶毒庶女顶嫁案：这布局不是一般人想出来的
    文/花漫 我一把揭开白布。 她就那样静静地躺着，像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上，一...
    开封第一讲书人阅读 48,784评论 1赞 283
  • 城市分裂传说
    那天，我揣着相机与录音，去河边找鬼。 笑死，一个胖子当着我的面吹牛，可吹牛的内容都是我干的。 我是一名探鬼主播，决...
    沈念sama阅读 38,126评论 3赞 399
  • 双鸳鸯连环套：你想象不到人心有多黑
    文/苍兰香墨 我猛地睁开眼，长吁一口气：“原来是场噩梦啊……” “哼！你这毒妇竟也来了？” 一声冷哼从身侧响起，我...
    开封第一讲书人阅读 36,765评论 0赞 258
  • 万荣杀人案实录
    序言：老挝万荣一对情侣失踪，失踪者是张志新（化名）和其女友刘颖，没想到半个月后，有当地人在树林里发现了一具尸体，经...
    沈念sama阅读 43,148评论 1赞 300
  • 护林员之死
    正文 独居荒郊野岭守林人离奇死亡，尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 35,744评论 2赞 323
  • 白月光启示录
    正文 我和宋清朗相恋三年，在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 37,858评论 1赞 333
  • 活死人
    序言：一个原本活蹦乱跳的男人离奇死亡，死状恐怖，灵堂内的尸体忽然破棺而出，到底是诈尸还是另有隐情，我是刑警宁泽，带...
    沈念sama阅读 33,479评论 4赞 322
  • 日本核电站爆炸内幕
    正文 年R本政府宣布，位于F岛的核电站，受9级特大地震影响，放射性物质发生泄漏。R本人自食恶果不足惜，却给世界环境...
    茶点故事阅读 39,080评论 3赞 307
  • 男人毒药：我在死后第九天来索命
    文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹，春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 30,053评论 0赞 19
  • 一桩弑父案，背后竟有这般阴谋
    文/苍兰香墨 我抬头看了看天上的太阳。三九已至，却和暖如春，着一层夹袄步出监牢的瞬间，已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 31,278评论 1赞 260
  • 情欲美人皮
    我被黑心中介骗来泰国打工， 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留，地道东北人。 一个月前我还...
    沈念sama阅读 45,245评论 2赞 352
  • 代替公主和亲
    正文 我出身青楼，却偏偏与公主长得像，于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子，可洞房花烛夜当晚...
    茶点故事阅读 42,590评论 2赞 343

推荐阅读更多精彩内容