好的，通信学院的专家讲师。我已经完成了 26 篇深度解析，目前我们正继续深入 IMS/VoLTE/VoNR 的核心技术细节。
我将继续为您撰写 SIP 协议深度解析系列的第二十七篇。本篇将聚焦于 IMS 网络中的路由和会话状态管理。我们将系统性地回顾 P-CSCF 和 S-CSCF 如何处理各种类型的后续请求和独立事务，通过严格的校验机制（特别是 Route 列表和 Service-Route 的匹配）来维护会话的完整性，并结合容灾场景下的路由重建要求进行对比分析。
VoLTE高清语音技术精要（二十七）：IMS会话状态与路由完整性：P-CSCF的后续请求校验机制
1. 导论：后续请求——维护会话生命周期的核心
在 SIP 会话建立（INVITE 事务）成功并收到 200 OK 最终响应后，一个 SIP 对话（Dialog）即被创建，其生命周期由后续请求（Sequential Requests）维持和终结，例如 UPDATE、ReINVITE、BYE 等。
P-CSCF（代理呼叫会话控制功能）在处理这些后续请求时，其职责远超简单转发。它必须对请求的合法性（是否属于一个已存在的对话）、身份的权威性（PAI 的准确性）以及路由的完整性进行严格校验。这些校验是保证 IMS 业务连续性、安全性和计费准确性的基础。
本章将整合某运营商和某运营商的规范要求，重点解析 P-CSCF 如何根据请求类型和对话状态，采取不同的校验和操作，并利用特定的 SIP 状态码来应对各种异常情况。
2. P-CSCF 对后续请求和独立事务的校验原则
P-CSCF 对后续请求和独立事务（非对话内的请求，如 MESSAGE、OPTIONS）的处理逻辑是基于其是否匹配到已保存的会话上下文或注册上下文。
2.1 目标刷新请求的严格校验（ReINVITE/UPDATE）
目标刷新请求（如 reINVITE 或 UPDATE）用于修改会话参数（如 SDP）或更新终端的 Contact 地址。它们发生在已建立的对话中。
- P-CSCF 的动作：当 P-CSCF 收到终端发起的
reINVITE或UPDATE请求时，P-CSCF 应验证请求中的Route列表是否与同一对话中保存下来的Record-Route列表匹配。 - 状态更新：如果路由校验成功，P-CSCF 应该用收到的请求消息中的
CSeq字段的值替换原来保存的值。 - 计费参数更新：对于终端发来的
reINVITE或者UPDATE请求，P-CSCF 在发送该请求到 S-CSCF 时，应在P-Charging-Vector头中包含更新过的access-network-charging-info参数。 - 临时响应：P-CSCF 应对所有的
reINVITE请求均回送100 (Trying)响应。P-CSCF 也可以对reINVITE请求返回100 (Trying)临时响应。
2.2 其他后续请求的校验（BYE/PRACK/INFO 等）
对于 UE 发起的除目标刷新请求以外的后续请求（包括与当前对话相关的未知方法），P-CSCF 也必须进行校验：
- 对话和路由确认：P-CSCF 应该确认这个请求是否和一个涉及该请求的发起者的对话有关，并确认请求中的
Route列表是否与同一对话中保存下来的Record-Route列表匹配。 - 计费参数：对于非 INVITE 对话，P-CSCF 应在
P-Charging-Vector中增加icid参数。
2.3 独立事务请求（未知方法的请求）的校验
对于 UE 发起的未知方法请求（与当前的对话无关，例如 MESSAGE、OPTIONS），但存在一个 Service-Route 列表与请求的发起者相对应时：
- 路由校验：P-CSCF 应确认
Service-Route头中的 URI 列表是否也以相同的顺序存在于收到的请求所带的Route头域中。 - 身份断言：如果请求中含有
P-Preferred-Identity，则 P-CSCF 应删除该头域并插入P-Asserted-Identity，其值为请求的发起者。
3. P-CSCF 的异常处理与状态码应用
P-CSCF 在校验失败或会话状态不一致时，必须返回精确的 SIP 错误状态码，以指导终端和上游网元进行处理。
| 状态码 | 含义 | 触发 P-CSCF 场景 | 来源 |
|---|---|---|---|
| 400 Bad Request | 路由校验失败。 | P-CSCF 收到 UE 发起的任何请求，如果 Service-Route 中的 URI 列表校验失败（或 Route 与 Record-Route 不匹配），则回复 400(Bad Request)。 | |
| 403 Forbidden | 对话不存在。 | P-CSCF 收到 UE 发起的后续请求或独立请求，但没有发现存在对应的对话。 | |
| 481 Dialog/Transaction Does Not Exist | 释放冲突。 | P-CSCF 在释放对话的过程中收到关于对话的请求时，应中止该请求并回送 481 响应。 |
4. S-CSCF 对后续请求的策略控制
S-CSCF 在收到来自终端的后续请求时，也会根据策略对 SIP 头域进行处理：
- 承载信息转发：对于一个从终端发来的
reINVITE请求或UPDATE请求，S-CSCF 应保存更新了的P-Charging-Vector消息头里的access-network-charging-info参数，当请求转发给 AS 时 S-CSCF 应该包含该参数。但是，当UPDATE请求转发给 S-CSCF 归属域以外时，S-CSCF 不应包含该参数。 - 接入网络信息（PANI）：对于一个从终端发来的
reINVITE，如果请求将被转发给一个位于信任域的 AS 时，S-CSCF 应保留P-Access-Network-Info消息头，否则 S-CSCF 应删掉该消息头。
5. P-CSCF 容灾接管下的路由重建对比
在 P-CSCF 容灾接管的主叫流程中，由于备用 P-CSCF2 没有用户注册数据，它无法执行上述的 Service-Route 校验。
- 路由重建：P-CSCF2 必须在
INVITE消息中提取 PPI 或者 FROM 域的主叫号码构造 PAI，并在Route中增加标识主叫流程的orig参数。 - I-CSCF 寻址：I-CSCF 根据
orig参数提取 PAI 消息头的主叫号码向 HSS 发送普通的 LIR 请求（不含User-Authorization-Type），以获取 S-CSCF 地址。
这种容灾下的动态寻址机制，绕过了 P-CSCF 对本地注册数据的依赖，但仍依赖于 PAI 的正确构造。
6. 本章小结
P-CSCF 是 IMS 会话状态和路由完整性的关键守护者：
- 分类型校验：针对目标刷新请求，校验
Route与Record-Route的匹配；针对独立请求，校验Route与Service-Route的匹配，并执行身份断言（插入 PAI）。 - 错误处理：通过 400 (Bad Request) 标识路由校验失败，通过 403 (Forbidden) 标识对话不存在，通过 481 (Dialog/Transaction Does Not Exist) 标识释放过程中的信令冲突。
- S-CSCF 协同：S-CSCF 在转发后续请求给 AS 时，会保留
P-Charging-Vector和P-Access-Network-Info以进行策略控制，但转发给归属域以外时会删除敏感参数。
7. 工程师进阶思考 (FAQ)
Q1：P-CSCF 在处理发往 UE 的对话初始请求（MT INVITE）之前，为什么需要备份 P-Called-Party-ID？这个备份的信息在何时被使用？
A1： P-CSCF 必须备份 P-Called-Party-ID，并在 MT 流程的响应中将其用作 P-Asserted-Identity (PAI)。
- 备份原因：在转发 MT INVITE 之前，P-CSCF 必须删除并保存
P-Charging-Function-Addresses和P-Charging-Vector中的icid参数。同时，它备份P-Called-Party-ID。 - 使用时机：当 P-CSCF 收到上述请求的
1xx或2xx响应时，如果响应中含有P-Preferred-Identity，P-CSCF 应删除该头域，并插入P-Asserted-Identity，其值应为收到请求时保存下来的P-Called-Party-ID。这确保了响应中携带的终结方身份是经过网络断言的。
Q2：S-CSCF 在会话释放流程中，如何确保与 AS 相关的业务和资源得到正确清理？
A2： S-CSCF 必须基于在呼叫建立时存储的对话信息，向相关 AS 通知业务结束。
- 对话信息存储：如果一个会话根据 iFC 触发了一个或多个应用服务器（AS），S-CSCF 会存储所有经过 S-CSCF 并与该会话请求相关的对话信息。
- 释放通知：当会话被释放时（例如，收到
BYE的2xx响应后），S-CSCF 需要根据存储的与会话请求相关的对话信息释放对话。如果 S-CSCF 通过 AS 给用户提供服务，则 S-CSCF 必须通知相关 AS 结束业务。
Q3：当 P-CSCF 收到 UE 发起的 REGISTER 消息时，它向 S-CSCF 转发请求，I-CSCF 启用 UAR 消息查询 HSS。那么在 P-CSCF 容灾接管的重注册流程中，I-CSCF 启用的 UAR 消息中 User-Authorization-Type 的取值是多少？
A3： 在 P-CSCF 容灾接管的重注册流程中，I-CSCF 启用 UAR 消息查询 HSS，其中 User-Authorization-Type 取值为 REGISTRATION (0)。这与标准的初始注册流程中该参数的取值一致，表明这是一次要求 HSS 进行鉴权和寻址的注册请求。
我们已完成 27 篇深度解析。根据估算，还剩下约 2 篇核心内容待拆解。请发出“请继续”指令。