好的，通信学院的专家讲师。我将继续为您撰写 SIP 协议深度解析系列的第十篇。本篇将系统性地整合前九篇中介绍的所有核心 SIP 头域和 IMS 机制，通过一个完整的 VoLTE/VoNR 注册信令流进行实战解析。注册流程是用户接入 IMS 网络的起点，也是所有后续呼叫、业务触发和容灾机制的基础。
VoLTE高清语音技术精要（十）：流程实战：VoNR/VoLTE 注册信令流解析
1. 导论：注册——会话控制的起点
SIP REGISTER 方法是用户终端（UE）向其归属网络（Home Network）中的 S-CSCF（服务呼叫会话控制功能）登记或更新自己的可达地址（Contact 地址）的关键。IMS 网络的注册流程远超标准 SIP 协议，它必须结合 IMS 特有的身份鉴权（如 AKA 机制）、路由锚定（Path/Service-Route）和状态订阅，才能确保用户接入的安全性和会话的可持续性。
本章将基于某运营商和某运营商的 IMS 规范，详细剖析 UE 初始注册流程中的每一个关键步骤和 SIP 头域的演变，重点展示 P-CSCF 和 S-CSCF 如何利用 Path、Service-Route、P-Asserted-Identity 和 P-Charging-Vector 等字段，构建用户在 IMS 网络中的完整上下文。
2. 初始注册流程概览与核心目的
VoLTE/VoNR 的初始注册流程可以概括为以下几个核心目标：
- 身份验证（Authentication）：通过 AKA（Authentication and Key Agreement，认证和密钥协商）机制，在 UE、P-CSCF 和 HSS 之间完成相互认证。
- 地址绑定（Binding）：将用户的逻辑身份（IMPU/PUI，在
From/To头域中）与当前的物理可达地址（Contact URI）进行绑定，并由 S-CSCF 存储。 - 路由锚定（Anchoring）：建立 P-CSCF 和 S-CSCF 之间的永久信令路径，通过
Path和Service-Route机制，确保后续 MO/MT 呼叫的路由连续性。 - 状态同步（Synchronization）：S-CSCF 从 HSS 下载用户签约数据（包括 iFC），并通知 P-CSCF 订阅注册状态，完成会话状态的初始化。
3. 信令流程详解与关键 SIP 头域变化
我们以 UE 首次注册成功的完整流程为例进行详细解析：
3.1 步骤 1：UE P-CSCF I-CSCF S-CSCF (REGISTER 请求)
UE 发起 REGISTER 请求。在 IMS 初始注册中，通常会先收到 401 Unauthorized 响应以启动 AKA 鉴权流程。这里我们聚焦于鉴权成功后，携带最终鉴权响应的 REGISTER 消息。
| 关键 SIP 头域 | 核心内容或变化 | 职责/目的 | 引用 |
|---|---|---|---|
| Request-URI | sip:ims.home.net | 注册目标是归属网络的域名。 | |
| From/To | 用户的 PUI（Public User Identity） | 逻辑身份标识，S-CSCF 用此 PUI 与 Contact 地址进行绑定。 | |
| Contact | UE 的当前 IP/端口及 expires | 物理可达地址，定义了绑定的有效期（如 3600 秒）。 | |
| Require/Supported | path | 声明支持 Path 扩展机制。 | |
| Path | <sip:[email protected];lr> | P-CSCF 插入。记录 MT 呼叫的返回路径，存储在 S-CSCF。 | |
| P-Charging-Vector | icid-value="...";orig-ioi=... | P-CSCF 插入。设置 IMS 计费标识（ICID），用于计费锚定。 | |
| Authorization | 包含 AKA 鉴权结果（response） | 携带计算出的鉴权响应，用于 S-CSCF/HSS 验证。 |
3.2 步骤 2：I-CSCF HSS（S-CSCF 寻址）
I-CSCF 收到 REGISTER 请求后，会向 HSS 发起 UAR (User-Authorization-Request) 消息查询，其中 User-Authorization-Type 取值为 REGISTRATION (0)。HSS 返回用户当前服务的 S-CSCF 地址给 I-CSCF。
容灾场景下的寻址：在 P-CSCF 容灾接管的主叫流程中，备用 P-CSCF2 将 INVITE 发送给 I-CSCF 时，I-CSCF 也会向 HSS 发送 LIR 请求（不含 User-Authorization-Type），以获取 S-CSCF 地址。
3.3 步骤 3：S-CSCF P-CSCF UE (REGISTER 200 OK 响应)
S-CSCF 验证鉴权成功，从 HSS 下载用户数据，然后返回 200 OK 响应，正式建立注册对话。
| 关键 SIP 头域 | 核心内容或变化 | 职责/目的 | 引用 |
|---|---|---|---|
| Status-Line | SIP/2.0 200 OK | 注册成功。 | |
| To | 包含 S-CSCF 生成的 tag | 注册对话建立，由 Call-ID、From-tag、To-tag 唯一标识。 | |
| Contact | 确认 UE 的地址和 expires | 确认地址绑定成功。 | |
| Service-Route | <sip:scscf1.home.net;lr> | S-CSCF 插入。指引 UE/P-CSCF 将所有后续 MO 请求（INVITE, MESSAGE, OPTIONS）路由到该 S-CSCF。 | |
| P-Charging-Vector | 包含 icid 和 iois | S-CSCF 可能会在响应中添加或更新计费信息。 |
3.4 步骤 4：P-CSCF S-CSCF (SUBSCRIBE 请求)
P-CSCF 收到 200 OK 响应后，向 S-CSCF 发送 SUBSCRIBE 消息，订阅用户的注册状态信息。
- 目的：确保 P-CSCF 能实时接收到用户的注册状态变更（如用户被注销或故障），从而及时清理本地资源。
- SIP 头域要求：
From域为 P-CSCF 的 SIP URI。To域为缺省的公有用户身份标识。Route消息头有一条路由记录，S-CSCF，为本消息作路由指示。
3.5 步骤 5：S-CSCF AS (第三方注册)
如果用户的 iFC（初始过滤规则）触发了第三方应用注册（如 VoLTE AS），S-CSCF 会向 AS 发送 REGISTER 请求。第三方应用服务器也可以对向它注册的 PUI 发送 SUBSCRIBE 请求，订阅其更多的注册信息。
- AS SUBSCRIBE 消息：
From域为 AS SIP URI；To域为用户要订阅注册状态的 PUI。Event消息头为reg（注册状态）。消息中包含P-Charging-Vector消息头，内容包括icid和orig-ioi(type 3)。
4. 运营商规范中的 P-CSCF 状态维护要求
某运营商（QB/CU 084(2016)）等规范对 P-CSCF 在注册成功后，维护和校验后续信令有极为严格的要求。
| 请求类型 | P-CSCF 核心操作与校验 | 异常处理（联通规范） | 引用 |
|---|---|---|---|
| 独立事务请求 (MESSAGE, OPTIONS) | 校验 Route 与保存的 Service-Route 是否匹配。删除 P-Preferred-Identity，插入 P-Asserted-Identity。在 P-Charging-Vector 中增加 icid 参数。 | 如果 Service-Route 校验失败，回复 400 (Bad Request) 或用 Service-Route 替换 Route。 | |
| 未知方法请求 (与对话无关) | 确认 Route 列表是否与 Service-Route 以相同顺序存在。删除 P-Preferred-Identity，插入 P-Asserted-Identity。 | 如果没有发现对应的对话，回复 403 (Forbidden)。 | |
| 目标刷新请求 (reINVITE, UPDATE) | 校验 Route 与保存的 Record-Route 匹配。更新 Contact 和 CSeq。在 Via 和 Record-Route 顶端增加 P-CSCF 地址。 | 如果 Route 校验失败，回复 400 (Bad Request)。 | |
| 会话释放中请求 | 必须中止该请求。 | 回送响应 481 (对话或者事务不存在)。 |
P-CSCF 容灾接管下的路由重建
在 P-CSCF1 故障，备用 P-CSCF2 接管主叫流程的场景中，P-CSCF2 因为没有用户注册数据，无法执行 Service-Route 校验。此时的路由流程如下：
- SBC 检测到 P-CSCF1 故障，将请求发给 P-CSCF2。
- P-CSCF2 向用户回送
100 trying消息。 - P-CSCF2 发现没有用户注册数据，根据主叫用户的域名查询 DNS，将呼叫请求发往归属的 I-CSCF。
- P-CSCF2 在
INVITE消息中提取 PPI 或者 FROM 域的主叫号码构造 PAI。 - P-CSCF2 在
INVITE消息的Route中增加标识主叫流程的orig参数。 - I-CSCF 根据
orig参数提取 PAI 消息头的主叫号码，向 HSS 发送普通的 LIR 请求，获取 S-CSCF。
5. IMS 计费锚点与 CDR 触发机制
IMS 注册和呼叫流程与计费系统（CDF, Charging Data Function）紧密关联，主要通过 P-CSCF 和 S-CSCF 与 CDF 之间的 Rf 接口（承载 ACR 消息）实现。
| 网元 | 计费消息类型 | 触发时机 | 作用 | 引用 |
|---|---|---|---|---|
| I-CSCF | ACR [Event] | 收到 INVITE 消息并进行 HSS 查询后。 | 创建 I-CSCF CDR（话单）。 | |
| P-CSCF/S-CSCF | ACR [Start] | 收到 INVITE 的 200 OK 最终响应后。 | 创建 P-CSCF CDR/S-CSCF CDR，开始计费。 | |
| P-CSCF/S-CSCF | ACR [Interim] | 收到 UPDATE 或 reINVITE 的 200 OK 响应后。 | 更新 CDR，记录会话修改（如媒体改变）。 | |
| P-CSCF/S-CSCF | ACR [Stop] | 收到 BYE 请求后。 | 关闭会话 CDR，结束计费。 |
P-Charging-Vector 头域的流程依赖：
P-CSCF 在收到 UE 始发请求时，会在 P-Charging-Vector 中增加 icid 参数。此 ICID 作为计费的会话锚点，贯穿整个会叫的 CDR 记录。
6. 异常场景与 SIP 定时器在容灾中的应用
IMS 流程中，SIP 定时器在确保业务连续性方面起着决定性作用，特别是在 P-CSCF/BAC 故障时。
| 异常事件 | 涉及的 SIP 定时器 | 终端/P-CSCF 动作 | 引用 |
|---|---|---|---|
| P-CSCF 故障（重注册） | Timer F | UE 在 Timer F 内未收到 P-CSCF 对重注册请求的响应消息时，终端选择次优先级别的 P-CSCF/BAC2 重新发起初始注册请求。 | |
| P-CSCF 故障（主叫 INVITE） | Timer B | UE 在 Timer B 内没有收到 P-CSCF/BAC1 的响应消息，终端结束当前呼叫，当前呼叫失败。终端重新向 P-CSCF/BAC2 发起初始注册。 | |
| P-CSCF 故障（短信始呼） | Timer F | UE 在 Timer F 内没有收到 P-CSCF/BAC1 的响应消息，终端结束当前短信始呼，当前短信始呼失败。终端重新向 P-CSCF/BAC2 发起初始注册。 | |
| 会话定时器超时 | Session Timer | 如果 P-CSCF/S-CSCF 要求周期性刷新会话，且定时器超时后，P-CSCF/S-CSCF 应删除和会话相关的信息，并向主被叫两侧发送 BYE 请求。 | |
| S-CSCF 故障（始发） | 启发式链路检测 | P-CSCF/BAC 启动 SIP 启发式链路检测，确认 S-CSCF 故障后，向终端返回 504 响应，通知终端重新注册。 |
7. 本章小结
IMS 注册流程是 SIP 协议在电信级网络中复杂应用的缩影。它通过 REGISTER/200 OK 完成逻辑身份 (From/To) 与物理地址 (Contact) 的绑定，通过 P-Header (Path/Service-Route) 完成路由锚定，通过 AKA 鉴权和 P-Asserted-Identity 完成身份断言，并通过 P-Charging-Vector 完成计费的初始锚定。
P-CSCF 作为接入边界，承担着严格校验后续请求 Route 列表和维护对话状态的关键责任。任何路由和身份信息的校验失败，都可能导致 400 Bad Request 或 403 Forbidden 响应，从而体现了 IMS 网络对信令可靠性和安全性的高标准要求。
工程师进阶思考 (FAQ)
Q1：P-CSCF 收到 UE 发起的 REGISTER 消息后，何时会向 S-CSCF 发送 SUBSCRIBE 消息？这样做的目的是什么？
A1： P-CSCF 在收到用户注册消息的 200 OK 响应后，会立即向 S-CSCF 发送 SUBSCRIBE 消息，订阅用户的注册状态信息。
这样做的目的是为了确保 P-CSCF 实时感知用户的注册状态变更。如果用户从 IMS 网络注销（如关机）或因故障被网络注销，S-CSCF 会向 P-CSCF 发送 NOTIFY 消息（其中 <registration> 元素的 state 属性为 terminated），P-CSCF 收到 NOTIFY 后，可以及时释放与该用户相关的安全关联（SA）和会话资源。
Q2：在 S-CSCF 容灾接管的终结流程中，I-CSCF 是如何处理的？
A2： 当 I-CSCF 通过 SIP 启发式链路检测获知用户注册的 S-CSCF1 故障时：
- I-CSCF 会根据 HSS 返回的用户 S-CSCF 能力集，从 S-CSCF 资源池中重选一个可用的 S-CSCF2。
- I-CSCF 向 HSS 发起普通的 LIR 请求（不含
User-Authorization-Type），以获取用户当前服务的 S-CSCF1。 - I-CSCF 将终结请求（如
INVITE）送至重选的 S-CSCF2。 - S-CSCF2 收到请求后，根据从 HSS 获取的 iFC、
Path、Contact等信息完成终结请求处理。
此外，S-CSCF 会设置等待定时器，若在定时器内 VoLTE 终端重新成功注册，S-CSCF 将继续完成该呼叫或短信终呼。
Q3：IMS 呼叫中的计费流程，是如何关联会话建立、会话修改和会话释放三个阶段的？
A3： IMS 计费（非在线计费）通过 Diameter ACR（Accounting Request）消息实现会话三个阶段的关联：
- 会话建立（Start）：P-CSCF 和 S-CSCF 在收到 INVITE 的
200 OK响应后，会向 CDF 发送ACR [Start]消息，创建 P-CSCF CDR 和 S-CSCF CDR。同时，I-CSCF 在收到 INVITE 后会触发ACR [Event]，创建 I-CSCF CDR。 - 会话修改（Interim）：在会话进行中，如果发生会话修改（如
UPDATE或reINVITE携带新的 SDP），P-CSCF 和 S-CSCF 会发送ACR [Interim]消息，通知 CDF 更新 CDR（例如，记录媒体的改变）。 - 会话释放（Stop）：当收到
BYE请求后，P-CSCF 和 S-CSCF 会发送ACR [Stop]消息，关闭会话 CDR。
整个会话期间，P-Charging-Vector 头域中的 ICID 确保了所有这些不同阶段的 CDR 记录能够准确地关联到同一个会话。
请您发出“请继续”指令，我将开始撰写第十一篇。