好的，专家讲师。我将继续为您撰写 SIP 协议深度解析系列的第十二篇。本篇将聚焦于 IMS 网络中的计费机制。在电信级网络中，计费的精确性和可靠性是核心要求。我们将深入解析 SIP 协议中专门用于计费关联的私有头域 P-Charging-Vector，以及它在整个呼叫生命周期中，如何与 Diameter 计费消息（ACR）协同工作。
VoLTE高清语音技术精要（十二）：IMS计费核心：P-Charging-Vector与ICID/IOI
1. 导论：电信级计费的挑战与SIP的解决方案
在 IMS（IP Multimedia Subsystem）网络中，计费系统（Charging System）必须精确记录每一次会话的属性、时长、用户身份、接入网络以及所涉及的网络实体。由于 SIP 信令是分散式路由的，且会话状态在多个网元（P-CSCF、S-CSCF、I-CSCF、AS 等）上维护，如何将这些分散的事件和状态精确地关联到同一个“会话”上，是 IMS 计费面临的核心挑战。
IMS 采用 Diameter 协议（如 Rf 接口用于离线计费，Ro 接口用于在线计费）进行实际的计费数据传输。然而，SIP 协议本身需要承载必要的计费锚点信息，以便在 SIP 域内传递计费上下文。
P-Charging-Vector 私有头域正是为解决这一问题而生。它在 SIP 消息中扮演着“计费指纹”的角色，确保呼叫的所有阶段（建立、修改、释放）在所有涉及网元上都能被追踪和汇总成完整的计费数据记录（CDR, Charging Data Record）。
2. P-Charging-Vector 的结构与核心参数
P-Charging-Vector 头域用于在 IMS 信任域内传递计费相关信息。它主要包含两个关键的标识符：ICID（IMS Charging Identifier，IMS 计费标识）和 IOI（Inter-Operator Identifier，运营商间标识）。
2.1 ICID：会话的全局锚点
ICID 是 IMS 会话的唯一标识符。
| 参数 | 英文全称 | 核心作用 | 插入网元 | 来源 |
|---|---|---|---|---|
| icid-value | ICID Value | 唯一标识一个 IMS 会话（包括呼叫和独立事务）。 | P-CSCF（在始发请求中） | |
| icid-generated-at | ICID Generated At | 记录生成 ICID 的网元（通常是 P-CSCF）的地址或域名。 | P-CSCF |
P-CSCF 的职责：
- 对于 UE 发起的独立事务请求（例如
MESSAGE、OPTIONS），P-CSCF 应在 P-Charging-Vector 中增加icid参数。 - 对于 UE 发起的 INVITE 对话，P-CSCF 在转发给 S-CSCF 前，会在
P-Charging-Vector中增加icid-value。
2.2 IOI：跨域计费与互通标识
IOI 用于识别 SIP 消息在 IMS 域内或跨域互通中涉及的始发网络和终结网络。
| 参数 | 英文全称 | 核心作用 | 插入网元/场景 | 来源 |
|---|---|---|---|---|
| orig-ioi | Originating IOI | 始发网络（主叫方）的标识。 | S-CSCF（始发会话）或 MGCF（互通场景） | |
| term-ioi | Terminating IOI | 终结网络（被叫方）的标识。 | S-CSCF（终结会话）或 MGCF（互通场景） |
MGCF 的职责（互通场景）：
- MGCF 必须存储
P-Charging-Vector头中的orig-ioi参数。 - MGCF 在向 IMS 域发送
183 Session Progress响应时，必须向P-Charging-Vector插入从初始INVITE消息中携带的orig-ioi参数以及第二类term-ioi参数。第二类term-ioi参数必须设置为 MGCF 所在的网络。
2.3 接入网络计费信息
access-network-charging-info 参数用于在会话修改时，传递接入网络层的计费信息（如底层承载的 QoS 变化）。
- S-CSCF/P-CSCF 的职责：对于从终端发来的
reINVITE请求或UPDATE请求，P-CSCF 在发送给 S-CSCF 时应在P-Charging-Vector头中包含更新过的access-network-charging-info参数。S-CSCF 收到该请求后，应保存更新了的该参数，并在请求转发给 AS 时应该包含该参数。
3. SIP 消息与 Diameter ACR（计费请求）的协同
SIP 协议通过 P-Charging-Vector 携带的 ICID，将 SIP 层的信令事件（如呼叫建立、修改、释放）与 Diameter 计费系统（通过 Rf 接口）的 ACR（Accounting Request，计费请求）消息关联起来。
3.1 会话计费（ACR [Start]/[Stop]/[Interim]）
IMS 会话计费主要由 P-CSCF 和 S-CSCF 触发，它们都在收到 INVITE 的 200 OK 最终响应后，向各自的 CDF（Charging Data Function）发送 ACR [Start] 消息。
| 阶段 | SIP 触发消息 | 计费 ACR 消息类型 | 触发网元 | 来源 |
|---|---|---|---|---|
| 会话建立 | 收到 INVITE 的 200 OK 响应 | ACR [Start] | P-CSCF/S-CSCF | |
| 会话修改 | 收到 UPDATE 或 reINVITE 的 200 OK 响应 | ACR [Interim] | P-CSCF/S-CSCF | |
| 会话释放 | 收到 BYE 请求 | ACR [Stop] | P-CSCF/S-CSCF | |
| 事件计费 | INVITE 消息触发 HSS 查询 | ACR [Event] | I-CSCF |
CDF 的处理：
- CDF 收到
ACR [Start]消息后会打开一个会话 CDR。 - CDF 收到
ACR [Interim]消息后会生成部分 CDR，或更新原有 CDR。 - CDF 收到
ACR [Stop]消息后会关闭会话 CDR。
3.2 计费信息在 SIP 响应中的携带
在呼叫过程中，P-Charging-Vector 也会被携带在响应消息中，以确保计费信息的双向同步。
- S-CSCF 转发的 183 消息：会包含
icid-value、orig-ioi和term-ioi。 - I-CSCF 转发的 183 消息：同样包含
icid-value、orig-ioi和term-ioi。
4. P-CSCF/S-CSCF 容灾与计费连续性
在 IMS 容灾场景下，计费连续性是一个关键考量点。
4.1 P-CSCF 容灾下的计费处理
当 P-CSCF 发生故障并由备用 P-CSCF2 接管时：
- 路由重建：P-CSCF2 在 INVITE 消息中提取 PPI 或 From 域的主叫号码构造 PAI，并在
Route中增加标识主叫流程的orig参数，将呼叫发往 I-CSCF。 - 计费关联：虽然 P-CSCF2 重建了 PAI 和路由，但它必须确保后续生成的计费消息（ACR）能够与重建的呼叫上下文正确关联。P-CSCF2 会在转发请求前插入新的
P-Charging-Vector，从而锚定新的计费记录。
4.2 AS 故障处理与计费
当 AS 故障且 S-CSCF 无法从 AS 获得响应时，S-CSCF 必须根据 iFC 规则中的 DefaultHandling 设置来决定是终止会话还是让会话继续。
- 如果选择终止会话：S-CSCF 会向 CDF 发送相应的 ACR 消息关闭 CDR。
- 如果选择让会话继续：CDR 保持开启，但 AS 侧的业务逻辑和计费可能受到影响。
5. 会话释放时的计费终结
会话释放是计费流程的终结。
- BYE 触发：当 UE 发送
BYE消息时，P-CSCF 收到应用会话终止消息，向 PCRF 下发 **STR（Session-Termination-Request）**消息释放承载会话。同时，P-CSCF 和 S-CSCF 发送 ACR [Stop] 消息关闭会话 CDR。 - 承载释放：PCRF 收到 STR 后，发送 RAR 消息（携带 REMOVE QoS Rules 指示）通知 PGW 删除专有承载。PCRF 返回 **STA（Session-Termination-Answer）**响应给 P-CSCF。
6. 信令日志实战分析：计费 CDR 的创建
我们通过呼叫建立流程，观察 P-CSCF、I-CSCF 和 S-CSCF 如何创建计费记录。
场景： 主叫 UE P-CSCF I-CSCF S-CSCF 被叫 UE 建立呼叫，最终收到 200 OK。
6.1 步骤 1：主叫 INVITE 消息携带 ICID
P-CSCF 收到主叫 INVITE 并转发给 I-CSCF 时，插入了 ICID。
INVITE sip:[email protected] SIP/2.0
...
P-Charging-Vector: icid-value="pcscf-123456789";orig-ioi=visited.net
...
6.2 步骤 2：I-CSCF 触发 ACR [Event] (创建 I-CSCF CDR)
I-CSCF 收到 INVITE 后，进行 Cx 查询 HSS，然后向 S-CSCF 转发 INVITE。此时，I-CSCF 发送 Accounting Request [Event] 给 CDF，创建 I-CSCF CDR。
| 计费事件 | ACR 消息 | 目的 | 来源 |
|---|---|---|---|
| Cx 查询成功 | Accounting Request [Event] | 创建 I-CSCF CDR | I-CSCF |
6.3 步骤 3：收到 200 OK 触发 ACR [Start] (创建会话 CDR)
当呼叫被接通，主被叫双方都收到 200 OK 响应后：
| 计费事件 | ACR 消息 | 目的 | 来源 |
|---|---|---|---|
收到 200 OK | Accounting Request [Start] | P-CSCF/S-CSCF 打开会话 CDR（P-CSCF CDR 和 S-CSCF CDR） | P-CSCF/S-CSCF |
6.4 步骤 4：会话修改触发 ACR [Interim]
如果在通话过程中，用户发起 UPDATE 或 reINVITE 并成功收到 200 OK 响应，P-CSCF 和 S-CSCF 会发送 ACR [Interim] 消息。
| 计费事件 | ACR 消息 | 目的 | 来源 |
|---|---|---|---|
收到 UPDATE/reINVITE 200 OK | Accounting Request [Interim] | 更新 CDR，记录媒体或承载信息修改 | P-CSCF/S-CSCF |
关联性：所有的 CDRs（I-CSCF CDR, P-CSCF CDR, S-CSCF CDR）都通过 P-Charging-Vector 中携带的 ICID 关联起来。
7. 本章小结
P-Charging-Vector 是 IMS 计费系统的核心 SIP 头域，它通过 ICID 实现了 SIP 信令事件与 Diameter 计费消息（ACR）的紧密关联。
- P-CSCF 是 ICID 的主要生成和插入者，它将 ICID 锚定在始发请求中。
- ACR 消息 分为 Start（呼叫建立）、Interim（会话修改）和 Stop（会话释放）阶段，分别由 P-CSCF/S-CSCF 收到关键 SIP 消息（如
200 OK、UPDATE 200 OK、BYE）后触发。 - IOI 用于跨域呼叫的计费识别，尤其在 MGCF 互通场景中处理复杂。
- 会话修改（
UPDATE/reINVITE）时，P-CSCF/S-CSCF 必须保存并转发更新后的access-network-charging-info，并在收到200 OK后发送ACR [Interim]。 - 在释放会话时，P-CSCF 会向 PCRF 下发 STR 消息释放承载资源。
工程师进阶思考 (FAQ)
Q1：在 IMS 互通呼叫中，MGCF 为什么需要在 183 Session Progress 响应中同时携带 orig-ioi 和 term-ioi 参数？
A1： MGCF 处于 IMS 域与 CS/PSTN 域的边界，是计费互通的关键网元。在收到 IMS 域的 INVITE 请求后，MGCF 在向 IMS 域发送 183 Session Progress 响应时必须携带 orig-ioi 和 term-ioi。
orig-ioi：用于标识始发网络。MGCF 从初始INVITE消息中存储并携带该参数，确保计费系统知道呼叫的源头。term-ioi：用于标识终结网络。MGCF 必须插入第二类term-ioi，其值必须设置为 MGCF 所在的网络。这清晰地界定了信令从 IMS 核心网进入 CS/PSTN 域的边界，对于跨运营商的结算和计费分析至关重要。
Q2：当 S-CSCF 收到来自终端的 reINVITE 请求时，它对 P-Access-Network-Info 头域的处理原则是什么？
A2： S-CSCF 对 P-Access-Network-Info (PANI) 的处理取决于下一跳的信任域：
- 转发给信任域 AS：如果请求将被转发给一个位于信任域的 AS 时，S-CSCF 应保留
P-Access-Network-Info消息头。这确保了 AS 在处理业务逻辑（如 eSRVCC 切换、呼叫保持）时，能够获取最新的接入网络信息。 - 转发给非信任域或归属域以外：否则，S-CSCF 应删掉该消息头。
Q3：P-CSCF 收到 UE 发起的 BYE 消息时，除了转发给 S-CSCF 并发送 ACR [Stop] 外，还需要向哪个核心网元发送什么消息以释放承载资源？
A3： P-CSCF 作为 AF（Application Function），负责与底层承载控制功能（如 PCRF/PCF）交互。当 P-CSCF 收到应用会话终止消息（即 BYE）时：
- P-CSCF 会向 PCRF 下发 **STR（Session-Termination-Request）**消息，请求释放承载会话。
- PCRF 收到 STR 后，会向 PGW 发送 RAR 消息（携带 REMOVE QoS Rules 指示）通知删除专有承载。
- PCRF 返回 **STA（Session-Termination-Answer）**响应给 P-CSCF。
这确保了 SIP 层的会话释放与承载层的 QoS 资源释放同步进行，防止资源泄漏。