附录 B. 相对 RFC 1889 的变更 (Appendix B - Changes from RFC 1889)
本 RFC 的绝大部分与 RFC 1889 完全相同。线上 (on the wire) 的包格式没有任何变化, 仅改变了管辖协议使用方式的规则与算法。最大的变更是对用于计算何时发送 RTCP 包的可扩展定时器算法的增强:
o 第 6.2 节和第 6.3 节所规定、并在附录 A.7 中示例的 RTCP 传输间隔计算算法, 被扩充加入了 "重新考虑 (reconsideration)", 以在大量参与者同时加入会话时, 将超出预期速率的传输降至最低; 并加入了 "反向重新考虑 (reverse reconsideration)", 以在参与者数量快速下降时, 减少错误的参与者超时被触发的频率和持续时间。反向重新考虑还用于在从被动接收方切换到主动发送方模式时, 可能缩短发送 RTCP SR 包之前的延迟。
o 第 6.3.7 节规定了新的规则, 控制何时应当发送 RTCP BYE 包, 以避免在许多参与者同时离开会话时产生包洪泛。
o 第 6.2.1 节中 "为非活跃参与者保留状态、时间要足以跨越典型网络分区" 的要求被移除。在一个许多参与者短暂加入且未能发送 BYE 的会话中, 该要求会导致对参与者数量的显著高估。本修订版中加入的重新考虑算法, 弥补了在分区愈合时大量新参与者同时加入的情况。
应当指出, 这些增强仅在会话参与者数量很大 (成千上万)、且大部分参与者同时加入或离开时, 才会产生显著影响。这使得在真实网络中进行测试颇为困难。然而, 该算法经过了深入的分析与仿真, 以验证其性能。此外, 增强算法被设计为可与 RFC 1889 中的算法互操作, 使得在阶梯式加入期间, 超额 RTCP 带宽降低的程度与实现了增强算法的参与者所占比例成正比。两种算法的互操作性已在真实网络上通过实验得到验证。
其他功能性变更包括:
o 第 6.2.1 节规定, 实现 MAY 仅存储参与者 SSRC 标识符的一个抽样 (sampling), 以允许扩展到非常大型的会话。相关算法在 RFC 2762 [21] 中规定。
o 第 6.2 节规定, RTCP 发送方与非发送方的带宽可以设置为会话的独立参数, 而非会话带宽的严格百分比, 并且 MAY 被设为零。对于使用 IP 多播的 RTP 会话, RTCP 是强制性的要求被放宽。然而, 同时也补充了一个澄清: 关闭 RTCP 是 NOT RECOMMENDED (不推荐的)。
o 在第 6.2、6.3.1 节以及附录 A.7 中, 规定发送方获得专用 RTCP 带宽的参与者比例阈值, 从固定的 1/4 变为: 当给出了 RTCP 发送方与非发送方带宽参数时, 基于该比例来确定。原来 "当没有发送方时不分配带宽给发送方" 的条件被移除, 因为那预期只是一个暂时状态。这也防止了非发送方在并非预期情况下使用发送方的 RTCP 带宽。
o 同样在第 6.2 节中规定, 最小 RTCP 间隔 MAY 针对高带宽会话被缩放为更小的值, 并且初始 RTCP 延迟 MAY 针对单播会话被设为零。
o 将某个参与者判定为超时, 应当基于在若干个 RTCP 报告间隔内的不活跃, 这些间隔使用接收方 RTCP 带宽比例计算, 即使对于活跃的发送方也是如此。
o 第 7.2 和 7.3 节规定, 转换器和混合器应当为它们不再转发的源发送 BYE 包。
o 针对分层编码的规则变更定义于第 2.4、6.3.9、8.3 以及 11 节。在最后这一节中指出, 地址和端口分配规则与 SDP 规范 RFC 2327 [15] 相冲突, 但预期该限制将在 RFC 2327 的修订版中被放宽。
o 第 11 节中, 为 RTP 和 RTCP 使用偶数/奇数端口对的约定被澄清为指目的端口。如果这两个端口是显式指定的, 则使用偶数/奇数端口对的要求被移除。对于单播 RTP 会话, 两端 MAY 使用不同的端口对 (见第 3、7.1 和 11 节)。
o 新增了第 10 节, 用以解释使用 RTP 的应用对拥塞控制的需求。
o 在第 8.2 节中, "只要源传输地址改变就 MUST 选择新的 SSRC 标识符" 的要求被放宽, 改为 MAY 选择新的 SSRC 标识符。相应地, 澄清了当一个 SSRC 冲突发生在另外两个参与者之间时, 实现 MAY 选择保留来自新源地址的包而非现有源地址的包; 并且对于诸如电话之类的应用, 其中某些源 (如移动实体) 可能在 RTP 会话过程中改变地址, SHOULD 如此处理。
o 通过对伪代码语法向伪 C 语言的转译, 修正了 RFC 1889 印刷版中第 8.2 节冲突检测与解决算法伪代码的缩进错误; 并且修改了该算法, 移除了 "RTP 和 RTCP 必须从同一源端口号发送" 的限制。
o 澄清了 RTCP 包的填充机制, 并规定填充 MUST 仅应用于一个复合 RTCP 包的最后一个包。
o 在第 A.1 节中, base_seq 的初始化被修正为 seq 而非 seq - 1, 并且文本修正为: 保存的是错误的序列号加 1。max_seq 以及其他变量的初始化从该段文字中分离出来, 以明确: 除了调用 init_seq() 函数之外, 还 MUST 进行这些初始化 (并且补回了 RFC 1889 中从源文档到成品文档处理过程中丢失的若干字)。
o 第 A.3 节中对丢失包数量的钳制 (clamping) 被修正为同时使用正负两个限值。
o RTCP SR 节中关于 "相对 (relative)" NTP 时间戳的规定, 现在将这些时间戳定义为基于最常见的系统相关时钟 (如系统正常运行时间 uptime), 而非基于会话经过时间 (后者对于在同一台机器上于不同时间启动的多个应用并不相同)。
非功能性变更:
o 规定接收方 MUST 忽略那些其负载类型它无法理解的包。
o 在图 2 中, 修正了浮点 NTP 时间戳值, 在一个十六进制数 (hex number) 中补加了若干缺失的前导零, 并指定了 UTC 时区。
o 解释了 NTP 时间戳在 2036 年回绕 (wrap around) 的无足轻重性。
o 注册 RTCP 包类型和 SDES 类型的策略在第 15 节 (IANA 考虑) 中被澄清。原先 "实验者注册他们所需的编号、而后注销那些被证明不需要的编号" 的建议被移除, 转而推荐使用 APP 和 PRIV。还规定了配置文件名称的注册。
o UTF-8 字符集的引用从一份 X/Open 初步规范改为 RFC 2279。
o RFC 1597 的引用更新为 RFC 1918, RFC 2543 的引用更新为 RFC 3261。
o RFC 1889 引言中最后一段警告实现者限制其在 Internet 上的部署的文字被移除, 因为被认为已不再相关。
o 在第 6 节中加入了一个关于 RTP 与源特定多播 (Source-Specific Multicast, SSM) 一起使用的资料性 (non-normative) 注释。
o 第 3 节中 "RTP 会话" 的定义被扩充, 承认单个会话 MAY 使用多个目的传输地址 (对于转换器或混合器向来如此), 并解释了 RTP 会话的区分特征是: 每个会话对应于一个独立的 SSRC 标识符空间。新增了 "多媒体会话 (multimedia session)" 的定义, 以减少对 "session" 一词的混淆。
o 在作为第 5.1 节中 RTP 头部时间戳字段定义的一部分, 对 "采样时刻 (sampling instant)" 的含义做了更详尽的解释。
o 在若干处做了小的文字澄清, 其中一些是针对读者提问所作的回应。特别是:
- 在 RFC 1889 中, 第 2.2 节第二句的前五个词在从源文档到成品文档的处理过程中丢失了, 现已补回。
- 在第 3 节中增加了 "RTP 媒体类型 (RTP media type)" 的定义, 以使第 5.2 节对 RTP 会话多路复用的解释关于多种媒体的多路复用更加清楚。该节现在还解释道: 基于 SSRC 标识符对同一种媒体的多个源进行多路复用可能是恰当的, 并且对于多播会话是常态。
- "非 RTP 手段 (non-RTP means)" 的定义被扩充, 纳入了构成非 RTP 手段的其他协议示例。
- 第 6.2 节对会话带宽参数的描述被扩充, 包括一个澄清: 控制流量带宽是在数据流量的会话带宽之外另行计算的。
- 第 6.4.4 节解释了包时长变化对抖动计算的影响。
- 第 6.5 节澄清了 SDES 项序列的终止与填充方法。
- 在第 6.5.1 节的 SDES CNAME 描述中加入了 IPv6 地址示例, 并改用 "example.com" 取代其他示例域名。
- 安全一节在 IPSEC 现已可用之际, 加入了对其的正式引用, 并说明本规范所定义的机密性方法主要是为了将现有实践编入规范。RECOMMENDED 使用更强的加密算法 (如三重 DES (Triple-DES)) 替代默认算法, 并指出基于 AES 的 SRTP 配置文件将来会是正确的选择。加入了对 "以 RTP 头部作为初始化向量较为脆弱" 的告诫。还指出, 仅对负载加密对于允许头部压缩是必要的。
- 澄清了 RTCP 部分加密的方法; 特别是, 当复合 RTCP 包被拆分时, SDES CNAME 只携带于其中一部分。
- 澄清了每个报告间隔只应发送一个复合 RTCP 包; 并且如果活动源过多、报告无法装入 MTU, 则应在多个间隔之间以轮转 (round-robin) 方式选择源的一个子集。
- 在附录 A.1 中加入了一条注释: 在 RTP 头部验证期间可以保存包, 并在验证成功时交付。
- 第 7.3 节现在解释: 聚合 SDES 包的混合器由于包更长而使用更多 RTCP 带宽; 而透传 RTCP 的混合器自然以高于单一源速率的方式发送包; 但这两种行为都是有效的。
- 第 13 节澄清: 一个 RTP 应用 MAY 使用多个配置文件, 但在给定会话中通常只使用一个。
- 术语 MUST、SHOULD、MAY 等按照 RFC 2119 中的定义使用。
- 参考文献被划分为规范性引用 (normative references) 和资料性引用 (informative references)。