WebRTC RTP

一、简介

实时传输协议（RTP）为数据提供了具有实时特征的端对端传送服务，如在组播或单播网络服务下的交互式视频音频或模拟数据。应用程序通常在 UDP 上运行 RTP 以便使用其多路结点和校验服务；这两种协议都提供了传输层协议的功能。但是 RTP 可以与其它适合的底层网络或传输协议一起使用。如果底层网络提供组播方式，那么 RTP 可以使用该组播表传输数据到多个目的地。

RTP 本身并没有提供按时发送机制或其它服务质量（QoS）保证，它依赖于底层服务去实现这一过程。 RTP 并不保证传送或防止无序传送，也不确定底层网络的可靠性。 RTP 实行有序传送， RTP 中的序列号允许接收方重组发送方的包序列，同时序列号也能用于决定适当的包位置，例如：在视频解码中，就不需要顺序解码。

二、RTP头格式

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |V=2|P|X|  CC   |M|     PT      |       sequence number         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           timestamp                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           synchronization source (SSRC) identifier            |
   +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
   |            contributing source (CSRC) identifiers             |
   |                             ....                              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

各个字段说明：

• 版本(V): 2bit，此域定义了RTP的版本。此协议定义的版本是2.（值1被RTP草案版本使用，值0用在最初"vat"语音工具使用的协议中）；
• 填充为(P): 1bit，如果该位置位，则该RTP包的尾部就包含附件的填充字节；
• 扩展位(X): 1bit，如果该位置位，RTP固定头部后面就跟有一个扩展头部；
• CSRC计数器(CC): 4bit，含有固定头部后面跟着的CSRC的数目；
• 标志(M): 1bit，标志的解释由具体协议规定。它用来允许在比特流中标记重要的事件，如帧边界；
• 负载类型(PT): 7bit，标识了RTP传输的负载类型；
• 序列号(sequence number): 16bit，每发送一个RTP数据包，序列号加1，接收端可以依次检测丢包和重建包序列。序列号的初始值是随机的。
• 时间戳(timestamp): 32bit，记录了该包中数据的第一个字节的采样时刻。在一次会话开始时，时间戳初始化成为一个初始值。即使在没有信号发送时，时间戳的数值也要随着时间而不断的增加。时间戳是去抖动和实现同步不可缺少的数据。
• 同步源标识符(SSRC): 32bit，同步源是指RTP包的来源。在同一个RTP会话中不能有两个相同的SSRC值。该标识符是随机选取的，RFC1889推荐了MD5随机算法。
• 贡献源列表(CSRC List): 0~15项，每项32bit，用来标志对一个RTP混合器产生的新包有贡献的所有RTP包的源。由混合器将这些有贡献的SSRC标识符插入表中。SSRC标识符都被列出来，以便接收端能正确指出交谈双方的身份。

三、RTP H264负载

官方文档：RFC 3984: RTP Payload Format for H.264 Video

RTP Payload有很多形式，可以传输编码的数据如视频H264、H265、音频G711、OPUS等数据，也可以传输封装好的数据，如GB28181中常用的PS流等。

H264 Payload定义了三种不同的基本的负载结构，接收端可能通过RTP Payload的第一个字节来识别它们。这一个字节类似 NALU 头的格式，如下：

      +---------------+
      |0|1|2|3|4|5|6|7|
      +-+-+-+-+-+-+-+-+
      |F|NRI|  Type   |
      +---------------+

• F：在规范中规定了这一位必须为0.
• NRI：取00~11，表示这个NALU的重要性，如00的NALU解码器可以丢弃它而不影响图像的回放. 
• Type：这个NALU单元的类型，具体如下：

Type	Packet	Description
1-23	NAL unit	单一NAL单元
24	STAP-A	单一时间的组合包模式A
25	STAP-B	单一时间的组合包模式B
26	MTAP16	多个时间的组合包模式A
27	MTAP24	多个时间的组合包模式B
28	FU-A	分片的单元模式A
29	FU-B	分片的单元模式B

1、单一NAL单元

   0                   1                   2                   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |F|NRI|  type   |                                               |
  +-+-+-+-+-+-+-+-+                                               |
  |                                                               |
  |               Bytes 2..n of a Single NAL unit                 |
  |                                                               |
  |                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                               :...OPTIONAL RTP padding        |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

对于H264 NALU的长度小于MTU的包, 一般采用单一NAL单元模式。打包时去除"00 00 01" 或 "00 00 00 01"的H264 NALU开始码, 把其他数据封装到RTP负载即可。

2、组合包

   0                   1                   2                   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                          RTP Header                           |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |STAP-A NAL HDR |         NALU 1 Size           | NALU 1 HDR    |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                         NALU 1 Data                           |
  :                                                               :
  +               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |               | NALU 2 Size                   | NALU 2 HDR    |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                         NALU 2 Data                           |
  :                                                               :
  |                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                               :...OPTIONAL RTP padding        |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

当 NALU 的长度特别小时, 可以把几个 NALU 单元封在一个 RTP 包中。比如H264的SPS和PPS数据，每个数据包前面带2bit的长度。

3、分片包

   0                   1                   2                   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  | FU indicator  |   FU header   |                               |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               |
  |                                                               |
  |                         FU payload                            |
  |                                                               |
  |                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                               :...OPTIONAL RTP padding        |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

当 NALU 的长度超过 MTU 时, 就必须对 NALU 单元进行分片封包了，比如H264的I帧。

3.1、FU indicator

  +---------------+
  |0|1|2|3|4|5|6|7|
  +-+-+-+-+-+-+-+-+
  |F|NRI|  Type   |
  +---------------+

• F：值为 0 表示 NAL 单元类型八位字节和有效负载不应包含位错误或其他语法违规行为。值为 1 表示 NAL 单元类型八位字节和有效载荷可能包含位错误或其他语法违规。
• NRI：与 H.264 规范保持不变
• Type：FU-A(28)或FU-B(29)

3.2、FU header

  +---------------+
  |0|1|2|3|4|5|6|7|
  +-+-+-+-+-+-+-+-+
  |S|E|R|  Type   |
  +---------------+

• S：起始位，当RTP包的有效负载是第一个NAL单元分片时，该位为1，否则为0；
• E：结束位，当RTP包的有效负载是最后一个NAL单元分片时，该位为1，否则为0；
• R：保留位必须等于 0
• Type：值为H264 NALU Header中的Type。