Skip to main content

6. RTP控制协议 - RTCP (RTP Control Protocol)

RTP控制协议(RTCP)基于对会话中所有参与者的周期性控制数据包传输,使用与数据包相同的分发机制。底层协议必须(MUST)提供数据和控制数据包的多路复用,例如使用UDP的不同端口号。

RTCP执行四个功能:

  1. 质量反馈 (Quality Feedback): 主要功能是提供有关数据分发质量的反馈。这是RTP作为传输协议角色的一个组成部分,与其他传输协议的流量和拥塞控制功能相关(参见第10节对拥塞控制要求的描述)。反馈可能直接用于适应性编码的控制[18,19],但是与IP多播的实验也表明,从接收方获得反馈对于诊断分发中的故障也至关重要。将接收反馈报告发送给所有参与者,使观察到问题的人能评估这些问题是局部还是全局的。通过像IP多播这样的分发机制,诸如网络服务提供商这样的实体(即使不直接参与会话)也可以接收反馈信息,并充当第三方监视器来诊断网络问题。这个反馈功能由RTCP发送者和接收者报告在下面的第6.4节中描述。

  2. 持久性标识符 (Persistent Identifier): RTCP携带一个称为规范名称或CNAME的持久性传输级标识符,用于RTP源,详见第6.5.1节。由于在发现冲突或重新启动程序时,SSRC标识符可能会更改,接收者需要CNAME来跟踪每个参与者。接收者也可能需要CNAME来关联来自给定参与者在一组相关RTP会话中的多个数据流,例如用于同步音频和视频。媒体间同步还需要由数据发送者在RTCP数据包中包含的NTP和RTP时间戳。

  3. 速率控制 (Rate Control): 前两个功能要求所有参与者发送RTCP数据包,因此必须控制速率,以便RTP能够扩展到大量的参与者。通过让每个参与者将其控制数据包发送给所有其他人,每个人都可以独立地观察参与者数量。该数字用于计算数据包发送的速率,如第6.2节中所解释的。

  4. 会话控制信息 (Session Control Information): 第四个,可选(OPTIONAL)的功能是传达最少量的会话控制信息,例如要在用户界面中显示的参与者标识。这最有可能在"松散控制"的会话中有用,即参与者进入和离开而不进行成员资格控制或参数协商。RTCP作为一个方便的渠道到达所有参与者,但不一定预计支持应用的所有控制通信要求。可能需要一个高级的会话控制协议,这超出了本文档的范围。

函数1-3应在所有环境中使用,特别是在IP多播环境中。RTP应用设计者应避免只能在单播模式下工作且无法扩展到更大数量的机制。

RTCP的传输可针对发送者和接收者单独进行控制,如第6.2节中所描述,用于如单向链接这样的情况,接收者无法提供反馈。

非规范性注释

在称为源特定多播(SSM)的多播路由方法中,每个"频道"(源地址,组地址对)只有一个发送者,接收者(除频道源外)不能使用多播直接与其他频道成员通信。这里的建议仅通过第6.2节的关闭接收者的RTCP的选项来适应SSM。未来的工作将指定RTCP对SSM的适应,以便可以保持来自接收者的反馈。

6.1 RTCP数据包格式 (RTCP Packet Format)​

本规范定义了几种RTCP数据包类型,以传送各种控制信息:

  • SR (Sender Report): 发送者报告,用于从活动发送者那里传输和接收统计信息
  • RR (Receiver Report): 接收者报告,用于从非活动发送者那里获取接收统计信息,以及与SR结合用于报告超过31个源的活动发送者
  • SDES (Source Description): 源描述项,包括CNAME
  • BYE: 表示参与结束
  • APP: 应用特定功能

每个RTCP数据包都以与RTP数据包相似的固定部分开头,后跟可能根据数据包类型而具有可变长度的结构化元素,但必须(MUST)在32位边界上结束。每个数据包固定部分中的对齐要求和长度字段包含在内,以使RTCP数据包"可堆叠"。多个RTCP数据包可以连接在一起,形成一个复合RTCP数据包,该数据包在较低层协议的单个数据包中发送,例如UDP。

复合数据包中没有单个RTCP数据包的明确计数,因为预计较低层协议将提供总长度以确定复合数据包的结尾。复合数据包中的每个单独RTCP数据包可以独立处理,对数据包的顺序或组合没有要求。然而,为了执行协议的功能,施加了以下约束:

  • 接收统计信息(在SR或RR中)应尽可能经常发送,以最大化统计信息的分辨率,因此每个周期性传输的复合RTCP数据包必须(MUST)包括一个报告数据包。

  • 新接收者需要尽快接收源的CNAME,以识别源并开始关联媒体以实现例如唇同步等目的,因此每个复合RTCP数据包也必须(MUST)包括SDES CNAME,除非复合RTCP数据包因部分加密而拆分,如第9.1节所述。

  • 首先可能出现在复合数据包中的数据包类型数量需要受到限制,以增加第一个字中的常数位数和成功验证RTCP数据包与错误寻址的RTP数据包或其他无关数据包的概率。因此,所有RTCP数据包必须(MUST)在至少两个单独数据包的复合数据包中发送。

实现应(SHOULD)忽略具有未知类型的传入RTCP数据包。可以按照第15节所述,通过互联网已分配数字管理局(IANA)注册其他RTCP数据包类型。

6.2 RTCP传输间隔 (RTCP Transmission Interval)​

RTP设计用于允许应用自动在从几个参与者到数千个参与者的会话规模内进行扩展。例如,在音频会议中,数据流量本质上是自限制的,因为一次只有一两个人会讲话,所以通过多播分发,任何给定链路上的数据速率相对恒定,与参与者数量无关。然而,控制流量并非自限制的。

如果每个参与者的接收报告以恒定速率发送,控制流量将随参与者数量线性增长。因此,必须通过动态计算RTCP数据包传输之间的间隔来缩小速率。

对于每个会话,假设数据流量受到称为"会话带宽"的总限制,以在参与者之间进行分配。这个带宽可能是预留的,并且网络会执行该限制。如果没有预留,则可能有其他约束,取决于环境,确定会话可以使用的"合理"最大值,那将是会话带宽。

会话带宽的选择可能基于某种成本或对会话可用网络带宽的事先了解。它与媒体编码有些独立,但编码选择可能受到会话带宽的限制。通常,会话带宽是预期同时活动的发送者的名义带宽之和。对于电话会议音频,这个数字通常是一个发送者的带宽。

控制流量应限制为会话带宽的一个小而已知的部分: 小是为了不损害传输协议携带数据的主要功能; 已知是为了能够将控制流量包含在给资源预留协议的带宽规范中,以便每个参与者可以独立计算其份额。

控制流量带宽是除了数据流量的会话带宽之外的。建议(RECOMMENDED)用于RTCP的会话带宽的部分固定为5%。还建议将RTCP带宽的1/4专用于正在发送数据的参与者,以便在接收者多但发送者少的会话中,新加入的参与者更快地接收到发送站点的CNAME。当发送者的比例大于参与者的1/4时,发送者将获得完整RTCP带宽的相应比例。

计算的RTCP复合数据包传输间隔也应有一个下限,以避免当参与者数量较少,流量没有根据大数定律进行平滑时,数据包突发超过允许的带宽。它还使报告间隔在诸如网络分区之类的短暂故障期间不会变得过小,从而导致分区愈合时适应性延迟。

6.2.1 维护会话成员数量 (Maintaining the Number of Session Members)​

根据会话参与者数量的估计,计算RTCP报文的间隔取决于两个因素: 发送方的数量和接受方的数量。这些值通过维护一个参与者表来跟踪。

为了保持可扩展性,会话参与者的平均报文间隔应该与组大小成比例。这个间隔称为计算间隔(T)。它通过结合上述几个状态变量来计算:

  1. 如果发送方的数量小于等于会员数量的25%,间隔取决于参与者是否为发送方。如果参与者为发送方(we_sent为true),常数C设置为平均RTCP报文大小(avg_rtcp_size)除以RTCP带宽(rtcp_bw)的25%,常数n设置为发送方的数量。如果we_sent是false,则常数C设置为平均RTCP报文大小除以RTCP带宽的75%。常数n设置为接收方的数量(members - senders)。如果发送方的数量超过25%,发送方和接收方被一起处理。常数C设置为平均RTCP报文大小除以总RTCP带宽,常数n设置为总参与者数量。根据RTP配置文件的规定,RTCP带宽可以用两个单独的参数(称为S和R)明确定义。在这种情况下,25%的分数变为S /(S + R),75%的分数变为R /(S + R)。

  2. 如果参与者尚未发送RTCP报文(变量initial为true),常数Tmin设置为2.5秒,否则设为5秒。

  3. 确定性计算间隔Td设置为max(Tmin, n * C)。

  4. 计算间隔T设置为在确定性计算间隔的0.5到1.5倍之间的一个随机数。

  5. T的结果值除以e-3/2 = 1.21828,以补偿定时器重新考虑算法收敛到低于期望平均值的RTCP带宽的事实。

这个过程产生了一个随机的间隔,但平均而言,发送方将获得至少RTCP带宽的25%,其余部分给接收方。如果发送方占成员的四分之一以上,此过程将平均地将带宽平均分配给所有参与者。

Last updated on