RTCP协议分析

我就是我 2022-10-06 14:48 410阅读 0赞

# RTCP协议分析 #

--------------------

## 目录 ##

1.  RTCP功能
2.  RTCP报⽂格式–报⽂类型
3.  RTSP play同步
    
    1.  时间戳映射关系
    2.  媒体间同步⽅法（不同设备的同步）
4.  RTCP同步

--------------------

### 1. RTCP功能 ###

1.  Real-time Transport Control Protocol或RTP Control Protocol或简写RTCP）是实时传输协议（RTP）的⼀个姐妹协议。RTCP由RFC 3550定义（取代作废的RFC 1889）。
2.  RTP 使⽤⼀个 偶数 UDPport ；⽽RTCP 则使⽤ RTP 的下⼀个 port，也就是⼀个奇数 port。
3.  RTCP与RTP联合⼯作，RTP实施实际数据的传输，RTCP则负责将控制包送⾄参与者。其主要功能是就RTP正在提供的服务质量做出反馈。
4.  RTCP报⽂封装在UDP中进⾏传输，作⽤如下:
    
    1.  质量反馈
    2.  传输层标识（CNAME）
    3.  给参与者发送RTCP控制报⽂
    4.  最⼩会话控制消息（可选）
5.  RTCP端⼝号 = RTP端⼝号 + 1

--------------------

### 2. RTCP报⽂格式–报⽂类型 ###

1.  在RTP的规范（RFC 3550）中，⼀共定义了5种RTCP报告⽤来报告当前控制信息：

<table> 
 <thead> 
  <tr> 
   <th>Packet Type值</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）</td> 
   <td>源描述报告</td> 
  </tr> 
  <tr> 
   <td>203</td> 
   <td>BYE（Goodbye）</td> 
   <td>离开会话</td> 
  </tr> 
  <tr> 
   <td>204</td> 
   <td>APP（Application-defined）</td> 
   <td>应⽤定义</td> 
  </tr> 
 </tbody> 
</table>

1.  RTCP的5种报告：RR，SR，SDES，BYE和APP。他们使⽤共同的结构，但是在某些具体的地⽅有⼀些不同。
2.  以下是RTCP报⽂基本结构：  
    ![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MTkxMDY5NA_size_16_color_FFFFFF_t_70]
3.  其中⽐较重要的⼏个域及其意义如下：

<table> 
 <thead> 
  <tr> 
   <th>域名</th> 
   <th>⻓度（bit）</th> 
   <th>含义</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td>Version（V）</td> 
   <td>2</td> 
   <td>定义了RTP的版本，此协议定义的版本是2。</td> 
  </tr> 
  <tr> 
   <td>Padding（P）</td> 
   <td>1</td> 
   <td>如果填充位被设置为1，则⼀个或多个附加的字节会加在包头的最后，附加的最后⼀个字节放置附加的字节数。填充可能⽤于某些具有固定⻓度的加密算法，或者在底层数据单元中传输多个RTP包。</td> 
  </tr> 
  <tr> 
   <td>Item count（IC）</td> 
   <td>5</td> 
   <td>有些RTCP分组类型包含多个条⽬（item），IC⽤来计算有多少个条⽬。因为IC只有5个⽐特，所以最多31个item。如果需要的item超过31个，那么应⽤实现必须包含多个RTCP分组。如果IC为0表示空的item列表。分组如果不需要item列表，那么可以把IC字段⽤于其他⽬的。</td> 
  </tr> 
  <tr> 
   <td>Packettype（PT）</td> 
   <td>8</td> 
   <td>PT标识了分组中携带消息的类型。在RTP标准中定义了5种类型：RR，SR，SDES，BYE和APP</td> 
  </tr> 
  <tr> 
   <td>Length（M）</td> 
   <td>16</td> 
   <td>分组⻓度，以4 bytes为单位，所以意味着RTCP分组必须是4字节对⻬。该⻓度不包含32 bites固定头，也就是说length为0也是合理的，说明只有4字节的头部（这种情况IC也是0）。</td> 
  </tr> 
 </tbody> 
</table>

1.  header size = 2 + 1 + 5 +8 + 16 = 4个字节
2.  SR 包，总共28字节 = header 4字节 + 4字节\*6  
    ![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MTkxMDY5NA_size_16_color_FFFFFF_t_70 1]

typedef struct _rtcp_header_t
    {
        
    	uint32_t v:2; // version
    	uint32_t p:1; // padding
    	uint32_t rc:5; // reception report count
    	uint32_t pt:8; // packet type
    	uint32_t length:16; /* pkt len in words, w/o this word */
    } rtcp_header_t;

#### 1. RTCP报⽂格式-- SR报⽂格式 ####

1.  为了补充接收者报告，RTP协议还规定了最近发送数据的参与者发送SR，该报告提供了发送的媒体的⼀些信息。主要⽤于接收端同步多媒体流，如语⾳和视频流  
    ![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MTkxMDY5NA_size_16_color_FFFFFF_t_70 2]
2.  其中域及其意义如下：

<table> 
 <thead> 
  <tr> 
   <th>域名</th> 
   <th>⻓度（bit）</th> 
   <th>含义</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td>NTP timestamp</td> 
   <td>64</td> 
   <td>64 bites，⽆符号整数。<strong>指出了该报告发出时的时间</strong>。该时间戳的⾼32 bites以NTP格式表示，从1900年1⽉1⽇开始计数，以秒为单位。低32 bites表示秒后⾯的⼩数。如果需要转化Unix时间到NTP时间，在Unix时间加上2,208,988,800即可。</td> 
  </tr> 
  <tr> 
   <td>RTP timestamp</td> 
   <td>/</td> 
   <td>RTP时间戳以RTP媒体流的时钟为单位，这个值通常不等于前⾯分组数据的RTP时间戳，因为时间会流逝。</td> 
  </tr> 
  <tr> 
   <td>Sender’s packet count</td> 
   <td>/</td> 
   <td>表示这个同步源从这个会话开始到现在（发出RTCP报⽂时）发出的数据分组的个数。</td> 
  </tr> 
  <tr> 
   <td>Sender’s octet count</td> 
   <td>/</td> 
   <td>表示同步源从这个会话开始到现在（发出RTCP报⽂时）发出的所有数据分组的字节数。如果发送者改变了SSRC，那么sender’s packet count和sender’s octet count被会被重置。</td> 
  </tr> 
 </tbody> 
</table>

typedef struct _rtcp_sr_t // sender report
    {
        
    	uint32_t ssrc;
    	uint32_t ntpmsw; // ntp timestamp MSW(in second)
    	uint32_t ntplsw; // ntp timestamp LSW(in picosecond)
    	uint32_t rtpts; // rtp timestamp
    	uint32_t spc; // sender packet count
    	uint32_t soc; // sender octet count
    } rtcp_sr_t;

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MTkxMDY5NA_size_16_color_FFFFFF_t_70 3]

1.  如下图我们可知：
    
    1.  video时间戳是 2794373590，采样率是90000，相除得到具体时间：31048.595秒
    2.  audio时间戳是 4216229973，采样率是48000，相除得到具体时间：87838.124秒
    3.  我们发现，相隔0.1毫秒（29.790-29.789）发送出去的视频、音频包时间戳的差值特别大
    4.  rtp包打时间戳时，是有一个base\_time的，base\_time是随机，比如视频第一帧，应用层是0.04秒，换算成90khz的时基，则为3600+base\_time(起点时间)
    5.  base\_time是随机生成的  
        ![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MTkxMDY5NA_size_16_color_FFFFFF_t_70 4]
2.  既然接收端，不能直接用收到的rtp的timestamp做音视频同步，那应该怎么办？
3.  接收端需要发送端把NTP时间发送过来
4.  rtcp发送间隔的问题
    
    1.  在发送第一个rtp包前要先发一个rtcp包（推流SR）
    2.  rtcp包占用rtp包的 %0.5的字节比例，rtcp\_bytes>=28字节
    3.  上次发送rtcp包和目前时间间隔超过5秒
5.  能否不发rtcp也能做音视频同步
    
    1.  每一路rtp通道的ts的起点时间不能随机进行初始化，每个通道base\_timestamp进行换算成秒单位值要一致。

#### 2. RTCP报⽂格式-- RR报⽂格式 ####

1.  RTCP通过RR可以很好地保证传输质量，每个接收数据的参与者都要发出RR。  
    ![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MTkxMDY5NA_size_16_color_FFFFFF_t_70 5]
2.  其中PT定义为201。接收者报告包含发送者的SSRC，跟随在由RC指定的（0个或多个）报告块之后。
3.  其中域及其意义如下：

<table> 
 <thead> 
  <tr> 
   <th>域名</th> 
   <th>⻓度（bit）</th> 
   <th>含义</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td>Reportee SSRC（接收者同步源）</td> 
   <td>32</td> 
   <td>占⽤32 bites，表示这个报告反馈给谁，也就是谁适合接收这个报告。</td> 
  </tr> 
  <tr> 
   <td>Loss fraction（丢包率）</td> 
   <td>8</td> 
   <td>占⽤8 bites，定义为这个报告周期丢失的分组除以期待的分组数量。</td> 
  </tr> 
  <tr> 
   <td>Cumulative number of packets lost（丢包数量）</td> 
   <td>24</td> 
   <td>24 bites带符号整形，累计丢失的包的个数。计算⽅法是：期待接收的分组数⽬-实际接收的分组数⽬。所谓期待的分组数⽬是这样定义的：最后⼀个分组的序列号－初始化分组序列号。</td> 
  </tr> 
  <tr> 
   <td>Extended highest sequencenumber（扩展⾼位序列号）</td> 
   <td>32</td> 
   <td>占⽤32 bites，低16 bites取值为当前收到的RTP报⽂的序列号，⾼16 bites是扩展位，⽤于标识序列号周期的计数。</td> 
  </tr> 
  <tr> 
   <td>Interarrival jitter（抖动评估）</td> 
   <td>32</td> 
   <td>占⽤32 bites，数据分组传输的统计评估值，⽤于评估⽹络的抖动情况。表示⽅式和时间戳相同</td> 
  </tr> 
  <tr> 
   <td>Last sender report (LSR)</td> 
   <td>32</td> 
   <td>占⽤32 bites，等于从reportee最近接收到SR分组的64 bits NTP 格式时间戳的中间32 bites，如果没有接收到SR分组，那么LSR置0。</td> 
  </tr> 
  <tr> 
   <td>Delay since last sender report (DLSR)</td> 
   <td>32</td> 
   <td>表示接收到最近的SR到发出这个报告的时延，单位是1/65,536秒。如果没有接收到SR，DLSR置0。</td> 
  </tr> 
 </tbody> 
</table>

typedef struct _rtcp_rr_t // receiver report
    {
        
    	uint32_t ssrc;
    } rtcp_rr_t;

typedef struct _rtcp_rb_t // report block
    {
        
    	uint32_t ssrc;
    	uint32_t fraction:8; // fraction lost
    	uint32_t cumulative:24; // cumulative number of packets lost
    	uint32_t exthsn; // extended highest sequence number received
    	uint32_t jitter; // interarrival jitter
    	uint32_t lsr; // last SR
    	uint32_t dlsr; // delay since last SR
    } rtcp_rb_t;

1.  丢包率计算：表示⽅式：分⺟固定为256，分⼦是loss fraction表示的整数。所以如果想要表示1/4的报⽂丢失，那么loss fraction＝64。
2.  丢包数量计算：cumulative number of packets lost不是以每个周期为计算范围，⽽是以整个会话为计算范围。所以0x7fffff是cumulative number of packets lost的最⼤值，因为它是带符号整数。
3.  扩展⾼位序列号：随着会话时间增⻓，16⽐特⻓度的序列号可能会不够⽤，当序列号⼜回到初始化序列号时，为了表示这个环绕，在⾼16⽐特记录环绕的次数，也就是把序列号扩展了。  
    ![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MTkxMDY5NA_size_16_color_FFFFFF_t_70 6]

–

### 3. RTSP play同步 ###

1.  RTP 包中的时间戳字段是说明数据包时间的同步信息，是数据能以正确的时间顺序恢复的关键。时间戳的值给出了分组中数据的第⼀个字节的采样时间。为了计算各个数据流的播放时间以及同步处理，仅有 RTP包中的时间戳信息是不够的。
2.  在整个播放过程中，包括这样⼏种时间:
    
    1.  RTP 包中的 rtptime
    2.  PLAY 请求的 Response 中的 rtp time 和 npt

#### 1. 时间戳映射关系 ####

1.  ⾸先介绍 PLAY 请求的 Response ⾥的两个域：

##### 1. npt #####

1.  npt 顾名思义 Normal PLay Time ，正常播放时间，指出了流相对与播放开始时的绝对位置。播放开始时的之间定义为 0.0s 。这个特殊的常量 now 被定义为现场事件的当前时刻。
2.  " now "常数允许客户端请求接收实时反馈⽽不是存储或者延时的版本。因为对于这种情况⽽⾔,既没有绝对时间,也没有 0 时间,所以需要该参数。

##### 2. rtptime #####

1.  rtptime 是发送 PLAY 请求后将收到的第⼀个 RTP 包的时间戳值。
2.  npt 和 rtptime 的区别在于 npt 是影⽚开始的相对时间，⽽ rtptime 是会话开始的相对时间。因此在client 端，需要对这两者进⾏ map 处理。
3.  在 client 端计算播放时间戳的公式如下：
    
    1.  nptUs = (current\_rtpTime - start\_rtptime) / scale + srart\_npt
4.  其中：
    
    1.  start\_rtptime 与 start\_npt 分别是 PLAY 请求的 Response 中的 rtptime 和 npt 。
    2.  current\_rtpTime 是当前收到的 RTP 包头中的 rtptime 。
    3.  scale 为 PLAY 请求的 Response 中的 scale 值。在正常播放的情况下为 1 ，快速播放时⼤于 1 ，当处于反向扫描模式时⼩于 -1

#### 2. 媒体间同步⽅法（不同设备的同步） ####

1.  上⾯的处理仅仅实现了媒体内的同步，在实现媒体间同步时，还需要进⾏其他的处理⼯作。这就需要⽤到RTCP 的 SR ( Sender Report )。在 SR 中包含⼀个< rtp ， ntp >时间戳对，通过这个时间戳对可以将⾳频和视频准确的定位到⼀个绝对时间轴上。
2.  < rtp ， ntp >时间戳对的必要性在于不同流的 RTP 时间戳有不同的随机偏移量，因此⽆法直接进⾏同步。
3.  < rtp ， ntp >中的 ntp 是⽹络时间协议格式表示的绝对时间值。
4.  < rtp ， ntp >中的 RTP 与数据包中的 RTP 时间戳具有相同的单位和偏移量，但在⼤多数情况下此时间戳不等于任何临近的 RTP 包中的时间戳。
5.  根据不同 stream 中的< rtp ， ntp >时间戳对，可以将⼀个 stream 中的时间戳值映射为另⼀个stream 的时间戳值，从⽽实现媒体间的同步。

--------------------

### 4. RTCP同步 ###

1.  RTP⽀持传送不同codec的steaming，不同codec的clock rate的也不⼀样，不同的media之间需要依靠RTCP进⾏同步。这⾥简单介绍⼀下他们的机制。
2.  在每个RTCP SR包中对应有⼀个RTP时间和⼀个NTP时间，它表达的意思很明确，那就是这个RTP时间对应的绝对时间， 不同media的RTP时间尽管不同，但可以通过NTP时间映射到同⼀个时间轴上，从⽽实现同步。
3.  如下图所示，RTP session 1 send H264 使⽤90,000HZ，⽽RTP session 2 send G.711 使⽤8,000HZ  
    ![4.][]
4.  也就是是说有3个时间轴，⾳频时间轴，视频时间轴，ntp时间轴。
5.  ⾳视频的时间轴的单位都是各⾃的采样率，需要除以采样率才能取得单位为秒的时间单位。
6.  有两个rtcp流，分别为⾳/视频的，其中有⼀个当前的⾳频的timestamp和⼀个ntp的timestamp。
7.  这两个值是在不同轴上的相同时间点，即⾳/视频轴和ntp轴的重合点。使⽤这个值可以使⾳视频轴同步。当拿到⾳频NTP时间 （Tan），⾳频RTP时间（Tar），视频NTP时间（Tvn），视频RTP时间（Tvr），就可以计算⾳视频时间轴的差距D:
8.  假设使⽤⾳频为主轴，视频向⾳频对⻬。D = (Tar-Tvr) - (Tan - Tvn);新的视频时间戳为Tar = Tar + D;
9.  在rtcp的sr单元中有32位的MSW和32位的LSW。MSW的单位为秒，⽽LSW的单位为232picoseconds。1⽪秒为1/10`^`12秒。LSW转为us的公式为(LSW\*10`^`12/2^32)/1000000;

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MTkxMDY5NA_size_16_color_FFFFFF_t_70]: /images/20221005/22b19748e31f44afb8572ee8b1aa21e7.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MTkxMDY5NA_size_16_color_FFFFFF_t_70 1]: /images/20221005/001cd8c240074c048dc84c9e8531415c.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MTkxMDY5NA_size_16_color_FFFFFF_t_70 2]: /images/20221005/1ebfa7d4c57546cebc98ca0bb7f2d78c.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MTkxMDY5NA_size_16_color_FFFFFF_t_70 3]: /images/20221005/ba41e4996bda436786365215233726ff.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MTkxMDY5NA_size_16_color_FFFFFF_t_70 4]: /images/20221005/de7f714043d4494f9364a503c3f78a7d.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MTkxMDY5NA_size_16_color_FFFFFF_t_70 5]: /images/20221005/8b4ecdc4791b4ba9beb0bdfa2da5bed1.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MTkxMDY5NA_size_16_color_FFFFFF_t_70 6]: /images/20221005/f1c9afae4127495ab831b193dfb43a37.png
[4.]: /images/20221005/5de0899cf89a4fdb899127b37ce5446e.png