rtcp 实时传输控制协议简介

矫情吗；* 2021-08-27 00:45 497阅读 0赞

### RTCP概要 ###

实时传输控制协议(Real-time ControlProtocol，RTCP)与RTP共同定义在1996年提出的RFC 1889中，是和 RTP一起工作的控制协议。RTCP单独运行在低层协议上，由低层协议提供数据与控制包的复用。在RTP会话期间，每个会话参与者周期性地向所有其他参与者发送RTCP控制信息包，如下图所示。对于RTP会话或者广播，通常使用单个多目标广播地址，属于这个会话的所有RTP和RTCP信息包都使用这个多目标广播地址，通过使用不同的端口号可把RTP信息包和RTCP信息包区分开来。

![20151225090240910][]  
图  每个参与者周期性地发送RTCP控制信息包

### RTCP功能 ###

1、为应用程序提供会话质量或者广播性能质量的信息

RTCP的主要功能是为应用程序提供会话质量或者广播性能质量的信息。每个RTCP信息包不封装声音数据或者电视数据，而是封装发送端（和 / 或者）接收端的统计报表。这些信息包括发送的信息包数目、丢失的信息包数目和信息包的抖动等情况，这些反馈信息反映了当前的网络状况，对发送端、接收端或者网络管理员都非常有用。RTCP规格没有指定应用程序应该使用这些反馈信息做什么，这完全取决于应用程序开发人员。例如，发送端可以根据反馈信息来调整传输速率，接收端可以根据反馈信息判断问题是本地的、区域性的还是全球性的，网络管理员也可以使用RTCP信息包中的信息来评估网络用于多目标广播的性能。

2、确定 RTP用户源

RTCP为每个RTP用户提供了一个全局唯一的规范名称 (Canonical Name)标志符 CNAME，接收者使用它来追踪一个RTP进程的参加者。当发现冲突或程序重新启动时，RTP中的同步源标识符SSRC可能发生改变，接收者可利用CNAME来跟踪参加者。同时，接收者也需要利用CNAME在相关RTP连接中的几个数据流之间建立联系。当 RTP需要进行音视频同步的时候，接受者就需要使用 CNAME来使得同一发送者的音视频数据相关联，然后根据RTCP包中的计时信息(Network time protocol)来实现音频和视频的同步。

3、控制 RTCP传输间隔

由于每个对话成员定期发送RTCP信息包，随着参加者不断增加，RTCP信息包频繁发送将占用过多的网络资源，为了防止拥塞，必须限制RTCP信息包的流量，控制信息所占带宽一般不超过可用带宽的 5%，因此就需要调整 RTCP包的发送速率。由于任意两个RTP终端之间都互发 RTCP包，因此终端的总数很容易估计出来，应用程序根据参加者总数就可以调整RTCP包的发送速率。

4、传输最小进程控制信息

这项功能对于参加者可以任意进入和离开的松散会话进程十分有用，参加者可以自由进入或离开，没有成员控制或参数协调。

### RTCP信息包 ###

RTCP也是用UDP来传送的，但RTCP封装的仅仅是一些控制信息，因而分组很短，所以可以将多个RTCP分组封装在一个UDP包中。

类似于RTP信息包，每个RTCP信息包以固定部分开始，紧接着的是可变长结构单元，最后以一个32位边界结束。

根据所携带的控制信息不同RTCP信息包可分为RR（接收者报告包）、SR（源报告包）、SEDS（源描述包）、BYE（离开申明）和APP（特殊应用包）五类5类：

<table> 
 <tbody> 
 <tr> 
 <td style="vertical-align:top;"> 类型 </td> 
 <td style="vertical-align:top;"> 缩写表示 </td> 
 <td style="vertical-align:top;"> 用途 </td> 
 </tr> 
 <tr> 
 <td style="vertical-align:top;"> 200 </td> 
 <td style="vertical-align:top;"> SR（Sender Report） </td> 
 <td style="vertical-align:top;"> 发送端报告 </td> 
 </tr> 
 <tr> 
 <td style="vertical-align:top;"> 201 </td> 
 <td style="vertical-align:top;"> RR（Receiver Report） </td> 
 <td style="vertical-align:top;"> 接收端报告 </td> 
 </tr> 
 <tr> 
 <td style="vertical-align:top;"> 202 </td> 
 <td style="vertical-align:top;"> SDES（Source Description Items） </td> 
 <td style="vertical-align:top;"> 源点描述 </td> 
 </tr> 
 <tr> 
 <td style="vertical-align:top;"> 203 </td> 
 <td style="vertical-align:top;"> BYE </td> 
 <td style="vertical-align:top;"> 结束传输 </td> 
 </tr> 
 <tr> 
 <td style="vertical-align:top;"> 204 </td> 
 <td style="vertical-align:top;"> APP </td> 
 <td style="vertical-align:top;"> 特定应用 </td> 
 </tr> 
 </tbody> 
</table>

<table> 
 <tbody> 
 <tr> 
 <th>Type</th> 
 <th>Description</th> 
 <th>References</th> 
 </tr> 
 <tr> 
 <th>0 - 191</th> 
 <td>&nbsp;</td> 
 <td>&nbsp;</td> 
 </tr> 
 <tr> 
 <th>192</th> 
 <td>FIR, full INTRA-frame request.</td> 
 <td><a href="http://www.networksorcery.com/enp/rfc/rfc2032.txt" rel="nofollow">RFC 2032</a></td> 
 </tr> 
 <tr> 
 <th>193</th> 
 <td>NACK, negative acknowledgement.</td> 
 <td><a href="http://www.networksorcery.com/enp/rfc/rfc2032.txt" rel="nofollow">RFC 2032</a></td> 
 </tr> 
 <tr> 
 <th>194</th> 
 <td>SMPTETC, SMPTE time-code mapping.</td> 
 <td>RFC5484</td> 
 </tr> 
 <tr> 
 <th>195</th> 
 <td>IJ, extended inter-arrival jitter report.</td> 
 <td><a href="http://www.networksorcery.com/enp/rfc/rfc5450.txt" rel="nofollow">RFC 5450</a></td> 
 </tr> 
 <tr> 
 <th>196 - 199</th> 
 <td>&nbsp;</td> 
 <td>&nbsp;</td> 
 </tr> 
 <tr> 
 <th>200</th> 
 <td>SR, sender report.</td> 
 <td><a href="http://www.networksorcery.com/enp/rfc/rfc3550.txt" rel="nofollow">RFC 3550</a></td> 
 </tr> 
 <tr> 
 <th>201</th> 
 <td>RR, receiver report.</td> 
 <td><a href="http://www.networksorcery.com/enp/rfc/rfc3550.txt" rel="nofollow">RFC 3550</a></td> 
 </tr> 
 <tr> 
 <th>202</th> 
 <td>SDES, source description.</td> 
 <td><a href="http://www.networksorcery.com/enp/rfc/rfc3550.txt" rel="nofollow">RFC 3550</a></td> 
 </tr> 
 <tr> 
 <th>203</th> 
 <td>BYE, goodbye.</td> 
 <td><a href="http://www.networksorcery.com/enp/rfc/rfc3550.txt" rel="nofollow">RFC 3550</a></td> 
 </tr> 
 <tr> 
 <th>204</th> 
 <td>APP, application defined.</td> 
 <td><a href="http://www.networksorcery.com/enp/rfc/rfc3550.txt" rel="nofollow">RFC 3550</a></td> 
 </tr> 
 <tr> 
 <th>205</th> 
 <td>RTPFB, Generic RTP Feedback.</td> 
 <td>&nbsp;</td> 
 </tr> 
 <tr> 
 <th>206</th> 
 <td>PSFB, Payload-specific Feedback.</td> 
 <td>&nbsp;</td> 
 </tr> 
 <tr> 
 <th>207</th> 
 <td>XR, RTCP extension.</td> 
 <td><a href="http://www.networksorcery.com/enp/rfc/rfc3611.txt" rel="nofollow">RFC 3611</a></td> 
 </tr> 
 <tr> 
 <th>208</th> 
 <td>AVB, AVB RTCP packet.</td> 
 <td>IEEE 1733</td> 
 </tr> 
 <tr> 
 <th>209</th> 
 <td>RSI, Receiver Summary Information.</td> 
 <td>RFC 5760</td> 
 </tr> 
 <tr> 
 <th>210 - 255</th> 
 <td>&nbsp;</td> 
 <td>&nbsp;</td> 
 </tr> 
 </tbody> 
</table>

**1、SR**

发送端报告包，用于发送和接收活动源的统计信息；

发送端报告分组SR（Sender Report）用来使发送端以多播方式向所有接收端报告发送情况。SR分组的主要内容有：相应的RTP流的SSRC，RTP流中最新产生的RTP分组的时间戳和NTP，RTP流包含的分组数，RTP流包含的字节数。SR包的封装如下图所示：

![20160107110831423][]

版本（V）：同RTP包头域。

填充（P）：同RTP包头域。

接收报告计数器（RC）：5比特，该SR包中的接收报告块的数目，可以为零。

包类型（PT）：8比特，SR包是200。

长度域（Length）：16比特，其中存放的是该SR包以32比特为单位的总长度减一。

同步源（SSRC of sender）：SR包发送者的同步源标识符。与对应RTP包中的SSRC一样。

NTP Timestamp（Network time protocol）SR包发送时的绝对时间值。NTP的作用是同步不同的RTP媒体流。

RTP Timestamp：与NTP时间戳对应，与RTP数据包中的RTP时间戳具有相同的单位和随机初始值。

Sender’s packet count：从开始发送包到产生这个SR包这段时间里，发送者发送的RTP数据包的总数. SSRC改变时，这个域清零。

Sender\`s octet count：从开始发送包到产生这个SR包这段时间里，发送者发送的净荷数据的总字节数（不包括头部和填充）。发送者改变其SSRC时，这个域要清零。

同步源n的SSRC标识符：该报告块中包含的是从该源接收到的包的统计信息。

丢失率（Fraction Lost）：表明从上一个SR或RR包发出以来从同步源n(SSRC\_n)来的RTP数据包的丢失率。

累计的包丢失数目：从开始接收到SSRC\_n的包到发送SR,从SSRC\_n传过来的RTP数据包的丢失总数。

收到的扩展最大序列号：从SSRC\_n收到的RTP数据包中最大的序列号，

接收抖动（Interarrival jitter）：RTP数据包接受时间的统计方差估计

上次SR时间戳（Last SR,LSR）：取最近从SSRC\_n收到的SR包中的NTP时间戳的中间32比特。如果目前还没收到SR包，则该域清零。

上次SR以来的延时（Delay since last SR,DLSR）：上次从SSRC\_n收到SR包到发送本报告的延时。

**2、RR**

接收者报告包，用于接收非活动站的统计信息；

**3、SDES**

源描述包，用于报告和站点相关的信息，包括CNAME；

**4、BYE**

断开RTCP包，是站点离开系统的报告，表示结束；

**5、APP**

应用特定函数。

不同类型的RTCP信息包可堆叠，不需要插入任何分隔符就可以将多个RTCP包连接起来形成一个RTCP组合包，然后由低层协议用单一包发送出去。由于需要低层协议提供整体长度来决定组合包的结尾，在组合包中没有单个RTCP包的显式计数。

组合包中每个RTCP包可独立处理，而不需要按照包组合的先后顺序处理。在组合包中有以下几条强制约束：

1、只要带宽允许，在SR包或RR包中的接收统计应该经常发送，因此每个周期发送的组合RTCP 包中应包含报告包。

2、每个组合包中都应该包含SDES CNAME，因为新接收者需要通过接收CNAME来识别源，并与媒体联系进行同步。

3、组合包前面是包类型数量，其增长应该受到限制。

所有RTCP包至少必须以两个包组合形式发送，推荐格式如下：

加密前缀（Encryption prefix）：

仅当组合包被加密，才加上一个32位随机数用于每个组合包发送。

SR或RR：

组合包中第一个RTCP包必须是一个报告包，以帮助分组头的确认。即使没有数据发送，也没有接收到数据，也要发送一个空RR，那怕组合包中RTCP包为BYE。

附加RR：

如报告统计源数目超过31，在初始报告包后应该有附加RR包。

SDES：

包含CNAME 项的SDES包必须包含在每个组合RTCP包中。SDES包可能包括其他源描述项，这要根据特别的应用需要，并同时考虑带宽限制。

BYE或APP：

除了BYE应作为最后一个包发送，其它RTCP包类型可以任意顺序排列，包类型出现可不止一次。

混合器从多个源组合单个RTCP包，如组合包整体长度超过网络路径最大传输单元，可分成多个较短组合包用低层协议以单个包形式发送。注意，每个组合包必须以SR或RR包开始。附加RTCP包类型可在Internet Assigned NumbersAuthority (IANA)处注册，以获得合法的类型号。

### RTCP传输间隔 ###

由于RTP设计成允许应用自动扩展，可从几个人的小规模系统扩展成上千人的大规模系统。而每个会话参与者周期性地向所有其他参与者发送RTCP控制信息包，如每个参与者以固定速率发送接收报告，控制流量将随参与者数量线性增长。由于网络资源有限，相应的数据包就要减少，直接影响用户关心的数据传输。为了限制控制信息的流量，RTCP控制信息包速率必须按比例下降。

一旦确认加入到RTP会话中，即使后来被标记成非活动站，地址的状态仍会被保留，地址应继续计入共享RTCP带宽地址的总数中，时间要保证能扫描典型网络分区，建议为30分钟。注意，这仍大于RTCP报告间隔最大值的五倍。

SR源报告包和RR接收者报告包

SR源报告包和RR接收者报告包用于提供接收质量反馈，除包类型代码外，SR与RR间唯一的差别是源报告包含有一个20字节发送者信息段。RR针对每个信源都提供信息包丢失数、已收信息包最大序列号、到达时间抖动、接收最后一个SR的时间、接收最后一个SR的延迟等信息。SR不仅提供接收质量反馈信息（与RR相同），而且提供SSRC标识符、NTP时间戳、RTP时间戳、发送包数以及发送字节数等。根据接收者是否为发送者来决定使用SR还是RR包，活动源在发出最后一个数据包之后或前一个数据包与下一个数据包间隔期间发送SR；否则，就发送RR；SR和RR包都可没有接收报告块也可以包括多个接收报告块，其发布报告表示的源不一定是在CSRC列表上的起作用的源，每个接收报告块提供从特殊源接收数据的统计。最大可有31个接收报告块嵌入在SR 或 RR包中，丢失包累计数差别给出间隔期间丢包的数量，而系列号的差别给出间隔期间希望发送的包数量，两者之比等于经过间隔期间包丢失百分比。从发送者信息，第三方监控器可计算载荷平均数据速率与没收到数据间隔的平均包速率，两者比值给出平均载荷大小。如假设包丢失与包大小无关，那么特殊接收者收到的包数量给出此接收者收到的表观流量。

SDES源描述包

SDES源描述包提供了直观的文本信息来描述会话的参加者，包括CNAME、NAME、EMAIL、PHONE、LOC等源描述项，这些为接收方获取发送方的有关信息提供了方便。SDES 包由包头与数据块组成，数据块可以没有，也可有多个。包头由版本（V）、填充（P）、长度指示、包类型（PT）和源计数（SC）组成。PT占8位，用于识别RTCP的SDES包，SC占5位，指示包含在SDES包中的SSRC/CSRC块数量，零值有效，但没有意义。数据块由源描述项组成，源描述项的内容如下：

CNAME: 规范终端标识SDES项

类似SSRC标识，RTCP为RTP连接中每一个参加者赋予唯一一个CNAME标识。在发生冲突或重启程序时，由于随机分配的SSRC标识可能发生变化，CNAME项可以提供从SSRC标识到仍为常量的源标识的绑定。

为方便第三方监控，CNAME应适合程序或人员定位源。

NAME：用户名称SDES项

这是用于描述源的真正的名称，如"John Doe, Bit Recycler, Megacorp"，可以是用户想要的任意形式。由于采用文本信息来描述，对诸如会议应用，可以对参加者直接列表显示，NAME项是除CNAME项以外发送最频繁的项目。NAME值在一次RTP会话期间应该保持为常数，但它不该成为连接的所有参加者中唯一依赖。

EMAIL：电子邮件地址SDES项

邮件地址格式由RFC822规定，如"John.Doe@megacorp.com"。一次RTP会话期间，EMAIL项的内容希望保持不变。

PHONE：电话号码SDES项

电话号码应带有加号，代替国际接入代码，如"+1 908 555 1212"即为美国电话号码。

LOC：用户地理位置SDES项

根据应用，此项具有不同程度的细节。对会议应用，字符串如"Murray Hill, New Jersey"就足够了。然而，对活动标记系统，字符串如"Room 2A244, AT&T BL MH"也许就适用。细节留给实施或用户，但格式和内容可用设置指示。在一次RTP会话期间，除移动主机外，LOC值期望保持不变。

TOOL：应用或工具名称SDES项

TOOL项包含一个字符串，表示产生流的应用的名称与版本，如"videotool 1.2"。这部分信息对调试很有用，类似于邮件或邮件系统版本SMTP头。TOOL值在一次RTP会话期间保持不变。

NOTE: 通知/状态SDES项

NOTE 项旨在描述源当前状态的过渡信息，如"on the phone, can't talk"，或在讲座期间用于传送谈话的题目，它的语法可在设置中显式定义。NOTE项一般只用于携带例外信息，而不应包含在全部参加者中，因为这将降低接收报告和CNAME发送的速度，损害协议的性能。一般NOTE 项不作为用户设置文件的项目，也不会自动产生。

由于NOTE项对显示很重要，当会话的参加者处于活动状态时，其它非CNAME项（如NAME）传输速率将会降低，结果使NOTE项占用RTCP部分带宽。若过渡信息不活跃，NOTE项继续以同样的速度重复发送几次，并以一个串长为零的字符串通知接收者。

PRIV: 专用扩展SDES项

PRIV项用于定义实验或应用特定的SDES扩展，它由长字符串对组成的前缀，后跟填充该项其他部分和携带所需信息的字符串值组成。前缀长度段为8位。前缀字符串是定义PRIV项人员选择的名称，唯一对应应用接收到的其它PRIV项。应用实现者可选择使用应用名称，如有必要，外加附加子类型标识。另外，推荐其它人根据其代表的实体选择名称，然后，在实体内部协调名称的使用。

注意，前缀应尽可能的短。SDES的PRIV项前缀没在IANA处注册。如证实某些形式的PRIV项具有通用性， IANA应给它分配一个正式的SDES项类型，这样就不再需要前缀，从而简化应用，并提高传输的效率。

BYE断开RTCP包

如混合器接收到一个BYE包，混合器转发BYE包，而不改变SSRC/CSRC 标识。如混合器关闭，在关闭之前它应该发出一个BYE包，列出混合器处理的所有源，而不只是自己的SSRC标识。作为可选项，BYE包可包括一个8位八进制计数，后跟文本信息，表示离开原因，如："cameramalfunction"或"RTPloop detected"。字符串的编码与在SDES 项中所描述的相同。如字符串信息至BYE包下32位边界结束处，字符串就不以空结尾；否则，BYE包以空八进制填充。

APP特殊应用包

APP包用于开发新应用和新特征的实验，不要求注册包类型值。带有不可识别名称的APP包应被忽略掉。测试后，如确定应用广泛，推荐重新定义每个APP包，而不用向IANA注册子类型和名称段。

### RTP/ RTCP的不足之处 ###

RTP与RTCP相结合虽然保证了实时数据的传输，但也有自己的缺点。最显著的是当有许多用户一起加入会话进程的时候，由于每个参与者都周期发送RTCP信息包，导致RTCP包泛滥(flooding)。

[20151225090240910]: /images/20210728/4ad0b722d083472d8f44fd14720442bc.png
[20160107110831423]: /images/20210728/b952158d5ed44f969362558e079e6a54.png