好的，专家讲师。我将按照既定规划，继续为您撰写SIP协议深度解析系列的第七篇。本篇将聚焦于 IMS 体系中最能体现电信级要求的私有头域（P-Header），特别是身份断言机制，这是实现信任域内身份传递、业务触发和计费准确性的基石。
VoLTE高清语音技术精要（七）：私有头域与身份断言：P-Asserted-Identity (PAI) 和 Privacy
1. 导论：信任域内的“通行证”
SIP 协议通过标准的 From 和 To 头域来定义会话的逻辑发起方和接收方。然而，在电信级 IMS 网络中，这些字段的内容并不可信，因为终端用户可以随意修改其显示的名称（Display Name），甚至部分 SIP URI。
为了确保 IMS 信任域（通常指 P-CSCF 到 S-CSCF、AS、I-CSCF 等核心网元之间）内部传递的身份是经过网络认证和鉴权的真实、可信身份，3GPP 引入了一系列 SIP 私有头域（P-Header）。其中，P-Asserted-Identity (PAI) 头域扮演了至关重要的角色，它是用户在 IMS 网络中的“真实通行证”。
本章将详细解析 PAI 的机制、它与用户偏好身份 P-Preferred-Identity (PPI) 的区别与转换，以及如何通过 Privacy 头域来控制这些身份的暴露，实现匿名呼叫等业务。
2. 身份的基石：P-Asserted-Identity (PAI)
P-Asserted-Identity (PAI) 头域用于在 IMS 信任网络内部传递一个经过鉴权的、可信的用户身份。
2.1 PAI 的核心定义与用途
PAI 承载的内容是经过 P-CSCF 或其他受信任实体认证的公共用户身份（Public User Identity, PUI）。
| 特性 | P-Asserted-Identity (PAI) | From/To 头域 |
|---|---|---|
| 用途 | 传递经网络认证的真实身份，用于计费、业务触发（iFC）和合法拦截。 | 用于建立 SIP 对话（Dialog）和标识会话的逻辑归属。 |
| 信任等级 | 信任域内可信。 | 仅在对话建立方面有意义，但身份内容不可信。 |
| IMS 网元处理 | 由 P-CSCF 插入/删除/校验。S-CSCF 用其进行 iFC 业务触发。 | 保持不变（除非被 B2BUA 重构）。 |
| 格式示例 | <sip:[email protected]> | <sip:[email protected]>;tag=... |
在 IMS 业务中的作用： S-CSCF 收到对话的最初请求或独立会话的请求时，会取出请求消息中 P-Asserted-Identity 头域中的公共标识对应的初始过滤规则（iFC），并检查该请求是否与下一条未执行的初始过滤规则相匹配，从而触发相应的 AS 业务。
2.2 用户身份偏好：P-Preferred-Identity (PPI)
与 PAI 相对的是 P-Preferred-Identity (PPI) 头域。
- 定义：PPI 由 UE（用户终端） 在发起请求时携带，用于向 IMS 网络表明用户希望使用的公有用户身份（Public User Identity）。
- 处理机制：由于 PPI 来自于终端，在进入核心信任域前，它必须经过 P-CSCF 的校验和转换。因此，PPI 在转发给 S-CSCF 或其他核心网元之前，必须被 P-CSCF 删除。
3. P-CSCF：身份断言的强制执行者
P-CSCF 作为信任域的边界，承担了验证、删除 PPI 和插入 PAI 的关键职责。运营商规范（如某运营商）对 P-CSCF 的身份操作有着细致的规定。
3.1 始发请求（MO Request）中的身份转换
无论是对话初始请求（INVITE），还是独立事务请求（MESSAGE, OPTIONS），P-CSCF 在将信令转发到上游网元（如 S-CSCF）之前，都会执行以下身份断言步骤：
| 场景 | P-CSCF 身份处理动作 | 目的 | 来源 |
|---|---|---|---|
| 独立事务请求 (MESSAGE, OPTIONS) | 1. 检查是否含有 P-Preferred-Identity 头域。2. 删除该头域（如果存在）。3. 插入 P-Asserted-Identity，其值应为请求的发起者（即 IMPU）。 | 用可信身份替代用户偏好身份，并增加计费参数 icid。 | |
| 未知方法请求 (与当前对话无关) | 1. 检查是否含有 P-Preferred-Identity 头域。2. 删除该头域（如果存在）。3. 插入 P-Asserted-Identity，其值应为请求的发起者。 | 确保所有独立请求都携带经过认证的 PAI 进入核心网。 | |
| P-CSCF 容灾接管 (主叫始呼 INVITE) | 备用 P-CSCF2 发现没有用户注册数据时，会在 INVITE 消息中提取 PPI 或者 FROM 域的主叫号码构造 PAI，并在 Route 中增加 orig 参数，路由到 I-CSCF。 | 在故障场景下，网络必须重建可信 PAI 以便后续寻址和业务触发。 |
3.2 终结请求响应（MT Response）中的身份插入
对于发往 UE 的终结请求响应，P-CSCF 也会执行身份断言操作，以确保终端收到的 PAI（如果适用）是正确的：
| 场景 | P-CSCF 身份处理动作 | 目的 | 来源 |
|---|---|---|---|
| 收到终结请求的 1xx 或 2xx 响应 | 1. 如果响应中含有 P-Preferred-Identity 头域，则 删除该头域。2. 插入 P-Asserted-Identity，其值应为收到请求时保存下来的 P-Called-Party-ID。 | 确保终结侧的 PAI 反映的是被叫用户的身份。 |
4. Privacy 头域：身份的隐藏与暴露
Privacy 头域（隐私头域）是用于控制用户身份（PAI）是否应该被隐藏或暴露给被叫方的机制。
4.1 匿名呼叫的实现（Privacy: id）
当用户选择发起匿名呼叫（即主叫号码限制 OIR, Originating Identification Restriction）时，UE 会在 SIP 请求中携带 Privacy 头域，并将其值设置为 id (Identity)。
| Privacy 头域值 | 含义 | 对应业务 |
|---|---|---|
id (Identity) | 请求发起者要求隐藏自己的身份。 | 主叫号码限制 (OIR) |
none | 用户不要求保护隐私。 | 主叫号码显示 (OIP) |
4.2 P-CSCF 对 Privacy 的处理
P-CSCF 负责执行 Privacy: id 的指令，以确保用户的匿名性得到保障。
| 场景 | P-CSCF 身份处理动作 | 目的 | 来源 |
|---|---|---|---|
| 发往 UE 的 INVITE 请求 | 如果收到的 INVITE 请求中携带的 Privacy 头域值为 id，则 P-CSCF 在转发 INVITE 请求前应删除其中的 P-Asserted-Identity 头域。 | 确保匿名请求（MT 侧）不会向终端暴露主叫的真实 PAI。 |
思考： 在这种情况下，被叫终端可能会收到一个匿名的 From 头域（如 Anonymous <sip:[email protected]>），而 P-CSCF 必须删除 PAI，从而在整个信令链路上实现了身份隐藏。
5. PAI 与 IMS 关键业务的深度关联
PAI 不仅仅是一个身份字段，它与 IMS 的计费、呼叫控制和容灾流程紧密耦合。
5.1 计费（Charging）关联
PAI 是计费系统识别用户的权威依据。在计费流程中：
- 计费标识（ICID）：P-CSCF 在转发来自 UE 的独立事务请求时，除了插入 PAI，还会插入 P-Charging-Vector，其中包含 icid 参数。
- S-CSCF CDR：S-CSCF 在收到呼叫请求并发送 ACR [Start] 消息给 CDF 时，会使用 PAI 作为用户的计费主体，创建 S-CSCF CDR。
- I-CSCF CDR：在被叫流程中，I-CSCF 触发 ACR [Event] 消息时，也会创建 I-CSCF CDR。虽然 I-CSCF 主要依赖被叫号码，但 PAI 贯穿了整个会话上下文，用于计费关联。
5.2 容灾接管（Disaster Recovery）中的 PAI 重建
在 P-CSCF 故障切换场景中，如果备用 P-CSCF2 无法获得用户注册数据，它必须重建 PAI，以便将呼叫发送给 I-CSCF 进行路由重建。
- P-CSCF 2 的职责：备用 P-CSCF2 发现没有用户注册数据，但仍需处理用户的初始请求（如 INVITE）。此时，它会根据主叫用户的域名查询 DNS，将呼叫请求发往主叫用户归属的 I-CSCF，并在 INVITE 消息中提取 PPI 或者 FROM 域的主叫号码构造 PAI。
- I-CSCF 的路由依赖：I-CSCF 收到这个请求后，会根据
Route头域中标识主叫流程的orig参数，并提取 PAI 消息头的主叫号码向 HSS 发送普通的 LIR 请求（不含 User-Authorization-Type），以获取主叫用户当前服务的 S-CSCF。
这清晰地表明，即使在最紧急的容灾场景中，PAI 依然是 IMS 寻址 S-CSCF 的核心依据。
6. 信令实战分析：P-CSCF 对 MESSAGE 请求的身份处理
我们通过一个实际的 MESSAGE 请求（独立事务请求，如 IMS 短信）流程，观察 P-CSCF 如何执行身份断言。
场景： 用户 A（UE-A）发送一条 IM 消息，P-CSCF 收到请求，并执行身份转换。
6.1 步骤 1：UE-A 发起 MESSAGE 请求（携带 PPI）
UE-A 在请求中携带了希望的身份（P-Preferred-Identity），并使用注册时存储的 Service-Route 逆序生成了 Route 列表。
| SIP 头域 | 示例值 | 关键作用分析 |
|---|---|---|
| 请求行 | MESSAGE sip:[email protected] SIP/2.0 | 独立事务请求。 |
| P-Preferred-Identity | <sip:[email protected]> | UE 偏好身份（P-CSCF 必须删除）。 |
| From | <sip:[email protected]>;tag=msg.from | 逻辑身份，用于对话标识（虽然 MESSAGE 事务本身不建立长期对话）。 |
| Route | <sip:scscf.home.net;lr> | MO 请求路由到 S-CSCF 的指引（来自 Service-Route）。 |
6.2 步骤 2：P-CSCF S-CSCF 转发的 MESSAGE 请求（插入 PAI, 删除 PPI, 增加 ICID）
P-CSCF 收到请求，根据运营商规范处理独立事务请求。
| SIP 头域 | P-CSCF 动作与示例值 | 关键作用分析 |
|---|---|---|
| 请求行 | MESSAGE sip:scscf.home.net SIP/2.0 | P-CSCF 移除顶端 Route，将 Request-URI 改为下一跳 S-CSCF。 |
| P-Preferred-Identity | (已删除) | 根据规范，P-CSCF 删除了来自 UE 的 PPI。 |
| P-Asserted-Identity | <sip:[email protected]> (插入) | P-CSCF 插入了经过认证的 PAI，其值为请求的发起者。 |
| P-Charging-Vector | icid-value="pcscf.id.xyz..." (插入) | P-CSCF 增加 ICID 计费锚点。 |
| Via | (添加 P-CSCF 地址) | 逐跳路由记录 P-CSCF 地址。 |
| Route | (移除顶端 Route) | 保持路由的持续性。 |
P-CSCF 的身份处理总结： P-CSCF 是在用户偏好 (PPI) 和 网络断言 (PAI) 之间进行转换和强制执行的唯一实体。它的职责是保证 IMS 核心网元收到的所有身份信息都是经过认证的 PAI，从而确保业务和计费的准确性。
7. 本章小结
P-Asserted-Identity (PAI) 是 IMS 信任域内传递的真实、可信的用户身份，它被 S-CSCF 用于 iFC 业务触发 和计费。
- P-Preferred-Identity (PPI) 仅代表用户偏好，必须在进入核心网前被 P-CSCF 删除。
- P-CSCF 在处理 UE 始发请求时，会删除 PPI 并插入 PAI，同时插入 icid 等计费标识。
- Privacy: id 头域用于实现匿名呼叫，P-CSCF 必须根据此指示删除 PAI，防止身份泄露。
- 在 P-CSCF 容灾接管场景下，即使没有注册数据，备用 P-CSCF 也必须通过提取 PPI 或 From 域信息构造 PAI，以协助 I-CSCF 重建到 S-CSCF 的路由。
- IMS 实体在会话终止时，需要释放所有与对话相关的信息，而 PAI 等身份信息是这些对话和会话状态的基础。
工程师进阶思考 (FAQ)
Q1：P-CSCF 收到 UE 发起的后续请求（例如 BYE）时，如果发现没有对应的对话，为什么必须返回 403 (Forbidden) 响应？
A1： P-CSCF 必须维护所有已建立会话的对话状态信息（包括 Call-ID, From-tag, To-tag）。当 P-CSCF 收到 UE 发起的后续请求或独立请求时，它会进行对话存在性检查。如果 没有发现存在对应的对话，则 P-CSCF 应回复 403 (Forbidden) 响应，且不再转发该请求。
返回 403 Forbidden 的目的是：
- 防止状态混乱：阻止与不存在会话相关的信令进入核心网，避免 S-CSCF 等网元处理无效请求。
- 安全防护：防止终端或攻击者在会话生命周期外，向核心网注入假冒的 SIP 消息。
- 资源保护：确保核心网资源（如会话状态机、iFC）不会被异常信令消耗。
Q2：IMS 呼叫中，P-CSCF 是如何防止 Via 头域被篡改，从而确保响应消息能够正确返回？如果发现不匹配，如何处理？
A2： P-CSCF 通过严格的 Via 列表匹配机制来防止篡改。
- 存储机制：对于对话初始请求（如 INVITE）和目标刷新请求，P-CSCF 在转发请求时，会保存该请求的
Via列表。 - 匹配校验：当 P-CSCF 收到上述请求的任何响应（1xx 或 2xx）时，它都必须确认响应中的 Via 列表是否与同一对话的请求消息中保存的 Via 列表相匹配。
- 异常处理：如果 Via 列表不匹配，P-CSCF 应该采取以下措施之一：丢弃该响应，或者用保存的 Via 列表替换响应中的 Via 头。这种处理确保了 SIP 响应消息严格地遵循请求的原路径返回，是保证事务可靠性的关键。
Q3：在 IMS S-CSCF 发起会话释放（如会话定时器超时）时，如果同时收到用户发来的其他会话请求（如 UPDATE），S-CSCF 应如何处理以保持状态一致性？
A3： 当 S-CSCF 发起会话释放流程（例如，向主被叫两侧发送 BYE 请求，或因会话定时器超时删除信息）时，如果又接收到该会话的其他请求消息，S-CSCF 应该终止接受请求，并返回一个 481 (对话或者事务不存在) 响应。
这样做的目的是确保会话资源和状态能被彻底、干净地释放。如果 S-CSCF 正在执行释放动作，任何到达的会话请求都应被视为无效，并立即被拒绝，从而避免状态机进入不可预知的状态。当 S-CSCF 收到 BYE 请求的 2xx 响应时，它会释放所有与对话和多媒体会话相关的信息。
请您发出“请继续”指令，我将开始撰写第八篇。