RTP Control Protocol -- RTCP-rtp控制协议

实时传输控制协议（RTCP）基于对会话中的所有参与者定期传输控制包，使用与数据包相同的分发机制。底层协议必须提供数据包和控制包的多路复用，例如使用UDP时使用不同的端口号。RTCP执行四种功能：

• 1、其主要功能是提供对数据分发质量的反馈。这是RTP作为传输协议角色的一个不可分割的部分，并且与其它传输协议的流量和拥塞控制功能相关（见第10节关于拥塞控制的要求）。这种反馈可能直接用于控制自适应编码[18,19]，但通过IP组播的实验表明，从接收方获取反馈以诊断分发中的故障也是至关重要的。向所有参与者发送接收反馈报告，可以让观察到问题的人评估这些问题是局部的还是全局的。使用像IP组播这样的分发机制，也允许像网络服务提供商这样的实体（如果他们没有以其他方式参与会话）接收反馈信息，并充当第三方监控器来诊断网络问题。这种反馈功能由RTCP发送方和接收方报告执行，将在下面的第6.4节中描述。

• 2、RTCP 携带了一个持久的传输层标识符，用于 RTP 源，称为规范名称或 CNAME，参见第 6.5.1 节。由于如果发现冲突或程序重启，SSRC 标识符可能会改变，接收方需要 CNAME 来跟踪每个参与者。接收方也可能需要 CNAME 来关联某个特定参与者在一组相关的 RTP 会话中的多个数据流，例如用于同步音频和视频。媒体间的同步还需要数据发送方在 RTCP 数据包中包含的 NTP 和 RTP 时间戳。

• 3、前两个功能要求所有参与者发送 RTCP 数据包，因此必须控制发送速率，以便 RTP 能够扩展到大量参与者。通过让每个参与者将其控制数据包发送给所有其他参与者，每个参与者可以独立观察参与者的数量。这个数量被用来计算数据包的发送速率，如第 6.2 节所解释的。

• 4、第四个功能是可选的，即传达最小的会话控制信息，例如在用户界面中显示的参与者标识。这在“松散控制”的会话中最有可能有用，在这样的会话中，参与者加入和离开时没有成员控制或参数协商。RTCP作为到达所有参与者的便捷通道，但不一定期望支持应用程序的所有控制通信需求。可能需要一个更高级别的会话控制协议，这超出了本文档的范围。

功能1到3应该在所有环境中使用，特别是在IP组播环境中。RTP应用程序的设计者应该避免只能工作在单播模式下且无法扩展到更大规模的机制。如第6.2节所述，RTCP的传输可以为发送方和接收方分别控制，在单向链路等情况下，接收方无法提供反馈。

非规范性注释：在称为源特定组播（SSM）的多播路由方法中，每个“通道”（源地址，组地址对）只有一个发送者，接收者（除了通道源之外）不能使用组播直接与其他通道成员通信。这里的建议仅通过第6.2节的选项来适应SSM，即完全关闭接收方的RTCP。未来的工作将指定对RTCP进行适应SSM的调整，以便可以保持来自接收方的反馈。

RTCP Packet Format-rtcp 包格式：

本规范定义了几种RTCP数据包类型，用于携带各种控制信息：

• SR : 发送方报告，用于传输和接收活跃发送方参与者的统计信息。

• RR：接收方报告，用于收集非活跃发送方参与者的接收统计信息，并结合发送方报告（SR），用于活跃发送方报告超过31个源的情况。

• SDES : 源描述项，包括CNAME（规范名称）。

• BYE  : 表示参与结束。

• AAP ：特定于应用程序的功能。

每个RTCP数据包都以与RTP数据包相似的固定部分组成，随后是结构化的元素，这些元素的长度可以根据数据包类型是可变的，但必须以32位边界结束。对齐要求和每个数据包固定部分中的长度字段被包含在内，是为了使RTCP数据包“可堆叠”。多个RTCP数据包可以不加任何分隔符地串联起来，形成一个复合的RTCP数据包，该数据包作为一个单独的下层协议数据包发送，例如UDP。复合数据包中没有明确计算个别RTCP数据包的数量，因为预期下层协议会提供整体长度以确定复合数据包的结束。

复合数据包中的每个单独的RTCP数据包可以独立处理，对数据包的顺序或组合没有要求。然而，为了执行协议的功能，施加了以下约束：

• 接收统计信息（在SR或RR中）应尽可能频繁地发送，以便在带宽限制允许的情况下最大化统计信息的分辨率，因此每个定期传输的复合RTCP数据包必须包含一个报告数据包。

• 新接收方需要尽快接收到某个源的CNAME（规范名称），以识别该源并开始将媒体关联起来，用于诸如音视频同步等目的，因此每个复合RTCP数据包也必须包含SDES（源描述协议）CNAME，除非复合RTCP数据包为了部分加密如第9.1节所述而被分割。

• 为了增加第一个词中恒定位数的数量，并提高成功验证 RTCP 数据包以对抗错误地址的 RTP 数据包或其他无关数据包的概率，需要限制可能出现在复合数据包中的第一个数据包类型的数量。

因此，所有 RTCP 数据包必须以至少包含两个独立数据包的复合数据包的形式发送，格式如下：

• 加密前缀：仅当复合数据包需要根据第9.1节中的方法进行加密时，它必须在每个传输的复合数据包前加上一个随机的32位量，且该量对于每个复合数据包都应重新绘制。如果加密需要填充（padding），则必须将其添加到复合数据包的最后一个数据包中。

• SR和RR：复合数据包中的第一个RTCP（实时传输控制协议）包必须始终是一个报告包，以便于进行如附录A.2中描述的头部验证。即使没有发送或接收数据，也必须发送一个空的RR（接收者报告），并且即使复合数据包中唯一的另一个RTCP包是一个BYE包，也必须这样做。

• 额外的接收者报告（RR）：如果正在报告接收统计信息的源的数量超过了31个，即一个发送者报告（SR）或接收者报告（RR）包能够容纳的数量，那么应该在初始的报告包之后跟随额外的RR包。

• SDES (源描述): 每个复合RTCP数据包中必须包含一个包含CNAME（规范名称）项的SDES（源描述）包，除非第9.1节中另有说明。如果特定应用需要，并且受到带宽限制（参见第6.3.9节），其他源描述项可以被可选地包含。

• BYE or APP: 其他RTCP包类型，包括那些尚未定义的类型，可以以任何顺序跟随，但BYE应该是使用给定的同步源标识符（SSRC）/贡献源标识符（CSRC）发送的最后一个包。包类型可以出现一次以上。

为了正确估计每个参与者的RTCP带宽（参见第6.2节），单个RTP参与者应该在每个报告间隔内只发送一个复合RTCP数据包，除非如第9.1节所述，复合RTCP数据包被拆分以进行部分加密。如果源的数量太多，以至于无法在不超出网络路径的最大传输单元（MTU）的情况下将所有必要的接收者报告（RR）包放入一个复合RTCP数据包中，那么每个间隔只应包含能够适应一个MTU的子集。这些子集应该通过多个间隔的循环方式选择，以确保报告所有源。

建议转换器和混音器在可行的情况下，将它们转发的多个源的个别RTCP包组合成一个复合包，以分摊数据包开销（见第7节）。图1显示了一个混音器可能产生的RTCP复合包的示例。如果一个复合包的总长度将超过网络路径的最大传输单元（MTU），则应将其分割成多个较短的复合包，以便在底层协议的单独数据包中传输。这不会损害RTCP带宽估计，因为每个复合包至少代表一个不同的参与者。请注意，每个复合包必须以发送者报告（SR）或接收者报告（RR）包开始。

实现应该忽略它不认识的传入的RTCP包类型。额外的RTCP包类型可以通过互联网号码分配机构（IANA）注册，如第15节所述。

RTCP Transmission Interval-RTCP传输间隔：

RTP（实时传输协议）旨在允许应用程序在会话规模上自动扩展，从几个参与者到数千人不等。例如，在音频会议中，数据流量本质上是自我限制的，因为一次只有一到两个人会发言，所以通过多播分发，任何给定链路上的数据速率保持相对恒定，与参与者的数量无关。然而，控制流量并不是自我限制的。如果每个参与者的接收报告以固定速率发送，控制流量将随着参与者数量的增加而线性增长。因此，必须通过动态计算RTCP（实时传输控制协议）数据包传输间隔来降低速率。

对于每个会话，假定数据流量受到称为“会话带宽”的总体限制，该限制需要在参与者之间分配。这个带宽可能由网络预留，并且限制由网络强制执行。如果没有预留，可能会有其他约束，这些约束取决于环境，它们建立了会话可以使用的“合理”最大值，那就是会话带宽。会话带宽的选择可能基于某些成本或对会话可用网络带宽的先验知识。它在某种程度上独立于媒体编码，但编码选择可能受到会话带宽的限制。通常，会话带宽是预期同时活动的发送者的标称带宽之和。对于电话会议音频，这个数字通常是单个发送者的带宽。对于分层编码，每一层都是一个单独的RTP会话，具有自己的会话带宽参数。

会话带宽参数预计将由会话管理应用程序在调用媒体应用程序时提供，但媒体应用程序可以根据会话选定的编码为单发送者数据带宽设置一个默认值。应用程序还可以根据多播作用域规则或其他标准强制执行带宽限制。所有参与者必须使用相同的会话带宽值，以便计算出相同的RTCP（实时传输控制协议）间隔。

控制和数据流量的带宽计算包括底层传输和网络协议（例如，UDP和IP），因为这是资源预留系统需要知道的信息。应用程序也可以预期知道这些协议中的哪些正在使用。链路层头部不包括在计算中，因为数据包在传输过程中会被封装成不同的链路层头部。

控制流量应该限制在会话带宽的一小部分：小到不会影响传输协议的主要功能——传输数据；已知的，以便控制流量可以包含在给资源预留协议的带宽规格中，以便每个参与者可以独立计算其份额。控制流量的带宽是数据流量会话带宽之外的。建议将用于RTCP（实时传输控制协议）的会话带宽比例固定在5%。同样建议将RTCP带宽的1/4专门用于正在发送数据的参与者，这样在接收者众多而发送者较少的会话中，新加入的参与者将更快地接收到发送站点的CNAME（规范名称）。当发送者的比例超过参与者的1/4时，发送者将获得他们在整个RTCP带宽中的比例。虽然这些间隔计算中的值和其他常数的值并不关键，但会话中的所有参与者必须使用相同的值，以便计算出相同的间隔。因此，这些常数应该为特定的配置文件固定。

一个配置文件可以指定控制流量带宽可以是会话的一个独立参数，而不是会话带宽的严格百分比。使用一个独立的参数允许自适应速率的应用程序设置一个与会话带宽参数指定的最大带宽相比更低的“典型”数据带宽相一致的RTCP带宽。

该配置文件可以进一步指定，将控制流量的带宽分为两个独立的会话参数，分别用于那些活跃的数据发送者和非发送者；我们将这些参数分别称为 S 和 R。根据建议，1/4 的 RTCP 带宽应专用于数据发送者，那么这两个参数的推荐默认值分别为 1.25% 和 3.75%。当发送者的比例超过参与者中 S/(S+R) 的比值时，发送者将获得这些参数总和中相应的比例。

使用两个参数可以让 RTCP 接收报告完全关闭，即通过将非数据发送者的 RTCP 带宽设置为零，而保持数据发送者的 RTCP 带宽非零，以便仍然能够发送发送者报告以实现多媒体同步。完全关闭 RTCP 接收报告并不推荐，因为这些报告对于第 6 节开头列出的功能，特别是接收质量反馈和拥塞控制，是必需的。然而，对于在单向链路上运行的系统，或者不需要接收质量反馈和接收者存活性反馈、并且有其他方式避免拥塞的会话，这样做可能是合适的。

计算复合 RTCP 包之间的传输间隔时，还应设置一个下限，以避免在参与者数量较少且流量未按照大数定律平滑时，数据包突发传输超过允许的带宽。这也可以防止在网络暂时中断（如网络分区）期间，报告间隔变得过短，从而在网络恢复后延迟适应。在应用程序启动时，应在发送第一个复合 RTCP 包之前施加一个延迟，以便有时间接收来自其他参与者的 RTCP 包，使报告间隔更快地收敛到正确的值。这个延迟可以设定为最小间隔的一半，以更快地通知新的参与者的存在。固定最小间隔的推荐值为5秒。

实现时可以将最小 RTCP 间隔按会话带宽参数的倒数比例缩小，但有以下限制：

• 对于多播会话，只有活跃的数据发送者可以使用缩小的最小值来计算复合 RTCP 包的传输间隔。

• 对于单播会话，非活跃数据发送者也可以使用缩小的最小值，并且在发送初始复合 RTCP 包之前的延迟可以设为零。

• 对于所有会话，在计算参与者超时时间间隔时（参见第 6.3.5 节），应使用固定的最小值，以确保未使用缩小值来传输 RTCP 包的实现不会被其他参与者过早超时。

• 缩小后的最小值推荐为用 360 除以会话带宽（以千比特/秒为单位）得到的秒数。对于带宽大于 72 kb/s 的情况，这个最小值小于5秒。

第 6.3 节和附录 A.7 中描述的算法旨在实现本节中概述的目标。该算法计算发送复合 RTCP 包之间的间隔，以便在参与者之间分配允许的控制流量带宽。这使得应用程序能够在小型会话中快速响应，例如，在所有参与者的识别很重要的情况下，同时又能自动适应大型会话。该算法包含以下特性：

• 计算得出的 RTCP 包之间的间隔与组成员的数量线性缩放。正是这个线性因子使得所有成员的控制流量总量保持恒定。

• RTCP 包之间的间隔在 [0.5, 1.5] 倍的计算间隔范围内随机变化，以避免所有参与者出现意外的同步现象 [20]。加入会话后发送的第一个 RTCP 包也会通过随机变化延迟半个最小 RTCP 间隔。

• 动态估算复合 RTCP 包的平均大小，包括所有接收到和发送出的包，以自动适应控制信息量的变化。

• 由于计算的间隔取决于观测到的组成员数量，因此当新的用户加入现有会话或大量用户同时加入新会话时，可能会出现不理想的启动效果。这些新用户最初会错误地估计组成员数量，从而导致其 RTCP 传输间隔过短。如果许多用户同时加入会话，这个问题可能会很严重。为了解决这个问题，采用了一个称为“计时器重新考虑”的算法。该算法实现了一个简单的退避机制，当组规模增加时，用户会推迟 RTCP 包的传输。

• 当用户通过发送 BYE 包或超时离开会话时，组成员数量会减少，因此计算的间隔应随之减小。使用“反向重新考虑”算法来使成员能够更快地响应组成员减少并缩短间隔。

• BYE 包的处理方式与其他 RTCP 包不同。当用户离开组并希望发送 BYE 包时，可以在下一个预定的 RTCP 包之前发送。然而，BYE 包的传输遵循一种退避算法，以避免大量成员同时离开会话时产生大量的 BYE 包洪流。

• 该算法可用于所有参与者均可发送的会话。在这种情况下，会话带宽参数是每个发送者的带宽乘以参与者数量的乘积，RTCP 带宽为其 5%。

算法的详细操作在接下来的章节中进行描述，附录 A.7 给出了一个示例实现。

Maintaining the Number of Session Members(维护会话的数量)：

RTCP 包间隔的计算依赖于对会话中参与站点数量的估计。当听到新的站点时，将其加入计数，并应在一个以 SSRC 或 CSRC 标识符（参见第 8.2 节）为索引的表中为每个站点创建一个条目以进行跟踪。新的条目可以在接收到携带该 SSRC 的多个数据包之前，或在接收到包含该 SSRC 的 SDES RTCP 包（其中包含 CNAME）之前被视为无效（参见附录 A.1）。当接收到包含相应 SSRC 标识符的 RTCP BYE 包时，可以从表中删除该条目，但有可能在 BYE 包之后仍会收到一些拖延到达的数据包并导致重新创建该条目。因此，应将该条目标记为已接收到 BYE，然后在适当的延迟后再删除。

如果在多个（建议为 5 个）RTCP 报告间隔期间未收到 RTP 或 RTCP 包，参与者可以将另一个站点标记为不活动，或者如果该站点尚未被视为有效，则可以将其删除。这提供了一定的抗丢包能力。为了使该超时机制正常工作，所有站点必须具有相同的倍数值，并且必须计算出大致相同的 RTCP 报告间隔值。因此，此倍数值应为特定配置文件固定。

对于拥有大量参与者的会话，维护一个存储所有 SSRC 标识符和状态信息的表可能不切实际。实现可以使用 SSRC 采样，如 [21] 所述，以减少存储需求。实现可以使用任何其他具有类似性能的算法。一个关键要求是，任何考虑使用的算法不应严重低估组的大小，尽管可以高估。