摘要

  • RFC 5215 在每个 Vorbis RTP 载荷前放置 24 位 Ident，用它指向解码所需的 Configuration。这个值说明发送方选择了哪套配置，却不能证明接收端已经拿到、解析并安装了那套配置。
  • Ident 变化后，如果客户端没有对应 Configuration，规范要求它不得解码相关原始数据。因此，“零丢包”和“零声音”可以同时成立，运行证据必须把传输到达与解码权限分开记录。

一份完全正确的错误结论

监控显示，节目切换后的 RTP 序号连续，抖动没有异常，原始 Vorbis 数据包全部进入接收端。网络团队据此写下“音频已完整交付”。前半句有证据，后半句却跨过了一个没有被观察的执行层。

切换发生时，载荷头里的 24 位 Ident 也变了。新值指向另一套解码 Configuration。那套配置体积更大，被拆成多个片段，其中一个没有抵达。于是接收端手里有完整的数据序列，却没有解释这些数据所需的码书。

RFC 5215 不允许解码器猜测。客户端发现 Ident 变化而又缺少正确 Configuration 时，在取回配置之前，必须停止解码对应的原始 Vorbis 数据。沉默不是系统没有看见包，而是系统拒绝把没有依据的比特解释成声音。

Ident 是指针，不是内容

Vorbis 与预置固定概率模型的编码方式不同。它把熵解码配置、向量量化和 Huffman 模型放进随流传送的数据块，解码器还需要声道数等具体参数。这些 Identification 与 Setup 信息常被统称为码书或配置头，在任何音频帧能够被解释之前就必须存在。

24 位 Ident 解决的是引用效率。每个原始包不必重复整套设置，只需写明使用哪一项 Configuration。一个会话也可以切换配置、码率或串接内容。

但指针的可见性不能替代被指对象的存在。抓到 Ident，只能证明发送方发出了引用；它不能证明接收端收齐配置片段，不能证明打包头解析成功，也不能证明本地映射表把这个 Ident 绑定到相同字节。

许多仪表盘恰好在这里越权。它们把 payload type、时钟率、声道数、Ident 和到包率排在同一行，再用一个绿色状态概括。前四项描述数据声称需要什么，最后一项描述传输发生了什么，没有任何一项直接盘点解码器实际安装了什么。

SDP 提供线索，Configuration 给出精确信息

会话描述可以通过 rtpmap 声明 vorbis、时钟率和声道数。RFC 5215 明确说，这些 SDP 信息应被视为提示；精确信息来自 Configuration。强制的 configuration 参数放在 fmtp 中，对非串接流，规范建议在初始 SDP 内携带打包后的 Configuration。

打包配置必须保留 Identification 和 Setup 头。Comment 头可以换成占位版本，因为艺术家、标题等元数据不参与帧序列解码。这形成了一个很有价值的优先级：最容易被人阅读的字段可能不是运行必需项，最难在界面中看见的数学模型反而决定服务能否存在。

会话中途还可以换配置。新码书可以通过 RTP 带内传输，也可以随新的 SDP 或带外地址取得。实现必须支持带内更新，并应支持带外更新。配置包的 RTP 时间戳标出它适用的第一个数据包。

这个时间戳界定的是适用边界，不是接收回执。它能回答“从何时起应该用新配置”，不能回答“某台接收机是否在那一刻之前装好了新配置”。

一个稀有对象支配成千上万个普通包

配置头通常比音频包大得多，因此可能被分片，也需要周期性重传支持。丢失一个原始音频包，会造成一段信号损失；丢失 Configuration 的任一片段，却可能让随后整个流都无法成功解码。

按包计数的可用性在这里会颠倒轻重。成千上万个小包都到达，会把一个配置片段的缺失稀释成接近于零的丢包率；对听众而言，那个统计上不起眼的对象却拥有全部后续数据的解释权。

接收端可以重新请求配置，等待重传，从带外来源抓取，或者先缓存原始载荷。基线反应也可能是重置或结束 RTP 会话。每种选择都有独立结果。配置最终找回，并不代表赶上了播放时限；缓存保住内容，并不代表实时服务仍然成立；重置恢复声音，也可能同时清除了最关键的故障现场。

给解码权限留一张回执

完整的运行记录应从协商开始：保存 offer/answer 代次、payload type、SSRC 与打包 Configuration 的精确哈希；记录 Ident、Identification/Setup 头哈希，以及新配置开始适用的 RTP 时间戳。

配置走的是信令、带内、带外还是重传路径，也必须明确。若有分片，要证明每片收齐和组合成功。接收端需要记录解析结果、安装时刻和实际使用的 Ident→配置哈希映射。配置缺失期间，哪些原始包被缓存、丢弃或过期，也应留痕。第一帧成功解码、提交播放的样本和可观察输出，才是链条的末端。

这张“解码权限回执”是 BTW 的编辑分析，不是 RFC 5215 新增的协议要求。它的作用是限制每类证据的管辖范围：RTP 证明运输，SDP 证明提议，Ident 证明选择，安装记录证明接收端具备解释条件，解码和输出事件证明系统真的执行了下一步。

Lu Heng 关于 running code 的论述在这里给出最简洁的判断标准：一个声明只有进入实际消费它的系统，才获得运行效果。可见性不能自动变成执行权，引用也不能代表对象。每个包都展示 Ident，并不能通过重复把缺失的码书“投票”出来。

领导者真正需要追问的，不是“包有没有到”，而是“在播放时限之前，哪一条证据证明这台解码器有权把这些包解释成声音”。

来源

  1. RFC 5215
  2. IETF Datatracker：RFC 5215
  3. RFC 5215 信息页
  4. RFC 5215 文档历史
  5. RFC 3550：RTP
  6. RFC 4566：SDP
  7. RFC 3264：Offer/Answer
  8. RFC 4588：RTP 重传
  9. RFC 3611：RTCP XR
  10. RFC 3533：Ogg 封装
  11. RFC 4648：Base 编码
  12. RFC 3986：URI 语法
  13. RFC 3551：RTP 音视频配置
  14. RFC 1191：路径 MTU 发现
  15. RFC 1981：IPv6 路径 MTU 发现
  16. Xiph：Vorbis I 规范
  17. RFC 8088：RTP 熔断
  18. RFC 8866：SDP
  19. Lu Heng：Running-code primacy