跳到主要内容

3.3. 工作模式 (Modes of Operation)

如后文与图 1 所述, 基于 RTCP 的反馈可在三种模式之一下工作. 工作模式仅表示接收端是否能够平均而言及时向发送端报告所有事件; 该模式并不影响用于调度 FB 消息传输的算法.

并且, 取决于接收质量以及对 RTP 会话的本地监视状态, 各接收端不必 (也无须) 对当前工作模式有一致的认识.

a) Immediate Feedback 模式: 在此模式下, 组规模低于 FB 阈值, 使每个接收方都有足够带宽传输用于预期目的的 RTCP 反馈分组. 即对每个接收端而言, 带宽足以通过近乎 "即时" 的 RTCP 反馈分组报告每个事件.

组规模阈值是若干参数的函数, 包括但不限于: 所用反馈类型 (例如 ACK 与 NACK), 带宽, 分组速率, 丢包概率与分布, 媒体类型, 编解码, 以及待报告事件的 (最坏情况或观测) 频率 (例如收到帧, 丢包).

粗略估计: 设 N 为某接收端在间隔 T 内要报告的平均事件数, B 为该接收端的 RTCP 带宽比例, R 为平均 RTCP 分组大小, 则只要 N<=B*T/R, 该接收端即工作在 Immediate Feedback 模式.

b) Early RTCP 模式: 在此模式下, 组规模与其他参数不再允许每个接收端对每一个值得报告 (或需要报告) 的事件都作出反应. 但仍可足够频繁地提供反馈, 使发送端能够相应调整媒体流传输, 从而提高总体播放质量.

沿用上述记号, Early RTCP 模式可粗略地用 N > B*T/R 作为 "下界" 刻画. 上界估计更困难. 令 N=1, 对给定的 R 与 B 可得 T = R/B, 作为待报告事件之间的平均间隔. 该信息可作为提示, 用于判断早期发送 RTCP 分组是否有益.

c) Regular RTCP 模式: 当组规模达到某一水平以上时, 根本不再适合由接收端为各个单独事件提供反馈, 这既因为反馈可运作的时间尺度, 也因为在大规模组中发送端已无法对个体反馈作出反应.

无法精确规定该模式从哪个组规模开始, 但显然, 该边界与上文 b) 项所述 Early RTCP 模式的上界相衔接.

由于本文档所述反馈算法可平滑扩展, 参与者无需就组内各自 FB 阈值的精确数值达成一致. 因此, 这些模式之间的边界是模糊的.

    ACK
  feedback
    V
    :<- - - -  NACK feedback - - - ->//
    :
    :   Immediate   ||
    : Feedback mode ||Early RTCP mode   Regular RTCP mode
    :<=============>||<=============>//<=================>
    :               ||
   -+---------------||---------------//------------------> group size
    2               ||
     Application-specific FB Threshold
        = f(data rate, packet loss, codec, ...)

                  Figure 1: Modes of operation

如前所述, 相应的 FB 阈值取决于多种技术参数 (编解码, 传输, 所用反馈类型等), 也取决于具体应用场景. 第 3.6 节给出估计这些阈值的一些有用提示 (但无精确计算).

最后于 更新