VoLTE高清语音技术精要（六）：IMS独有的路由锚定机制：Path与Service-Route深度解析
1. 导论：为什么 IMS 呼叫需要特殊的路由锚定？
在 SIP 协议的通用路由模型（由 Via, Request-URI, Record-Route 组成）中，核心挑战在于：如何在用户终端（UE）的 IP 地址动态变化，且网络拓扑复杂多变的情况下，确保 IMS 核心网元——特别是 S-CSCF（服务呼叫会话控制功能，即 IMS 的“大脑”）——能够持续、可靠地找到用户代理（UA）？
VoLTE/VoNR 网络对呼叫的控制和维护比传统 SIP 更严格。一旦用户注册成功，S-CSCF 就必须“锚定”该用户的接入路径，以便处理：
- 用户发起的呼叫/请求（MO/Mobile Originated）：UE 必须知道将所有后续的始发 SIP 请求（如 INVITE, MESSAGE）路由到哪一个 S-CSCF。
- 网络发起的呼叫/请求（MT/Mobile Terminated）：S-CSCF 必须知道如何将网络终结的请求（如被叫 INVITE）准确地发送回该用户当前的 P-CSCF/BAC，从而到达用户终端的实际 IP 地址。
Path 和 Service-Route 这两个 P-Header（私有头域），正是 3GPP 和运营商为解决 IMS 特有的 “注册锚定” 这一核心路由需求而引入的扩展机制。它们构成了 IMS 领域内 注册路径与始发/终结呼叫路径 的关键桥梁。
2. P-Header 路由扩展的定义与哲学
Path 和 Service-Route 都属于 SIP 协议中的扩展头域，专门用于 IMS 网元之间传递会话路径信息，它们本质上是对标准 SIP Record-Route 和 Route 头域在注册场景下的专业化应用。
2.1 P-Header 路由扩展概览
| 头域名称 | 传输方向（在 REGISTER 流程中） | 核心作用 | 扮演的角色 |
|---|---|---|---|
| Path | UE S-CSCF （由 P-CSCF 插入） | 记录 S-CSCF 到 P-CSCF 的反向信令路径，用于 MT 呼叫寻址。 | 注册请求的 Record-Route 扩展。 |
| Service-Route | S-CSCF UE （由 S-CSCF 插入） | 指引 UE 或 P-CSCF 路由到 S-CSCF 的路径，用于 MO 呼叫寻址。 | 注册响应的 Route 扩展。 |
在 IMS 信任域内，这两个头域都是强制性要求，用于确保 P-CSCF 和 S-CSCF 之间对话路径的精确锚定。
2.2 为什么不用 Record-Route 和 Route 替代？
虽然 Path 和 Record-Route 都是记录路由路径，Service-Route 和 Route 都是指定路由路径，但它们在 REGISTER 流程中 扮演的角色不同：
- REGISTER 是独立事务：
REGISTER消息本身并不建立媒体会话（Session），但它建立了注册对话（Registration Dialog），用于绑定From/To与Contact地址。传统的Record-Route主要用于对话（如 INVITE 建立的对话）内部的后续请求路由（如BYE）。 - 注册的持久性：IMS 需要一个长期的机制来保存 P-CSCF 和 S-CSCF 的锚定关系，以便所有始发请求（包括后续的 INVITE、MESSAGE、OPTIONS 等独立事务）都能准确路由。
Path和Service-Route提供了这种专用的、用于锚定注册上下文的机制。
3. Path 头域：MT 呼叫的信令回程票
Path 头域在 SIP REGISTER 流程中，由 P-CSCF 插入到请求中，并发送给 S-CSCF。
3.1 Path 的工作机制与格式
- 插入时机：UE 发送
REGISTER请求到 P-CSCF 后，P-CSCF 在转发给 I-CSCF/S-CSCF 之前，必须将自身的 SIP URI（通常包含transport=...;lr参数）添加到Path头域中。 - 记录作用：
Path记录了当前 P-CSCF 的地址。 - S-CSCF 的处理：S-CSCF 收到包含
Path头域的REGISTER请求后，会将整个Path列表信息存储在用户会话数据中（S-CSCF 是注册状态的维护者）。 - MT 呼叫使用：当 S-CSCF 收到一个终结于该用户的请求（如被叫
INVITE）时，S-CSCF 会利用存储的Path列表，将其内容反向复制到INVITE请求的Route头域中，从而确保该INVITE消息能够准确地路由回到该用户当前注册的 P-CSCF/BAC。
Path 头域示例（P-CSCF 添加）：
Path: <sip:[email protected]:30402;lr>
pcscf1.ims.bj.chinamobile.com: P-CSCF 的地址。;lr(loose routing)：表示松散路由。;term@: 某些实现中可能携带的参数，指示这是终端侧的地址记录。
3.2 Path 的必选性要求
Path 头域在 IMS 注册流程中是至关重要的，因此 SIP 协议要求在 REGISTER 请求中必须携带 Require: path 和 Supported: path 头域。
| 注册请求中的 Path 相关头域 | 作用 | 来源 |
|---|---|---|
| Require: path | 强制要求路径上的 SIP 实体（主要是 S-CSCF）支持 Path 扩展机制。 | UE 或 P-CSCF |
| Supported: path | 声明该实体支持 Path 扩展机制。 | UE 或 P-CSCF |
4. Service-Route 头域：MO 呼叫的信令导航仪
Service-Route 头域在 SIP REGISTER 流程中，由 S-CSCF 在注册成功的响应（200 OK）中插入，并发送回 UE/P-CSCF。
4.1 Service-Route 的工作机制与格式
- 插入时机：S-CSCF 成功处理完
REGISTER请求，完成用户身份与 Contact 地址的绑定后，会在200 OK响应中插入Service-Route头域。 - 路由指引：
Service-Route中包含 S-CSCF 自身的 SIP URI。在 IMS 部署中，如果请求需要经过多个 AS，S-CSCF 也会将 AS 的 URI 或其他关键路由锚点加入到这个列表中。 - UE 的处理：UE（或 P-CSCF）收到
200 OK响应后，会解析并存储这个Service-Route列表。 - MO 呼叫使用：当用户发起任何对话初始请求（如
INVITE,MESSAGE）时，终端将使用存储的Service-Route列表，将其内容逆序复制到新请求的Route头域中。这确保了用户的始发请求能够精确地到达为其提供服务的 S-CSCF。
Service-Route 示例（S-CSCF 插入）：
Service-Route: <sip:scscf1.home.net;lr>, <sip:as1.home.net;lr>
// 假设 S-CSCF 和 AS 都希望参与始发呼叫
4.2 Service-Route 的严格校验（运营商规范）
由于 Service-Route 确定了用户所有后续业务的入口，运营商对 P-CSCF 接收到始发请求后，对 Route 头域的校验有严格要求。
| 请求类型 | P-CSCF 校验要求 | 异常处理 (CU) | 来源 |
|---|---|---|---|
| 独立事务请求 (如 MESSAGE, OPTIONS) | P-CSCF 必须验证请求中的 Route 列表是否与注册时保存的 Service-Route 列表精确匹配。 | 如果校验失败：P-CSCF 应回复 400 (Bad Request) 响应且不再继续处理请求。或者，P-CSCF 应支持用最新注册消息中的 Service-Route 头替换请求消息的 Route 头。 | |
| 未知方法的请求 (与当前对话无关) | P-CSCF 应确认 Service-Route 头中的 URI 列表是否也以相同的顺序存在于收到的请求所带的 Route 头域中。 | 如果没有发现对应的对话：P-CSCF 应回复 403 (Forbidden) 响应，且不再转发该请求。 |
这种严格的校验机制确保了：
- 会话完整性：所有后续请求必须沿着 S-CSCF 在注册时指定的路径，防止业务旁路。
- 安全和防篡改：防止恶意终端篡改
Route列表，将请求路由到非法的 S-CSCF 或 AS。
5. 注册流程中的 Path 与 Service-Route 交互实战
以下是 SIP REGISTER 消息流中，Path 和 Service-Route 如何在 P-CSCF 和 S-CSCF 之间完成锚定和指引的详细过程。
5.1 阶段一：注册请求（Path 的记录）
UE P-CSCF S-CSCF (REGISTER Request)
| 步骤 | 消息流向 | 关键 SIP 头域变化 | 锚定目的 |
|---|---|---|---|
| 1. UE P-CSCF | REGISTER | 携带 Supported: path, Require: path。Contact 携带 UE 地址。 | 启动注册，声明支持 Path 机制。 |
| 2. P-CSCF S-CSCF | REGISTER | P-CSCF 插入 Path 头域：<sip:[email protected];lr>。P-CSCF 在 Via 顶端增加自己的地址。 | S-CSCF 存储此 Path，用于未来 MT 呼叫的 Route 列表生成。 |
5.2 阶段二：注册响应（Service-Route 的指引）
S-CSCF P-CSCF UE (REGISTER 200 OK Response)
| 步骤 | 消息流向 | 关键 SIP 头域变化 | 锚定目的 |
|---|---|---|---|
| 3. S-CSCF P-CSCF | 200 OK | S-CSCF 插入 Service-Route 头域：<sip:scscf.home.net;lr>。S-CSCF 在 To 域添加 tag。 | UE/P-CSCF 存储此 Service-Route，用于未来 MO 呼叫的 Route 列表生成。 |
| 4. P-CSCF UE | 200 OK | P-CSCF 移除顶端 Via，将 200 OK 转发给 UE。P-CSCF 存储 Service-Route 列表，并根据本地策略，可能会在终端的 Route 列表添加 P-CSCF 地址。 | 终端或 P-CSCF 获得 S-CSCF 的“导航地图” (Service-Route)。 |
5.3 阶段三：后续 MO 呼叫（Service-Route 的应用）
UE P-CSCF S-CSCF (INVITE Request)
| 步骤 | 消息流向 | 关键 SIP 头域变化 | 锚定目的 |
|---|---|---|---|
| 5. UE P-CSCF | INVITE | UE 使用存储的 Service-Route（例如 <sip:scscf.home.net;lr>），将其复制到 Route 头域中，并可能在 Route 列表中将 S-CSCF 地址放在顶端或特定位置。 | 强制请求路由到 S-CSCF，启动业务。 |
| 6. P-CSCF S-CSCF | INVITE | P-CSCF 校验 Route 列表与保存的 Service-Route 是否匹配。校验通过后，P-CSCF 移除顶端 Route，并将自身加入 Record-Route 顶端。 | 确保始发请求沿着正确的路径流向 S-CSCF，并开始对话锚定（Record-Route）。 |
6. 容灾场景下的路由接管（以 P-CSCF 容灾为例）
在运营商网络中，Path 和 Service-Route 机制与容灾（Disaster Recovery）流程紧密耦合，尤其是在 P-CSCF/BAC 故障时。
6.1 P-CSCF 故障后的路由接管
当用户原来注册的 P-CSCF1 发生故障时，SBC 或终端会将请求切换到备用的 P-CSCF2。由于 P-CSCF2 没有用户注册数据，它必须采取特殊手段来获取 S-CSCF 的地址并路由呼叫。
| 故障场景 | P-CSCF2 的路由处理 (CU 容灾规范) | 路由依赖 | 来源 |
|---|---|---|---|
| 重注册（REGISTER） | 终端向 P-CSCF2 发起初始注册请求。P-CSCF2 收到后，转发给 I-CSCF，I-CSCF 查询 HSS 获取原 S-CSCF 地址，从而将注册消息发送到当前服务的 S-CSCF。 | S-CSCF 地址查询。 | |
| 主叫始呼（INVITE） | P-CSCF2 无用户注册数据。P-CSCF2 根据主叫用户的域名查询 DNS，将呼叫请求发往主叫用户归属的 I-CSCF。P-CSCF2 在 INVITE 消息的 Route 中增加标识主叫流程的 orig 参数。 | 依赖 I-CSCF/HSS 寻址和 orig 标识。 | |
| 主叫始呼身份构造 | P-CSCF2 在 INVITE 消息中提取 PPI 或者 FROM 域的主叫号码构造 PAI。 | 依赖 From 或 P-Preferred-Identity 构造 PAI。 |
专家解读： 在 P-CSCF 故障导致无注册数据的场景下，P-CSCF2 无法使用保存的 Service-Route 列表进行路由校验。因此，它必须通过查询 I-CSCF 来重建路由路径，并通过在 Route 中携带 orig 参数，告知 I-CSCF 这是一个容灾接管场景下的始呼请求。
6.2 注册后请求的 Service-Route 校验与异常处理
某运营商的 IMS 系统规范对 P-CSCF 的 Service-Route 校验流程有着细致的要求，这体现了对 SIP 协议细节的深度控制。
| SIP 消息类型 | P-CSCF 的校验与操作 | 异常/错误响应 |
|---|---|---|
| 目标刷新请求 (reINVITE, UPDATE) | 校验请求中的 Route 列表是否与保存的 Record-Route 列表匹配。如果匹配，更新 Contact 和 CSeq。 | 如果 Route 列表校验失败，返回 400 (Bad Request) 响应。 |
| 独立事务请求 (MESSAGE, OPTIONS) | 验证 Service-Route URI 列表与请求中的 Route 头域是否匹配。检查是否含有 P-Preferred-Identity，有则删除并插入 P-Asserted-Identity。 | 如果校验失败，返回 400 (Bad Request) 或用最新注册消息中的 Service-Route 替换 Route。 |
| 未知方法的请求 (与当前对话无关) | 确认 Service-Route 头中的 URI 列表是否以相同顺序存在于 Route 头中。如果含有 P-Preferred-Identity，则删除并插入 P-Asserted-Identity。 | 如果没有发现对应的对话，回复 403 (Forbidden)。 |
这种多层次的校验，确保了 SIP 消息在 IMS 信任域内的每一跳都是可信且可追踪的。
7. 信令日志实战分析：P-CSCF 的路由锚定与身份断言
以下日志片段展示了 P-CSCF 如何在收到独立事务请求（如 MESSAGE）时，执行 Service-Route 校验 和 身份断言。
场景： UE 发送了一条 IM 消息（MESSAGE），该请求不属于任何正在进行的通话对话，但它属于注册对话。
7.1 UE 发起的 MESSAGE 请求（包含 Service-Route 逆序的 Route 列表）
MESSAGE sip:[email protected] SIP/2.0
Via: SIP/2.0/UDP 10.1.1.10:5060;branch=z9hG4bKue.msg.1
Route: <sip:scscf1.home.net;lr>, <sip:pcscf1.visited.net;lr> // Service-Route 的逆序
From: <sip:[email protected]>;tag=msg.from
To: <sip:[email protected]>
CSeq: 1 MESSAGE
P-Preferred-Identity: <sip:[email protected]>
// ... 其他头域
7.2 P-CSCF 收到并处理（校验 Service-Route，插入 PAI）
P-CSCF 收到此 MESSAGE 请求后：
- Service-Route 校验：P-CSCF 检查请求中的
Route列表（包含scscf1.home.net和pcscf1.visited.net）是否与该用户注册时 S-CSCF 返回的Service-Route精确匹配。假设匹配成功。 - 身份处理：请求包含
P-Preferred-Identity。P-CSCF 删除P-Preferred-Identity，并插入经过认证的P-Asserted-Identity。 - 计费处理：在
P-Charging-Vector中增加icid参数。 - 路由转发：P-CSCF 移除顶端
Route（即scscf1.home.net），将自己的地址压入Via顶端，并将Request-URI设置为scscf1.home.net的 SIP URI。
P-CSCF S-CSCF 转发的 MESSAGE 请求：
MESSAGE sip:scscf1.home.net SIP/2.0
Via: SIP/2.0/UDP 20.1.1.20:5060;branch=z9hG4bKpcscf.msg.2 // P-CSCF 地址在顶端
Route: <sip:pcscf1.visited.net;lr> // S-CSCF 地址已被移除，P-CSCF 地址成为新的顶端 Route
From: <sip:[email protected]>;tag=msg.from
To: <sip:[email protected]>
CSeq: 1 MESSAGE
P-Asserted-Identity: <sip:[email protected]> // P-CSCF 插入 PAI
P-Charging-Vector: icid-value="pcscf.id.xyz..." // P-CSCF 增加 icid
// P-Preferred-Identity 头域已被删除
分析要点： 通过 Service-Route 的校验和应用，P-CSCF 确保了独立事务请求能够准确地沿注册锚定的路径发往 S-CSCF，同时在转发前完成了至关重要的**身份（PAI）和计费（icid）**信息的插入。
8. 本章小结
在 IMS 这种严格管控的电信网络中，SIP 路由的可靠性超越了 RFC 3261 的基本要求。
- Path 头域在 REGISTER 请求 中由 P-CSCF 插入，S-CSCF 存储，用于 MT 呼叫 时生成返回 P-CSCF 的
Route列表（信令回程票）。 - Service-Route 头域在 REGISTER 200 OK 响应 中由 S-CSCF 插入，P-CSCF/UE 存储，用于 MO 呼叫 时生成发往 S-CSCF 的
Route列表（信令导航仪）。 - 运营商规范（如某运营商）严格要求 P-CSCF 对后续的独立事务请求中的
Route列表与保存的Service-Route进行精确匹配校验，这是维持会话状态和业务连续性的关键。 - 在 P-CSCF 容灾接管场景中，由于注册数据丢失，备用 P-CSCF2 必须通过查询 I-CSCF/HSS 重建路由，并在
INVITE的Route中携带orig参数，同时执行身份的断言（PAI 构造）。
工程师进阶思考 (FAQ)
Q1：P-CSCF 在收到 UE 发起的独立事务请求（例如 MESSAGE）时，如果 Service-Route 校验失败，P-CSCF 应该如何处理？返回 400 Bad Request 还是 403 Forbidden？
A1： P-CSCF 的处理取决于校验失败的原因，通常返回 400 Bad Request。
Service-Route列表校验失败：如果请求中的Route头域与注册时保存的Service-RouteURI 列表不匹配，某运营商规范要求 P-CSCF 应回复400 (Bad Request)响应且不再继续处理请求。或者，P-CSCF 可以选择用最新注册消息中的Service-Route头替换请求消息的Route头。- 对话不存在：如果 P-CSCF 收到 UE 发起的请求，但没有发现存在对应的对话（即无法找到该用户的会话状态，如会话已被释放或从未建立），P-CSCF 应回复
403 (Forbidden)响应，且不再转发该请求。
Q2：IMS 网络中的 S-CSCF 是如何判断一个到来的请求（如 INVITE）是新呼叫还是与现有对话的关联请求？
A2： S-CSCF 通过检查请求消息中 Route 头域的最高项是否包含 S-CSCF 以前放置的原始对话标识来判断。
- 不存在：如果
Route头域的最高项不存在 S-CSCF 放置的原始对话标识，则表示这个请求是第一次拜访这个 S-CSCF（即一个新的始发或终结请求）。 - 存在：如果
Route头域的最高项存在 S-CSCF 放置的原始对话标识，则表示了与一个现存对话的联系，并且该请求是从 AS 发来的对于先前发送请求的响应。
这种检查是 S-CSCF 确定是否需要执行初始过滤规则（iFC）和业务触发的关键第一步。
Q3：在 IMS P-CSCF 容灾场景下，为什么备用 P-CSCF2 必须将呼叫请求发往 I-CSCF，而不是直接发往 S-CSCF？
A3： 因为 P-CSCF2 故障接管时没有用户注册数据，不知道该用户当前由哪个 S-CSCF 服务。
- 缺乏 S-CSCF 地址：正常的始呼流程依赖于注册时存储的
Service-Route来确定 S-CSCF 地址，但 P-CSCF2 此时没有这些数据。 - I-CSCF 的寻址功能：I-CSCF 的核心职责就是根据用户标识（IMPU/PAI）向 HSS 发起 LIR/UAR 查询，获取用户当前服务的 S-CSCF 地址和能力集。
- 容灾流程：因此，P-CSCF2 必须将请求转发给 I-CSCF，由 I-CSCF 完成 S-CSCF 的动态寻址。同时，P-CSCF2 会在
Route中添加orig等标识，帮助 I-CSCF 识别这是一个容灾流程，以获取正确的主叫用户 S-CSCF 路由。
请您发出“请继续”指令，我将开始撰写第七篇。