SFU接收多客户端RTCP接收报告后，如何处理并回传至媒体发送端？

我有一台SFU，负责将媒体轨道转发给10个客户端。目前已收到全部10个客户端发送的RTCP.RR（接收报告）数据包，想咨询以下问题：

• 应向媒体轨道的发送端回传什么内容？是直接转发全部10份接收报告，还是需要对其进行合并？
• 若需合并，具体该如何操作？
• 合并后的报告应在何时发送？
• 在Sender Report发送后，需等待多久才能收集齐所有10个客户端的接收报告？如果某客户端的接收报告数据包丢失该如何处理？

单条媒体轨道的接收报告包含以下7个字段（参考RFC3550）：

• ssrc
• fraction lost（丢包率）
• cumulative number of packets lost（累计丢包数）
• highest sequence number received（已接收的最高序列号）
• jitter（抖动）
• timestamp（时间戳）
• delay since last SR（距离上次发送报告的延迟）

我的初步处理想法如下：

• ssrc：始终保持一致
• fraction lost：取最大值
• packet lost：取最大值
• sequence number：取最小值？
• jitter：取平均值？
• timestamp：取最大值
• delay：取最大值

回传内容选择：必须合并，禁止直接转发全部RR #

SFU作为转发中间节点，直接把10份RR发给发送端会徒增其处理负担，也不符合RTCP的设计逻辑——发送端需要的是能反映整体转发链路最差情况或核心状态的汇总数据，以此调整码率、帧率等发送策略，而非每个客户端的单独数据。

合并字段的具体规则 #

针对你列出的7个字段，正确的合并逻辑如下：

• ssrc：保持发送端媒体轨道的SSRC不变。所有客户端的RR都是针对该SSRC的媒体流，合并后统一使用这个标识即可。
• fraction lost（丢包率）：取最大值。发送端需要掌握链路中最严重的丢包情况，以此调整发送策略避免恶化，保留最大丢包率是最合理的选择。
• cumulative number of packets lost（累计丢包数）：取最大值。理由同上，最大累计丢包数代表该流在转发链路中遭遇的最严重丢包状况，是发送端做拥塞控制的关键参考。
• highest sequence number received（已接收最高序列号）：取最小值。这个值最小的客户端是链路中接收进度最滞后的节点，发送端需要确保该节点能跟上流的节奏，取最小值能反映最不利的接收状态。
• jitter（抖动）：取最大值而非平均值。抖动反映数据包到达时间的波动程度，最大抖动对应链路中最不稳定的节点，发送端需要针对该情况调整抖动缓冲；平均值会掩盖极端情况，没有实际指导意义。
• timestamp：取最大值。该时间戳是客户端生成RR的时间，取最晚的时间能保证合并后的报告反映的是最新的链路状态。
• delay since last SR（距离上次SR的延迟）：取最大值。最大延迟对应链路中响应最慢的节点，发送端可基于此调整SR发送间隔或做延迟补偿。

合并报告的发送时机 #

1. 遵循RTCP基础周期：常规每5秒发送一次汇总RR；如果已收集到足够多的客户端RR（比如你这里收齐10份），可立即发送，无需等到固定周期。
2. 配合发送端SR：若收到发送端的SR，需在收到SR后的1秒内发送汇总RR，这是RFC3550推荐的响应时机。

等待RR的时长与丢包处理 #

1. 等待时长：无需等齐所有10个客户端的RR，一般等待100-200ms即可。RTCP RR的发送周期约为5秒，超过200ms未收到的RR大概率已丢失，继续等待会导致汇总报告发送延迟，反而影响发送端的策略调整效率。
2. 丢包处理：若某客户端的RR丢失，直接忽略该客户端数据，用已收到的RR进行合并；若超过半数客户端RR丢失，可沿用上次的汇总数据，或基于已收到的少数RR生成报告——核心原则是不能因等待丢包的RR而延迟发送，发送端需要及时的链路反馈数据。

内容的提问来源于stack exchange，提问作者Horcrux7