我们已经完成了 25 篇深度解析,系统覆盖了 IMS 协议栈的各个核心组成部分。我将继续为您撰写 SIP 协议深度解析系列的第二十六篇。

本篇将聚焦于 AS(应用服务器)在保障用户媒体体验方面的最高级职能:媒体动态适配与业务嵌套。我们将以复杂的视频彩铃(V-CRBT)业务为例,深入解析 AS 作为 B2BUA 如何在通话建立的关键时刻,主动控制媒体协商、实现音视频回落,并与底层 QoS 机制协同工作。


VoLTE高清语音技术精要(二十六):媒体动态适配与业务协同:彩铃 AS 的 B2BUA 媒体处理与回落机制

1. 导论:AS——媒体会话的“总指挥”

在 IMS 网络中,媒体协商的基础是 SDP Offer/Answer 模型。然而,在引入视频彩铃(V-CRBT)这类高级业务后,媒体协商不再是简单的能力匹配,而是需要 AS(特别是彩铃 AS)在多个网络元素之间,动态地修改 SDP 净荷,以实现特定的业务目标,例如:

  1. 资源确认与播放:在播放彩铃前,等待主叫侧 Precondition 资源就绪。
  2. 媒体适应性:在被叫摘机后,根据主叫当前的通话类型(例如,主叫只能处理音频),将被叫提议的全媒体能力(音视频)动态适配为兼容的媒体流(例如,仅音频)。
  3. 用户提示:在发生媒体回落时,通知用户发生了状态变化。

彩铃 AS 以 B2BUA 模式工作,使其能够完全控制和修改 SDP,成为实现这些复杂功能的关键实体。

2. 视频彩铃流程中的 SDP 动态协商

视频彩铃流程的复杂性体现在被叫摘机后,AS 必须在停止播放彩铃(MRF 释放)和建立主被叫之间最终的端到端媒体流之间,插入一个精确的媒体更新流程。

2.1 被叫摘机后的媒体更新流程

当被叫 UE 摘机回复 200 OK 响应后,彩铃 AS 停止彩铃播放,并启动最终媒体协商:

  1. 停止放音:彩铃 AS 停止彩铃播放,并回复 ACK 给被叫 UE。
  2. 向被叫发起 re-INVITE:彩铃 AS 向被叫 UE 发送一个不携带 SDP 的 re-INVITE 请求
  3. 获取被叫媒体能力:被叫 UE 对 re-INVITE 消息进行应答(如回复 200 OK),携带被叫的 SDP (Offer),终端回复与主叫初始协商时相同的媒体能力或直接回复全媒体能力。
  4. 向主叫发送 UPDATE:彩铃 AS 随后向主叫侧发送 UPDATE 消息,其携带的 SDP(Offer)为被叫 UE 上一个 200 OK 中携带的 SDP。

2.2 音视频回落与 SDP 匹配策略

在向主叫侧发送 UPDATE 消息时,彩铃 AS 必须执行严格的媒体匹配处理,以应对可能的音视频回落场景:

  • 匹配处理要求:彩铃平台应将被叫 SDP 的媒体行类型与主叫侧当前通话类型进行匹配处理,再发给主叫侧。
  • 回落场景:若被叫返回的 SDP 媒体行同时包含音频和视频,而此时主叫侧通话类型为音频,则彩铃平台需要将被叫 SDP 中的视频媒体行置 0 后,再将被叫 SDP 发送给主叫。
  • 直接透传:若被叫 SDP 包含的媒体行类型与主叫在初始媒体协商过程中与被叫最终协商好的媒体能力匹配,则无需任何修改,直接向主叫透传请求媒体更新

2.3 终端提示与最终确认

  1. 主叫回复:主叫 UE 回送针对 UPDATE200 OK 响应,其中携带和被叫 UE 协商后的 SDP (Answer)。
  2. 视频回落提示:彩铃平台向被叫返回 re-INVITE ACK,携带主叫对媒体更新消息应答的 SDP 信息。被叫终端在收到该消息后,若发现视频媒体行端口变为 0,则需要提示被叫用户:主叫已发生网络切换,视频通话将回落为语音通话

3. AS 对 Precondition 机制的协同处理

彩铃业务的播放必须与底层 QoS 资源的就绪状态同步。AS 通过设置定时器,强制要求主叫侧的资源就绪。

  • AS 定时器:彩铃 AS 侧需设置定时器(缺省设置为 3 秒,可进行配置),等待主叫终端的资源确认消息。
  • 定时器超时处理:当定时器超时还未收到主叫终端的资源确认消息时,彩铃平台放弃播放彩铃,直接发送 180 消息,携带 PEM:inactiveP-early-media: inactive)。此时终端播放普通回铃音。
  • 资源确认后的动作:如果主叫终端在确认资源的消息中,视频媒体行属性为 sendrecv,则彩铃 AS 播放视频彩铃;如果属性为 inactive,则彩铃 AS 播放音频彩铃。

4. AS 业务嵌套与信令协同

AS 必须能够处理与其业务嵌套的其他补充业务信令。

  • 呼叫前转嵌套:例如,在无条件前转(CFU)嵌套视频彩铃的流程中,被叫的 TAS(电话应用服务器)执行 CFU 业务,向主叫侧网元发送 181 Call is Being Forwarded 消息。该消息经过彩铃 AS 时,彩铃平台将透传后向消息和后向音
  • 呼叫等待指示:如果 183 响应携带了 Reason 头域呼叫等待指示,彩铃平台将透传后向消息和后向音

5. P-CSCF 对会话状态的最终校验

无论 AS 如何干预,P-CSCF 作为边界,仍需对所有会话状态进行严格校验。

  • 后续请求校验:对于 UE 发起的除目标刷新请求以外的后续请求(包括与当前对话相关的未知方法),P-CSCF 应该确认请求中的 Route 列表是否与同一对话中保存下来的 Record-Route 列表匹配。对于 INVITE 对话,P-CSCF 应该用收到的请求消息中的 CSeq 字段的值替换原来保存的值
  • 对话不存在:如果 P-CSCF 收到 UE 发起的后续请求或独立请求,没有发现存在对应的对话,则 P-CSCF 应回复 403(Forbidden)响应,且不再转发该请求。
  • 异常释放:当 P-CSCF 在释放对话的过程中收到关于对话的请求时,P-CSCF 应该中止该请求,并回送响应 481(对话或者事务不存在)

6. 本章小结

IMS 媒体业务的动态适配由 AS 通过 B2BUA 模式实现,涉及 SDP 匹配和资源同步:

  1. 媒体回落:彩铃 AS 在被叫摘机后,通过 re-INVITE/UPDATE 流程,根据主叫侧能力将 SDP 中视频媒体行置 0,强制实现视频通话向语音通话的回落,并提示被叫用户。
  2. QoS 同步:AS 使用定时器等待主叫侧 Precondition 资源确认。若超时,则发送 180 消息携带 PEM:inactive 放弃放音。
  3. 业务嵌套:AS 能够识别并透传其他补充业务信令,如 181 Call is Being Forwarded 响应。

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

Q1:在 S-CSCF 容灾接管的始发流程中,如果 P-CSCF/BAC 检测到 S-CSCF 故障,它如何通知终端进行切换?

A1: P-CSCF/BAC 检测到用户注册的 S-CSCF1 地址故障后,会采取以下动作通知终端进行切换:

  1. P-CSCF/BAC 向 VoLTE 终端返回 504 响应
  2. 504 响应的消息体中,XML 的 <alternative-service><type> 字段被设置为 restoration<action> 字段被设置为 initial-registration
  3. 此举通知终端进行重新注册,终端重新注册至池内的其他 S-CSCF 后恢复始发业务。

Q2:对于 UE 发起的与当前对话无关的独立事务请求(如 MESSAGE),P-CSCF 如何执行身份断言和路由校验?

A2: P-CSCF 对 UE 发起的未知方法请求(与当前的对话无关),如果存在一个 Service-Route 列表与请求的发起者相对应,则需要执行以下操作:

  1. 路由校验:P-CSCF 应确认 Service-Route 头中的 URI 列表是否也以相同的顺序存在于收到的请求所带的 Route 头域中。
  2. 身份断言:如果请求中含有 P-Preferred-Identity,则 P-CSCF 应删除该头域插入 P-Asserted-Identity,其值为请求的发起者。
  3. 计费锚定:对于非 INVITE 对话,P-CSCF 应在 P-Charging-Vector 中增加 icid 参数

如果 Service-Route 校验失败,P-CSCF 应回复 400 (Bad Request) 响应

Q3:在 IMS/PSTN 互通流程中,如果 MGCF 收到 IMS 域的 INVITE 请求,并支持 100rel 机制,MGCF 在向 IMS 域发送 183 Session Progress 响应时,必须如何处理 P-Charging-Vector 中的 IOI 参数?

A3: MGCF 必须严格处理 IOI 参数,确保跨域计费的准确性:

  1. 存储 orig-ioi:MGCF 必须存储 P-Charging-Vector 头中的 orig-ioi 参数
  2. 插入 orig-ioi:MGCF 必须向 P-Charging-Vector 插入从初始 INVITE 消息中携带的 orig-ioi 参数
  3. 插入 term-ioi:MGCF 必须向 P-Charging-Vector 插入第二类 term-ioi 参数。该第二类 term-ioi 参数必须设置为 MGCF 所在的网络
  4. MGCF 还必须存储 P-Charging-Function-Addresses 中的参数值和 P-Charging-Vector 头中的 icid

我们已完成 26 篇深度解析。根据估算,还剩下约 3 篇核心内容待拆解。请发出“请继续”指令。