摘要

  • 已被 RFC 8285 取代的 RFC 5285，把 RTP 扩展元素中的数字明确设计为“本地标识符”；真正定义格式与含义的是 URI，extmap 负责在协商范围内连接两者。
  • 可靠证据必须把原始包、协商时期、媒体或 BUNDLE 范围与解码器版本一起保存。收到、解析、解释、采取行动和观察结果是五种不同事实。

故障发生在回放系统，而不是媒体链路。抓包里连续出现扩展 ID 3，旧版分析器把它标成“音频电平”。工程师因此认定主动发言人选择出了问题。直到有人翻出当次 SDP 才发现：这场会话里的 3 指向传输时间偏移，音频电平使用的是另一个编号。

包没有撒谎。系统丢掉了包的词典。

RFC 5285 的设计目标，正是让很多小型元数据能够高效进入 RTP 头扩展。若每个包都携带完整 URI，开销会很大；若给所有可能扩展分配一个永久短码，编号空间又会迅速僵化。标准选择第三条路：线上的短编号只在局部有效，绝对 URI 才准确标识扩展的格式与含义，SDP 中的 a=extmap:<编号> <URI> 建立映射。

2017 年的 RFC 8285 取代了 RFC 5285，也解除了一字节与两字节格式不能在同一流中交替使用的旧限制。但它没有把本地编号升级为全局名称。相反，它更清楚地写明：本地编号没有静态分配，必须由协商或带外配置赋义。

IANA 管的是 URI，不是这通会话里的 3

IANA 的 RTP Compact Header Extensions 注册表收录传输时间偏移、同步时间戳、音频电平、MID、RID、帧标记等 URI。注册表给出的是可引用、可审查的名称及规范，不是某个会话内应该使用的短编号。

一字节格式只有 1 到 14 可用，适合扩展数量少、值也短的场景。两字节格式提供更大的 ID 与长度空间。编号小，正因为它是频繁发送的会话资源。不同会话完全可以把同一个数字绑定到不同 URI。

因此，ID=3 不是完整事实。至少还需要知道它属于哪个 RTP 会话、哪一条媒体描述或哪个 BUNDLE 组、哪个 offer/answer 时期、哪个方向，以及映射中的 URI 与扩展属性。把“3 表示音频电平”缓存成进程级常量，相当于取消了标准规定的作用域。

当映射缺失时，正确状态是“含义未解析”，不是“未知扩展已损坏”。抓包仍可证明包到达、时间顺序、SSRC、序列号和原始扩展字节。它只是不能单独证明这些字节代表什么。

会拆包，只证明掌握了语法

RTP 扩展区的 profile 字段表明当前包使用一字节还是两字节形式。解析器可以按照长度逐个取出扩展元素，验证填充与边界。这是一张格式收据。

语义收据要晚一步。编号必须在当时有效的映射中找到 URI，URI 对应的专用解码器还必须接受载荷。把“成功读出 ID 与长度”写成“成功理解元数据”，是在一个绿色状态里混合两种权力来源。

混合模式尤其容易被误报。RFC 5285 要求一个流始终采用一种形式。RFC 8285 允许一个流在不同包之间使用两种形式，但前提是所有接收方已经通过 extmap-allow-mixed 的 offer/answer，或其他带外方式确认能力。它并不允许同一个包同时混合两种元素编码。

所以，在抓包里看到两字节格式，只能证明发送方发了它；不能证明接收方同意接收。只在 offer 里看到 extmap-allow-mixed，也只能证明发起方提出了能力；不能证明 answer 接受，更不能证明线上真的出现过两字节包。

映射稳定性保护的是正在运行的系统

在适用范围内，有效 ID 不能重复分配。会话更新可以增加或删除扩展，也可以修改方向，却不能把一个已经有效的 ID 重映射给另一种扩展。否则，更新前后飞行中的媒体会面对两本词典。

这一规则也要求取证系统保存时间。仅保存“最后一版 SDP”可能用新映射解释旧包，即使每个包都结构合法。每一次协商变化都应成为一个不可变时期，并有明确生效点。

4096 到 4351 是另一个边界。发起方可用这些扩展范围值提供互斥候选，或列出暂时放不进有效空间的选项；应答方选择后，把它映射到可在线上传输的空闲编号。那些高值本身不能作为扩展元素 ID 发到包里。它们是候选，不是执行证据。

方向限定同样不能省略。inactive 映射可以表达“支持但当前不发送”。recvonly 也不证明对端已经发送。SDP 说明许可与配置，包说明实际出现；二者互相补全，不能互相替代。

BUNDLE 让错误映射跨越多条媒体描述

BUNDLE 允许多条 m= 媒体描述共享同一个传输。端口更少，连通性更简单，但接收方必须知道一个 RTP 流究竟属于哪条媒体描述。MID 头扩展承担快速关联，RFC 9143 要求在打包的 RTP 媒体中启用它。

RFC 8285 把同一 BUNDLE 组内的媒体描述视为共享一个本地 ID 空间。同一个 URI 与配置若出现在多个成员中，必须使用同一个 ID；但每条媒体描述仍可以有不同的扩展集合。这不是“整台服务器一个表”，也不是“每条 m= 完全独立”。

如果录制器只保存扁平字典，会出现两类错误：要么把某条媒体专属的扩展错误推广到整个组，要么忽略同一扩展在组内必须一致的约束。正确的数据模型应保存组、成员、URI、配置和有效时期的关系。

RID 进一步展示了作用域嵌套。RFC 8852 说明 RtpStreamId 受源与媒体会话约束，在 BUNDLE 中还受 MID 约束。扩展的本地编号先找到 RID 这种“扩展类型”，RID 的值再在另一个范围内选择媒体流。两个字段都叫 ID，不等于它们共享一种全局身份。

加密改变可见性，不替代映射

头扩展可能携带敏感信息。RFC 6904 曾允许按扩展选择性加密值。RFC 9335 又指出，即使值被保护，暴露的扩展编号与长度也可能成为终端或应用指纹，因此 Cryptex 进一步保护 ID、长度、值与 CSRC。

启用加密后，中间探针可能再也看不到过去能读取的音频电平或 MID。这不能被记录为“发送方停止产生该字段”，只能记录为“此观察点不再有明文可见性”。在授权端解密成功，也不意味着已经取到正确协商时期。密码学证明与映射证明仍是两张收据。

成熟系统至少保留六步：收到原始包；格式解析成功；查到确切映射；专用解码器接受值；获授权组件使用该事实；独立观测确认后续结果。任何一步都可能成功而下一步失败。“已处理”这个词太宽，宽到足以藏住事故。

RFC 5285 的价值不只在节省字节。它明确限制了短编号的权威：数字便于传输，含义来自上下文。只要证据系统也尊重这个边界，就能在不篡改原始包的前提下修正解码器、撤回错误结论、替换供应商工具。