摘要

  • RFC 5577 取代了早期的 RTP 载荷规范，以支持 G.722.1 附件 C 中最高 14 kHz 的音频带宽、32 kHz 采样时钟和 48 kbit/s 模式。
  • 它没有规定一次性切断旧配置：规范建议为互通继续提供 16 kHz 配置，并要求通过 SDP 声明每一种计划使用的时钟频率与码率组合。

新标准没有让旧终端自动消失

RFC 5577 于 2009 年 7 月发布，首页写着“Obsoletes: 3047”。这句话看似宣布了明确换代：旧规范退场，新规范接管。但它的互通条款描述的是另一种更谨慎的迁移。RFC 3047 为 G.722.1 定义了 16 kHz 采样时钟。后来 ITU-T 修订建议的附件 C 带来超宽带音频支持；RFC 5577 因此把音频带宽扩至 14 kHz，并加入 32 kHz 时钟配置和 48 kbit/s 码率。

这些数字分别描述不同维度。14 kHz 是编码音频的带宽；16 或 32 kHz 是 RTP 时间戳所用的采样时钟；24、32 或 48 kbit/s 才是编解码器的码率。RFC 5577 没有把它们混成一个“音质档位”，而是让会话信令表达一组可用配置。

G.722.1 的比特流不会在带内通知码率变化。因此，RFC 5577 要求用带外方式传达码率，并规定同一个 RTP 载荷类型必须保持固定码率。应用可以在不同数据包之间切换配置，但必须为不同配置分配不同载荷类型。在 SDP 中，a=rtpmap 表明编码名称和时钟频率，a=fmtp 给出码率。接收端据此知道发送端提出的是什么组合。

Offer/Answer 模型使这份声明具有实际意义。RFC 5577 要求发送方把打算使用的每种配置都写进 offer。它也直接指出兼容性缺口：RFC 3047 只支持 16 kHz 时钟，所以希望与旧设备互通的系统应当同时提供 16 kHz 载荷类型。规范示例把 16 kHz/24 kbit/s 与 32 kHz/48 kbit/s 分配给不同的载荷类型。

这并不意味着所有旧终端都能顺利协商，更不意味着新配置会自动回退。Offer 只是列出可选能力，不能证明对端如何回答，也不能证明声音最终抵达听众。接收端必须从自身支持的配置中作出选择，随后媒体流还要遵循双方同意的配置。RFC 5577 保留了一条兼容路径，却没有给出谁实际走过这条路的证据。

数据包格式保留了另一个边界：每帧仍是 20 毫秒。标准码率下，单帧分别占 60、80 或 120 个八位组。一个包可以聚合连续帧，但同包帧必须具有相同码率和时钟，帧也不能拆分到不同数据包。载荷中没有额外字段指出帧数，接收端要根据总字节数和每帧预期长度推算。对于重视延迟的电话应用，规范建议减少每包帧数；对可容忍延迟的流媒体或消息应用，则可聚合更多。它没有给出适用于所有场景的延迟数字。

从迁移角度看，RFC 5577 讲的不是“新编解码器淘汰旧编解码器”，而是如何让选择仍然可见。Obsoletes 替换的是规范文本；16 kHz offer 则让旧的互通边界继续留在选项中。两者都不能说明有多少终端实现了哪一种配置。

来源