摘要

  • RFC 3323 将隐私定义为对特定对话参与方隐藏信息，而不是保证 SIP 请求完全不带身份线索。
  • 隐私服务可以隐藏头字段，却仍须保存并恢复对话路由状态；信任边界因此转移到了中介服务，并未消失。

匿名必须说明“对谁”

2002 年的 SIP 隐私不是“实名”与“匿名”之间的单一开关。RFC 3323 把隐私理解为：让一个或多个对话参与方看不到某些信息。呼叫者可以不向被叫者显示真实姓名，却仍让可信服务知道是谁发起请求；另一种部署则可能希望向用户隐藏网络细节。关键问题始终是：对哪个观察者匿名？

因此，From 字段使用匿名值，并不意味着请求中不能存在可用地址。规范建议匿名 SIP URI 使用 anonymous.invalid，但同一对话内的后续请求仍须抵达正确端点。消息可以隐藏面向人的身份，同时保留 Contact、Via、Record-Route 或其他维持路由所需的信息。这里的隐私是对协议状态的受控展示，不是把状态抹去。

隐藏信息的服务必须记住它

RFC 3323 区分用户层隐私与网络提供的隐私。Privacy 头可请求 user、header 或 session 等处理；none 要求服务不要采取隐私动作；若请求带有 critical 而服务不能提供全部层级，就应失败，而不能悄悄降低保护。它们表达的是策略，不是身份认证、呼叫授权、媒体加密，也不能证明每个中间节点都遵守了要求。

头字段隐私暴露了运行成本。隐私服务可以作为 B2BUA，移除或改写可识别身份的头字段，将 Contact 改成自己的地址，并在本地保存原始路由值。后续对话消息返回时，它必须恢复继续通信所需的信息。接收方看到的更少了，服务手中的特权状态却更多；呼叫者并没有对该服务匿名。

会话隐私要求更高：需要 B2BUA 以及媒体中间设备或流量匿名器。由于服务进入通信路径，RFC 3323 不建议在缺乏端到端媒体保护（例如 SRTP）时使用会话隐私。这是架构上的告诫，不是关于现实部署比例的结论。

身份隐藏会形成新的控制点

这份规范留下的历史张力是：接收方知道得越少，通信可能越依赖执行隐藏的组件。服务决定删除、保留、改写和恢复什么；为了对话连续，它还必须被信任。

RFC 3261 规定 SIP 对话与路由集的上下文。RFC 3325 随后讨论可信网络内的断言身份，并明确不定义跨信任域的一般身份模型。这些规范处理相邻边界，而不是给出万能隐私方案。RFC 3323 也没有证明它被广泛部署或实现互通。它记录的是一种取舍：减少一方能看到的信息，同时保留通话所需状态，并明确指出承担这一取舍的中介服务。

来源