3.6. 组规模考虑 (Considerations on the Group Size)

本节就不同反馈模式可适用的组规模给出若干指南.

3.6.1. ACK 模式

RTP 会话 MUST 恰有两个成员且组规模 MUST NOT 增长, 即 MUST 为点对点通信. 会话描述中 SHOULD 使用单播地址.

单向或双向两方通信时, RTP 会话带宽的 2.5% 可用于来自接收端的 RTCP 流量 (含反馈). 64 kbit/s 流对应 RTCP 约 1,600 bit/s. 若平均每个 RTCP 分组 96 字节 (=768 bit), 接收端每秒可向发送端报告约 2 个事件. 若每个 FB 消息聚合 10 个事件的确认, 则每秒可确认 20 个事件. 256 kbit/s 时每秒约可报告 8 个事件, ACK 粒度可更细 (例如每个 FB 只合并三个 ACK).

自 1 Mbit/s 起, 接收端可对 30 fps 视频逐帧 (而非逐包!) 确认.

ACK 策略 MUST 在上述带宽限制下仍能正常工作. 是否允许某会话使用 ACK 及采用何种 ACK 策略, MAY 通过带外机制传达, 例如 SDP 会话描述中的媒体相关属性.

3.6.2. NACK 模式

否定确认 (及报告特征类似的其他反馈类型) MUST 用于组规模可能大于 2 的所有会话. 当然, NACK MAY 也用于点对点.

是否采用 Early RTCP 分组取决于会话带宽, 编解码, 反馈类型及发送端/接收端数量等.

判定工作模式时最重要的参数是: 两个复合 RTCP 分组之间允许的最小间隔 (T_rr), 以及单位时间内推测需报告的平均事件数 (及其时间分布). 最小间隔可由可用 RTCP 带宽与预期平均 RTCP 分组大小导出; 待报告事件数 (如每秒) 可由丢包率与发送端发包率导出. 由二者可计算 Immediate Feedback 模式允许的组规模.

如第 3.3 节所述:

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

Early RTCP 模式的上界则仅取决于可接受的质量劣化, 即单位时间内允许多少事件不被报告.

如第 3.3 节所述:

沿用上述记号, Early RTCP 模式可粗略用 N > B*T/R 作为下界. 上界更难估计. 令 N=1, 对给定 R 与 B 得 T = R/B, 为待报告事件之间的平均间隔, 可作为是否值得早期发送 RTCP 的提示.

示例: 256 kbit/s, 30 fps 视频经 MTU 约 1,500 字节的网络传输, 多数情况下每帧一包, 包率约 30 pps. 若网络丢包 5% (均匀分布, 接收端间无关联), 则平均每接收端每两秒需报告约 3 个丢包. 假定单发送端且接收端多于三个, 接收端分得 RTCP 带宽 3.75%, 即 9.6 kbit/s. 再假定平均复合 RTCP 分组 120 字节, 则每秒约可发 10 个 RTCP, 两秒 20 个. 若每接收端每两秒需报告 3 个丢包且全部报告, 最大组规模约 6--7. Early RTCP 传输规则应能为其中大部分及时报告提供足够灵活性.

将本例延伸到 Early RTCP 上界: 若编码与应用 (及用户容忍度) 允许约每两秒一次不修复的丢失, 则每接收端每两秒报告量降为 2 个丢包, 组规模可增至 10. 若部分丢包相关, 反馈流量进一步降低, 用 Early RTCP 模式合理支持约 12--16 (甚至 20) 人组是可能的. 注意这些均基于统计, 某些情况下会不成立.