摘要

  • RTCP 的发送预约以当前观察到的参与者规模为依据。群体快速扩大时，计时器到期必须重新计算，不能把旧预约当成无条件的发送许可。
  • 1996年的规范已经使用随机化和按规模调整间隔。2003年的重要变化，是处理预约之后规模仍在变化的问题，并在群体缩小时反向调整。
  • 后来的提前反馈、精简报文与多 SSRC 规则没有取消共同预算。它们进一步要求区分：谁在报告、实际发了多少字节，以及沉默是否足以证明离开。

预约时的房间，已经不是现在的房间

设想一个组播音频会话，少数来源不断发送声音，更多接收方陆续加入。听众增加，不一定意味着声音源同比增加；但如果每个接收方都按固定频率汇报接收情况，控制流量就会随着参与者数量增长。用于观察网络的消息，反而可能成为网络要承担的新负担。

RTCP 是 RTP 的控制协议。它提供接收质量反馈，也使参与者能够识别来源、估计会话规模。这里的规模不是会议主持人登记的签到人数，而是协议通过有效来源标识等信息形成的本地估计。不同端点掌握的信息可能暂时不同，后来加入的来源尤其不可能立即知道全部成员。

RFC 3550 中，新参与者最初把成员数设为1，将自己的 SSRC 算在其中。这个起点便于开始，却也说明一个危险：若许多来源几乎同时进入，每个来源都可能从很小的分母出发，给自己安排过早的第一次报告。

把这些早报稍微随机错开，仍可能在短时间内发出太多。随机化解决的是同步，规模估计解决的是总量。两个问题相关，却不能互相替代。一个排列得很整齐的错误预算，依旧是错误预算。

1996年并非没有想到随机化

如果把2003年的改动写成“从固定发送改成随机发送”，就会把历史讲错。RFC 1889 在1996年1月已经要求报告间隔随成员数变化，估计平均控制包大小，并通过随机化避免意外同步。它也安排了加入后的初次延迟。

真正棘手的情况，是算出一个时间之后，作出计算的条件继续变化。参与者在等待期间听到更多来源，得知会话比自己最初理解的大。原来的发送时刻即使没有与别人重合，也可能已经不符合共同控制预算。

RFC 3550 把这一点写成计时器重新考虑机制。到期时，端点依据最新估计重新算一个随机间隔。若上次发送时间加上这个新间隔，已经不晚于现在，就可以发送；若还在未来，就把预约挪到那个未来时刻，继续等待。

这不是每收到一个新成员的包，就必须立刻重排所有计时器。规则中的关键检查点是到期。它也不是中央调度者逐个批准报告，而是每个参与者用共同规则和自己的最新观察，判断旧预约是否仍成立。

这种设计让“时间到了”与“可以发送”分开。时间到了，只说明应该再次评估条件；发送许可还取决于条件有没有改变。

共用预算，不等于预留容量

基本计算把相应参与者数量、平均 RTCP 包大小和控制带宽结合起来，再考虑最小间隔、随机化及补偿。包大小的核算包含网络层和传输层头部，而不只是报告里那几个统计字段。人数不变、报告变大，也可能需要更长的间隔。

规范中的会话带宽是一个需要共同理解的配置参数，不是计时器实时测得的可用链路容量。常被引用的5%建议，是相对媒体数据会话带宽额外安排的控制带宽，也不是一条不论配置、角色和应用都必须采用的普遍常数。

因此，不能因为所有人都按公式计算，就推断网络已经为这些字节预留了空间。公式解决的是参与者怎样约束彼此累加的控制开销；实际路径能否承受，还依赖别的条件。

RFC 3556 把发送者和非发送者的控制带宽参数表达得更明确，使用 RS、RR 和以比特每秒表示的数值。这两个参数不能被当成同一把开关：RS 为零不意味着所有发送者 RTCP 都被禁止；RR 为零可以停止非发送者的报告，但规范并不普遍推荐这样做。

不让接收方说话，当然能够减少它们消耗的带宽，却同时减少对接收质量和参与状态的观察。这个选择有成本，不能包装成单纯的节约。更何况，过大的带宽参数也可能诱导过量发送；RFC 3556 专门要求应用检查收到的会话参数，尤其是未经认证的信息。

离开的人，会把剩下的人留在旧时刻吗

增长不是唯一需要处理的变化。如果许多参与者离开，其余来源还按原来的大规模会话等待，反馈就可能变得过于稀疏。等待时间越长，别的来源也越容易把这种稀疏误认为失联。

反向重新考虑处理这个方向的问题。成员数减少时，算法按新旧数量之比，围绕当前时刻缩放剩余等待和已过去的间隔。它并不要求大家在同一瞬间得到同一份完整名单，而是让已经观察到收缩的参与者更快调整自己的节奏。

离开通知本身也可能形成突发。大群体的 BYE 报文有自己的退避办法，其计数对象是正在离开的通知，不能直接套用普通加入时的成员计数解释。协议也允许不发送 BYE 而离开，随后由其他参与者超时移除。离开不是一个必然被全体即时看见的事件。

这意味着成员表始终是一项需要维护的判断。过少估计会让控制报告发得过密，过多估计则可能让反馈变慢。规范对大型会话特别警惕严重低估，同时容许某些近似方法高估数量。这里接受的是有方向的误差取舍，而不是声称估计永远准确。

紧急消息不能被当成普通报表

报告节奏越能适应规模，单个来源等待的时间就可能越长。对于定期质量汇总，这是预算的一部分；对于刚发生、过一会儿就失去价值的反馈，则未必合适。

2006年的 RFC 4585 定义 AVPF 的提前反馈规则。在允许的条件下，事件反馈可以早于普通报告时刻发送。群体场景还会让接收方短暂随机等待，听见别人已经发出相应反馈后，抑制自己的重复消息。

提前不等于无预算，反馈也不等于每个丢包都要求每位接收方立刻作答。发送历史、时机和控制带宽仍约束行为。这些规则的存在，正是为什么不能把本篇开头的定期报告计时器，推广成“所有 RTCP 报文都必须等到同一个钟响”。

2009年的 RFC 5506 又允许某些提前或即时反馈使用精简 RTCP，减少随包携带的内容。但它没有取消普通复合报告：使用精简形式之前至少要发过一个复合包，定期报告也仍须采用复合形式并贯穿会话。

兼容声明还不是交付证据。端点或中间设备可能丢弃精简包，所以规范要求检测持续交付失败，并在验证失败时强烈建议回到复合形式。观察网络的渠道本身，也要接受观察。

一个端点，不等于一个参与者

到2017年的 RFC 8108，多来源实现把早期直觉的局限暴露得更明显。同一端点可以拥有多个 SSRC；每个 SSRC 都是一个有自己 RTCP 状态和报告间隔的参与者。把“会议有多少设备”直接填进“协议有多少参与者”，可能算错。

刚加入的端点可以零延迟发送的初始复合 RTCP 包，也有数量限制：最多四个。这限制的是包，不是四个人或四个来源；后续报告仍遵循通常的调度规则。一个设备不能仅凭在内部多建几个来源，就把原本谨慎的启动节奏成倍放大。

聚合则提出另一种细账。如果多个来源的报告装进一个包，不能让每个来源都把整包大小计作自己的成本。RFC 8108 按不同报告 SSRC 的数量分摊大小。同时，聚合不能反复把将来才到期的来源提前拉来，而不补偿它们的时钟，否则省下包头的同时又悄悄提高了报告频率。

规范因此使用有效的未来发送时刻来调整调度状态。某些状态值甚至可以位于当前时间之后，它们不是对上一次物理发包时刻的简单抄录。这里保留的是各来源的发送节奏，而不只是把几份报告装进同一个容器。

同一份更新还统一了相关配置下的参与者超时计算，避免把允许提前、抑制或减少定期报告的安排，误解为成员已经离开。超时依赖确定性间隔及其参数，不是一条“沉默五秒即失联”的通用规则。

修改行为，不一定修改线上的字节格式

RFC 3550 的附录强调，相比 RFC 1889，RTP 与 RTCP 线上的报文格式没有改变。定时行为却改变了。旧实现仍能读懂包，新实现也能借新的节奏减少特定场景的突发；混合部署并不会使旧端自动获得新算法。

这是一种容易被版本表忽略的演化。互操作不仅关乎字段是否认识，还关乎大家什么时候开口、怎样解释没有开口，以及何时放弃旧的群体估计。截至2026年8月26日检查到的 RFC 3550 勘误记录，没有一项已确认的计时器修正推翻这里的机制；待文档更新和被拒绝的条目，也不能冒充已经通过的新规则。

报文可解析，不表示身份已被认证；报告按时发出，也不表示媒体已可靠到达。这套机制承担的任务更窄，却很关键：当每个来源只能知道一部分情况时，让它在花掉共同预算之前，再看一眼自己是否仍有理由照旧行事。