RTSP协议

1.RTP协议
RTP 数据协议负责对流媒体数据进行封包并实现媒体流的实时传输，每一个 RTP 数据 报都由头部（ Header）和负载（Payload）两个部分组成，其中头部前 12 个字节的含 义是固定的，而负载则可以是音频或者视频数据。 RTP 数据报的头部格式如图 1 示：

其中比较重要的几个域及其意义如下：
1、Version（V）: RFC 1889 Version(2)
2、Padding 填充标志（ P）：False
3、Extension 扩展标志（ X）：False
4、CSRC(Contributing source identifiers count) 记数（ CC）: 表示 CSRC 标识的数目。 CSRC 标识紧跟在 RTP 固定头 部之后，用来表示 RTP 数据报的来源， RTP 协议允许在同一个会话中存在多个数据源，它们可以通过 RTP 混合器 合并为一个数据源。 例如，可以产生一个 CSRC 列表来表示一个电话会议， 该会议通过一个 RTP 混合器将所有讲话 者的语音数据组合为一个 RTP 数据源。
5、M：标志位。标志位的具体解释可由具体协议规定。如可用于帧边界标志。
6、负载类型 (Payload type)（PT）：标明 RTP 负载的格式，包括所采用的编码算法、采样频率、承载通道等。例如， 类型 2 表明该 RTP 数据包中承载的是用 ITU G.721 算法编码的语音数据，采样频率为 8000Hz，并且采用单声道。 对于 H.264 来说，该值为 105。
7、序列号 (sequence number)：用来为接收方提供探测数据丢失的方法，但如何处理丢失的数据则是应用程序自己的 事情， RTP 协议本身并不负责数据的重传。序列号用于对 RTP 包进行计数。每发送一个 RTP 包，序列号加 1。序列 号的初始值可以置为零，也可用随机数开始。为了更加安全，应从一个随机初始化值开始。
8、时间戳 (Timestamp)：记录了负载中第一个字节的采样时间，时间戳的增量为采样频率 /帧率。接收方根据时间戳 能够确定数据的到达是否受到了延迟抖动的影响，但具体如何来补偿延迟抖动则是应用程序自己的事情。按 RFC3984 规定，采用 90000HZ 的时钟，所以如果帧率为 15，则时间戳增量为 6000。RTP 规定一次会话的初始时间 戳必须随机选择，但协议没有规定时间戳的单位。

 

由上图可知，如果只有系列号，并不能完整按照顺序的将 data 播放出来，因为如果 data 中间有一段是没有资 料的，只有系列号的话会造成错误，需搭配上让它知道在哪个时间将 data 正确播放出来，如此我们才能播放出正 确无误的信息。
9、SSRC：同步源识别符。若只使用下个同步源，则 SSRC 应该一样
10、CSRC：可无

 一。上面介绍的都是RTP head信息，接下来介绍RTP的Payload信息：
       h264rtp打包载荷结构有三种：单一NAL单元模式、组合封包模式、分片封包模式。
      1、单一NAL单元模式
              即一个RTP包仅由一个完整的NALU组成。这种情况下RTP NAL头类型字段和原始的H.264的NALU头类型字段是一样的。对于NALU的长度小于MTU大小的包，一般采用单一NAL单元模式。对于一个原始的H.264NALU单元常由[StartCode][NALUHeader][NALUPayload]三部分组成，其中StartCode用于标示这是一个NALU单元的开始，必须是"00 00 00 01"或"00 00 01"，NALU头仅一个字节，其后都是NALU单元内容。打包时去除"00 00 01"或"00 00 00 01"的开始码，把其他数据封包的RTP包即可。
                                        

PPS、SPS等NAL，每个NAL都单独打包一个RTP报文，很明显这种打包方式比较浪费带宽。

       2、组合封包模式
             由多个NAL单元组成一个RTP包。组合打包又分STAP(Single-time aggregation packet)、MTAP（Multi-time aggregation packet）两种。      
                   

       STAP
            单时间聚合包，聚合具有相同NALU时间的NAL单元。定义两种STAPs类型，一个没有DON(STAP-A)，另一个包含DON(STAP-B)。
        MTAP
            多时间聚合包，聚合具有潜在不同NALU时间的NAL单元。定义了两个不同的MTAPs，其NAL单元的时间戳偏移的长度不同。

3、分片封包模式。
用于把一个NALU单元封装成多个RTP包。存在两种类型FU-A和FU-B。类型值分别是28和29。而当NALU的长度超过MTU时，就必须对NALU单元进行分片封包。也称为Fragmentation Units(FUs)。将NALU拆分成小于MTU的数据包进行发送。
                     

                       

FU indicator定义:
         F:1个比特.
              forbidden_zero_bit. 在 H.264 规范中规定了这一位必须为 0.
         NRI:2个比特.
              nal_ref_idc. 取00~11,似乎指示这个NALU的重要性,如00的NALU解码器可以丢弃它而不影响图像的回放,0～3，取值越大，表示当前NAL越重要，需要优先受到保护。如果当前NAL是属于参考帧的片，或是序列参数集，或是图像参数集这些重要的单位时，本句法元素必需大于0。
          Type:5个比特
               nal_unit_type. 这个NALU单元的类型,1～12由H.264使用，24～31由H.264以外的应用使用,简述如下:
               0     没有定义
               1-23  NAL单元  单个 NAL 单元包
               1     不分区，非IDR图像的片
               2     片分区A
               3     片分区B
               4     片分区C
               5     IDR图像中的片
               6     补充增强信息单元（SEI）
               7     SPS
               8     PPS
               9     序列结束
               10    序列结束
               11    码流借宿
               12    填充
               13-23 保留

                24    STAP-A   单一时间的组合包
                25    STAP-B   单一时间的组合包
                26    MTAP16   多个时间的组合包
                27    MTAP24   多个时间的组合包
                28    FU-A     分片的单元
                29    FU-B     分片的单元
                30-31 没有定义

        FU header定义:
             S：1 位
                 当被设置为 1 时，Start 位表示被分片 NAL 单元的开始。当后面的 FU 载荷不是被分片 NAL 单元载荷的开始时，Start 位被设置为 0。
             E：1 位
                  当被设置为 1 时，End 位表示被分片 NAL 单元的结束，比如，载荷的最后一个字节也是被分片的 NAL 单元的最后一个字节。当后面的 FU 载荷不是被分片的 NAL 单元的最后一个片段时，End 位被设置为0。
             R：1 位
                   Reserved 位必须等于 0，且接收者必须忽略它。
             Type：5 位
                   NAL 单元载荷类型，如 ITU-T Recommendation H.264 的表 7-1 所定义的那样。
 

       从 RTP 数据报的格式不难看出，它包含了传输媒体的类型、格式、序列号、时间戳以及是否有附加数据等信 息，这些都为实时的流媒体传输提供了相应的基础。 RTP 本身并没有提供按时发送机制或其它服务质量（ QoS） 保证，它依赖于低层服务去实现这一过程。 RTP 协议 的目的是提供实时数据（如交互式的音频和视频）的端到端 传输服务， 因此在 RTP 中没有连接的概念， 它可以建立在底层的面向连接或面向非连接的传输协议之上； RTP 也不 依赖于特别的网络地址格式，而仅仅只需要底层传输协议支持组帧（ Framing）和分段（ Segmentation）就足够了； 另外 RTP 本身还不提供任何可靠性机制，这些都要由传输协议或者应用程序自己来保证。在典型的应用场合下， RTP 一般是在传输协议之上作为应用程序的一部分加以实现的，如图 2 所示：

 

RTP 是目前解决流媒体实时传输问题的最好办法，要在 Linux 平台上进行实时传送编程，可以考虑使用一些开 放源代码的 RTP 库，如 LIBRTP 、JRTPLIB 等。 JRTPLIB 是一个面向对象的 RTP 库，它完全遵循 RFC 1889 设计， 在很多场合下是一个非常不错的选择。 JRTPLIB 是一个用 C++ 语言实现的 RTP 库，这个库使用 socket 机制实现网 络通讯 因此可以运行在 Windows 、Linux 、FreeBSD、Solaris、Unix 和 VxWorks 等多种操作系统上。
         对于每一个NALU，根据其包含的数据量的不同，其大小也有差异。在IP网络中，当要传输的IP 报文大小超过最大传输单元MTU（Maximum Transmission Unit ）时就会产生IP分片情况。在以太网环境中可传输的最大 IP 报文（MTU）的大小为 1500 字节。如果发送的IP数据包大于MTU，数据包就会被拆开来传送，这样就会产生很多数据包碎片，增加丢包率，降低网络速度。对于视频传输而言，若RTP 包大于MTU 而由底层协议任意拆包，可能会导致接收端播放器的延时播放甚至无法正常播放。因此对于大于MTU 的NALU 单元，必须进行拆包处理。
RFC3984 给出了3 中不同的RTP 打包方案：
   (1)Single NALU Packet:在一个RTP 包中只封装一个NALU，在本文中对于小于 1400字节的NALU 便采用这种打包方案。
   (2)Aggregation Packet:在一个RTP 包中封装多个NALU，对于较小的NALU 可以采用这种打包方案，从而提高传输效率。 
  (3)Fragmentation Unit:一个NALU 封装在多个RTP包中，在本文中，对于大于1400字节的NALU 便采用这种方案进行拆包处理。

二、RTCP
RTCP 控制协议需要与 RTP 数据协议一起配合使用，当应用程序启动一个 RTP 会话时将同时占用两个端口， 分别供 RTP 和 RTCP 使用。RTP 本身并不能为按序传输数据包提供可靠的保证， 也不提供流量控制和拥塞控制， 这 些都由 RTCP 来负责完成。 RTCP 的一个关键作用就是能让接收方同步多个 RTP流，比如音频和视频流。 通常 RTCP 会采用与 RTP 相同的分发机制， 向会话中的所有成员周期性地发送控制信息， 应用程序通过接收这些数据， 从中获 取会话参与者的相关资料，以及网络状况、分组丢失概率等反馈信息，从而能够对服务质量进行控制或者对网络状 况进行诊断。
RTCP 协议的功能是通过不同的 RTCP 数据报来实现的，主要有如下几种类型：
SR 发送端报告 ，所谓发送端是指发出 RTP 数据报的应用程序或者终端，发送端同时也可以是接收端。
RR 接收端报告 ，所谓接收端是指仅接收但不发送 RTP 数据报的应用程序或者终端。
SDES 源描述 ，主要功能是作为会话成员有关标识信息的载体，如用户名、邮件地址、电话号码等，此外还具有向 会话成员传达会话控制信息的功能。
BYE 通知离开 ，主要功能是指示某一个或者几个源不再有效，即通知会话中的其他成员自己将退出会话。
APP 由应用程序自己定义，解决了 RTCP 的扩展性问题，并且为协议的实现者提供了很大的灵活性。
RTCP 数据报 携带有服务质量监控的必要信息，能够对服务质量进行动态的调整，并能够对网络拥塞进行有效的控 制。由于RTCP 数据报采用的是多播方式，因此会话中的所有成员都可以通过 RTCP 数据报返回的控制信息，来了 解其他参与者的当前情况。
        在一个典型的应用场合下，发送媒体流的应用程序将周期性地产生发送端报告 SR，该 RTCP 数据报含有不同媒 体流间的同步信息，以及已经发送的数据报和字节的计数，接收端根据这些信息可以估计出实际的数据传输速率。另一方面，接收端会向所有已知的发送端发送接收端报告 RR，该 RTCP 数据报含有已接收数据报的最大序列号、 丢失的数据报数目、延时抖动和时间戳等重要信息，发送端应用根据这些信息可以估计出往返时延，并且可以根据 数据报丢失概率和时延抖动情况动态调整发送速率，以改善网络拥塞状况，或者根据网络状况平滑地调整应用程序 的服务质量。

三、RTSP协议
       RTSP(Real-Time Stream Protocol ) 作为一个应用层协议，提供了一个可供扩展的框架，它的意义在于使得实时流媒体数据的受控和点播变得可能。总的说来， RTSP是一个流媒体表示协议， 主要用来控制具有实时特性的数据发送， 但它本身并不传输数据， 而是必须依赖于下层传输协议所提供的某些服务。 RTSP可以对流媒体提供诸如播放、暂停、快进等操作，它负责定义具体的控制消息、操作方法、状态码等，此外还描述了与 RTP间的交互操作。

 

        RTSP被用于建立的控制媒体流的传输，它为多媒体服务扮演 “网络远程控制” 的角色。尽管有时可以把 RTSP控制信息和媒体数据流交织在一起传送，但一般情况 RTSP本身并不用于转送媒体流数据。媒体数据的传送可通过RTP/RTCP等协议来完成。
       一次基本的 RTSP操作过程是 : 首先，客户端连接到流服务器并发送一个 RTSP描述命令（ DESCRIBE）。流服务器通过一个 SDP描述来进行反馈，反馈信息包括流数量、媒体类型等信息。 客户端再分析该 SDP描述，并为会话中的每一个流发送一个 RTSP建立命令 (SETUP)，RTSP建立命令告诉服务器客户端用于接收媒体数据的端口。 流媒体连接建立完成后，客户端发送一个播放命令 (PLAY)，服务器就开始在 UDP上传送媒体流（ RTP包）到客户端。 在播放过程中客户端还可以向服务器发送命令来控制快进、快退和暂停等。最后，客户端可发送一个终止命令 (TERADOWN)来结束流媒体会话
3.2  RTSP 协议与 HTTP 协议区别
       RTSP在制定时较多地参考了 HTTP/1.1 协议，甚至许多描述与 HTTP/1.1 完全相同。 RTSP之所以特意使用与 HTTP/1.1 类似的语法和操作，在很大程度上是为了兼容现 有的 Web基础结构，正因如此， HTTP/1.1 的扩展机制 大都可以直接引入到 RTSP中。
1. RTSP引入了几种新的方法，比如 DESCRIBE 、PLAY、SETUP 等，并且有不同的协议标识符， RTSP为 rtsp 1.0,HTTP 为 http 1.1 ；
2. HTTP是无状态的协议，而 RTSP为每个会话保持状态；
3. RTSP协议的客户端和服务器端都可以发送 Request 请求，而在 HTTPF 协议中， 只有客户端能发送 Request 请求。
4. 在 RTSP协议中，载荷数据一般是通过带外方式来传送的 ( 除了交织的情况 )，及通过 RTP协议在不同的通 道中来传送载荷数据。而 HTTP协议的载荷数据都是通过带内方式传送的，比如请求的网页数据是在回应 的消息体中携带的。
5. 使用 ISO 10646(UTF-8) 而不是 ISO 8859-1 ，以配合当前 HTML的国际化；
6. RTSP使用 URI 请求时包含绝对 URI。而由于历史原因造成的向后兼容性问题， HTTP/1.1 只在请求中包含绝 对路径，把主机名放入单独的标题域中；
3.3 RTSP 重要术语
1、集合控制 (Aggregate control ):  对多个流的同时控制。对音频 /视频来讲，客户端仅需发送一条播放或者暂停消息就可同时控制音频流和视频 流。
2、实体 (Entity) ： 作为请求或者回应的有效负荷传输的信息。由以实体标题域（ entity-header field ）形式存在的元信息和以 实体主体（ entity body ）形式存在的内容组成
3、容器文件（ Container file ）： 可以容纳多个媒体流的文件。 RTSP服务器可以为这些容器文件提供集合控制。
4、RTSP会话 (RTSP session ) ： RTSP交互的全过程。对一个电影的观看过程 , 会话 (session) 包括由客户端建立媒体流传输机制 (SETUP)，使用 播放 (PLAY)或录制 (RECORD)开始传送流，用停止 (TEARDOWN)关闭流

3.4  RTSP请求消息
1. 消息格式：
     方法 URI RTSP 版本    CR LF
     消息头 CR LF         CR LF          
     消息体 CR LF
其中方法包括 OPIONS 、DESCRIBE 、SETUP、PLAY、TEARDOWN 等,URI 是接受方的地址 , 如:rtsp://192.168.0.1/video1.3gp 。 RTSP版本一般都是 RTSP/1.0 。每行后面的 CR LF 表示回车换行，需要接受端有相应的解析，最后一个消息头 需要有两个 CR LF 消息体是可选的，有的 Request 消息并不带消息体。 

3.5 RTSP回应消息
1. 消息格式：
        RTSP版本 状态码 解释 CR LF
        消息头 CR LF          CR LF
        消息体 CR LF
       其中 RTSP版本一般都是 RTSP/1.0, 状态码是一个数值， 用于表示 Request 消息的执行结果 , 比如 200 表示成功 , 解释是与状态码对应的文本解释 . 

3.6  RTSP重要方法
1. OPTIONS: 用于得到服务器提供的可用方法；
OPTIONS rtsp://192.168.20.136:5000/xxx666 RTSP/1.0
CSeq: 1 //每个消息都有序号来标记，第一个包通常是 option 请求消息
服务器的回应信息会在 Public 字段列出提供的方法。如 : 
RTSP/1.0 200 OK
CSeq: 1 //每个回应消息的 cseq数值和请求消息的 cseq相对应
Public: OPTIONS, DESCRIBE, SETUP, TEARDOWN, PLAY, PAUSE
2. DESCRIBE ： 客户端向服务器端发送 DESCRIBE ，用于得到 URI 所指定的媒体描述信息， 一般是 SDP信息。客户端通过 Accept
头指定客户端可以接受的媒体述信息类型。
   C->S:  
        DESCRIBE rtsp://server.example.com/fizzle/foo RTSP/1.0 
        CSeq: 312
        Accept: application/sdp, application/rtsl, application/mheg) 
服务器回应 URI 指定媒体的描述信息 : 如: 
   S->C: RTSP/1.0 200 OK CSeq: 312 
        Date: 23 Jan 1997 15:35:06 GMT
        Content-Type: application/sdp  // 表示回应为 SDP信息
        Content-Length: 376
        // 这里为一个空行
       // 以下为具体的 SDP信息
        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 
        媒体初始化是任何基于 RTSP系统的必要条件，但 RTSP规范并没有规定它必须通过 DESCRIBE方法完成。 RTSP 客户端可以通过以下方法来接收媒体描述信息： a) 通过 DESCRIBE方法； b) 其它一些协议（ HTTP，email 附件，等）； c) 通过命令行或标准输入设备 
3. SETUP ： 用于确定转输机制，建立 RTSP会话。客户端能够发出一个 SETUP请求为正在播放的媒体流改变传输参数，服
务器可能同意这些参数的改变。若是不同意，它必须响应错误 "455 Method Not Valid In This State" 。Request 中的 Transport 头字段指定了客户端可接受的数据传输参数； Response 中的 Transport 头字段包含了由服务器选出的传输参数。
如: 
      C->S:
            SETUP rtsp://example.com/foo/bar/baz.rm RTSP/1.0 
            CSeq: 302
            Transport: RTP/AVP;unicast;client_port=4588-4589 
服务器端对 SETUP Request产生一个 Session Identifiers 。如 : 
     S->C:
             RTSP/1.0 200 OK CSeq: 302 
             Date: 23 Jan 1997 15:35:06 GMT
             Session: 47112344  // 产生一个 Session ID 
             Transport: RTP/AVP;unicast;
             client_port=4588-4589;server_port=6256-6257 
4. PLAY ： 
       PLAY方法告知服务器通过 SETUP中指定的机制开始发送数据 。在尚未收到 SETUP请求的成功应答之前，客户端不可以发出 PLAY请求。PLAY请求将正常播放时间 （normal play time ）定位到指定范围的起始处， 并且传输数据流直到播放范围结束。
PLAY请求可能被管道化（ pipelined ），即放入队列中（ queued）；服务器必须将 PLAY请求放到队列中有序执行。也就是说，后一个 PLAY请求需要等待前一个 PLAY请求完成才能得到执行。比如，在下例中，不管到达的两个 PLAY请求之间有多紧凑，服务器首先 play 第 10 到 15 秒，然后立即第 20到 25 秒，最后是第 30 秒直到结束。
        C->S:
               PLAY rtsp://audio.example.com/audio RTSP/1.0 
               CSeq: 835
               Session: 12345678
               Range: npt=10-15   //设置播放时间的范围
      C->S:
              PLAY rtsp://audio.example.com/audio RTSP/1.0
              CSeq: 836
              Session: 12345678 
              Range: npt=20-25 
      C->S:
              PLAY rtsp://audio.example.com/audio RTSP/1.0 
              CSeq: 837
              Session: 12345678
              Range: npt=30- 
Range头可能包含一个时间参数。 该参数以 UTC格式指定了播放开始的时间。 如果在这个指定时间后收到消息，那么播放立即开始。时间参数可能用来帮助同步从不同数据源获取的数据流。不含 Range头的 PLAY请求也是合法的。 它从媒体流开头开始播放， 直到媒体流被暂停。 如果媒体流通过 PAUSE暂停，媒体流传输将在暂停点（ the pause point ）重新开始。如果媒体流正在播放，那么这样一个 PLAY请求将不起更多的作用，只是客户端可以用此来测试服务器是否存活。
5. PAUSE：
       PAUSE请求引起媒体流传输的暂时中断。如果请求 URL中指定了具体的媒体流，那么只有该媒体流的播放和记录被暂停（ halt ）。比如，指定暂停音频，播放将会无声。如果请求 URL指定了一组流，那么在该组中的所有流的传输将被暂停。如：
       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 
       PAUSE请求中可能包含一个 Range 头用来指定何时媒体流暂停，我们称这个时刻为暂停点（ pause point ）。该头必须包含一个精确的值，而不是一个时间范围。媒体流的正常播放时间设置成暂停点。当服务器遇到在任何当前挂起（ pending ）的 PLAY请求中指定的时间点后，暂停请求生效。如果 Range头指定了一个时间超出了任何一个当前挂起的 PLAY请求，将返回错误 "457 Invalid Range" 。如果一个媒体单元（比如一个音频或视频禎）正好在一个暂停点开始，那么表示将不会被播放或记录。如果 Range头缺失，那么在收到暂停消息后媒体流传输立即中断，并且暂停点设置成当前正常播放时间。
6. TEARDOWN ：
     TEARDOWN请求终止了给定 URI 的媒体流传输，并释放了与该媒体流相关的资源。如：
         C->S:
             TEARDOWN rtsp://example.com/fizzle/foo RTSP/1.0
             CSeq: 892
             Session: 12345678 
         S->C:
             RTSP/1.0 200 OK
             CSeq: 892
3.7    RTSP 重要头字段参数
      1. Accept: 用于指定客户端可以接受的媒体描述信息类型。比如 : 
              Accept: application/rtsl, application/sdp;level=2 
      2. Bandwidth: 用于描述客户端可用的带宽值。
      3. CSeq： 指定了 RTSP请求回应对的序列号，在每个请求或回应中都必须包括这个头字段。对每个包含一个给定序列号
的请求消息，都会有一个相同序列号的回应消息。
      4. Rang： 用于指定一个时间范围，可以使用 SMPTE 、NTP或 clock 时间单元。
      5. Session:Session 头字段标识了一个 RTSP会话。 Session ID 是由服务器在 SETUP的回应中选择的，客户端一当得到
Session ID 后，在以后的对 Session 的操作请求消息中都要包含 Session ID. 
      6. Transport:Transport 头字段包含客户端可以接受的转输选项列表，包括传输协议，地址端口， TTL 等。服务器端也通过
这个头字段返回实际选择的具体选项。如 : 
              Transport: RTP/AVP;multicast;ttl=127;mode="PLAY",
              RTP/AVP;unicast;client_port=3456-3457;mode="PLAY"