摘要

  • RFC 3323 把隐私定义为对特定一方隐藏特定身份；呼叫者可对接收方匿名，同时仍被中介、认证系统或隐私服务识别。
  • Privacy: critical 不是成功证明，而是失败规则：若服务无法兑现所请求的隐藏功能，请求应被拒绝，不能带着暴露信息继续前进。

隐私不是一个全局布尔值

同一条 SIP 消息可以对不同观察者呈现不同身份。用户可能不让最终接收方知道地址，却向本地域中介透露；也可能用端到端保护把信息交给接收方，同时不让路径上的部分中介读取；还可能两边都隐藏。只记录“anonymous=true”，会丢失判断真伪所必需的观察者。

用户代理能够先做一部分工作：省略可选的 Call-Info、Organization 等字段，把显示名写成 Anonymous，在 From 使用保留的匿名 SIP 域，并避免 Call-ID 直接携带主机名或 IP。可是 Contact 和 Via 常常必须提供能继续路由会话的地址，SDP 也可能暴露媒体端点。随意伪造这些字段会换来另一种失败——后续请求找不到参与者。

因此网络隐私需要中介。隐私服务读取原始信息，删除或改写接收方不应看见的内容，并承担把后续消息送回匿名用户的责任。它通过知道或控制被隐藏的路线来提供隐藏。对被叫匿名，不等于对服务提供者匿名。

请求、执行与失败是三件事

Privacy 头可以请求 header、session、user。第一种要求中介处理用户无法自行安全删除的路由字段；第二种要求代理会话流量以隐藏网络地址；第三种要求网络替能力不足的终端完成用户级清理。

这些 token 只证明偏好被写入消息，不证明服务实际执行。RFC 3323 明确承认法律限制、功能未实现、配置错误或异常条件都可能使请求无法满足。若审计系统把 header 的存在当作隐私成功，就会把意图冒充结果。

critical 提供关键边界：无法提供时应拒绝请求。静默转发会让一次寻求保护的行为成为泄露身份的原因，且泄露不可逆。相反，none 要求即使预设配置通常会匿名化，也不得对本消息应用隐私功能；中介不能删除或改写这个选择。协议保护的是用户明确意图，而不是盲目最大化匿名。

到达服务前也会泄露

文档强烈建议通过 TLS 等安全路径直接联系隐私服务。否则身份可能在抵达删除点之前就被其他中介看见，隐私请求也可能被移除。验证证书和缩短路径减少了暴露面，却不会让服务本身失明。

会话隐私尤其说明这种交换。媒体中继可以让对端看不到用户 IP，但未端到端加密的媒体可能被中继观察。对接收方的地址隐私与对隐私服务的内容机密性是两项不同性质。

代理和接收者仍可拒绝无法识别来源的请求。用户有隐藏身份的选择，对方也有不处理匿名流量的选择。RFC 3325 同期处理可信网络中的身份断言，后来的身份与历史 RFC 又扩展了证据面；这些文档共同说明，身份可以对一个信任域已验证、对另一个观察者被隐藏。

RFC 3323 的历史意义不在把一个名字替换成 Anonymous，而在把隐私变成可追踪的责任链。必须知道谁原本看得到、谁负责删除、谁仍能关联、失败是否关闭。少任何一项，“匿名”都可能只是界面文字。

响应路径不能临时补进隐私服务

SIP 响应沿请求经过的节点返回，接收端在收到请求以后，不能凭空把新的隐私服务塞进既定响应路径。若被叫方希望自己的 Contact 或当前位置不暴露，就必须提前让入站请求经过相应服务，例如使用匿名回呼地址、通过服务注册匿名 Contact，或维持受保护的持久连接。

这条规则把“稍后再匿名”排除在外。路径是隐私机制的执行输入，不是事后可修饰的元数据。只有提前部署的中介才能在看到原始字段的同时承担替代路由。若运营记录只保存最终匿名头，却没有保存请求实际经过的节点，就无法证明响应也受到了同样保护。

头部隐私与会话隐私不能相互代替

隐藏 From、Contact 或 Via，并不自动改变媒体包的来源；通过媒体中继隐藏网络地址，也不会清除 SIP 头中的组织名、设备信息或 Call-ID。RFC 3323 把 header 与 session 分开，正是为了防止一项成功被误报为整体成功。

测试也应保持这种分离。头部测试要验证各字段在目标观察者处的可见性；会话测试要验证 SDP 改写、媒体路径和地址暴露；认证测试要说明哪个域仍掌握真实身份。只有每一项都有独立证据，才能准确说“对接收方隐藏了地址，但本地域仍能认证并计费”。这种句子比“匿名呼叫”更长，却也更接近事实。边界必须留下。

Sources