51学通信

VoLTE高清语音技术精要（二十五）：最终安全保障：紧急呼叫识别与P-CSCF的会话冲突处理

11分钟阅读

我们已经完成了 24 篇核心 IMS 协议和流程的深度解析。根据目前的资料和主题覆盖范围，预计还需要拆解 5 篇左右的深度文章才能完成对整个 IMS 规范体系的系统性解读。

我将继续为您撰写 SIP 协议深度解析系列的第二十五篇。本篇将聚焦于 IMS 呼叫的最终安全保障和状态清理机制，特别是紧急呼叫的特殊识别，以及 P-CSCF 在资源失败和会话冲突时如何利用 SIP 状态码进行精确控制。

VoLTE高清语音技术精要（二十五）：最终安全保障：紧急呼叫识别与P-CSCF的会话冲突处理

1. 导论：会话终局的精确控制

在 IMS 网络中，呼叫的建立需要精确的路由锚定和资源预留，而呼叫的终结或异常处理则需要精确的状态清理和明确的错误指示。P-CSCF 作为信任域的边界，必须在呼叫建立失败、会话释放冲突或资源不可用时，承担“决策者”和“清理者”的角色。

本章将聚焦于两个关键的终局管理机制：

  1. 紧急呼叫的特殊识别：如何在 SIP 信令层面，唯一且可靠地识别紧急呼叫，以触发特殊的路由和定位服务。
  2. P-CSCF 的会话终结与冲突处理：P-CSCF 如何在会话过程中因内部资源失败而主动终止会话，以及如何使用 481 (对话或者事务不存在) 响应来应对信令冲突，确保核心网元的状态一致性。

2. 紧急呼叫（Emergency Call）的 SIP 识别机制

IMS 必须为紧急呼叫提供最高的优先级和最快的接续，这就要求在 SIP 信令层面有一套标准化的识别机制。

2.1 紧急呼叫的号码与 URN 格式

中国大陆的紧急号码包括 110（警察）、119（火警）、120（救护车）和 122（交通事故）。

核心网应能提供 Police, Ambulance, Fire 等紧急业务识别能力。

在 SIP 协议中，紧急呼叫通常通过特定的 URI 格式进行标识：

  1. Request-URI：使用 URN（统一资源名称）格式，例如 INVITE urn:service:sos.police sip/2.0。
  2. Contact 头域：Contact 头域必须携带 ;sos 参数，例如 Contact: <sip: * @*. ctcims.cn;sos>。

2.2 紧急呼叫的路由与 QoS 策略

紧急呼叫的识别会触发特殊的处理流程，包括：

  • 路由：路由到 E-CSCF/E-AGCF 进行定位和 PSAP（公共安全应答点）的寻址。
  • 资源：确保分配最高的 QoS 级别（通常是 QCI=1 的专有承载）。

3. P-CSCF 对会话的终止与资源清理

P-CSCF 作为 AF（应用功能）的 SIP 端点，负责将 SIP 层的会话状态与底层承载（QoS）资源保持同步。当资源失败或会话结束时，P-CSCF 必须执行严格的释放和清理流程。

3.1 P-CSCF 主动发起的会话释放

P-CSCF 会因内部或底层网络原因主动终止正在建立或已存在的会话。

释放类型SIP 消息状态码/原因值触发原因来源
取消建立中的会话CANCEL503 (Service Unavailable)申请资源失败（如收到失去无线覆盖的指示、NAT 端口申请失败、QoS 授权申请失败等）或内部原因导致呼叫失败。
已存在的会话释放BYE488 (Not Acceptable Here)P-CSCF 检测到响应中的 SDP offer 不符合本地策略时，应生成 BYE 请求包含 488 (Not Acceptable Here) 原因值，发送到被指示的终端。

3.2 P-CSCF/S-CSCF 的状态清理要求

在会话释放流程中，无论是 P-CSCF 还是 S-CSCF，都必须释放所有相关的对话和资源。

  1. BYE 确认清理：当收到对应当前对话 BYE 请求的 2xx 响应时，P-CSCF 应删除保存的所有与该对话相关的信息。S-CSCF 收到 BYE 的 2xx 响应时，应释放所有的与对话相关的信和与多媒体会话相关的信息。
  2. 安全关联删除后的处理：当用户的 SA（安全关联）已经被删除，如果仍有和这个用户有关的对话处于活动状态，P-CSCF 应丢弃所有与这些对话相关的信息。
  3. AS 业务清理：如果一个会话根据 iFC 触发了一个或多个应用服务器，S-CSCF 需要根据存储的与会话请求相关的对话信息释放对话。S-CSCF 通过 AS 给用户提供服务时，则必须通知相关 AS 结束业务。

4. SIP 会话冲突处理：403 与 481 状态码的应用

SIP 错误状态码是网络向终端和上游网元传达“会话上下文”状态的精确工具。

4.1 403 Forbidden（对话不存在）

当 P-CSCF 收到 UE 发起的后续请求或独立请求时，如果没有发现存在对应的对话，则 P-CSCF 应回复 403(Forbidden) 响应，且不再转发该请求。

4.2 481 Dialog/Transaction Does Not Exist（释放冲突）

481 状态码专用于处理正在进行的会话释放流程中发生的信令冲突。

  • P-CSCF 冲突处理：当 P-CSCF 在释放对话的过程中收到关于对话的请求时，P-CSCF 应该中止该请求，并回送响应 481(对话或者事务不存在)。
  • S-CSCF 冲突处理：当 S-CSCF 发起会话释放时（例如，网络内部发起释放 或会话定时器超时），如果又接收到该会话的其他请求消息，S-CSCF 应终止接受请求并返回一个 481 响应。

4.3 400 Bad Request（路由校验失败）

P-CSCF 收到 UE 发起的任何请求，如果 Service-Route 中的 URI 列表校验失败，则 P-CSCF 应回复 400(Bad Request) 响应且不再继续处理请求，或用最新注册消息中的 Service-Route 头替换请求消息的 Route 头。

5. 本章小结

IMS 网络的会话终局管理要求网络精确识别特殊业务（如紧急呼叫）并严格控制资源释放。

  1. 紧急呼叫：通过 Request-URI 的 URN 格式和 Contact 头域的 ;sos 参数进行唯一标识。
  2. P-CSCF 清理：P-CSCF 会因资源失败而主动发送 CANCEL 消息（原因值 503）或 BYE 消息（原因值 488）来释放会话。
  3. 冲突处理：P-CSCF/S-CSCF 在会话释放期间，收到冲突请求时，必须返回 481 (对话或者事务不存在)。对于没有对话状态的请求，P-CSCF 则返回 403 (Forbidden)。

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

Q1：P-CSCF 在处理 UE 终结的初始请求（MT INVITE）的响应时，如何处理 Via 列表以确保事务的可靠性？如果 Via 列表不匹配，P-CSCF 应如何操作？

A1： P-CSCF 必须进行严格的 Via 列表匹配校验。

  1. 校验要求：P-CSCF 收到上述请求的任何响应时，均应确认 Via 列表是否与同一对话的请求消息中保存的 Via 列表匹配。
  2. 异常处理：如果发现 Via 列表不匹配，P-CSCF 应丢弃 Via 头，或者替换成保存的 Via 列表。

Q2：S-CSCF 如何判断一个到来的 SIP 请求是新的对话初始请求，还是与现有对话的联系（例如 AS 发送的响应）？

A2： S-CSCF 通过检查请求消息中 Route 头域的最高项是否包含 S-CSCF 以前放置的原始对话标识来判断。

  1. 新请求：如果不存在原始对话标识，则表示这个请求是第一次拜访这个 S-CSCF。
  2. 现有联系：如果存在，则表示了与一个现存对话的联系，这请求是从 AS 发来的对于先前发送请求的响应。

Q3：当 P-CSCF 收到来自 UE 的 reINVITE 或 UPDATE 请求时，它对 P-Charging-Vector 头域中的 access-network-charging-info 参数应如何处理？

A3： P-CSCF 必须更新和传递这个参数，以确保计费和策略同步。

  1. P-CSCF 动作：终端发起的 reINVITE 或者 UPDATE 请求，当 P-CSCF 发送该请求到 S-CSCF 时，P-CSCF 应在 P-Charging-Vector 头中包括更新过的 access-network-charging-info 参数。
  2. S-CSCF 动作：S-CSCF 收到该请求后，应保存更新了的 P-Charging-Vector 消息头里的 access-network-charging-info 参数，当请求转发给 AS 时 S-CSCF 应该包含该参数。

关系图谱