RTP: A Transport Protocol for Real-Time Applications——3

 RTCP Packet Format 

本规范定义了几种RTCP包类型，用于传输多种控制消息：

   SR: 发送者报告(Sender report)，用于传输和接收来自作为活动的发送者的参与方的统计信息

   RR: 接收者报告(Receiver report), 用于接收来自非活动发送者的参与方的统计信息
   SDES: Source description items, including CNAME
   BYE: Indicates end of participation，参与方的结束标志
   APP: Application specific functions

   RTCP包的开头也是固定格式的，这跟RTP数据包差不多。RTCP包头由一系列结构化元素组成，每个元素的长度

可能根据包类型而变化，但一般结束都是以32-bit为边界。固定部分包含了对齐需求和长度字段，以使得RTCP包

“可堆叠”。这样多个RTCP包可以在不使用分隔符的情况下连接到一起构成一个复合RTCP包，能够在低层协议的

一个数据包中传送，譬如UDP协议。复合数据包中没有显式说明单独的RTCP包的个数，因为底层协议需要的是统一

的长度，用以判断复合数据包结束之处即可。

   复合包中的每一个RTCP包可以被独立处理无需考虑数据包的顺序或他们之间的关系。但是为了执行协议的功能

需要考虑下列的约束：   
        o 接收统计信息（SR或RR）应尽可能频繁地发送，因为带宽限制将允许{BANNED}最佳大化统计信息的分辨率，因此每

个周期性发送的复合RTCP包应包括一个报告包。

        o 新的接收者需要尽可能快地收到源的CNAME以标识源并开始关联媒体，以实现诸如lip-sync之类的目的。

因此每个复合RTCP分组应该也要包含SDES CNAME。

        o 应限制复合包中可能首先出现的包类型的个数以增加{BANNED}中国第一个字中常量比特的数量，并提高针对寻址错误

的RTP数据包或其他不相关数据包的RTCP包的验证概率(个人认为就是可以提高验证算法效率的意思？)。

    因此用复合分组的形式来发送RTCP包，那么至少每个复合分组包含两个单独的RTCP包，推荐使用如下的格式：

   Encryption prefix:  当且仅当复合数据包需要加密时，它以为每个所要传输的复合数据包重新计算的32位随

机量为前缀。
   SR or RR:  复合数据包中的{BANNED}中国第一个RTCP数据包必须始终是报告数据包，以便于附录a.2中所述的报头验证。

即使没有发送或接收数据，在这种情况下发送空RR，并且即使复合分组中唯一的其他RTCP分组是BYE，这也是正确

的。

   Additional RRs:  如果正在报告其接收统计信息的源的数量超过31个，该数量将适合于一个SR或RR分组，则

附加的RR分组应跟随初始报告分组。
   SDES:包含CNAME项的SDES数据包必须包含在每个复合RTCP数据包中。如果特定应用程序需要，可根据带宽限制

（见第6.2.2节）选择包括其他源描述项。

   BYE or APP: 其他RTCP数据包类型（包括尚未定义的数据包）可以按照任何顺序进行，但BYE应是与给定SSRC

/CSRC一起发送的{BANNED}最佳后一个数据包。数据包类型可能出现多次。

   建议转换器和混合器在可行的情况下将来自其转发的多个源的单个RTCP数据包合并为一个复合数据包，以摊销

数据包开销（见第7节）。图1所示为混合器可能产生的示例RTCP复合包。如果复合分组的总长度将超过网络路径

的{BANNED}最佳大传输单元（MTU），则可以将其分割成多个较短的复合分组，以在基础协议的单独分组中传输。注意，每个

复合包必须以SR或RR包开头。

如果转换器或混合器不认识到来的RTCP包的类型，那么可以忽略它。其他RTCP包类型可以使用
Internet Assigned Numbers Authority (IANA)j进行注册。

 RTCP Transmission Interval

 如果加密: random 32-bit integer
    |
    |[------- packet -------][----------- packet -----------][-packet-]
    |
    |             receiver reports          chunk        chunk
    V                                    item  item     item  item
   --------------------------------------------------------------------
   |R[SR|# sender #site#site][SDES|# CNAME PHONE |#CNAME LOC][BYE##why]
   |R[  |# report #  1 #  2 ][    |#             |#         ][   ##   ]
   |R[  |#        #    #    ][    |#             |#         ][   ##   ]
   |R[  |#        #    #    ][    |#             |#         ][   ##   ]
   --------------------------------------------------------------------
   |<------------------  UDP packet (compound packet) --------------->|

   #: SSRC/CSRC

              Figure 1: Example of an RTCP compound packet

RTP设计上允许应用程序自动扩展会话的个数，可以是几个到数千个。例如，在音频会议中，数据流量本质上是自

限制的，因为一次只有一个或两个人发言，因此通过多播分发，任何给定链路上的数据速率都保持相对恒定，与

参与者的数量无关。然而，控制流量并非自我限制。如果每个参与者的接收报告以恒定的速率发送，则控制流量

将随着参与者的数量线性增长。因此，必须缩小比率。

对于每个会话，假设数据流量受到一个称为“会话带宽”的聚合限制，该限制将在参与者之间分配。该带宽可能是由网络

保留并强制实施的限制，或者它可能只是一个合理的共享。可以基于会话的可用网络带宽的一些成本或先验知识来选择

会话带宽。它在某种程度上独立于媒体编码，但编码选择可能受到会话带宽的限制。当会话管理应用程序调用媒体应用

程序时，会话带宽参数预期由其提供，但是媒体应用程序也可以基于为会话选择的编码的单个发送者数据带宽来设置默

认值。应用程序还基于多播范围规则或其他标准强制实施带宽限制。 

控制和数据流量的带宽计算包括较低层传输和网络协议（例如UDP和IP），因为这是资源预留系统需要知道的。还可以

期望应用程序知道这些协议中的哪些正在使用。计算中不包括链路级报头，因为数据包在传输时将被不同的链路级报头

封装。 

控制流量应限制在会话带宽的较小的已知的一部分：小到不损害传输协议承载数据的主要功能；使得控制业务可

以被包括在给定给资源预留协议的带宽规范中，并且使得每个参与者可以独立地计算其份额。建议将分配给RTCP

的会话带宽部分固定为5%。虽然间隔计算中的此常数和其他常数的值并不重要，但会话中的所有参与者必须使用

相同的值，以便计算相同的间隔。因此，对于特定的配置文件，这些常数应该是固定的。

附录A.7中描述的算法旨在满足上述目标。它计算发送复合RTCP分组之间的间隔，以在参与者之间划分允许的控制

业务带宽。这允许应用程序为小型会话提供快速响应，例如，识别所有参与者很重要，但自动适应大型会话。该

算法包含以下特征：

        o 发送方被共同分配至少1/4的控制流量带宽，以便在具有大量接收方但发送方数量较少的会话中，新

加入的参与者将更快地接收发送站点的CNAME。

        o RTCP分组之间的计算间隔需要大于至少5秒，以避免当参与者数量少且流量未根据大数定律平滑时

RTCP分组的突发超过允许带宽。

        o RTCP分组之间的间隔在计算间隔的[0.5，1.5]倍范围内随机变化，以避免所有参与者的意外同步[10]。

在应用程序在多个站点同时启动的情况下，在加入会话之后发送的{BANNED}中国第一RTCP分组也被延迟{BANNED}最佳小RTCP间隔的一半的

随机变化，例如，由会话通告发起。

  o 计算平均复合RTCP分组大小的动态估计，包括接收和发送的所有分组，以自动适应所携带的控制信息量的

变化。

  该算法可用于允许所有参与者发送的会话。在这种情况下，会话带宽参数是单个发送者的带宽乘以参与者数量

的乘积，RTCP带宽为其5%。

 Maintaining the number of session members

RTCP分组间隔的计算依赖于参与会话的站点数目的估计。当新的站点能够听到就会被纳入计数，并会在一个以

SSRC或者CSRC标识符(看8.2节)为索引的表格中为新站点创建相应的条目。 只有携带新SSRC的多个分组被接收

到之后(参考附录A.1)才会认为新条目是合法的。如果接收到携带对应SSRC标识符的RTCP BYE包则会从表格中删

除该条目。

如果在RTCP报告间隔的{BANNED}最佳小倍数(建议为5倍)没有收到RTP或者RTCP包，一个参与者就可以标记另外一个站点为

非活动的，或者如果仍然不有效的话就删除它。这提供了一些防止数据包丢失的鲁棒性。所有站点计算出来的

RTCP报告间隔的值必须大概相同，以便该超时能够正常工作。

一旦一个站点被验证，如果它后来被标记为不活动，则该站点的状态仍应被保留，并且该站点应继续计入共享

RTCP带宽的站点总数，持续时间足以跨越典型的网络分区。这是为了避免分区恢复时由于RTCP报告间隔太小而

导致的过多流量。建议超时30分钟。请注意，这仍然大于RTCP报告间隔预期有效缩放的{BANNED}最佳大值的5倍，约为2至

5分钟。 

 Allocation of source description bandwidth 

除了强制性CNAME项之外，本规范还定义了几个源描述（SDES）项，例如NAME（个人名称）和EMAIL（电子邮件

地址）。它还提供了一种定义新的特定于应用程序的RTCP数据包类型的方法。应用程序在为这些附加信息分配

控制带宽时应谨慎，因为这会降低发送“接收报告”和CNAME的速率，从而降低协议的性能。建议不超过分配给单

个参与者的RTCP带宽的20%用于携带附加信息。此外，并非所有SDES项目都应包含在每个应用程序中。根据其

效用，应为包含的带宽分配一部分。建议将百分比静态转换为基于一个项的一般长度的报告间隔计数，而不是动

态估计这些分数。
例如，应用程序可能被设计为只发送CNAME、NAME和EMAIL，而不发送任何其他信息。NAME可能被赋予比EMAIL更高

的优先级，因为NAME将在应用程序的用户界面中连续显示，而EMAIL将仅在请求时显示。在每个RTCP间隔，将发送

带有CNAME项的RR分组和SDES分组。对于以{BANNED}最佳小间隔运行的小会话，平均每5秒一次。每三个间隔（15秒），SDES

数据包中就会包含一个额外的项目。八次中有七次是NAME项，每八次（2分钟）是EMAIL项。
当多个应用通过每个参与者的公共CNAME使用跨应用绑定协同操作时，例如在由每个媒体的RTP会话组成的多媒体

会议中，可以仅在一个RTP会话中发送附加SDES信息。其他会话将仅携带CNAME项目。