摘要

  • RFC 3555 规定，媒体类型中的类型、子类型、时钟、声道、分组时长和格式专用参数进入 SDP 时必须各归其位，不能把整串文字当作自动等价的协议对象。
  • fmtp 是把参数交给载荷实现的通道，不是登记表随意增加线上语义的抽屉；登记存在也不等于终端支持、报文正确或解码成功。

设想登记记录里出现这样一串文字：audio/L16; rate=48000; channels=2; ptime=5; emphasis=50-15。如果名字真的能自动携带全部含义，那么另一套协议只要原样复制即可。RFC 3555 偏偏没有这样做。

进入 SDP 后，audio 落在 m= 行，说明媒体种类；L16、48000 和双声道落在 a=rtpmap:97 L16/48000/2，把会话里的动态载荷号 97 绑定到编码名、RTP 时间戳时钟和编码参数；emphasis=50-15 落在 a=fmtp:97；ptime=5 则成为独立的 a=ptime:5。

这不是排版转换，而是证据拆分。同一个名字只有在每一项参数都抵达正确位置时，才保留了原来的契约。

fmtp 的边界比它的自由外表更重要

fmtp 看起来像一段可以继续填键值对的空间。RFC 3555 却明确把解释权交还给载荷格式规范：允许出现哪些格式专用参数，由定义该载荷的 RFC 决定。媒体子类型登记可以说明这些参数怎样从 MIME 风格的字符串转换到 SDP，但不能在没有修订载荷规范的情况下扩展参数集合。

因此，一个网关即使成功生成了语法正确的 a=fmtp，也不能据此声称新参数已经成为标准。SDP 可以把它交给媒体工具，却不需要理解它；接收端也可能忽略、拒绝或错误解释。登记机构维护名字与引用，不负责让每台设备出现相同的代码路径。

这正是“运行代码优先”所要求的分层。登记记录证明协调层上存在一个名字；载荷 RFC 证明该名字下有哪些合法语义；会话描述证明某次会话声明了什么；抓包与解码日志才证明执行层发生了什么。前一层不能冒充后一层。

分组时长不是已经发生的分组

ptime 与 maxptime 被放在独立属性里，是因为它们描述推荐或允许的每包媒体时长，而不是编码身份。看到 a=ptime:5，最多可以证明描述中出现了五毫秒建议。它不能证明发送端真的始终按五毫秒封包，更不能证明网络送达、接收缓冲按时播放或用户听见了内容。

同样，rate=48000 在这里表示 RTP 时间戳时钟，不应不加判断地改写成关于文件采样、播放设备或主观质量的结论。字段位置让用途可审计，却不会替实现完成工作。

会话里的 97 不是全球的 L16

动态载荷号是最容易被误读的地方。例子中的 97 只在这次会话的映射内代表 L16。另一场会话可以把 97 分给别的格式，也可以用 96 或 98 表示同样的 L16 组合。RFC 8866 延续了这一结构：rtpmap 从媒体行中的载荷号映射到编码名、时钟和编码参数。

所以历史档案若只保存 RTP 报文中的数字，却丢失 SDP，就失去了重建含义的关键证据。反过来，仅保存 SDP 也不能证明报文真的遵守它。可靠记录至少要把登记名、会话绑定、载荷规范版本、实际 RTP 头部与解码结果分开保存。

被废止的文档，延续的映射

2007 年，RFC 4855 与 RFC 4856 共同废止 RFC 3555。前者保留并更新登记程序，后者接走具体的 RTP 音视频配置登记。RFC 4856 说明，这次拆分没有给这些登记带来技术变化。

RFC 4855 还补清了另一个隐患：RTP 与非 RTP 文件传输不能仅因想共用名字就使用相同子类型。两者的数据格式必须满足它给出的等价条件，必需参数集合也必须相同；否则应登记不同类型。名字的一致性要由底层契约的一致性支撑，不能倒过来用名字强迫两个格式被视为相同。

截至冻结的 2026 年 10 月 6 日 IANA XML，音频登记有 165 条，视频登记有 97 条，其中 20 条直接引用 RFC 4856，audio/L16、audio/PCMA、audio/PCMU 都在其中。这证明登记链仍可追溯，不证明任何具体设备安装了这些编码器。

RFC 3555 的价值就在这条克制的链上：名字可以跨协议复用，但每一次跨越都必须公开说明怎样搬运参数、谁有权解释它们，以及从哪里开始必须用运行证据回答。

来源