摘要

  • RFC 5359 把必要控制消息、可选控制消息和媒体路径画成不同线型。信令序列完成，只能证明相关事务和对话可能推进；SDP 协商、媒体双向可达、终端播放与用户体验仍需独立观察。
  • 文档将示例称为经过仔细检查和工作组审阅的配套场景，同时明确底层规范才是协议问题的权威来源，而且服务可以通过 3pcc、B2BUA 等其他架构实现。审阅提高参考价值，不证明某一实现实际选择了该路径。
  • 示例为可读性省略真实 Digest、重复 Call-ID、常从一开始 CSeq，并用 ... 代替部分 Content-Length。它可以成为测试生成器的输入，却不是可直接发送的逐字节报文，更不是身份、授权或服务结果收据。

双线不是已经送达的声音

RFC 5359 的重点是 SIP 信令。它展示的 SDP 通常只覆盖简化的音频协商，并把更复杂的 offer/answer 情形交给其他文档。图中媒体使用双线，控制消息使用另一种线，这已经提示二者不是同一种事实。

一个 INVITE 事务可以完全成功，媒体仍可能因地址不可达、编解码不兼容、网络策略、防火墙、媒体中继或终端渲染失败而沉默。200 OK 说明某个协议阶段接受了协商，不说明用户已经听到声音。

保持也有方向性。把对方置于保持状态的一端通常也会停止发送，但“通常”不消除 sendonly、inactive、接收和播放之间的差别。文档还说明，以 0.0.0.0 表示保持是旧做法，应使用相应的 SDP 方向属性。

因此媒体收据至少要保存 offer、answer、SDP origin 版本、方向属性、媒体地址、编解码、每个方向的包计数、终端渲染状态和用户侧观察。仅有信令截图，不能替代这些记录。

经过审阅的场景仍不是唯一实现

工作组审阅意味着示例不是随意拼出的时序图。它们为呼叫保持、转移、转接、会议、查找、筛选、代接、停泊与自动重拨等功能提供共同讨论基础。

但文档同时说，SIP 及其引用扩展才是协议问题的决定性来源；这些流程并非唯一实现方式。第三方呼叫控制、B2BUA 或其他架构可以把同一服务分配给不同角色。

这两句话应同时保留。审阅证明示例作为设计材料具有质量；底层规范定义协议义务；部署架构决定谁生成消息；运行时证据说明某次执行发生了什么。

BCP 身份也不等于产品认证。它不能证明某个当前系统实现了所有场景、遵循相同拓扑、与另一个系统互通，或为用户交付了完整功能。

省略号必须先被编译成字节

RFC 5359 主动列出示例与实际 SIP 报文的差异。Digest 响应不是实际 MD5 编码，Call-ID 可能重复，CSeq 经常从一开始，首部通常以固定顺序展示，只列出最小集合，报文体长度有时直接写成 ...。

这些简化让长篇流程可读，却也明确阻止读者把文本当作抓包。解析器需要精确的十进制长度；事务需要本次执行唯一且关联一致的 branch、tag、Call-ID 与 CSeq；认证需要真实挑战与计算结果。

从示例到测试夹具之间存在一次编译。应记录原始章节和版本、每个替换值、生成器版本、可选消息规则、最终字节与哈希，以及每个角色如何映射到被测部署。

若这一步不可追溯，绿色结果最多说明测试台接受了自己的重建。它不能证明两个独立实现对规范有相同理解。

箭头顺序不等于状态机等价

图中的 F1、F2 等标签把箭头与详细消息相连。它们擅长表达先后关系，却没有自动记录每个节点在接收消息前后的内部状态。

消息可以通过语法解析，却因事务匹配失败而被拒绝；响应可以有效却在状态过期后到达；代理可以正确转发，而终端不支持某个扩展；功能看似完成，却留下对话或订阅残余。

可执行验证必须把每组字节关联到时间、方向、branch、tag、Call-ID、CSeq、路由集、认证决定、事务状态、对话状态与订阅状态。

两条轨迹可以拥有相同方法名和响应码，却落到不同状态。流程外形是索引，实际状态转换才是执行证据。

架构选择会移动证据保管点

很多示例把功能放在用户代理，并由 SIP proxy 协助。B2BUA 会终止一个对话再创建另一个；3pcc 控制器可能代表终端发起 offer、answer 与控制动作。

用户都可能把结果称为“转移”或“会议”，但证据归属完全不同。谁创建标识符，谁终止 TLS，谁修改 SDP，谁认证身份，谁授权功能，都随架构变化。

测试报告不能只写“符合 RFC 5359 流程”。它要列出每个真实组件的角色和信任边界，并指出每条消息和决定的产生者。

把多种架构压成一张图，会失去故障定位和责任分配所需的信息。RFC 提供设计空间中的实例，不替部署替代归责。

sips 是场景假设，不是握手记录

示例普遍使用 Secure SIP URI，由此假定每一跳都有 TLS 并进行了证书验证。部分场景也展示 Digest，文档允许使用其他安全方式。

写在 URI 中的 sips 不包含证书链、信任库、名称验证、协商参数、终止位置或应用身份映射。一个实现可以显示相同 URI 却验证错误；中间设备也可能改变真正的保护边界。

安全收据必须来自运行路径：握手或等价证明、证书、验证结果、对端身份、保护边界、Digest 挑战与响应状态，以及该身份之后获得的授权。

示例能声明前提，不能声称某次连接已经满足前提。把排版中的安全标记当作执行证明，会让部署借用文档没有观察到的事实。

群组身份决定敏感功能的权限

代接等服务常依赖群组。部门、家庭分机组或呼叫中心成员可能获得外部人没有的特权，包括查看详细对话状态或接管某通呼叫。

RFC 5359 要求通过证书或共享秘密等普通 SIP 方式认证群组成员。但认证只回答“是谁”，不会自动回答“属于哪个群组”或“能做什么”。还需要权威成员来源和版本化策略。

请求可以身份真实、对话定位准确，却仍没有代接或加入权限。NOTIFY 也可以完整可信，却向不该看到的人披露过多状态。

记录中应保留身份凭证、成员来源、有效期、策略版本、请求特权、决定和实际披露字段。正确拒绝是安全控制成功，而不是为了贴合快乐路径而要删除的异常。

REFER 的 2xx 只完成接受

REFER 要求接收方访问指定资源。接受它会建立用于报告进度的事件状态，后续通过 NOTIFY 提供信息。

首个 2xx 证明接收方在该阶段接受请求，不证明新目标接听、媒体移动、旧对话结束或用户得到预期拓扑。后续成功通知同样只覆盖其协议语义。

转移账本要保存发起者身份、Refer-To、授权、订阅、每个通知、新旧对话标识、旧对话释放、媒体观察与用户结果。

只有分开这些阶段，才能看见部分成功，也才能避免让最早的肯定响应替未来步骤背书。

Replaces 与 Join 能定位对象，不能授予权限

Replaces 用新对话逻辑替代已有对话，Join 把新对话加入已有对话。它们支持受理转移、代接、会议等功能。

正确的 Call-ID 和 tags 可以命中目标对话，但命中不是许可。扩展本身的安全要求、身份、群组特权、隐私和本地策略仍然有效。

详细对话标识也可能是敏感信息。群组示例假定有共享理由，现实部署必须证明该信任边界。

应分别保存查找、匹配、身份、授权、状态变化和媒体后果。指向正确对象是寻址收据，不是权限收据。

后续规范改变环境，不会自动改写旧示例

RFC 5359 引用了当时由 RFC 3265 定义的 SIP Events。RFC 6665 在多年实现经验之后取代了它，并以向后兼容方式改进机制。

这种演进不否定历史示例，也不证明当前产品采用了更新。测试必须明确自己依据的每一份规范版本，并记录如何把旧示例映射到当前规则。

本次冻结的 RFC Editor errata 页面显示一个 Rejected 报告，没有显示 Verified、Held for Document Update 或 Reported 分组。这只是带日期的文档状态，不证明绝对无误，也不允许悄悄采用被拒内容。

文档之间的关系是规范演进证据；实现支持和本次执行仍要另外证明。

场景生成器本身必须接受审计

将 RFC 5359 用于自动化的稳妥方法，是让它驱动场景生成器。生成器为占位符赋值、计算长度和认证、选择可选分支、映射角色并定义断言。

这些选择决定测试含义，因此生成器版本、配置与输出都必须保存。断言要分别覆盖解析、事务、对话、授权、媒体、清理和用户结果。

负面测试也不可缺少：错误证书、群组外身份、过期对话、长度不符、REFER 被接受但未完成、信令成功而媒体缺失。

失败时要保留原始输出和状态。若只是不断重生成直到绿色，示例就会变成移动的裁判，永远看似预测了结果。