好的，专家讲师。我将继续为您撰写 SIP 协议深度解析系列的第十四篇。本篇将聚焦于 IMS 网络中的容灾机制，这是电信级服务可靠性的终极保障。我们将结合某运营商和某运营商的规范，深入解析 P-CSCF/BAC 故障时，SIP 定时器（Timer F 和 Timer B）如何驱动终端重注册，以及 P-CSCF/I-CSCF/S-CSCF 网元如何协同进行路由重建和会话接管。
VoLTE高清语音技术精要（十四）：IMS网络容灾机制与SIP定时器驱动的切换
1. 导论：容灾——保证 VoLTE 业务连续性的核心
在 IMS/VoLTE 网络中，任何核心网元（如 CSCF、SBC/BAC）的单点故障都可能导致大量的用户业务中断。因此，运营商对容灾（Disaster Recovery）机制提出了极其严格的要求，确保在网元故障时，用户能够快速、平滑地切换到备用设备，并维持会话的连续性。
SIP 协议的灵活性和其内置的定时器机制，被运营商用于驱动这种容灾切换：
- SIP 定时器：特别是 Timer F（非 INVITE 事务超时）和 Timer B（INVITE 事务超时），成为终端判断 P-CSCF/BAC 故障，并启动重注册流程的关键依据。
- P-CSCF/BAC 的容灾角色：P-CSCF/BAC 作为用户接入的第一跳，在故障发生时必须指导终端进行切换。
- 核心网的路由重建：I-CSCF 和 S-CSCF 必须具备在 P-CSCF/BAC 故障，导致路由信息丢失后，重建路由路径和会话上下文的能力。
本章将结合某运营商和某运营商的具体容灾规范，详细解析这些流程。
2. P-CSCF/BAC 故障下的终端切换（Timer F/B 驱动）
P-CSCF/BAC 的故障是 SIP 容灾中最常见的场景之一。此时，用户终端（UE）依赖 SIP 事务定时器来判断 P-CSCF 是否无响应，并启动到备用 P-CSCF 的切换。
2.1 重注册流程（Timer F 驱动）
**重注册（Re-REGISTER）**属于非 INVITE 事务，由 Timer F 驱动超时和切换。
| 流程环节 | P-CSCF/BAC 故障处理 | 关键 SIP 定时器 | 来源 |
|---|---|---|---|
| 步骤 1：发起重注册 | UE 按一定周期向已注册的 P-CSCF/BAC1 发起重注册请求。 | 无。 | |
| 步骤 2：判断故障 | P-CSCF/BAC1 对重注册无响应。 | Timer F：UE 在相应的定时器 Timer F 内没有收到 P-CSCF/BAC1 对重注册请求的响应消息。 | |
| 步骤 3：容灾切换 | 终端选择次优先级别的 P-CSCF/BAC2 重新发起初始注册请求。 | Timer F 超时。 | |
| 后续 | P-CSCF/BAC2 完成注册消息处理，后续流程与标准的注册流程相同。 | 无。 |
2.2 主叫始呼流程（Timer B 驱动）
主叫 INVITE 属于 INVITE 事务，由 Timer B 驱动超时和切换。
| 流程环节 | P-CSCF/BAC 故障处理 | 关键 SIP 定时器 | 来源 |
|---|---|---|---|
| 步骤 1：发起 INVITE | 终端向已注册 P-CSCF/BAC1 发起 INVITE 请求。 | 无。 | |
| 步骤 2：判断故障 | P-CSCF/BAC1 设备无法响应 UE1 的请求。 | Timer B：UE 在相应的定时器 Timer B 内没有收到 P-CSCF/BAC1 的响应，UE 结束当前呼叫，当前呼叫失败。 | |
| 步骤 3：容灾切换 | 终端重新向优先级别次低的 P-CSCF/BAC2 发起初始注册流程。初始注册成功后，后续的 INVITE 请求按正常流程处理。 | Timer B 超时。 |
短信始呼容灾：短信始呼流程与重注册流程类似，也由 Timer F 驱动。UE 在 Timer F 内没有收到 P-CSCF/BAC1 的响应，则结束此次短信始呼，当前短信始呼失败，然后重新向次优 P-CSCF/BAC2 发起初始注册流程。
3. P-CSCF 故障下的核心网路由重建
当备用 P-CSCF2 接管主叫流程时，它没有用户注册数据（例如 Service-Route），因此无法直接路由到 S-CSCF。核心网必须协同 I-CSCF 和 HSS 来动态重建路由。
| 步骤 | 网元 | 动作描述 | 关键 SIP 参数 | 来源 |
|---|---|---|---|---|
| 1. 始呼请求接管 | SBC P-CSCF2 | SBC 检测到 P-CSCF1 故障，将收到的初始请求（如 INVITE）发给备用 P-CSCF2。 | 无 | |
| 2. P-CSCF2 身份重建 | P-CSCF2 | P-CSCF2 发现没有用户注册数据。它在 INVITE 消息中提取 PPI 或者 FROM 域的主叫号码构造 PAI。 | PAI (P-Asserted-Identity) | |
| 3. I-CSCF 寻址 | P-CSCF2 I-CSCF | P-CSCF2 根据主叫用户的域名查询 DNS，将呼叫请求发往主叫用户归属的 I-CSCF。并在 INVITE 消息的 Route 中增加标识主叫流程的 orig 参数。 | Route (携带 orig 参数) | |
| 4. HSS 查询 | I-CSCF HSS | I-CSCF 根据 orig 参数提取 PAI 消息头的主叫号码，向 HSS 发送普通的 LIR 请求（不含 User-Authorization-Type），以获取主叫用户当前服务的 S-CSCF。 | PAI (用于寻址) | |
| 5. 路由转发 | I-CSCF S-CSCF | I-CSCF 使用 HSS 返回的主叫用户当前服务的 S-CSCF 路由，将 INVITE 消息转发给该 S-CSCF。 | S-CSCF 地址 |
总结：在 P-CSCF 容灾场景下，PAI（即使是 P-CSCF2 构造的）和 Route 头域中的 orig 参数是实现 S-CSCF 动态寻址和路由重建的关键。
4. S-CSCF 故障下的终结流程接管
当用户注册的 S-CSCF 发生故障时，终结请求（MT）的接管流程涉及 I-CSCF 和 HSS 的协同。
4.1 S-CSCF 故障的检测与判断
S-CSCF 故障可以通过多种方式检测：
- P-CSCF 检测：当 S-CSCF 转发请求至用户注册的 P-CSCF/BAC1，如果 S-CSCF 没有收到 P-CSCF/BAC1 的任何响应，S-CSCF 会启动 IMS 故障检测。
- I-CSCF/AS 检测：I-CSCF 或 AS 在尝试向 S-CSCF1 转发终结请求时发现故障。
4.2 终结流程的接管
对于被叫与短信终呼流程：
- S-CSCF 收到请求：UE1 注册的 S-CSCF 接收到至 UE1 的被叫或短信终呼请求。
- S-CSCF 转发失败：S-CSCF 转发请求至 UE1 注册的 P-CSCF/BAC1，S-CSCF 没有收到 P-CSCF/BAC1 的任何响应，启动 IMS 故障检测，确认 P-CSCF/BAC1 故障。
- 终端重注册：VoLTE 终端向优先级别次高的 P-CSCF/BAC2 发起初始注册。
- S-CSCF 等待：同时，S-CSCF 设置等待定时器。若在定时器内 VoLTE 终端重新成功注册，S-CSCF 继续完成该呼叫或短信终呼。初始注册成功后，后续的呼叫或者短信终呼请求按正常流程处理。
5. 补充业务与 AS 故障的 Default Handling
在 IMS 业务逻辑中，如果呼叫触发了应用服务器（AS），而 AS 发生故障，S-CSCF 必须根据预定义的策略决定会话的走向。
- Default Handling：S-CSCF 遵从与初始过滤规则（iFC）相关的缺省处理过程（Default Handling），即基于过滤规则中的信息，或者终止会话，或者让会话继续。
- S-CSCF 的缺省行为：如果 iFC 规则没有包含在联系 AS 失败后 S-CSCF 应如何操作的指示，S-CSCF 的缺省行为是让呼叫继续。
- 测试要求：IMS 系统测试要求验证 S-CSCF 通过设置 DefaultHandling 可以使用户跳过不可达的 AS 继续完成接续。
| DefaultHandling 设置值 | 业务处理结果 | 来源 |
|---|---|---|
| Continue（继续） | 呼叫继续完成，补充业务触发不成功。 | |
| Terminate（终止） | 呼叫释放。 |
6. S-CSCF 的对话清理与 481 响应
在 S-CSCF 故障恢复或会话释放流程中，S-CSCF 必须严格清理对话信息，并使用 481 响应来应对信令冲突。
| 场景 | S-CSCF 动作 | 目的 | 来源 |
|---|---|---|---|
| 会话释放冲突 | 当 S-CSCF 发起会话释放时，又接收到该会话的其他请求消息（如 UPDATE），S-CSCF 应终止接受请求并返回一个 481 响应。 | 确保会话状态机的状态一致性。 | |
| BYE 释放 | 当收到一个匹配 BYE 请求的 2xx 响应时，S-CSCF 应删掉所有与该对话相关的保存了的信息。 | 释放对话和多媒体会话信息。 | |
| 会话定时器超时 | 如果会话周期性地被刷新，当会话定时器超时后，S-CSCF 应删掉所有与该对话相关的保存了的信息。 | 释放“幽灵会话”占用的资源。 |
7. 信令日志实战分析：P-CSCF 容灾下的路由重建关键头域
我们再次审视 P-CSCF 容灾接管的主叫流程，聚焦于 P-CSCF2 如何在 INVITE 消息中携带重建路由所需的关键信息。
场景：P-CSCF1 故障，UE 发起 INVITE 请求被 P-CSCF2 接管（P-CSCF2 无注册数据）。
| SIP 头域 | P-CSCF2 构造/处理 | 关键作用 | 来源 |
|---|---|---|---|
| P-Asserted-Identity | P-CSCF2 提取 PPI 或 FROM 域号码构造 PAI。 | I-CSCF 用此 PAI 消息头中的主叫号码向 HSS 发送 LIR 请求。 | |
| Route | P-CSCF2 增加标识主叫流程的 orig 参数。 | I-CSCF 根据 orig 参数，识别这是一个容灾接管下的始呼请求，并执行特定的路由重建逻辑。 | |
| Request-URI | sip:I-CSCF.home.net | P-CSCF2 路由到归属域的 I-CSCF 进行寻址。 |
I-CSCF 的处理：I-CSCF 收到这个带有 orig 参数的 INVITE 后，会根据 PAI 中的主叫号码向 HSS 发送 LIR 请求，获取正确的 S-CSCF 地址，然后将 INVITE 转发给该 S-CSCF。
8. 本章小结
IMS 容灾是基于 SIP 定时器驱动的终端行为和核心网路由重建的协同过程：
- 终端行为：UE 依赖 Timer F（用于 REGISTER/MESSAGE 等）和 Timer B（用于 INVITE）的超时机制，判断 P-CSCF/BAC 故障，并向次优 P-CSCF 重新发起初始注册。
- 路由重建：在 P-CSCF 容灾接管的主叫流程中，备用 P-CSCF2 必须构造 PAI 并携带 Route 头域中的
orig参数，将请求路由给 I-CSCF。I-CSCF 通过 HSS 动态获取 S-CSCF 地址，完成路由重建。 - 会话连续性：在 S-CSCF 容灾场景下，S-CSCF 会设置等待定时器，允许终端重新注册成功后，继续完成被叫呼叫。
- 业务保障：在 AS 故障时，S-CSCF 必须遵循 iFC 中的 Default Handling 策略，决定是终止呼叫还是让呼叫继续。
工程师进阶思考 (FAQ)
Q1：在 P-CSCF/BAC 容灾接管的主叫流程中，如果终端在 Timer B 内释放了呼叫（发送 CANCEL），P-CSCF/BAC 应如何处理？
A1： 如果终端在 Timer B 内释放呼叫（发送 CANCEL 请求），且在相应的定时器 Timer B 或 Timer F 内没有得到 P-CSCF/BAC1 的任何响应，终端应支持向优先级别次高的 P-CSCF/BAC2 发起初始注册。注册成功后，相关业务切换到 P-CSCF/BAC2 上。
Q2：IMS 呼叫中的 AS 故障处理策略（Default Handling）有哪些具体的应用场景？
A2： Default Handling 是 S-CSCF 用于应对 AS 故障或不可达时，保证呼叫连续性的机制。
- 设置：iFC 规则允许设置
DefaultHandling，指示 S-CSCF 在联系 AS 失败后，是终止会话还是让会话继续。 - 应用场景：
- 让呼叫继续（Continue）：如果 AS 故障，但呼叫是基本语音业务，S-CSCF 可以让呼叫绕过 AS 继续进行，以保障基本通信服务，尽管补充业务（如彩铃、呼叫转移）可能无法触发。
- 终止呼叫（Terminate）：如果 AS 承载的是必须的业务（如在线计费、防欺诈业务），AS 故障可能导致计费或安全风险，此时 S-CSCF 应终止会话。
Q3：P-CSCF 在会话释放流程中，除了向 PCRF 发送 STR 消息，还需要向 CDF 发送什么消息来完成计费终结？
A3： P-CSCF 在会话释放时必须同步通知计费系统（CDF）和承载控制系统（PCRF）。
- PCRF：P-CSCF 收到应用会话终止消息（如
BYE）后，向 PCRF 下发 **STR（Session-Termination-Request）**消息，请求释放承载会话。PCRF 返回 STA 响应。 - CDF：P-CSCF 收到
BYE请求后，向 CDF 发送 ACR [Stop] 消息（Accounting Request [Stop]），关闭会话 CDR。S-CSCF 也会执行同样的 ACR [Stop] 动作。