3.2. 算法概要 (Algorithm Outline)

FB 消息属于 RTCP 控制流的一部分, 因而受 RTCP 带宽约束. 这意味着, 尤其可能无法在接收端观测到某一事件后立即将其报告回发送端. 然而, 对发送端而言反馈的价值通常会随时间下降, 无论从接收端用户感知到的媒体质量来看, 还是从实现媒体流修复所需代价来看.

RTP [1] 与常用的 RTP 概要 [2] 规定了何时应发送复合 RTCP 分组. 本文档修改这些规则, 以便应用能够及时报告事件 (例如 RTP 分组的丢失或接收), 并容纳使用 FB 消息的算法.

修改后的 RTCP 传输算法可概述如下: 只要无需承载 FB 消息, 复合 RTCP 分组就按 RTP [1] 的规则发送, 但不强制 RTCP 报告之间的 5 秒最小间隔. 因此, RTCP 报告间隔仅由平均 RTCP 分组大小以及可供 RTP/RTCP 实体使用的 RTCP 带宽份额推导. 可选地, 可强制 Regular RTCP 分组之间的最小间隔.

若接收端发现需要发送 FB 消息, 它可以比下一个常规 RTCP 报告间隔 (按上述常规 RTCP 算法调度) 更早发送. 多方会话中使用反馈抑制 (feedback suppression) 以避免反馈内爆: 接收端等待一段 (较短的) 随机抖动间隔, 以检查是否看到任何其他接收端报告同一事件的对应 FB 消息. 注意, 对于点到点会话不存在此类延迟. 若收到来自其他成员的对应 FB 消息, 该接收端不再发送该 FB 消息, 并继续遵循 Regular RTCP 传输时间表. 若接收端尚未从任何其他成员处看到对应 FB 消息, 则检查是否允许发送 Early feedback. 若允许发送 Early feedback, 接收端将 FB 消息作为最小复合 RTCP 分组的一部分发送. 是否允许发送 Early feedback 取决于该接收端此前发送的 RTCP 分组类型以及此前发送 Early feedback 消息的时间.

FB 消息也可作为完整复合 RTCP 分组的一部分发送, 这些分组按 [1] (5 秒下界除外) 以常规间隔传输.