51学通信

VoLTE高清语音技术精要（十五）：流程实战：VoNRVoLTE 主叫呼叫建立信令流解析

12分钟阅读

VoLTE高清语音技术精要（十五）：流程实战：VoNR/VoLTE 主叫呼叫建立信令流解析

1. 导论：整合 IMS 核心机制的 MO-INVITE 流程

在前续的篇章中，我们详细探讨了 SIP 协议的各个独立组成部分：路由锚定（Path/Service-Route）、身份断言（PAI）、媒体协商（SDP/Precondition）以及容灾机制。然而，所有这些机制最终都汇集于一个核心流程：主叫会话建立（Mobile Originated INVITE Call Setup）。

MO-INVITE 流程不仅是用户发起通话的起点，更是 IMS 网络对所有已学知识的综合实践。在这个流程中，P-CSCF、S-CSCF、I-CSCF 和终端（UE）必须严格遵循时序和状态转换要求，才能在保障 QoS 和计费准确性的同时，完成一次高质量的 VoLTE/VoNR 通话。

本章将通过一个完整的 MO-INVITE 流程，从 SIP 请求的发起到会话的最终建立，整合 SIP 头域、Diameter 消息和底层承载控制机制，进行全面的实战解析。

2. 阶段一：INVITE 请求的路由与状态初始化

主叫终端 (UE#1) 发起 INVITE 请求，请求流经 P-CSCF，最终到达服务于主叫的 S-CSCF。

2.1 UE 发起 INVITE 请求

主叫 UE#1 会根据在注册时收到的 Service-Route 头域，将其逆序后作为本次 INVITE 请求的 Route 列表。

关键 SIP 头域/参数来源作用描述引用
RouteUE#1包含 S-CSCF 地址，指导请求到达 S-CSCF。
Request-URIUE#1被叫用户的逻辑身份（如 sip:[email protected]）。
SDP 消息体UE#1SDP Offer，包含编解码器提议、媒体流方向，以及 Precondition 属性（a=des, a=curr）。
P-Preferred-Identity (PPI)UE#1用户期望的身份（必须在 P-CSCF 被删除）。

2.2 P-CSCF 的路由与身份断言

P-CSCF 收到请求后，作为 IMS 信任域的边界，必须执行严格的校验和身份断言。

  1. 即时响应：P-CSCF 应给所有的 INVITE 请求回送 100 (Trying) 临时响应，该响应不会被转发，目的是阻止终端在 Timer A 超时后重传 INVITE。
  2. 路由校验与维护：P-CSCF 验证 Route 列表是否与保存的 Service-Route 匹配。P-CSCF 将其地址添加到 Via 列表顶端并保存该列表。
  3. 身份断言：P-CSCF 删除 P-Preferred-Identity，并插入经过鉴权的 P-Asserted-Identity (PAI)。
  4. 计费锚定：P-CSCF 在 P-Charging-Vector 中增加 icid 参数，锚定会话的计费记录。

2.3 S-CSCF 的业务触发与对话锚定

S-CSCF 收到请求（Request-URI 此时通常已被 P-CSCF 更改为 S-CSCF 的地址）后，开始处理业务逻辑：

  1. 身份判断：S-CSCF 取出请求消息中 P-Asserted-Identity 头域中的公共标识。
  2. iFC 评估：S-CSCF 检查 PAI 对应的初始过滤规则（iFC），并按照优先级顺序检查该请求是否与下一条未执行的初始过滤规则相匹配。若匹配，则转发给相应的 AS。
  3. 对话锚定：S-CSCF 将其地址添加到 Record-Route 列表中，确保在整个会话生命周期中，后续的信令（如 BYE, UPDATE）都会经过 S-CSCF.
  4. 路由转发：S-CSCF 根据路由结果或 AS 返回的指示，将请求路由到下一跳（可能是被叫 S-CSCF 或 IBCF）。

3. 阶段二：媒体协商、QoS 预留与 PRACK

在请求到达被叫 UA 并返回响应后，信令流的核心目标是完成媒体协商（SDP Offer/Answer）并确认底层 QoS 资源已预留。

3.1 被叫侧的临时响应 (183 Session Progress)

被叫侧的 IMS 网元（如被叫 S-CSCF 或 MGCF）在被叫振铃前，通常会返回 183 Session Progress 响应。

  1. 对话建立：183 响应在 To 头域中添加 tag 参数，正式建立早期对话（Early Dialog）。
  2. SDP Answer：183 响应中携带 SDP Answer，对应于主叫的 SDP Offer，确定双方选择的编解码器。
  3. QoS 触发：183 响应的收发是触发双方底层专用 QoS 流建立的关键信令。该响应通常携带 Precondition 属性（a=des, a=curr）。
  4. 可靠性要求：由于 183 携带了关键的媒体和 QoS 信息，通常要求 Require: 100rel，确保可靠传输。

3.2 PRACK 确认与资源预留的启动

主叫 UE 收到可靠的 183 响应后，必须进行确认。

  1. PRACK 发送：主叫 UE 发送 PRACK 请求，对其收到的 183 响应进行确认。
  2. PRACK 标识：PRACK 请求中包含 RAck 头域，指明被确认的 183 响应的序列号 (RSeq) 和 CSeq。

PRACK 流程完成后，双方的 P-CSCF/BAC 收到 183 响应，会向 PCF 发起资源建立请求，触发主被叫两侧 QoS 流的建立。

4. 阶段三：资源同步、最终建立与计费终结

4.1 资源状态的 UPDATE 同步

在 QoS 承载资源建立成功后，会话双方通过 UPDATE 消息同步 Precondition 状态。

  1. UPDATE 请求：资源先建立成功的一方（例如主叫侧），会发送 UPDATE 请求，携带 SDP 净荷，将 a=curr:qos local sendrecv（本地当前状态）更新，通知对端资源已就绪。
  2. UPDATE 200 OK：对端收到 UPDATE 后，如果自身资源也已就绪，会返回 200 OK (for UPDATE) 响应，更新 SDP 中的 a=curr:qos remote sendrecv（远端当前状态），完成双方资源同步。
  3. P-CSCF/S-CSCF 对 UPDATE 的处理：P-CSCF/S-CSCF 收到 UPDATE 的 200 OK 响应后，会向 CDF 发送 ACR [Interim] 消息，更新 CDR。

4.2 最终呼叫建立与计费启动

一旦双方资源同步完成，被叫终端摘机，被叫 UA 发送 200 OK (for INVITE) 响应。

  1. 最终响应：200 OK 是 SIP 事务的成功响应，标志着会话建立成功。该响应包含 Session-Expires 头域，协商会话定时器，通常由 UAC (主叫) 负责刷新 (refresher=uac)。
  2. 计费启动：
    • I-CSCF CDR：I-CSCF 在 Cx 查询 HSS 后，向 CDF 发送 ACR [Event]。
    • 会话 CDR：P-CSCF 和 S-CSCF 在收到 INVITE 的 200 OK 最终响应后，分别向各自的 CDF 发送 ACR [Start] 消息。
  3. ACK 确认：主叫 UE 收到 200 OK 后，必须回复 ACK 请求，完成 INVITE 事务的“三次握手”。

5. 阶段四：会话释放与资源清理（BYE）

当呼叫结束后，任一方发送 BYE 请求，启动会话释放流程。

  1. P-CSCF 校验：P-CSCF 收到 BYE 请求时，会校验其 Route 列表是否与保存的 Record-Route 列表匹配，并用收到的 CSeq 值替换原来的值。
  2. 承载释放：P-CSCF 收到应用会话终止消息（即 BYE）后，向 PCRF 下发 **STR（Session-Termination-Request）**消息，释放承载会话。
  3. 计费终止：P-CSCF 和 S-CSCF 在收到 BYE 请求后，发送 ACR [Stop] 消息，关闭会话 CDR。
  4. 资源清理：P-CSCF 和 S-CSCF 收到 BYE 请求的 2xx 响应后，应删除所有对话和多媒体会话相关的信息。

6. 本章小结

完整的 VoLTE/VoNR 主叫流程是 IMS 技术的集大成者，它依赖于 SIP 协议的强大扩展性和严格的状态管理：

  • 信令锚定：MO 请求依赖注册时获得的 Service-Route，通过 Route 头域进入 S-CSCF。
  • 可靠协商：SDP Offer/Answer 模型在 INVITE / 183 阶段完成，并通过 PRACK/100rel 确保可靠性。
  • QoS 保障：Precondition 机制通过 UPDATE 消息同步资源状态，确保媒体流在 QoS 专有承载就绪后才开始传输。
  • 状态维护与计费：P-CSCF 和 S-CSCF 严格校验和更新 Route、Contact、CSeq 等状态，并在收到 200 OK 后触发 ACR [Start] 计费。

7. 工程师进阶思考 (FAQ)

Q1：在 MO-INVITE 流程中，如果主叫 AS 发生故障（如无响应），S-CSCF 如何处理以保证呼叫连续性？

A1： S-CSCF 遵从与初始过滤规则（iFC）相关的缺省处理过程（Default Handling）。如果 AS 没有响应，S-CSCF 会根据 iFC 规则中的 DefaultHandling 设置来决定下一步操作：

  1. Continue（继续）：如果 iFC 规则没有明确指示，S-CSCF 的缺省行为是让呼叫继续。呼叫会绕过 AS 继续完成接续，但补充业务将不会被触发。
  2. Terminate（终止）：如果规则指示终止会话，S-CSCF 则会释放呼叫。

通过 DefaultHandling，IMS 系统验证了即使 AS 故障，也可以使用户跳过不可达的 AS 继续完成接续。

Q2：在 MO-INVITE 流程中，P-CSCF/S-CSCF 在收到 INVITE 请求后，向 CDF 发送 ACR [Start] 消息与 I-CSCF 发送 ACR [Event] 消息，分别发生在何时？它们如何关联？

A2： 这两种 ACR 消息发生在不同的阶段，用于记录不同类型的计费数据：

  1. I-CSCF CDR (ACR [Event])：I-CSCF 在收到 INVITE 消息后，进行 Cx 查询 HSS 后，向 CDF 发送 ACR [Event] 消息。这是一个事件话单，主要记录路由查询等事件。
  2. P-CSCF/S-CSCF CDR (ACR [Start])：P-CSCF 和 S-CSCF 在收到 INVITE 消息的 200 OK 最终响应后，分别向各自的 CDF 发送 ACR [Start] 消息，打开会话 CDR。

关联性：所有的 CDRs（I-CSCF CDR, P-CSCF CDR, S-CSCF CDR）都通过 SIP 消息中 P-Charging-Vector 头域携带的 ICID 进行唯一关联。

Q3：当 P-CSCF 收到 UE 终结的初始请求（MT INVITE）的响应（1xx 或 2xx）时，它对身份头域（PAI/PPI）的处理原则是什么？

A3： P-CSCF 在处理发往 UE 的终结请求响应时，必须确保身份信息的权威性：

  1. Via 校验：P-CSCF 必须确认响应中的 Via 列表是否与同一对话的请求消息中保存的 Via 列表匹配。
  2. 身份转换：如果响应中含有 P-Preferred-Identity，P-CSCF 应删除该头域。
  3. 身份插入：P-CSCF 应插入 P-Asserted-Identity，其值应为收到请求时保存下来的 P-Called-Party-ID。

此过程确保了终端收到的响应消息中，身份信息是由网络断言的，而非用户偏好。

关系图谱