摘要

  • SDP 有两种不同的“版本”：v=0 表示 SDP 协议格式，o= 中的 sess-version 则在同一个已识别会话内部记录描述的修订。
  • 版本号的作用域由来源元组限定。跨来源只比较十进制数字，或把形似时间戳的值当成可信时间，会丢掉证明连续性所需的关键证据。

自动选择最高值，恰好选掉了身份

设想主控制器故障后，备用控制器开始发出会话描述。旧控制器使用 controller-a.example，新控制器使用 controller-b.example；两边的版本生成器各自运行。备用机发来的数字更大，可能只是它自己的起点更高。旧机的数字更大，也可能只是另一套时钟或计数规则。

如果数据库只保留 session_id 和最大版本，它便制造了一个标准从未定义的全局序列。到达时间、创建者声明的版本顺序、获准接替旧来源，是三件事。接收较晚不等于修订较新，数字较大不等于来源获权，语法正确更不等于会话已经生效。

v=0 并不是这次会话的第零版

RFC 8866 要求 SDP 以 v=0 开头。这里的 v= 指 SDP 协议自身的版本，而且规范明确说没有次版本号。增加视频、变更 codec 或移动媒体地址，都不应把它改成 v=1。

紧随其后的 o= 才携带会话来源与修订信息。它由六个值组成：用户名、会话 ID、会话版本、网络类型、地址类型和单播地址。规范要求创建工具在描述被修改时提高 sess-version，并建议采用时间戳来分配数值。

所以两种错误方向相反。普通会话更新若递增 v=，便把内容变化误写成协议格式变化；内容已经变化而 sess-version 不动，则把不同字节伪装成同一修订。成熟的系统会同时保存两者，但不混淆其作用域。

五个字段构成身份，第六个字段排列修订

RFC 8866 把用户名、会话 ID、网络类型、地址类型和单播地址组成的元组定义为会话的全局唯一标识。单拿任何一个字段都不够。另一台主机复用相同会话 ID，不会因此继承原会话；熟悉的用户名也不是身份认证；地址改变，更不是天然透明的延续。

1998 年的 RFC 2327 对设计动机说得很直白。Handley 与 Van Jacobson 写道，这个版本用于帮助代理公告在“同一会话”的多份公告中识别最新者。“同一会话”正是比较边界。现行规范保留了完整身份元组，也保留了描述发生修改时提高版本的要求。

因此，主备切换若有意改变来源元组，就需要单独的迁移记录：谁批准接替、旧来源与新来源是什么、何时生效、哪些会话状态被继承、如何撤回。更大的整数不能替管理层或协议参与方签署这条边。

在 offer/answer 中，同版本必须同内容

RFC 3264 对 offer/answer 场景规定得更严。修改既有会话的 offer，其 o= 行除来源版本加一外，必须与上一份 SDP 相同。如果版本没有增加，SDP 必须与此前使用该版本的内容完全一致。重复收到未改变的版本，在协议意义上等同无操作，但回答方仍要给出有效 answer。

这提供了一项强而窄的检查：同一来源身份、同一版本、不同内容，不应被“最后到达者胜出”掩盖。系统应保留两份原文与哈希，把该谱系标为冲突，再按本地错误策略处理。

反过来，版本增加只证明创建者把描述声明为新修订。它不证明对方接受了 offer，不证明媒体包沿新地址抵达，也不证明用户听到了声音。描述生成、协商接受、网络收包和应用结果必须分别留痕。

时间戳的外形不等于可信时钟

RFC 8866 建议用自 1900 年 1 月 1 日 UTC 起计的秒数分配会话 ID，并同样建议为会话版本使用时间戳。这是创建者获得独特、递增十进制数的一种实用办法，不是可信时间服务。字段由创建者填写，无法单独证明时钟同步、接收时刻或组织授权。

同一 RFC 在安全章节明确提醒：除非会话描述来自已认证、受完整性保护的传输，并且来源已知且可信，否则不能信任它。于是，一条可审计的修订收据必须在来源元组之外记录传输方式、认证主体和完整性结果。o= 只能表达文档声称的来源，不能自行证明是谁发送或批准了它。

不同层的变化信号不能互相冒名

SAP 提供了一个有用对照。RFC 2974 为 Session Announcement Protocol 定义了自己的 originating source 和 message identifier hash。SAP 哈希改变，会促使接收方重新解析公告内容；SDP 负载仍用自己的来源元组与会话版本标记内容谱系。一层的哈希不能替代另一层的身份。

这种分离符合 SDP 的基本边界。RFC 8866 把 SDP 定义为描述格式，而不是传输协议；它本身也不负责协商会话内容或编码。SIP offer/answer 可以借助 SDP 建立有限协商，SAP、HTTP 或邮件可以承载它。传输收据、描述身份、协商状态与媒体结果必须能够连接，又不能被缩成一个“最新版本”。

Mark Handley 在这条谱系中的位置

RFC 2327 由 Mark Handley 与 Van Jacobson 署名；RFC 4566 的作者是 Handley、Jacobson 与 Colin Perkins；现行 RFC 8866 则署名 Ali Begen、Paul Kyzivat、Perkins 与 Handley。这是一项跨年代的集体标准化成果，不能包装成个人发明。准确保留作者谱系，本身也呼应了文章讨论的来源纪律。

Royal Society 的官方简介称 Handley 为 UCL 的网络系统教授、众多互联网标准的作者和前 Internet Architecture Board 成员，并记录他获得 2007 年 British Computer Society Roger Needham Award 与 2012 年 IEEE Internet Award。ACM SIGCOMM 在 2019 年表彰他对互联网多媒体、组播、拥塞控制、多路径网络和相关协议标准化的贡献。

这个数字能证明什么

只要完整身份、原始 SDP 字节与可信获取记录都在，sess-version 可以支持一条有限主张：同一创建者把这份描述标为同一会话的较后修订。在 RFC 3264 场景中，它还能暴露同版本异内容，或内容修改却未提升版本的矛盾。

它不能证明另一个来源是合法继任者，不能证明创建者的时钟准确，不能证明发送方有权，不能证明 offer 已获接受，也不能证明媒体到达或用户体验成功。那些结论分别需要迁移授权、传输认证、offer/answer 记录、收包观察和结果测试。

来源