好的，专家讲师。我将继续为您撰写 SIP 协议深度解析系列的第二十篇。本篇将聚焦于 IMS 网络中的呼叫异常处理与录音通知机制。我们将解析 SIP 状态码在异常场景下的应用，特别是如何将网络侧故障（如 AS 故障、资源不可用）转化为对用户友好的提示音（录音通知），以及 MGCF/AS/MRF 在其中扮演的角色。
VoLTE高清语音技术精要（二十）：异常处理与用户体验：SIP状态码、放音与AS干预
1. 导论：从 SIP 错误到用户感知
在 IMS 网络中，当呼叫无法正常建立或维持时，网络需要向用户（UAC）返回一个 SIP 错误响应（4xx, 5xx, 6xx 系列状态码）。然而，对于终端用户而言，这些 SIP 状态码缺乏直观性。因此，IMS 系统必须将这些内部错误转化为用户可感知的提示音（录音通知），以确保良好的用户体验。
这一机制涉及 SIP 核心网元（CSCF、AS）与媒体资源功能（MRF）的紧密协同，特别是 AS 通过特定的 SIP 响应（通常是 183 Session Progress）携带放音指示（如 p-early-media 和 Reason 头域）来控制 MRF 播放预设的语音或文字。
本章将详细解析几种常见的呼叫失败场景，以及 P-CSCF/S-CSCF 在异常处理中返回的关键状态码（如 400 Bad Request 和 403 Forbidden）和相应的处理逻辑。
2. 核心 SIP 错误状态码在 IMS 中的应用
SIP 响应状态码的首位数字定义了响应的类别：1xx 为临时响应，2xx 为成功响应，3xx 为重定向响应，4xx 为客户端错误，5xx 为服务器错误，6xx 为全局错误。
| 状态码 | 类别 | IMS 场景示例 | 运营商处理原则 | 来源 |
|---|---|---|---|---|
| 100 Trying | 临时响应 | P-CSCF 收到 INVITE 请求后立即回送。 | 阻止 UAC 重传 INVITE 请求，Proxy 不转发。 | |
| 181 Call is Being Forwarded | 临时响应 | 呼叫前转业务中，AS 向主叫侧网元发送，指示呼叫正在前转。 | 需要 Require: 100rel 才能可靠传输。 | |
| 400 Bad Request | 客户端错误 | P-CSCF 收到 UE 始发请求，Service-Route 中的 URI 列表校验失败。 | P-CSCF 应回复 400(Bad Request) 且不再继续处理请求。 | |
| 403 Forbidden | 客户端错误 | P-CSCF 收到 UE 后续请求或独立请求，没有发现存在对应的对话。 | P-CSCF 应回复 403(Forbidden) 且不再转发请求。 | |
| 481 Dialog/Transaction Does Not Exist | 客户端错误 | P-CSCF 在释放对话的过程中收到关于对话的请求。 | P-CSCF 应该中止该请求，并回送 481 响应。S-CSCF 发起释放时收到冲突请求也返回 481。 | |
| 503 Service Unavailable | 服务器错误 | P-CSCF 申请资源失败（如 NAT 端口申请失败、QoS 授权失败）时，向 UE 发送 CANCEL 消息释放会话，原因值为 503。 | 用于指示呼叫失败的原因是服务不可用。 |
3. AS 驱动的异常场景放音与通知机制
在 IMS 中，AS（或彩铃 AS）负责在呼叫失败或异常时，通过 183 Session Progress 响应携带 p-early-media 头域和 Reason 头域，指示 MRF 播放提示音。
3.1 呼叫等待（有呼叫等待）放音
当被叫用户正在通话中，但已登记并激活了呼叫等待（CW）业务时，网络应向主叫播放呼叫等待提示音。
- 触发条件：主叫呼叫被叫时，被叫正在通话中，且被叫在 SIP AS 登记有 CW 业务并激活。被叫侧 AS 收到被叫终端发的
182消息。 - 放音机制：被叫侧 AS 向主叫侧发
183消息进行放音，要求183携带p-early-media，放音结束后向主叫侧放基本回铃音。 - 放音内容：中文提示音为：“您好！请不要挂机，您拨打的电话正在通话中。”。
- 放音原则：由被叫登记有呼叫等待业务的 SIP AS 控制对应 MRS 向主叫放音。
3.2 被叫停机/用户主动申请停机放音
当主叫呼叫的用户处于停机状态时，主叫侧 AS 负责播放相应的提示音。
- 用户主动申请停机：主叫侧 VoLTE AS 收到
INVITE请求后，发现用户（被）设置补充业务中的闭锁所有呼出。AS 对主叫用户播放提示音，放音结束后，AS 发送487响应（携带原因值 31）释放该呼叫。- 放音内容：中文提示音为：“您好！您的电话已停机。详情请垂询‘10086’”。
- 被叫停机：主叫侧 AS 播放提示音。
- 放音内容：中文提示音为：“您好！您拔打的电话已停机。”。
3.3 被叫忙（无呼叫等待）放音
当被叫忙且没有呼叫等待业务时，网络应播放被叫忙提示音。
- 放音内容：中文提示音为：“您好！您拨打的电话正在通话中，请稍后再拨。”。
- 触发：被叫终端拒接，回
603消息。被叫 AS 收到被叫终端回复的603消息后，向主叫侧回183消息，带p-early-media，带Q.850的Reason值 17（User busy）。
4. P-CSCF 的路由和会话状态校验与异常响应
P-CSCF 严格执行会话完整性校验，以防止非法或混乱的信令影响核心网状态。
4.1 校验失败的 SIP 状态码
| 异常场景 | P-CSCF 校验失败 | P-CSCF 返回状态码 | 来源 |
|---|---|---|---|
| 路由非法 | UE 发起的任何请求，Service-Route 中的 URI 列表校验失败。 | 400 (Bad Request) | |
| 对话丢失 | 收到 UE 发起的后续请求或独立请求，没有发现存在对应的对话。 | 403 (Forbidden) | |
| 释放冲突 | P-CSCF 在释放对话的过程中收到关于对话的请求。 | 481 (对话或者事务不存在) | |
| Via 不匹配 | 收到任何响应时，Via 列表与保存的 Via 列表不匹配。 | 丢弃 Via 头，或者替换成保存的 Via 列表 |
4.2 P-CSCF 发起的会话释放
P-CSCF 不仅接收和转发释放消息，还会因内部原因主动发起会话释放。
- 取消正在建立的会话：当申请资源失败（如收到失去无线覆盖的指示、NAT 端口申请失败、QoS 授权申请失败等）或内部原因导致呼叫失败时，P-CSCF 应向 UE 发送
CANCEL消息以释放会话，并包含原因值为503 (Service Unavailable)。
5. AS 故障下的 S-CSCF 缺省处理
当 AS 发生故障（没有响应）时，S-CSCF 必须根据 iFC 中的 Default Handling 策略来决定呼叫的走向。
- 策略执行：S-CSCF 遵从与初始过滤规则相关的缺省处理过程。
- 缺省行为：如果 iFC 规则没有包含在联系 AS 失败后 S-CSCF 应如何操作的指示，S-CSCF 的缺省行为是让呼叫继续。
- 目的：验证通过设置
DefaultHandling可以使用户跳过不可达的 AS 继续完成接续。
6. 本章小结
IMS 异常处理机制确保了网络在故障时能够快速同步状态，并向用户提供清晰的反馈：
- 身份断言与路由校验：P-CSCF 严格校验
Service-Route/Route和对话状态，并返回400或403拒绝非法请求。 - 放音通知：异常场景下的提示音由 AS/MRF 播放，通常通过
183 Session Progress携带p-early-media和Reason头域来触发。 - 资源清理：会话释放时 P-CSCF 必须处理
BYE、CANCEL等请求，并在收到2xx响应后删除所有对话信息。在释放过程中收到冲突请求时，P-CSCF/S-CSCF 返回481响应。 - 容灾：S-CSCF 通过
Default Handling机制处理 AS 故障，保障基本呼叫的连续性。
7. 工程师进阶思考 (FAQ)
Q1：P-CSCF 收到 UE 终结 INVITE 请求的响应时（1xx 或 2xx），如何处理身份头域 P-Preferred-Identity？
A1： P-CSCF 必须删除 UE 终结请求响应中的 P-Preferred-Identity，并插入经过网络断言的身份。
- 删除 PPI：P-CSCF 收到上述请求的
1xx或2xx响应时，如果含有P-Preferred-Identity，P-CSCF 应删除该头域。 - 插入 PAI：P-CSCF 插入
P-Asserted-Identity，其值应为收到请求时保存下来的P-Called-Party-ID。
Q2：当 P-CSCF 在会话释放的过程中收到关于该对话的请求时，返回 481 响应的目的是什么？
A2： P-CSCF 在释放对话的过程中收到关于对话的请求时，P-CSCF 应该中止该请求，并回送响应 481 (对话或者事务不存在)。
返回 481 的目的是为了确保会话状态的干净清理和同步。它明确告知发送方，该请求所引用的对话上下文在服务器上已失效或正在释放，从而阻止无效的信令继续流转，避免状态混乱和资源泄漏。当 S-CSCF 发起会话释放时，如果收到该会话的其他请求消息，S-CSCF 也应终止接受请求并返回一个 481 响应。
Q3：在 IMS 互通场景中，MGCF 收到来自 IMS 域的 INVITE 请求，若其中 Supported 头的值为 100rel 时，MGCF 在向 IMS 域发送 183 Session Progress 响应时，应如何处理计费信息？
A3： MGCF 必须处理并插入计费信息，特别是跨域标识 IOI。
- 存储信息：MGCF 必须存储
P-Charging-Vector头中的orig-ioi参数。 - 插入信息：MGCF 必须向
P-Charging-Vector插入从初始INVITE消息中携带的orig-ioi参数。 - 插入终结 IOI：MGCF 必须向
P-Charging-Vector插入第二类term-ioi参数。第二类term-ioi参数必须设置为 MGCF 所在的网络。 - 其他存储：MGCF 还必须存储
P-Charging-Function-Addresses中的参数值和P-Charging-Vector头中的icid值。 - 可靠性：MGCF 必须将
Require头设成100rel，确保183响应的可靠传输。