摘要

  • RFC 7865 把 SIPREC 录音元数据 XML 文档称为 application/rs-metadata+xml；RFC 7866 的流程和示例却写成 application/rs-metadata。
  • 2024 年 6 月提交的 Erratum 7987 至今显示为 Held for Document Update。2025 年 6 月发布的 RFC 9806 更新 RFC 7866，并要求替换所有旧写法。
  • RFC 9806 还补上了两份 2016 年文档遗漏的 IANA 注册。当前登记项使用 application/rs-metadata+xml，同时引用 RFC 7865 和 RFC 9806。
  • 这些记录能证明现行规范采用什么名称，却不能证明线上 SRC 发出了什么、SRS 接受了什么、multipart 正文怎样被解析，或归档最终保存了什么。

四个字符足以把规范与运行状态分开

RFC 7865 定义 SIPREC 录音会话的元数据格式，其中参与者等信息由专用 XML 文档承载，媒体类型写作 application/rs-metadata+xml。同月发布的 RFC 7866 描述录音会话协议，却在第 9 节及多个示例里省略了后缀，写成 application/rs-metadata。

这不是两种 XML 格式之争。RFC 7866 本身仍然指向 RFC 7865 的数据模型。矛盾发生在 MIME 标识符：接收端即便具备解析同一段 XML 的能力，也可能因为 Content-Type 没有命中分派表而拒绝正文；发送端也可能生成有效的 SIP 和 XML，却用错误名称声明内容。

Erratum 7987 在 2024 年 6 月 12 日记录了这一矛盾，并列出旧值、修正值以及两份原始 RFC 都没有注册媒体类型的事实。页面当前状态仍是 Held for Document Update。这个状态必须原样保留，它不是 Verified，也不能为了叙事方便被说成已经验证的勘误。

RFC 9806 给出了后续正式决定。它于 2025 年 6 月以 IETF Standards Track 文档发布，标明 Updates: 7866，说明该文档解决 Erratum 7987，并把 RFC 7866 中每一处 application/rs-metadata 替换为 application/rs-metadata+xml。现行规则已经清楚，现实部署是否跟上仍需另外举证。

更新文档不会抹去旧实现曾经读到的页面

今天打开 RFC 7866 的原始文本，仍然可以看到旧标签。RFC 9806 没有悄悄改写历史文件，而是新增一层公开、可追溯的更新关系。这种档案设计有利于审计：原始说法、问题报告和最终处理都能被重新检查。

代价是证据分散。只读 RFC 7866 的开发者仍可能复制旧字符串；资产清单只写“支持 RFC 7866”，无法说明采用哪种解释；只抓勘误状态的系统可能停留在 Held，而没有把它与后来的更新 RFC 关联起来；只查 IANA 的审计又只能确认名称已经登记，无法确认任何软件版本实际消费过该登记。

因此，四类记录回答的是四个不同问题。RFC 7865 表明元数据类型原本如何命名；RFC 7866 显示矛盾在哪里进入线上的协议流程；Erratum 7987 保存报告及其编辑状态；RFC 9806 提供正式更新与注册。没有一份记录是运行中软件的清单。

IANA 关闭命名缺口，而不是上线缺口

RFC 9806 明确指出 2016 年的两份 RFC 都没有完成注册，并给出所需模板。类型是 application，子类型是 rs-metadata+xml，没有必需或可选参数，编码规则按 RFC 7303 与 application/xml 对齐；使用者是 Session Recording Client 与 Session Recording Server，预期用途为 COMMON，变更控制方为 IETF。

截至 2026 年 9 月 20 日捕获的 IANA Media Types 登记表确实包含 application/rs-metadata+xml，并引用 RFC 7865 与 RFC 9806。这一行证明公共命名已经协调完成，却不能告诉运营者某个发行版是否加入了新字符串、某项配置是否启用它、中间代理是否改写它，或者归档是否保留了收到的原始值。

+xml 后缀的证明范围同样有限。RFC 7303 让通用软件识别这是 XML 家族的 MIME 实体，但它不能证明文档符合 SIPREC 模式、属于正确的 Recording Session，也不能证明完整快照和增量更新之间保持一致。

真正的修正发生在 MIME 信封内部

RFC 7866 允许 SRC 在 INVITE 或 UPDATE 中发送完整快照或局部更新。当一个 SIP 消息同时携带 SDP offer 与元数据时，外层正文必须是 multipart/mixed：一个部分装载 SDP，另一个部分装载录音元数据，且元数据部分使用 Content-Disposition: recording-session。

所以，互操作凭据不能只有“RFC 9806 已支持”这一项。它需要关联 SIP 方法和受限标识符、外层 Content-Type 与 boundary、元数据部分的 Content-Type 与 Content-Disposition、正文哈希、XML namespace、完整或局部更新状态，以及对端的解析结果。

结果也不能被压缩成“会话成功”。SRS 必须按顺序维护局部更新；内部状态丢失后，可以请求新的完整快照；发现元数据语法或语义错误时，还可以终止 Recording Session。其他层面的 2xx 响应，不能被提升为这条元数据链已经被接受的证据。

录音文件存在也不够。RFC 7866 没有规范存储与回放。音频可能已经保存，而元数据被延迟、拒绝、标准化成内部值，或者以旧标签建立索引。修正凭据必须继续追踪到归档保存的标签、索引规则以及随后回放或导出的解释结果。

兼容性会让最后一个旧节点消失在成功率里

迁移期同时接受 application/rs-metadata 和 application/rs-metadata+xml，可能是合理的稳定性措施。它让旧对端继续工作，也给新生成器留下部署窗口。但这不是 RFC 9806 的强制要求，而且每一次兼容成功都会降低“成功”作为迁移证据的强度。

如果服务器永久接受两个值，过期客户端就不会暴露；如果网关把旧值改成新值，下游遥测会误以为源端已经修正；如果日志在记录前把两个值统一为同一个内部枚举，剩余旧流量就失去可见性。

可靠迁移必须规定方向和退出条件。新生成器只发修正后的值；解析器仅在指定对端或批次内暂时双重接受；中间改写同时记录收到值和转发值；每项例外都有负责人，并根据实际流量而非日历猜测来关闭。

一张修正保管凭据

这里提出的“修正保管凭据”是 Daniel Kade 的编辑性控制，不是 RFC 9806 字段，也不是 IETF、RFC Editor 或 IANA 的要求。

第一部分固定文档链：两份原始 RFC 的具体段落，Erratum 7987 的编号、日期、状态和替换内容，RFC 9806 的文档类别、更新关系与替换规则，以及带日期的 IANA 条目和模板哈希。

第二部分绑定实现：SRC 与 SRS 的产品、版本、build、解析器和生成器模块、配置代次、每个方向接受与发出的精确标签。旧别名是拒绝、接受、标准化还是改写，都要连同使行为可观测的规则一起保存。

第三部分记录交易：SIP 方法、受限标识符、Accept 和 Content-Type、multipart boundary、Content-Disposition、元数据正文哈希与 namespace、快照状态、SDP 绑定和对端结论。拒绝、快照请求、会话终止不能统一折叠成“录音成功”。

最后连接归档：保存标签、索引键、标准化规则、导出表示与回放结果，再附上部署批次、新/旧/未知流量计数、canary 结果、兼容窗口、负向测试、回滚触发条件、负责人、别名退出决定和残余例外。

规范发布证明规则存在；保管凭据证明规则在哪里运行过。

证据边界

公开来源能确认矛盾、勘误、更新与登记状态，却没有 SIPREC 产品或部署普查，没有厂商版本支持矩阵，没有新旧标签占比，也没有把事故归因于这处差异的记录。本文不指称任何具名实现过时或不合规。

文中风险路径是可以执行验证的场景，不是已经观察到的故障。它们来自协议的明确表面：精确媒体类型、multipart framing、XML 解析、更新序列和归档处理。部署方应在本地逐项验证，而不能把 RFC 9806 的存在当成运行证据。

来源