好的，专家讲师。我将继续为您撰写SIP协议深度解析系列的第四篇。本篇将深入剖析 SIP 路由机制的基础，重点讲解 Via、Request-URI 和 Record-Route 这三个核心头域，并结合运营商规范，阐释 P-CSCF 如何利用它们进行信令路径的维护和校验。
VoLTE高清语音技术精要（四）：SIP路由机制（一）：Via、Request-URI 与 Record-Route 详解
1. 导论：SIP路由的哲学：请求寻址与路径记录
IMS（IP Multimedia Subsystem）网络是高度分布式的，一个简单的呼叫建立请求（INVITE）可能需要穿越数十个信令跳（Hop），涉及多个CSCF、AS和边界控制器（SBC/IBCF）。因此，SIP协议必须提供强大而灵活的路由机制。
SIP路由机制的核心在于解决两个根本问题：
- 请求路由（Request Forwarding）：如何将当前的请求消息（如 INVITE, REGISTER, BYE）准确地送到下一跳网元，并最终送达会话的逻辑终点？
- 响应路由和对话持续性（Response & Dialog Maintenance）：请求被处理后，响应消息如何原路返回？会话建立后，后续的所有信令消息（如 BYE, UPDATE）如何沿原路径传输，以维持对话上下文？
本章将深入解析实现这两个机制所需的三个核心 SIP 头域：Request-URI 负责初始目标寻址，Via 负责事务的逐跳路由和响应返回，而 Record-Route 和 Route 负责对话的持续性路由。
2. Request-URI：请求的寻址目标
Request-URI（请求统一资源标识符）位于 SIP 请求消息的起始行（Request-Line）中，是 SIP 协议用于确定请求初始目标的地址字段。
2.1 Request-URI 的格式与类型
Request-URI 可以使用 SIP、SIPS 或 TEL URI 格式。在 IMS 网络中，URI 的格式选择和转换是实现电信级呼叫的重要步骤：
| URI 格式 | 示例 | 核心用途 | IMS 路由处理 |
|---|---|---|---|
| SIP/SIPS URI | sip:[email protected] | 标识用户或网元，IMS域内路由的基本格式。 | S-CSCF 和 I-CSCF 通过域名（domain.com）进行 DNS/ENUM 查询和路由决策。 |
| TEL URI | tel:+86139xxxx1234 | E.164 电话号码格式。 | IMS 网元（如 S-CSCF）必须将其转换为 SIP URI 或通过 ENUM/DNS 查询（如江苏省二级 ENUM/DNS 查询）来确定归属域的下一跳地址。 |
| URN | urn:service:sos.police | 统一资源名称。 | 用于紧急呼叫，由核心网（如 E-CSCF）识别并路由到对应的 PSAP（公共安全应答点）。 |
2.2 Request-URI 在路由中的作用
- 初始目标：对于对话初始请求（如
REGISTER,INVITE），Request-URI指定了请求应该被转发到的逻辑目的地或下一跳代理的地址。 - 路由重写：当请求在 IMS 网络中流动时，代理服务器（Proxy）可能会根据其路由逻辑或运营商策略修改
Request-URI的值，但这必须谨慎进行，通常是当代理确切地知道最终的下一步目标时。 - 终结请求处理：对于发往终端（UE）的对话初始请求，P-CSCF 在转发给终端之前，应在
Request-URI中包含终端的 URI。
3. Via 头域：事务路由与响应路径的保障
Via 头域是 SIP 协议中实现请求逐跳路由（Hop-by-Hop Routing）和响应反向路由（Reverse Routing）的核心机制。它确保了响应消息能够沿着与请求消息完全相同的路径原路返回。
3.1 Via 头域的结构与工作机制
Via 头域是一个列表，请求每经过一个 SIP 代理，该代理就会将自己的地址（IP 地址/端口）添加到 Via 列表的最顶端。
| Via 组成要素 | 作用 | 运营商关注点 |
|---|---|---|
| SIP 版本 | 协议版本，如 SIP/2.0。 | |
| 传输协议 | 承载 SIP 消息的协议，如 UDP, TCP。 | VoLTE 信令通常通过 UDP 或 TCP 承载。 |
| 地址与端口 | 代理的 IP 地址或域名及端口。 | P-CSCF/SBC 在转发到下一跳之前，必须将自己的地址添加到 Via 列表顶端。 |
| 分支参数 (branch) | branch=z9hG4bK...，唯一标识一个事务。 | 确保请求和所有响应（包括重传）能够正确关联到同一个事务。 |
| Rport/Received | rport（客户端端口）和 received（客户端IP地址）。 | 用于处理 NAT/防火墙场景。当代理收到请求时，会根据实际源地址填充这两个参数，指导响应返回到正确的公网地址。 |
3.2 响应消息的路由规则
当 UAS 或代理生成响应消息（如 200 OK, 183 Session Progress）时，它不会使用 Route 或 Request-URI 进行路由。它仅检查 Via 列表：
- 移除最顶端 Via：UAS/代理将响应发送给
Via列表最顶端记录的地址。 - 逐跳 Pop：接收到响应的代理检查自己是否是
Via列表的第二个条目。如果是，它移除顶端的Via条目，并重复步骤 1，直到响应到达发起请求的 UAC。
3.3 P-CSCF 对 Via 头域的严格校验要求
作为 IMS 的接入实体，P-CSCF 必须确保 Via 列表的完整性和一致性，这在运营商规范中被严格要求：
| P-CSCF 场景 | 动作要求 | 引用标准 |
|---|---|---|
| 收到 UE 目标刷新请求 | 如果 Route 头域列表与已保存的 Record-Route 列表匹配，P-CSCF 必须在 Via 头域最顶端增加 P-CSCF 的地址。 | |
| 收到发往 UE 的请求 | P-CSCF 必须将 P-CSCF 的地址添加到 Via 列表的最顶端。 | |
| 收到任何响应 | P-CSCF 必须确认响应中的 Via 列表是否与同一对话的请求消息中保存的 Via 列表相匹配。 | |
| Via 列表不匹配 | 如果 Via 列表不匹配，P-CSCF 应丢弃该响应，或者用保存的 Via 列表替换响应中的 Via 头。 | |
| 初始 INVITE 请求 | P-CSCF 应给所有的 INVITE 请求回送 100 (Trying) 临时响应。 注意：100 (Trying) 响应是特殊的，它不会被有状态代理向上游转发，仅在逐跳链路上使用，以防止 UAC 因超时而重传 INVITE。 |
4. Record-Route 与 Route：对话的路由锚定
Record-Route 和 Route 头域共同作用，实现了 对话的持续路由。它们确保了一旦会话建立，后续所有对话内的请求（如 BYE, Re-INVITE, UPDATE）能够沿着 IMS 核心网的同一路径进行。
4.1 Record-Route：记录路径
Record-Route 头域由 SIP 代理（Proxy） 在转发对话建立请求（如 INVITE, SUBSCRIBE）时添加。
- 记录行为：如果一个代理希望在对话的生命周期内持续参与后续的信令交互，它必须将自己的 SIP URI 添加到
Record-Route列表的最顶端。 - 用途：
Record-Route记录了所有希望参与后续对话的中间代理地址。
4.2 Route：强制路由
Route 头域由 UAC（或 UAS 收到响应后的代理）生成，用于指定请求的强制路由路径。
- 生成规则：在对话建立后，UAC 发送后续对话内请求（如
BYE,UPDATE）时，它会使用保存在本地的Record-Route列表，将其内容反向复制到新请求的Route头域中。 - 路由类型：SIP 代理在处理
Route头时，通常遵循松散路由（Loose Routing），由;lr参数指示。代理读取Route列表的最顶端 URI，并将其作为本次路由的下一跳地址，然后将该 URI 移动到Route列表的末尾。
4.3 运营商对路由列表的校验和维护
在 IMS 场景中，P-CSCF 和 S-CSCF 作为核心路由节点，肩负着验证和维护 Route 列表的重任。
4.3.1 P-CSCF 对后续请求的路由校验
运营商规范对 P-CSCF 接收来自 UE 的后续请求（如 BYE, UPDATE）时的处理流程有明确要求：
| 场景 | P-CSCF 校验/操作 | 引用标准 |
|---|---|---|
| 目标刷新请求 (reINVITE/UPDATE) | P-CSCF 必须确认请求中的 Route 列表是否与同一对话中保存下来的 Record-Route 列表相匹配。如果匹配，P-CSCF 在 Record-Route 顶端增加自己的 SIP URI。 | |
| 独立事务请求/未知方法 | P-CSCF 应验证注册时保存的 Service-Route 头域的 URI 列表与收到请求中的 Route 头域是否匹配。 | |
| Route 列表校验失败 | P-CSCF 应回复 400 (Bad Request) 响应，且不再继续处理请求；或者用最新注册消息中的 Service-Route 头替换请求消息的 Route 头。 | |
| 请求无对应对话 | P-CSCF 收到 UE 发起的后续请求或独立请求，如果没有发现存在对应的对话，P-CSCF 应回复 403 (Forbidden) 响应，且不再转发该请求。 | |
| 会话释放中收到请求 | 当 P-CSCF 在释放对话的过程中收到关于对话的请求时，P-CSCF 应中止该请求，并回送响应 481 (对话或者事务不存在)。 |
4.3.2 S-CSCF 对对话请求的路由检查
S-CSCF 在处理对话请求时，也会检查路由头以确认请求的来源和对话的上下文：
- 当 S-CSCF 从服务用户或 PSI 接收到对话的最初请求或者独立会话的请求时，它应该检查是否 S-CSCF 以前放置在 Route 头域中的原始对话标识存在于到来请求 Route 头域的最高项。
- 如果不存在，表示该请求是第一次拜访该 S-CSCF。
- 如果存在，则表示该请求是与一个现存对话的联系，且请求是从 AS 发来的对于先前发送请求的响应。
5. 计费标识的路由伴随：ICID 参数的插入
虽然计费头域 P-Charging-Vector 将在后续章节详细讨论，但在路由过程中，P-CSCF 负有插入其关键参数的责任。
- P-CSCF 的计费锚点作用：P-CSCF 在接收到 UE 发起的独立事务请求（如
MESSAGE,OPTIONS）后，必须在 P-Charging-Vector 中增加 icid（IMS Charging Identifier，IMS 计费标识）参数。 - 始发 INVITE 计费：P-CSCF 收到 UE 发起的 INVITE 请求时，也会插入
P-Charging-Vector，其中包含更新过的access-network-charging-info参数，并在转发给 S-CSCF 时包含该参数。
6. 信令日志实战分析：INVITE 请求的路径追踪
我们通过一个主叫 INVITE 消息穿越 P-CSCF 和 S-CSCF 的简化流程，观察 Via、Request-URI 和 Record-Route 的变化。
场景： 主叫 UE（UE-A）发起呼叫，信令流经拜访地的 P-CSCF（P-CSCF1）和归属地的 S-CSCF（S-CSCF1）。
6.1 步骤 1：UE-A 发起 INVITE 请求
| SIP 头域 | 示例值 | 关键作用分析 |
|---|---|---|
| Request-Line | INVITE sip:[email protected] SIP/2.0 | 初始目标地址。 |
| Via (1) | SIP/2.0/UDP 10.1.1.10:5060;branch=z9hG4bKabc123 | UE 地址。该 branch 标识了 INVITE 事务。 |
| Route | <sip:pcscf1.visited.net;lr> | 包含 P-CSCF 的地址（由注册流程获得）。 |
| Record-Route | 无 | 初始请求没有，由代理添加。 |
| P-Preferred-Identity | <sip:[email protected]> | 用户的期望身份（P-CSCF 将处理并删除）。 |
6.2 步骤 2：P-CSCF1 收到并转发 INVITE 请求
P-CSCF1 必须执行多项路由和身份处理功能，然后将请求路由到 S-CSCF1。
| SIP 头域 | 示例值 | 关键作用分析 |
|---|---|---|
| Request-Line | INVITE sip:S-CSCF1.home.net SIP/2.0 | P-CSCF 根据路由决策（或 Route 头）将 URI 目标改为 S-CSCF1。 |
| Via (2) | SIP/2.0/UDP 20.1.1.20:5060;branch=z9hG4bKdef456 | P-CSCF 地址（新的顶端 Via）。 |
| Via (1) | SIP/2.0/UDP 10.1.1.10:5060;branch=z9hG4bKabc123... | UE 地址（位于第二层）。 |
| Record-Route (1) | <sip:pcscf1.visited.net;lr> | P-CSCF 将自己加入 Record-Route 列表顶端，锚定路由。 |
| P-Asserted-Identity | <sip:[email protected]> | P-CSCF 删除了 P-Preferred-Identity，插入 P-Asserted-Identity。 |
| P-Charging-Vector | icid-value="pcscf.id.xyz..." | P-CSCF 插入 ICID 计费锚点。 |
6.3 步骤 3：S-CSCF1 收到 INVITE 请求并转发到被叫域
S-CSCF1 检查 Record-Route，并执行业务逻辑（iFC）后继续路由。
| SIP 头域 | 示例值 | 关键作用分析 |
|---|---|---|
| Via (3) | SIP/2.0/UDP 30.1.1.30:5060;branch=z9hG4bKghi789 | S-CSCF 地址（新的顶端 Via）。 |
| Via (2) | SIP/2.0/UDP 20.1.1.20:5060... | P-CSCF 地址。 |
| Via (1) | SIP/2.0/UDP 10.1.1.10:5060... | UE 地址。 |
| Record-Route (2) | <sip:scscf1.home.net;lr> | S-CSCF 将自己加入 Record-Route 列表顶端，锚定路由。 |
| Record-Route (1) | <sip:pcscf1.visited.net;lr> | P-CSCF 地址被推到第二层。 |
6.4 响应流：200 OK 响应的反向路由
当被叫侧返回 200 OK 响应时，路由路径如下：
- 被叫 UAS → S-CSCF1：UAS 收到 INVITE，发送
200 OK。它查看请求中的Via列表顶端（即S-CSCF1），将响应发送给 S-CSCF1。 - S-CSCF1 → P-CSCF1：S-CSCF1 收到响应，删除顶端
Via（自己的地址），将响应发送给新的顶端Via（P-CSCF1 的地址）。 - P-CSCF1 → UE-A：P-CSCF1 收到响应，删除顶端
Via（自己的地址），将响应发送给新的顶端Via（UE-A 的地址）。P-CSCF 还会对响应中的Via列表进行严格匹配校验。
在这个过程中，Record-Route 列表（包含了 P-CSCF1 和 S-CSCF1）被保存在各个网元中，用于指导后续的 BYE 或 UPDATE 请求的路由。
7. 本章小结
IMS 网络路由的可靠性基于 SIP 协议对请求和响应的严格分离和管理：
- Request-URI 决定了 SIP 请求的初始寻址目标。
- Via 头域是实现事务的逐跳路由和响应消息原路返回的关键，每个代理都会在请求中将自己的地址压入 Via 栈的顶端。
- Record-Route 头域用于在对话建立时记录所有中间代理的地址，这些记录随后被转换为 Route 头域，指导所有后续对话请求（如
BYE,UPDATE）沿固定路径传输，从而维持 IMS 网络的会话状态和拓扑。
运营商规范（例如某运营商）对 P-CSCF 提出了严苛的路由校验要求，包括确保对话存在性（否则 403 Forbidden）和 Route/Record-Route/Service-Route 列表的精确匹配，以防止非法请求和会话劫持。
工程师进阶思考 (FAQ)
Q1：在运营商网络中，为什么 P-CSCF 必须对 UE 发起的“目标刷新请求”中的 Route 头域进行严格校验，确保其与已存储的 Record-Route 列表匹配？如果不匹配，会带来哪些风险？
A1： P-CSCF 必须对目标刷新请求（如 Re-INVITE 或 UPDATE）中的 Route 头域进行严格校验，这是 IMS 会话状态完整性和安全的关键保障。
- 状态维护：对话建立后，IMS 核心网元（特别是 P-CSCF 和 S-CSCF）会基于
Record-Route确定的路径来存储会话状态、媒体参数和计费锚点信息。如果Route列表不匹配，后续请求可能会绕过某些必要的网元（如 AS 或 IBCF），导致业务逻辑（如计费、AS 业务）被旁路，造成“幽灵会话”或计费漏洞。 - 安全风险：如果
Route列表被恶意篡改，可能导致信令流被重定向到非法的 SIP 实体，造成呼叫劫持或欺诈。因此，P-CSCF 必须检查传入的Route列表是否与之前建立对话时记录的路径一致。如果校验失败，P-CSCF 应返回400 (Bad Request)。
Q2：SIP 响应中的 Via 列表和 Record-Route 列表在 IMS 转发过程中有何本质区别？哪些网元会修改它们？
A2：
| 特征 | Via 列表 | Record-Route 列表 |
|---|---|---|
| 路由目的 | 事务逐跳路由。指导响应消息如何沿原路返回 UAC。 | 对话路由锚定。指导后续对话内请求（BYE, UPDATE）的端到端路由。 |
| 修改者 | 请求沿路径转发时，每个代理在请求中将自己地址添加在最顶端。 | 代理希望参与对话时，在对话初始请求中将自己地址添加在最顶端。 |
| 状态维护 | 响应到达时，每跳代理会将顶端 Via 移除（Pop）。 | 仅在对话建立时记录，对话内请求（如 BYE）将 Record-Route 逆转为 Route，作为请求的转发指引。 |
| IMS 关注点 | P-CSCF 必须验证 Via 列表与保存列表的匹配性。 | P-CSCF/S-CSCF 必须保存此列表并将其转换为 Route 以进行后续会话控制。 |
Q3：IMS 网络中的 SIP 消息中，P-CSCF 何时会删除 P-Preferred-Identity 头域并插入 P-Asserted-Identity 头域？
A3： 这发生在 P-CSCF 首次接收到来自 UE 的请求，并对其身份进行鉴权和断言的过程中。
- P-Preferred-Identity (PPI)：由终端（UE）携带，表示用户期望使用的身份。
- P-Asserted-Identity (PAI)：由 P-CSCF 插入，表示经过网络认证和断言的真实身份，用于信任域内传输。
根据运营商规范，当 P-CSCF 收到 UE 发起的独立事务请求（或未知方法请求）：
- 如果请求中包含
P-Preferred-Identity头域，P-CSCF 必须删除该头域。 - P-CSCF 必须插入
P-Asserted-Identity头域，其值应为请求的发起者（即终端的 IMPU）。 - 如果 P-CSCF 收到发往 UE 的响应，且响应中含有
P-Preferred-Identity，P-CSCF 同样会删除 PPI，并插入 PAI，其值为收到请求时保存下来的P-Called-Party-ID中的参数。
简而言之，P-CSCF 在将信令转发到信任的核心网域之前，是身份断言的强制执行者。
请您发出“请继续”指令，我将开始撰写第五篇。