流媒体-RTP-RTCP协议解析-RTSP流的传输与控制（二）

缺乏、安全感 2023-01-10 10:20 304阅读 0赞

1.  [流媒体-RTSP协议-live555学习-打开RTSP流（一）][-RTSP_-live555_-_RTSP]
2.  [流媒体-RTP-RTCP协议解析-RTSP流的传输与控制（二）][-RTP-RTCP_-RTSP]

### 文章目录 ###

*   *  RTP(real-time transport protocol),实时传输协议
     *   *  相关概念
         *   *  同步源(SSRC,Synchronization source)
             *  作用源(CSRC,Contributing source )
             *  混频器和转换器(Mixers and Translators)
         *  RTP 包解析
         *   *  RTP 包头格式
             *  RTP 头扩展
     *  RTCP（RTP 控制协议）
     *   *  RTCP包类型
         *   *  SR（Sender Report）
             *   *  第一部分：头部（8字节）
                 *  第二部分：发送者信息（20 字节）
                 *  第三部分：零到多个接收报告块
             *  RR（Receiver Report）
             *  SDES（Source Description Items）
             *  BYBE
             *  APP

## RTP(real-time transport protocol),实时传输协议 ##

### 相关概念 ###

RTP 在多点传送(多播)或单点传送(单播)的网络服务上,提供端对端的网络传输功能,适合应用程序传输实时数据,如:音频,视频或者仿真数据。RTP没有为实时服务提供资源预留的功能,也不能保证QoS(服务质量)。数据传输功能由一个控制协议(RTCP)来扩展,通过扩展,可以用一种方式对数据传输进行监测控制,该协议(RTCP)可以升级到大型的多点传送(多播)网络,并提供最小限度的控制和鉴别功能。RTP 和 RTCP 被设计成和下面的传输层和网络层无关。协议支持 RTP 标  
准的转换器和混合器的使用。

#### 同步源(SSRC,Synchronization source) ####

RTP 包流的源,用 RTP 报头中 32 位数值的  
SSRC 标识符进行标识,使其不依赖于网络地址。一个同步源的所有包构成了相同计时和序列号  
空间的一部分,这样接收方就可以把一个同步源的包放在一起,来进行重放。举些同步源的例子,  
像来自同一信号源的包流的发送方,如麦克风、摄影机、RTP 混频器(见下文)就是同步源。  
一个同步源可能随着时间变化而改变其数据格式,如音频编码。 SSRC 标识符是一个随机选取的  
值,它在特定的 RTP 会话中是全局唯一(globally unique)的(见章节 8)。参与者并不需要  
在一个多媒体会议的所有 RTP 会话中,使用相同的 SSRC 标识符;SSRC 标识符的绑定通过  
RTCP(见章节 6.5.1)。如果参与者在一个 RTP 会话中生成了多个流,例如来自多个摄影机,  
则每个摄影机都必须标识成单独的同步源。

#### 作用源(CSRC,Contributing source ) ####

若一个 RTP 包流的源,对由 RTP 混频器生成  
的组合流起了作用,则它就是一个作用源。对特定包的生成起作用的源,其 SSRC 标识符组成的列表,被混频器插入到包的 RTP 报头中。这个列表叫做 CSRC 表。相关应用的例子如,在音  
频会议中,混频器向所有的说话人(talker)指出,谁的话语(speech)将被组合到即将发出的  
包中,即便所有的包都包含在同一个(混频器的)SSRC 标识符中,也可让听者(接收者)可以  
清楚谁是当前说话人。

#### 混频器和转换器(Mixers and Translators) ####

混频器(Mixer)：一种中间系统,它从一个或多个源中接收 RTP 包,可能改变其数据格式,  
再按某种方式把这些包组合成一个新的包,然后转发出去。由于多个输入源的计时一般不会同步,  
所以混频器会对各个流的计时作出调整,并为组合流生成一个新的计时。因此,混频器将被标识  
成它所产生所有数据包的同步源。

转换器(Translator)：一种中间系统,它转发 RTP 包而不改变各包的同步源标识符。转  
换器的例子如下:不作混频地转变编码的设备,把多播复制到单播的重复装置,以及防火墙里应  
用层次的过滤器。

考虑一下这种情况,一个地方的参与者只能低速接入会议,而其他大部分参与者都能享受高速连接。与其让强迫大家都忍受低带宽,不如在只能低速接入的地方,放置一个减质量音频编码的RTP层次的中继(称作混频器)。混频器将重新同步输入的音频包,重建发送方产生的20ms固定间隔,混频已重建过的音频流为单一的流,转换音频编码为低带宽格式,最后通过低带宽连接转发数据包流(package stream)。这些包可能被单播到一个接收方,也可能多播到另一个的地  
址而发给多个接收方。RTP 报头为混频器提供了一种方法,使其能辨识出对混频后的包有用的  
源,从而保证提供给接收方正确的说话者指示。

在音频会议中,一些预定参与者尽管有高带宽连接,但不能通过IP多播直接接入会议。例如,他们可能位于一个不允许任何 IP 包通过的应用层防火墙后面。对这些站点,可能就不需要混频,而需要另一种称为转换器的RTP层次中继。可以在防火墙两侧分别安装一个转换器,外侧转换器将所有多播包通过安全连接转入内侧转换器,  
内侧转换器再转发给内部网的一个多播组(multicast group)。

混频器和转换器可以设计成用于各种目的。比如,一个视频混频器在测量多个不同视频流中各人的单独影像后,将它们组合成一个单一视频流来模拟群组场景。又如,在只用 IP/UDP和只用ST\_II的两个主机群之间通过转换建立连接。再如,在没有重新同步或混频时,用packet-by-packet 编码转换来自各个独立源的视频流。

### 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            |
    |                             ....                              |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

前 12 个字节出现在每个 RTP 包中,仅仅在被混合器插入时,才出现 CSRC 识别符列表。这些域有以下意义:

<table> 
 <thead> 
  <tr> 
   <th>类型</th> 
   <th>长度（位）</th> 
   <th>描述</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td>版本(V)</td> 
   <td>2 比特</td> 
   <td>此域定义了 RTP 的版本。此协议定义的版本是 2。(值 1 被 RTP 草案版本使用,值 0 用在最初"vat"语音工具使用的协议中。)</td> 
  </tr> 
  <tr> 
   <td>填充§</td> 
   <td>1 比特</td> 
   <td>若填料比特被设置,则此包包含一到多个附加在末端的填充比特,填充比特不算作负载的一部分。填充的最后一个字节指明可以忽略多少个填充比特。填充可能用于某些具有固定长度的加密算法,或者用于在底层数据单元中传输多个 RTP 包。</td> 
  </tr> 
  <tr> 
   <td>扩展(X)</td> 
   <td>1 比特</td> 
   <td>若设置扩展比特,固定头(仅)后面跟随一个头扩展。</td> 
  </tr> 
  <tr> 
   <td>CSRC 计数(CC)</td> 
   <td>4 比特</td> 
   <td>CSRC 计数包含了跟在固定头后面 CSRC 识别符的数目。</td> 
  </tr> 
  <tr> 
   <td>标志(M)</td> 
   <td>1 比特</td> 
   <td>标志的解释由具体协议规定。它用来允许在比特流中标记重要的事件,如帧边界。</td> 
  </tr> 
  <tr> 
   <td>负载类型(PT)</td> 
   <td>7 比特</td> 
   <td>此域定义了负载的格式,由具体应用决定其解释。协议可以规定负载类型码和负载格式之间一个默认的匹配。其他的负载类型码可以通过非 RTP 方法动态定义。 RTP发送端在任意给定时间发出一个单独的 RTP 负载类型;此域不用来复用不同的媒体流。</td> 
  </tr> 
  <tr> 
   <td>序列号(sequence number)</td> 
   <td>16 比特</td> 
   <td>每发送一个 RTP 数据包,序列号加 1,接收端可以据此检测丢包和重建包序列。序列号的初始值是随机的(不可预测),以使即便在源本身不加密时(有时包要通过翻译器,它会这样做),对加密算法泛知的普通文本攻击也会更加困难。</td> 
  </tr> 
  <tr> 
   <td>时间戳(timestamp)</td> 
   <td>32 比特</td> 
   <td>时间戳反映了 RTP 数据包中第一个字节的采样时间。时钟频率依赖于负载数据格式,并在描述文件(profile)中进行描述。也可以通过 RTP 方法对负载格式动态描述。</td> 
  </tr> 
  <tr> 
   <td>SSRC</td> 
   <td>32 比特</td> 
   <td>用以识别同步源。标识符被随机生成,以使在同一个 RTP 会话期中没有任何两个同步源有相同的 SSRC 识别符。尽管多个源选择同一个 SSRC 识别符的概率很低,所有RTP实现工具都必须准备检测和解决冲突。若一个源改变本身的源传输地址,必须选择新的SSRC识别符,以避免被当作一个环路源</td> 
  </tr> 
  <tr> 
   <td>CSRC 列表</td> 
   <td>0 到 15项,每项32比特</td> 
   <td>CSRC列表识别在此包中负载的所有贡献源。识别符的数目在 CC 域中给定。若有贡献源多于 15 个,仅识别 15 个。CSRC 识别符由混合器插入,并列出所有贡献源的SSRC识别符。例如语音包,混合产生新包的所有源的SSRC标识符都被列出,以在接收端处正确指示参与者</td> 
  </tr> 
 </tbody> 
</table>

#### 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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |      defined by profile       |             length            |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                         header extension                      |
    |                             ....                              |

若 RTP 头中的扩展比特位置 1,则一个长度可变的头扩展部分被加到 RTP 固定头之后，RTP固定头之后只允许有一个头扩展。为允许多个互操作实现独立生成不同的头扩展,或某种特定实现有多种不同的头扩展：

<table> 
 <thead> 
  <tr> 
   <th>类型</th> 
   <th>长度</th> 
   <th>描述</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td>识别标识符或参数</td> 
   <td>16比特</td> 
   <td>这16比特的格式由具体实现的上层协议定义。基本的RTP明并不定义任何头扩展本身。</td> 
  </tr> 
  <tr> 
   <td>长度域(length)</td> 
   <td>16比特</td> 
   <td>指示扩展项中32比特字的个数,不包括 4 个字节扩展头(因此零是有效值)。</td> 
  </tr> 
 </tbody> 
</table>

## RTCP（RTP 控制协议） ##

### RTCP包类型 ###

<table> 
 <thead> 
  <tr> 
   <th>类型</th> 
   <th>名称</th> 
   <th>描述</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td>200</td> 
   <td>SR（Sender Report）</td> 
   <td>发送者报告：描述作为活跃发送者成员的发送和接收统计数字</td> 
  </tr> 
  <tr> 
   <td>201</td> 
   <td>RR（Receiver Report）</td> 
   <td>接收者报告：描述非活跃发送者成员的接收统计数字</td> 
  </tr> 
  <tr> 
   <td>202</td> 
   <td>SDES（Source Description Items）</td> 
   <td>源描述项：其中包括规范名 CNAME</td> 
  </tr> 
  <tr> 
   <td>203</td> 
   <td>BYE</td> 
   <td>结束传输：表明参与者将结束会话</td> 
  </tr> 
  <tr> 
   <td>204</td> 
   <td>APP</td> 
   <td>应用描述功能</td> 
  </tr> 
 </tbody> 
</table>

#### SR（Sender Report） ####

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|    RC   |   PT=SR=200   |              length           |头部8字节==》版本(V)|填充(P)|接收报告块计数(RC）|包类型(PT)|长度
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                        SSRC of sender                         |SR 包发送者的同步源标识符
    +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
    |               NTP timestamp, most significant word            |发送者信息20字节==》NTP 时间戳8字节
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |               NTP timestamp, least significant word           |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                          RTP timestamp                        |RTP 时间戳
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                        sender's packet count                  |发送的报文数
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                         sender's octet count                  |发送的字节数
    +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
    |                 SSRC_1 (SSRC of first source)                 |接收报告块==》SSRC_n(同步源标识符)
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | fraction lost |       cumulative number of packets lost       |丢包率 | 累计包丢失数
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |           extended highest sequence number received           |接收到的扩展的最高序列号
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                      interarrival jitter                      |到达间隔抖动
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                           last SR (LSR)                       |上一 SR 报文
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                    delay since last SR (DLSR)                 |自上一 SR 的时间
    +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
    |                SSRC_2 (SSRC of second source)                 |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                              ...                              |
    +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
    |                   profile-specific extensions                 |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

##### 第一部分：头部（8字节） #####

<table> 
 <thead> 
  <tr> 
   <th>类型</th> 
   <th>长度</th> 
   <th>描述</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td>版本(V)</td> 
   <td>2 比特</td> 
   <td>RTP 版本识别符,在 RTCP 包内的意义与 RTP 包中的相同。此协议中定义的版本号为 2。</td> 
  </tr> 
  <tr> 
   <td>填充§</td> 
   <td>1 比特</td> 
   <td>若设置填充比特,该RTCP包在末端包含一些附加填充比特,并不是控制信息的基本部分。填充的最后一个比特统计了多少个字节必须被忽略。填充可能会用于需要固定长度块的加密算法。在复合 RTCP 包中,复合包作为一个整体加密,填料比特只能加在最后一个单个 RTCP 包的后面。</td> 
  </tr> 
  <tr> 
   <td>接收报告块计数(RC)</td> 
   <td>5 比特</td> 
   <td>该包中所含接收报告块的数目。零值有效。</td> 
  </tr> 
  <tr> 
   <td>包类型(PT)</td> 
   <td>8 比特</td> 
   <td>包含常数 200,用以识别这个为 SR 包。</td> 
  </tr> 
  <tr> 
   <td>长度</td> 
   <td>16 比特</td> 
   <td>该 RTCP 包的长度减 1。其单位是 32 比特字,包括头和任何填充字节。(偏移量 1 保证零值有效,避免了在扫描 RTCP 包长度时可能发生的无限循环,同时以 32 比特为单位避免了对以 4 为倍数的有效性检测。)</td> 
  </tr> 
  <tr> 
   <td>SSRC</td> 
   <td>32 比特</td> 
   <td>SR 包发送者的同步源标识符。</td> 
  </tr> 
 </tbody> 
</table>

##### 第二部分：发送者信息（20 字节） #####

在每个发送者报告包中出现。它概括了从此发送者发出的数据传输情况。此域有以下意义:

<table> 
 <thead> 
  <tr> 
   <th>类型</th> 
   <th>长度</th> 
   <th>描述</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td>NTP 时间戳</td> 
   <td>64 比特</td> 
   <td>网络时间戳，用于音视频同步，指示了此报告发送时的背景时钟(wallclock)时刻,它可以与从其它接收者返回的接收报告块中的时间标志结合起来,计算往返每个接收者所花的时间。接收者应让 NTP 时间戳的精度远大于其他时间戳的精度。一个系统可能没有背景时钟的概念,而只有系统指定的时钟,如系统时间(system uptime)。在这样的系统中,此时钟可以作为参考计算相对 NTP 时间戳。选择一个公用的时名是非常重要的。这样多个独立的应用都可以使用相同的时钟，一个发送者,如果不用背景时钟时间或逝去时间,可以设置此项为零。</td> 
  </tr> 
  <tr> 
   <td>RTP 时间戳</td> 
   <td>32 比特</td> 
   <td>与以上的 NTP 时间标志对应同一时刻。与数据包中的RTP时间戳具有相同的单位和偏移量。这个一致性可以用来让 NTP 时间标志已经同步的源之间进行媒体内/间同步,还可以让与媒体无关的接收者估计名义 RTP 时钟频率。注意在大多数情况下此时间戳不等于任何临近的 RTP 包中的时间戳。RTP 时间戳可以由相应的 NTP 时间戳计算得到。依据的是―RTP时间戳计数器和―在采样时通过周期性检测背景时钟时间得到的实际时两者之间的关系。</td> 
  </tr> 
  <tr> 
   <td>发送的报文数</td> 
   <td>32 比特</td> 
   <td>从开始传输到此 SR 包产生时该发送者发送的 RTP 数据包总数。若发送者改变 SSRC 识别符,该计数器重设</td> 
  </tr> 
  <tr> 
   <td>发送的字节文数</td> 
   <td>32 比特</td> 
   <td>从开始传输到此 SR 包产生时该发送者在RTP数据包发送的字节总数(不包括头和填充)。若发送者改变 SSRC 识别符,该计数器重设。此域可以用来估计平均的负载数据发送速率。</td> 
  </tr> 
 </tbody> 
</table>

在 RTCP  
SR 包中有 NTP 时间戳、RTP 时间戳,它们可以计算背景时钟和 RTP 时钟之间的对应关系,通过这个关系,可以由 RTP 数据包中的 RTP 时间戳计算也相应的回放时刻。这样就可以进行多个流的同步了。之所以要有 NTP 时间戳,是因为不同流的 RTP 时间戳有不同的随机偏移量,无法直接进行同步。

##### 第三部分：零到多个接收报告块 #####

块数等于从上一个报告以来该发送者侦听到的其它源(不  
包括自身)的数目。每个接收报告块传输从某个同步源来的数据包的接收统计信息。若数据源因  
冲突而改变其 SSRC 标识符,接收者重新设置统计信息。这些统计信息有:

<table> 
 <thead> 
  <tr> 
   <th>类型</th> 
   <th>长度</th> 
   <th>描述</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td>SSRC_n(同步源标识符)</td> 
   <td>32 比特</td> 
   <td>在此接收报告块中信息所属源的 SSRC 标识符。</td> 
  </tr> 
  <tr> 
   <td>丢包率</td> 
   <td>8 比特</td> 
   <td>自从前一 SR 包或 RR 包发送以来,从SSRC_n传来的RTP数据包的丢失比例。以定点小数的形式表示。该值定义为损失包数/期望接收的包数。若由于包重复而导致包丢失数为负值,丢包率设为零。注意在收到上一个包后,接收者无法知道以后的包是否丢失。如:若在上一个接收报告间隔内从某个源发出的所有数据包都丢失,那么将不为此数据源发送接收报告块。</td> 
  </tr> 
  <tr> 
   <td>累计包丢失数</td> 
   <td>24 比特</td> 
   <td>从开始接收到现在,从源SSRC_n发到本源的RTP数据包的丢包总数。该值定义为:期望接收的包数-实际接收的包数。接收的包括复制的或迟到的。由于迟到的包不算作损失,在发生复制时丢包数可能为负值。期望接收的包数定义为:扩展的上一接收序号(随后定义)减去最初接收序号。</td> 
  </tr> 
  <tr> 
   <td>接收到的扩展的最高序列号</td> 
   <td>32比特</td> 
   <td>低16比特包含从源SSRC_n来的最高接收序列号,高16比特用相应的序列号周期计数器扩展该序列号，防止数据值大溢出，注意在同一会议中的不同接收者,若启动时间明显不同,将产生不同的扩展项。</td> 
  </tr> 
  <tr> 
   <td>到达间隔抖动</td> 
   <td>32 比特</td> 
   <td>RTP 数据包到达时刻统计方差的估计值。测量单位同时间戳单位,用无符号整数表达。到达时间抖动定义为一对包中接收者相对发送者的时间间隔差值的平均偏差(平滑后的绝对值)。如以下等式所示,该值等于两个包相对传输时间的差值。相对传输时间是指:包的 RTP 时间戳和到达时刻接收者时钟时间的差值。</td> 
  </tr> 
  <tr> 
   <td>上一 SR 报文(LSR)</td> 
   <td>32 比特</td> 
   <td>接收到的来自源 SSRC_n 的最新 RTCP 发送者报告(SR)的 64 位 NTP 时间标志的中间 32 位。若还没有接收到 SR,该域值为零。</td> 
  </tr> 
  <tr> 
   <td>自上一 SR 的时间(DLSR)</td> 
   <td>32 比特</td> 
   <td>是从收到来自 SSRC_n 的 SR 包到发送此接收报告块之间的延时,以 1/65536 秒为单位。若还未收到来自 SSRC_n 的 SR 包,该域值为零。</td> 
  </tr> 
 </tbody> 
</table>

#### RR（Receiver Report） ####

接收者报告包(RR)与发送者报告包基本相同,除了包类型域包含常数 201 和没有发送者信息  
的 5 个字(NTP 和 RTP 时间标志和发送者包和字节计数)。余下区域与 SR 包意义相同。若没有  
发送和接收据报告,在 RTCP 复合包头部加入空的 RR 包(RC=0)。

#### SDES（Source Description Items） ####

源描述(SDES)包由一个头及 0 个或多个块组成。每个块都由块中所标识的数据源的标识  
符及其后的各个描述构成。

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|    SC   |  PT=SDES=202  |           length            |
    +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
    |                            SSRC/CSRC_1                        |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                            SDES items                         |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                             ...                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                           SSRC/CSRC_2                         |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                            SDES items                         |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                             ...                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

描述信息如：

<table> 
 <thead> 
  <tr> 
   <th>SDES items</th> 
   <th>描述</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td>CNAME</td> 
   <td>CNAME与SSRC对应，为源的唯一标识（SSRC可能会发生变化）</td> 
  </tr> 
  <tr> 
   <td>NAME</td> 
   <td>名字</td> 
  </tr> 
  <tr> 
   <td>EMAIL</td> 
   <td>邮箱</td> 
  </tr> 
  <tr> 
   <td>PHONE</td> 
   <td>电话</td> 
  </tr> 
  <tr> 
   <td>LOC</td> 
   <td>位置</td> 
  </tr> 
  <tr> 
   <td>TOOL</td> 
   <td></td> 
  </tr> 
  <tr> 
   <td>NOTE</td> 
   <td>备注</td> 
  </tr> 
  <tr> 
   <td>PRIV</td> 
   <td>私有扩展</td> 
  </tr> 
 </tbody> 
</table>

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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |     CNAME     |    length     |  user and domain name ...
    +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

#### BYBE ####

BYE 包表明一个或多个源将要离开。如果混合器收到 BYE 包,混合器应当发送这个 BYE 包,  
并保持 SSRC/CSRC 不变。如果混合器关闭,应向贡献源列表中的所有 SSRC,包括它自己的  
SSRC 发送 BYE 包。BYE 包可能会有选择的包含 8 个字节的统计字段,其后跟上几个字节的文  
本表明离开的原因。文本字符串编码格式和 SDES 中描述的相同。

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|    SC   |   PT=BYE=203  |             length            |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                          SSRC/CSRC                            |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    :                             ...                               :
    +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
    |    length     |             reason for leaving (opt)    ...
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

#### APP ####

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| subtype |   PT=APP=204  |            length             |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                              SSRC/CSRC                        |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                            name (ASCII)                       |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                   application-dependent data        ...
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

<table> 
 <thead> 
  <tr> 
   <th>类型</th> 
   <th>长度</th> 
   <th>描述</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td>子类型（subtype ）</td> 
   <td>5 比特</td> 
   <td>可以用作子类型，以允许在一个唯一名称下定义一组应用程序包</td> 
  </tr> 
  <tr> 
   <td>名称（name ）</td> 
   <td>32 比特</td> 
   <td>由定义应用程序数据包集的人员选择的名称，该数据包集相对于此应用程序可能接收的其他应用程序包。应用程序创建者可以选择使用应用程序名称，然后协调将子类型值分配给希望为应用程序定义新的数据包类型。或者，建议其他人根据他们所代表的实体选择一个名称，然后协调名称的使用在该实体内。名称被解释为四个ASCII字符的序列，其中视为不同的大小写字符。</td> 
  </tr> 
  <tr> 
   <td>应用程序相关数据</td> 
   <td>可变长度</td> 
   <td>应用程序相关数据可能出现在应用程序包中，也可能不出现。它被解释为而不是RTP本身。它必须是32位长的倍数。</td> 
  </tr> 
 </tbody> 
</table>

[-RTSP_-live555_-_RTSP]: https://blog.csdn.net/bwangk/article/details/112972065
[-RTP-RTCP_-RTSP]: https://blog.csdn.net/bwangk/article/details/113058155