摘要

  • user、header、session、id 与 history 指向不同的信息面，不是一条从弱到强的“隐私等级”轴；每次动作都必须落到具体字段和具体消息方向。
  • Identity/Identity-Info、Path、Replaces、Route、Service-Route 与 Target-Dialog 是明确的非目标字段，但这不等于永远不得处理；签名失效或 Call-ID 关联修复可能产生另一条独立依据。
  • 可审计链条应依次记录：谁提出请求、令牌覆盖什么、另有何种规则、实际改了什么、后续状态如何维持、业务语义是否连续，以及哪个观察者最终看不到什么。

同一条消息，不是同一种权限

设想一个隐私服务收到 INVITE。里面有 From、Call-ID、Route、Contact、Identity、SDP，还有一行 Privacy:user。如果系统只有一个“隐私开启”布尔值，那么后面的逻辑很容易变成：扫描所有疑似身份信息，能删则删，能替换则替换。

这正是边界丢失的起点。From 可能属于本次请求的目标；Route 却承载下一跳语义；Identity 是对其他字段的完整性证明；SDP 只有在相应会话隐私请求下才进入特定处理；Call-ID 一旦变化，又会把义务延伸到后来的 Replaces 与 Target-Dialog。

RFC 5379 于 2010 年 2 月发表，属于 Independent Stream 的 Informational 文档。它明确说明，自己只是解释 RFC 3323、RFC 3325 与 RFC 4244 既有隐私机制的实际使用方式，不改变原有机制，也不创造新的规范性行为。

因此，它不是再发一条更大的命令，而是给已有命令画出边界。这个定位决定了阅读方法：表格中的建议帮助实现者对齐含义，真正的规范依据仍要追溯到相应 RFC；表格没有把说明文档变成新的治理中心。

五列不是五档强度

RFC 5379 整理的核心值各自有对象。user 面向用户插入、且可由用户侧隐藏的信息；header 面向网络添加的信令信息；session 面向会话描述中的信息；id 面向 RFC 3325 信任域中的 P-Asserted-Identity；history 面向 History-Info。none 与 critical 又处理是否执行及无法满足时怎么办。

这些词不能排成“普通、增强、最高”三档。请求 session，不代表同时授权所有头字段改写；请求 user，也不意味着凡是看起来像标识符的值都归服务任意处置。

表格把这个差异落实到动作。某些字段应删除，某些不应新增，某些需要匿名化，某些格子则没有动作。请求与响应也分开，因为同一字段在不同方向上的语义和暴露面不一定相同。

SDP 的范围尤其清楚：Privacy:session 对应 c、m、o、i、u、e、p 行。这里的“session”不是自然语言中“整个通话”的同义词，而是一个带有目标集合的协议值。实现若依据词感扩大范围，就不再是在执行令牌，而是在制定自己的政策。

所以，最小执行单元不是 privacy=true，而应至少包含：具体值、消息方向、字段类型、规定动作、适用条件、规范来源和实现版本。失去其中任何一项，日志都可能只证明服务“做过事”，无法证明“做对了事”。

非目标字段为何仍然敏感

RFC 5379 明确列出 Identity/Identity-Info、Path、Replaces、Route、Service-Route 与 Target-Dialog，说明它们不是这些 priv-value 的目标，不应仅因为 Privacy 头中出现某个值就被匿名化或修改。

这份名单并没有声称它们毫无隐私风险。Path 可能暴露访问域或管理域；Route 会出现代理地址；Identity-Info 会指向签名者证书；Replaces 与 Target-Dialog 会把不同消息关联到一个对话。

但“存在风险”和“本请求授权我修改”不是同一句话。Path 的存在是为了让请求能够抵达已在访问域注册的用户代理。只删除暴露信息却没有功能等价的替代路径，会让用户失去可达性。Route 是强制经过一组代理的指令；随意匿名化后，路由本身就不再成立。

Service-Route 属于注册服务提供的路径机制，不能因为用户发起隐私请求就自动纳入用户信息清洗。Replaces 与 Target-Dialog 则用于指向另一个对话。它们可能含有可关联值，但粗暴改写会让转接、接听或对话替换找不到目标。

这说明敏感性只是风险证据，不是权限来源。真正的问题应该是：哪个主体以什么规则要求处理这个字段，处理后必须保持哪一项协议语义，失败时由谁承担后果。

“不是目标”也不是绝对冻结

若把非目标清单编码成“任何情况下都不得动”，系统会犯另一种错误。Identity/Identity-Info 展示了独立因果链。

RFC 5379 使用当时的 RFC 4474 机制说明：Identity 签名覆盖 From、To、Call-ID、CSeq、Date、Contact 与消息体。隐私服务若基于合法目标修改了其中一项，原有签名就不再证明修改后的消息。Identity 本身不是 user、header 或 session 的直接目标，但继续携带已经失效的完整性证明同样不正确。

此时移除 Identity 的依据，是“它保护的输入发生变化”，不是“Privacy 令牌把 Identity 也纳入了目标”。审计记录应当保留这两步：第一步依据请求修改被保护字段；第二步依据完整性规则撤销失效证明。

RFC 4474 后来被 RFC 8224 取代。历史机制不应被当作今天的直接部署指南。然而因果模型没有过时：任何派生证明都依赖一组输入；输入变化时，证明必须撤销或重新生成，并且要保留导致变化的依据。

如果日志只写“因隐私删除 Identity”，就把依赖修复伪装成了用户授权。久而久之，机构自己的行为会借用用户请求的名义，边界再也无法审计。

Call-ID 把瞬时动作变成长期义务

Call-ID 更能说明为什么一次改写不是一次性事件。服务把 C1 改为 C2 后，事实上创建了一张关联表。以后 In-Reply-To、Replaces、replaces 参数或 Target-Dialog 可能再次引用这个对话。

后续消息未必带有 Privacy 头，甚至可能由另一方发起。服务仍可能需要把 C1 与 C2 恢复或翻译。这次动作不是执行新的 Privacy:user，而是在偿还第一次改写产生的状态债务。

RFC 5379 的转接示例把后果写得很具体：初始 INVITE 经过隐私服务后使用 C2；REFER 或新的 INVITE 却可能携带 C1。若后续消息没有经过掌握映射的同一服务，或映射已经过期，接收方就找不到要替换的对话。每条消息的语法都可能正确，转接仍然失败。

因此，改变 Call-ID 之前必须回答：服务能否持续位于相关信令路径？映射要保留多久？主备节点如何同步？重启后能否恢复？异步转接和长时对话如何处理？当映射缺失时，是拒绝、透传，还是触发人工调查？

只在发出 C2 时打上“成功”标记，会把未来的失败外包给其他组件。谁创造了映射，谁就必须拥有映射的生命周期，直到协议中不再有任何消息依赖它。

本地政策必须用自己的名字出现

RFC 5379 允许实现方式和网络政策影响如何遮蔽目标数据，也承认某些非目标字段可能出于其他原因需要处理。这个弹性不等于可以把所有动作都归因于用户请求。

运营商可能实施拓扑隐藏；信任域可能在不可信边界删除 P-Asserted-Identity；完整性服务可能删除失效签名；关联引擎可能在先前修改 Record-Route 后恢复 Route。它们都可能合理，却不是同一个权力来源。

若日志只留下“已应用隐私”，机构就无法回答是谁决定、依据什么、修改了什么。用户发出的有限信号会被用来替机构政策背书。正确做法是让每项本地政策带上自己的名称、版本、所有者、适用面与结果；让关联修复引用最初那次转换；让用户请求保持为用户请求本身。

这与更广泛的记录治理一致：记录是对一层现实的证据，不是创造其他层现实的命令。Privacy 头记录请求，目标表记录解释边界，执行日志记录动作，调用轨迹记录协议结果，观察测试记录实际暴露。谁也不应代替谁。

“通话成功”和“隐私成功”分别需要证明

通话能够建立，不代表预期信息没有泄露。接收方看不到主叫身份，隐私服务仍可能知道；SDP 的媒体地址可能暴露位置；计费与诊断日志可能保留可反查关联；下游扩展字段也可能重新带出信息。

隐私结论必须说明观察者。具体要隐藏哪个身份或属性？不让谁看到？覆盖哪些请求、响应和媒体阶段？哪些内部系统仍能关联？状态保留多久？

测试也必须走完整路径，而不是只看配置截图。应捕获隐私服务前后的消息，执行注册、初始建链、响应、对话内请求、转接、回呼与终止；同时验证目标观察者没有收到受保护信息，以及用户仍能完成预期功能。

表格一致性为这种测试提供基础，却不能代替结果证据。RFC 5379 改善的是实现解释的一致性，不是对任何部署签发“已经隐私”的总收据。

文档状态和注册表同样不能越权

RFC 5379 的 Informational 与 Independent Stream 身份不是脚注。它明确说规范性用语来自既有 RFC，自己没有新增规范行为。实现者可以用它解决歧义，但应把每项义务链接回真正的规范来源。

时间也要保留。RFC 4244 后来被 RFC 7044 取代，RFC 4474 被 RFC 8224 取代。旧文档的例子可以解释设计张力，却不能自动代表当前部署要求。

IANA SIP 参数注册表又是另一张收据。它证明某个字段或值有共同登记的名称与参考资料，不证明某个产品支持它，更不证明实现会正确执行、保存状态或实现用户期望的隐私。

一套可审计的最小记录应包括：

  • 原始消息、方向、请求主体与观察者目标；
  • Privacy 头中的每一个值及适用规范；
  • 每个字段命中的目标表行与动作；
  • 独立本地政策或协议修复依据；
  • 字段前后状态及失效的派生证明；
  • 标识符映射、保存期限与持有节点；
  • 后续消费映射的消息；
  • 路由、对话、转接、媒体的实际结果；
  • 对各相关观察者执行的暴露测试。

这条链能阻止三种偷换：令牌存在不等于拥有全字段权限；消息被改不等于协议成功；通话成功也不等于隐私实现。