51学通信

VoLTE高清语音技术精要（十七）：补充业务与AS干预：呼叫前转与呼叫保持的SIP实践

12分钟阅读

好的，专家讲师。我将继续为您撰写 SIP 协议深度解析系列的第十七篇。本篇将聚焦于 IMS 网络中的补充业务（Supplementary Services），特别是呼叫前转（Call Forwarding）和呼叫保持（Call Hold），并结合 SIP 消息、SDP 状态以及 AS（应用服务器）在这些流程中扮演的关键 B2BUA 角色。

VoLTE高清语音技术精要（十七）：补充业务与AS干预：呼叫前转与呼叫保持的SIP实践

1. 导论：补充业务与应用服务器（AS）的角色

VoLTE/VoNR 网络旨在提供电信级通信体验，这不仅仅包括基本语音呼叫，还包括一系列丰富的补充业务（Supplementary Services），如呼叫等待（Call Waiting, CW）、呼叫保持（Call Hold, CH）、呼叫前转（Call Forwarding, CF）等。

在 IMS 架构中，这些复杂的业务逻辑主要由 **应用服务器（AS）**承载。AS 通常以 **B2BUA（Back-to-Back User Agent）**模式工作，这意味着它能够完全控制并隔离主叫和被叫之间的信令流和媒体流，从而实现业务逻辑的精确干预。

本章将详细解析呼叫前转和呼叫保持这两类核心补充业务的 SIP 流程，重点关注 AS 如何通过修改 SIP 消息、SDP 媒体属性和插入特定的响应码来实现业务逻辑。

2. 呼叫前转业务（Call Forwarding）

呼叫前转（CF）允许用户将其来电转移到另一个预设号码。SIP 流程中通过特定的状态码和 AS 的路由重定向来实现。

2.1 无条件呼叫前转（CFU）流程

无条件前转（CFU）是最直接的前转类型。

  1. 触发：主叫 UEa 呼叫 UEb。UEb 签约并激活了无条件前转业务。UEb 的 **TAS（Telephony Application Server，电话应用服务器）**通过 iFC（初始过滤规则）被 S-CSCF 触发。
  2. AS 执行前转：UEb 的 TAS 执行无条件前转业务，发起呼叫到前转号码 UEc。
  3. 指示前转：UEb 的 TAS 发送 181 Call is Being Forwarded 消息给主叫侧网元，指示呼叫正在前转。
    • 181 响应：状态码 181 明确告知这是一个呼叫前转的临时响应。当需要进行可靠传输时，181 须携带 Require: 100rel。
    • 业务嵌套：当彩铃业务与无条件前转嵌套时，181 消息经过 UEb 的彩铃 AS。彩铃平台将透传后向消息和后向音。
  4. 后续接续：UEc 振铃，主叫听回铃音，UEc 摘机后与 UEa 正常接续。AS 在收到 200 OK 后，通常会向 CDF 发出呼叫前转计费消息。

2.2 遇忙前转（CFB）与无应答前转（CFNRy）

  • 遇忙前转（CFB）：当 UEb 正在通话中（或通过按键指示忙时），TAS 触发业务，发起到前转号码 UEc 的呼叫。同时，TAS 向主叫侧回送 181 消息，指示呼叫正在前转。
  • 无应答前转（CFNRy）：UEb 的 TAS 启动无应答定时器。定时器超时后，TAS 发送 CANCEL 消息取消到 UEb 的呼叫，并发送 INVITE 消息发起到 UEc 的呼叫。同时，TAS 发送 181 消息到主叫侧网元，指示呼叫正在前转。

3. 呼叫保持业务（Call Hold）

呼叫保持允许用户暂时挂起当前通话，同时可以发起或接听另一个呼叫。它通过 SIP reINVITE 或 UPDATE 消息，并修改 SDP 的媒体流方向属性来实现。

3.1 呼叫保持的 SIP/SDP 机制

  1. 触发：用户（例如 UE A）将当前有效呼叫置于保持状态。UE A 向对端（UE B）发起 reINVITE 或 UPDATE 请求。
  2. SDP 修改（Hold）：UE A 在请求中携带的 SDP 会将媒体流方向属性（a= 属性行）修改为 sendonly 或 inactive。
    • 如果 UE A 保持呼叫并向 UE B 播放保持音，则方向通常是 sendonly（UE A 仅向 UE B 发送媒体，即保持音）。
  3. AS 干预：在 AS 实现的呼叫保持流程中，AS（作为 B2BUA）会收到 reINVITE 消息，并与 **MRF（多媒体资源功能）**交互，申请播放保持音。
  4. 播放保持音：AS 收到 B 用户的 200 OK 消息后，如果 B 用户支持接收和发送媒体流消息，AS 会回 ACK 给 B 用户，给 MRF 回 200 OK 带 B 用户的媒体，并下 INFO 指示 MRF 向 A 用户放保持音。此时 B 用户听保持音。
    • AS 收到 B 用户的 200 OK 响应后，向 A 用户回送 reINVITE 200 OK 消息，SDP 属性的 a 行携带了 a=recvonly。

3.2 呼叫恢复（Retrieve）

  1. 触发：用户 A 想要恢复与 B 的通话。
  2. SDP 修改（Retrieve）：UE A 发送 reINVITE 或 UPDATE 消息，将 SDP 属性的 a 行修改回 a=sendrecv。
  3. AS 处理：AS 收到用户 A 发的 reINVITE 消息中 SDP 属性的 a 行携带了 a=sendrecv 后，会 BYE 掉 MRF（停止放音），并给用户 B 改向（发送新的 reINVITE），让用户 A 与 B 恢复通话。

4. 业务嵌套与 AS 协同

IMS 补充业务通常涉及多个 AS 的嵌套或协同工作，例如彩铃 AS 和 TAS 的嵌套。

4.1 视频彩铃与补充业务的嵌套

在视频彩铃业务中，彩铃 AS 必须能够识别和响应 TAS 发送的补充业务指示：

  • 收到 181 响应：如果彩铃平台收到第一条后向消息为 181 Call is Being Forwarded 响应，彩铃平台将透传后向消息和后向音。
  • 媒体更新：在彩铃播放完毕，被叫摘机后，彩铃平台将被叫对 re-INVITE 消息应答的媒体能力作为 SDP offer 向主叫进行媒体更新。如果被叫返回的 SDP 媒体行同时包含音频和视频，而此时主叫侧通话类型为音频，则彩铃平台需要将被叫 SDP 中的视频媒体行置 0 后，再将被叫 SDP 发送给主叫。

4.2 AS 的 DefaultHandling 机制

如果呼叫触发了 AS，而 AS 没有响应（例如 AS 故障），S-CSCF 必须根据 iFC（初始过滤规则）中的 Default Handling 策略来决定呼叫的走向。

  • Default Handling 可以设置为 **Continue（继续）**或 Terminate（终止）。
  • 目的：验证通过设置 DefaultHandling 可以使用户跳过不可达的 AS 继续完成接续。如果 iFC 规则没有指示，S-CSCF 的缺省行为是让呼叫继续。

5. P-CSCF 对后续请求的严格校验

无论是呼叫前转导致的路由重建，还是呼叫保持导致的会话更新，所有对话内的请求都必须经过 P-CSCF 的严格校验。

  • 目标刷新校验：P-CSCF 收到 reINVITE 或 UPDATE 时，必须确认请求中的 Route 列表是否与同一对话中保存下来的 Record-Route 列表匹配。如果校验失败，P-CSCF 应回复 400 (Bad Request) 响应。
  • 对话存在性校验：P-CSCF 收到 UE 发起的后续请求或独立请求，如果没有发现存在对应的对话，则 P-CSCF 应回复 403 (Forbidden) 响应。
  • 释放冲突：当 P-CSCF 在释放对话的过程中收到关于对话的请求时，P-CSCF 应该中止该请求，并回送响应 481 (对话或者事务不存在)。

6. 本章小结

IMS 补充业务的实现依赖于 **AS（B2BUA）**对 SIP 消息流的精确控制：

  1. 呼叫前转：通过 TAS 发送 181 Call is Being Forwarded 响应来指示，AS 随后发起新的呼叫分支，并修改路由。
  2. 呼叫保持：通过 reINVITE/UPDATE 消息和 SDP 媒体流方向属性（如 a=sendonly/a=recvonly）的切换来实现，通常涉及 MRF 播放保持音。
  3. AS 故障：S-CSCF 通过 Default Handling 策略确保 AS 故障不中断基本通信。

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

Q1：P-CSCF 收到 UE 发起的 UPDATE 请求，但发现该请求中的 Route 头域与本地保存的 Record-Route 列表不匹配，P-CSCF 如何处理？

A1： P-CSCF 必须确保对话的路由完整性。如果 P-CSCF 收到 UE 发起的任何请求，且 Service-Route 中的 URI 列表校验失败（对于独立请求），或 Route 列表与保存的 Record-Route 列表不匹配（对于目标刷新请求），则 P-CSCF 应回复 400 (Bad Request) 响应且不再继续处理请求。或者，P-CSCF 也可以选择用最新注册消息中的 Service-Route 头替换请求消息的 Route 头。

Q2：在 MO-INVITE 流程中，如果主叫 UE 的 P-CSCF 故障（无响应），SIP 定时器如何驱动终端切换到备用 P-CSCF？

A2： 在主叫流程中，终端依赖 Timer B（INVITE 事务定时器）来判断 P-CSCF 故障并触发切换。

  1. 故障判断：UE 发起 INVITE 请求，在相应的定时器 Timer B 内没有收到 P-CSCF/BAC1 的响应消息。
  2. 呼叫失败：终端结束当前呼叫，当前呼叫失败。
  3. 重新注册：终端重新向优先级别次低的 P-CSCF/BAC2 发起初始注册流程。初始注册成功后，后续的 INVITE 请求按正常流程处理。

Q3：P-CSCF 在处理发往 UE 的对话初始请求（MT INVITE）时，在转发请求前和收到响应后，如何处理 Via 列表以保证事务可靠性？

A3： P-CSCF 必须严格处理 Via 列表以保证事务可靠性。

  1. 转发请求前：P-CSCF 必须将 P-CSCF 地址填加到 Via 头域最顶端并保存该列表。
  2. 收到响应时：P-CSCF 收到上述请求的任何响应时，必须确认 Via 列表是否与同一对话的请求消息中保存的 Via 列表匹配。
  3. 异常处理：如果发现 Via 列表不匹配，P-CSCF 应丢弃 Via 头，或者替换成保存的 Via 列表。

关系图谱