摘要

  • SDP 的 o= 行同时放入稳定的会话身份 tuple 与独立的 sess-version；描述更新，不必把会话改名。
  • 通用 SDP 要求描述变化时版本增加；Offer/Answer 更严格：修改后的 offer 除版本精确加一外必须保留原 origin，复用旧版本则必须携带完全相同的 SDP。
  • 更大的版本号能帮助识别陈旧描述，却不能认证发送方、接受提案、授权媒体、证明同意或证明数据真正传输。

同一场会话需要两种连续性

早期多媒体公告面对的不是静态文件。会议可以改时间，呼叫可以增加视频、暂停音频、换接收地址。如果每次修改都生成新身份，参与者会失去“仍是同一场会话”的线索；如果身份永远不变却没有修订号，旧公告又可能覆盖新公告。

SDP 把答案压进一行：

o=<username> <sess-id> <sess-version> <nettype> <addrtype> <unicast-address>

用户名、会话 ID、网络类型、地址类型与 origin 地址共同组成会话标识。sess-version 则只排列这条身份谱系里的描述版本。接收方必须先确认两份描述属于同一 tuple，之后才有资格比较版本号。只看 sess-id，或跨不同 origin 比较数字，都越过了证据边界。

Origin 不是身份证明

字段名很容易诱导错误理解。username 可以是登录名，也可以在没有相应概念时写成 。现行规范还允许为了隐私使用任意用户名与私有 origin 地址，只要完整 tuple 的唯一性不受破坏。

因此，o= 是描述的命名空间，不是人的凭据。origin 地址也不必等于媒体目的地址。一个形似 NTP 时间戳的 sess-id 只是降低冲突概率的分配办法；它不证明时钟同步，不证明创建时刻，更不证明填写者拥有该地址。

这种克制很重要。系统可以用 tuple 关联版本，却仍需由外层信令回答“谁发来的”“途中是否被改过”“此人是否有权提出改变”。

修订判断留在每个接收方

SDP 规定，描述发生修改时，创建工具要提高 sess-version。代理或参与者可以保存已接受描述的完整身份、版本与正文指纹；新副本到来时，它无需询问一个全球版本服务，就能拒绝明显落后的状态。

这里的数字只是相对证据。通用 SDP 要求“增加”，没有要求所有应用都精确加一；建议采用时间戳，也没有把它变成民用时钟；不同身份 tuple 下的版本更没有共同的排序空间。

真正可审计的记录不是“我见过 42”，而是“在这个 origin tuple 与信令上下文里，我见过版本 42 的这组确切字节，并作出了这个本地决定”。

Offer/Answer 把规则收得更紧

SDP 最初偏向会话描述。Offer/Answer 为两个 agent 如何形成共同视图补上状态机，同时把一个依赖暴露出来：SIP 等上层协议负责传送、关联、排序、拒绝与并发冲突处理。

在这个模型里，agent 修改自己先前的 offer 时，新 o= 行除版本外必须完全不变，版本必须精确加一。稳定字段说明仍是同一条提案谱系；一步增长说明这是该 agent 的下一次修订。

反向约束同样关键。版本没有变化，SDP 就必须与该版本原有正文完全一致。相同 offer 可以作为 no-op 再发，接收方仍要给出有效 answer；但发送方不能把新内容藏在旧版本号下面。

这形成一个强审计信号：同一个 (origin, version) 出现两份不同正文，不是两个“同等有效版本”，而是相互冲突的证据。到达先后不能自动修复冲突。

Offer/Answer 还要求 session ID 与版本可放入 64 位有符号整数，初始版本低于 2^62 - 1，以避开回卷。它是该应用的寿命约束，不是 DNS 式环形算术，也不是跨会话比较的许可。

版本变大，仍只是一项提案

Offer/Answer 没把版本推进等同于接受。answerer 可以接受兼容的流、拒绝部分选择，或让外层信令拒绝整个 offer。拒绝发生后，会话回到此前的描述状态。

并发也不由版本号裁决。一个 agent 在等待自己 offer 的答复，或尚未答复对端 offer 时，不能继续发新 offer。双方同时提出修改会形成 glare，要由上层协议解决。“数字大者胜”不是协议规则。

即使 answer 有效，也只说明描述层达成了结果。它不能证明媒体包到达、编解码器运行、防火墙放行、用户同意、录音合法、计费成立或业务完成。

新鲜度没有制造信任

攻击者同样会写一个极大的数字。Offer/Answer 因而要求承载它的应用信令提供端到端认证与完整性保护；接收软件还要独立执行准入与用户同意政策。

认证说明被认可的来源，完整性说明传输中是否被改写，origin tuple 声称描述谱系，版本声称修订顺序，Offer/Answer 状态记录提出、接受或拒绝，媒体观测记录实际效果。任何一项都不能替代其余几项。

SDP 的历史价值并非创造了一个拥有权威的版本号，而是让身份与变化各有坐标。接收方因此能在没有中央修订机构的情况下判断旧与新，同时保留拒绝改变的本地权力。

来源与证据边界

规范链条来自 RFC 2327、RFC 4566、RFC 8866 与 RFC 3264。它们证明语法与 Offer/Answer 规则，不证明当前产品实现、某个真实发送者的身份、一次业务变更的正当性或媒体交付成功。