摘要

  • RFC 3327 允许代理在 REGISTER 经过时加入有序 Path；注册成功后，注册服务器将其与 AOR/Contact 绑定关联并在响应中返回。
  • 归属域代理之后可把保存的向量放进 Route，转发发往该 Contact 的请求。这个向量并不证明 REGISTER 数据包实际走过哪些节点。

绑定是关联键，不是拓扑地图

SIP 注册服务器可以保存用户代理（UA）所在的地址。这个绑定回答了一个有限的问题：发往这个 Address-of-Record（AOR）的请求应交给哪个 Contact？它不一定回答另一个问题：请求还必须经过哪些中间代理才能到达这个 Contact？

当 REGISTER 经过边缘代理，而归属域代理无法从 DNS 或自己的路由表推回这些节点时，缺口就出现了。UA 可能从被访网络注册，注册服务器则位于别处；之后的入站请求可能必须经过 Contact URI 没有显示的节点才能返回。RFC 3327 于 2002 年 12 月发布，为这些节点提供了在注册交换中留下路由向量的方法。

“Path”这个名称容易让人以为它在测量网络路径，但这不是它的用途。REGISTER 经过的代理可以添加 Path 值。注册服务器把这些有序值与 Contact 和 AOR 的绑定一起保存，并在成功的 REGISTER 响应中反射回来。以后，归属域代理查到该绑定时，可以把向量放入预装载的 Route 头部，让新请求经过其中的代理。保存的是绑定所需的路由信息，不是 REGISTER 事务的分组抓包。

路由跨过了事务边界

Path 看起来像 Record-Route，但作用期限不同。Record-Route 建立的是当前对话内后续请求的路由。Path 则随 REGISTER 及其成功响应传递，为未来对话保存代理序列。RFC 3261 已有的路由机制负责执行 Route；RFC 3327 让这组路由引用跨越注册事务。

它的适用范围是明确的：用于经过或源自用户归属域的请求。Path 值遵循 Route 元素的语法，并使用松散路由参数 ;lr。UA 可以用 Supported: path 表示支持；通常，UA 未作此声明时，代理不应添加 Path。如果注册服务器收到 Path，却没有收到支持声明，RFC 推荐拒绝，但仍允许本地策略决定。

所以历史变化并不是 SIP 开始知道每个数据包经过了哪里，而是注册事务成为代理附加路由上下文的时点，这段上下文会影响后续入站请求。注册服务器也把 Path 返还给 UA，让新增代理有机会被查看，而不是悄悄将其变成全网通用的拓扑数据库。

向量不是证人

RFC 3327 明确允许了解拓扑的代理加入一个指向其他节点的 Path 值，即使这个值与 REGISTER 实际经过的路由不同。这个条款决定了如何理解 Path：它是在代理和注册服务器策略下组装的有序路由指令，不是网络分组经过路径的取证记录。它本身不能证明某个代理转发过先前消息、建议路由仍然可达，或未来呼叫一定送达。

这一设计也划出了安全边界。若代理插入了自己，它可能被放入保存的向量，进而进入未来请求路径并截获呼叫。RFC 3327 因此讨论传输完整性和相互认证，例如 TLS 或 IPsec；它也描述了受保护的 S/MIME 副本，让 UA 有机会发现返回 Path 被修改。URI 语法有效，不等于中间代理已获授权。

后续工作为更窄的用途重用了这套机制。RFC 5626 会把唯一流令牌放入 Path，使边缘代理将未来请求映射回某条客户端发起的连接。这种逐流处理属于后来的扩展，不应倒推成每个 RFC 3327 Path 向量的属性。方向相反的 RFC 3608 Service-Route，则向 UA 提供它自己发出的请求所用的路由，而不是发往 UA 的入站路径。

来源