51学通信

深度解析 3GPP TS 23.380：4.3 - 4.5 S-CSCF故障后的呼叫流程恢复

26分钟阅读

深度解析 3GPP TS 23.380：4.3 - 4.5 S-CSCF故障后的呼叫流程恢复

本文技术原理深度参考了3GPP TS 23.380 V18.1.0 (2024-09) Release 18规范中，关于“4.3 UE Terminating Procedure”, “4.4 UE Originating Procedure”以及“4.5 SIP-AS Originating Procedure”的核心章节。继上一篇剖析了注册恢复机制后，本文将深入探讨在S-CSCF发生故障时，IMS网络如何保障最核心的业务——呼叫（包括被叫、主叫和应用发起的呼叫）的成功建立。

1. 故事续篇：风暴中的通信生命线

在上一篇文章中，我们的主角，商务精英小张，在毫不知情的情况下，她的IMS业务已经从一个故障的S-CSCF-1节点，无缝地切换并注册到了一个健康的S-CSCF-2节点上。她的手机和工作平板都已在新节点上恢复了正确的注册状态。

然而，注册成功仅仅是拉开了应急预案的序幕。真正的考验在于实际的业务流程。此刻，小张正驶向客户公司的停车场，一场决定性的会议即将在半小时后开始。她的通信生命线在接下来的几分钟内将面临三种典型的、也是最严峻的考验：

  1. 被叫考验：她的老板需要打入一个紧急电话，向她确认一个关键数据。
  2. 主叫考验：她需要立刻回电给助理，让助理将最新数据发送到她的邮箱。
  3. 应用触发考验：她公司CRM系统（一个SIP应用服务器）的“一键拨号”功能需要自动为她接通客户方的技术负责人。

这三个场景，完美对应了3GPP规范中的UE Terminating (被叫)、UE Originating (主叫) 和 SIP-AS Originating (应用发起) 流程。我们将逐一剖析，在S-CSCF服务中断的背景下，IMS网络如何确保小张的每一次关键通信都能成功。

2. 被叫考验：当老板的来电遇上S-CSCF故障 (Chapter 4.3 UE Terminating Procedure)

这是最常见的场景。当有电话呼叫小张时，呼叫请求会通过一系列网元最终到达I-CSCF。I-CSCF查询HSS后得知，小张当前分配的S-CSCF是S-CSCF-2。但此时，可能出现两种不同的“故障”情况。

2.1 状况一：S-CSCF重启后“失忆” (Chapter 4.3.2 S-CSCF Restoration after Restart)

故事背景：S-CSCF-2虽然硬件和网络都正常，但它刚刚经历了一次快速重启（例如，软件补丁更新）。虽然HSS中的记录显示小张归它管理，但它自身的内存（用户上下文）里却是一片空白。就在此时，小张老板的来电抵达了S-CSCF-2。

The S-CSCF lost all user data if it restarts after a failure or it is unable to trust any data after it resumes operation, due to the fact that it may have lost profile updates from the HSS in the service interruption period. If such a S-CSCF receives a terminating service request from the I-CSCF, it sends an SAR to the HSS for unregistered service data.

这段原文揭示了S-CSCF重启后的核心行为模式。S-CSCF-2收到一个指向小张的呼叫请求，但在自己的“记忆”中搜索不到小张的任何信息。它不会直接拒绝呼叫，而是会启动一个恢复流程： 它会向HSS发送一个SAR（Server-Assignment-Request）消息，但这个消息的意图是去获取“未注册业务数据（unregistered service data）”。

这看起来有点矛盾，小张不是已经注册了吗？ 是的，这正是IMS恢复机制的精妙之处。S-CSCF-2此时表现得像是在处理一个从未注册过的用户的来电。这个行为会触发HSS的智能判断。

if the Public User Identity is stored as registered in the HSS, and there are S-CSCF restoration information related to the Public User Identity stored in the HSS, the HSS shall send the S-CSCF restoration information together with the user profile in the SAA. The result code shall be set to DIAMETER_ERROR_IN_ASSIGNMENT_TYPE. The S-CSCF shall trigger matched registered services for the Public User Identity.

HSS收到这个“查询未注册用户”的请求后，一查自己的数据库，发现小张明明是已注册状态，并且HSS中存有为她备份的S-CSCF恢复信息。HSS立刻明白，S-CSCF-2是“失忆”了。

于是，HSS并不会返回错误，而是将计就计，在SAA（Server-Assignment-Answer）响应中，将小张的用户签约数据和完整的S-CSCF恢复信息（包括她手机和平板的IP地址、端口等动态信息）一并发送给S-CSCF-2。

  • 深度解析：HSS返回的Result-Code是DIAMETER_ERROR_IN_ASSIGNMENT_TYPE。这个特殊的结果码，是在友好地提醒S-CSCF-2：“你查询的类型（未注册）和你实际的情况（已注册）不匹配，但我已经把你需要的数据都给你了，请进行恢复。” S-CSCF-2收到这个响应和数据后，会立即在内存中重建小张的完整上下文，然后像正常一样处理这个来电，将其准确地路由到小张的手机和平板上。老板的紧急来电，通了！

事后弥补：主动同步状态

通话虽然接通了，但恢复流程并未完全结束。S-CSCF-2还需进行一步“善后”工作。

If the S-CSCF restoration information received includes the UE’s subscription information, the S-CSCF shall construct a NOTIFY message … to trigger a new registration at anytime after normal processing of the terminating request.

在成功处理完这次来电后，S-CSCF-2会构建一个SIP NOTIFY消息，主动发送给小张的手机和P-CSCF。这个NOTIFY消息相当于一个“状态同步提醒”，它会触发小张的设备立即发起一次新的重注册（Re-registration）。

  • 深度解析：为什么要这么做？因为S-CSCF-2从HSS恢复的数据，可能不是100%最新的。比如在S-CSCF-1故障到S-CSCF-2重启的这段时间里，UE的网络状态可能发生了微小的变化。通过强制UE进行一次重注册，可以确保S-CSCF-2上存储的用户上下文与UE的真实状态完全同步，为后续的业务提供最可靠的保障。这是一个从“被动恢复”到“主动校准”的升华。

2.2 状况二：S-CSCF彻底失联 (Chapter 4.3.3 S-CSCF Restoration after Failure)

故事背景：这次的情况更糟，不是重启后失忆，而是S-CSCF-1彻底宕机，I-CSCF完全联系不上它。

If the S-CSCF returned by the HSS during location query procedure fails, the I-CSCF is unable to contact the S-CSCF during terminating procedure. In this case, the I-CSCF shall send LIR to the HSS to explicitly request S-CSCF capabilities. … after re-selection of another S-CSCF … the I-CSCF shall forward the service request to the new S-CSCF.

这个流程与我们上一篇文章中分析的注册恢复流程（4.2.2）高度相似：

  1. I-CSCF发现故障：I-CSCF向HSS发送LIR（Location-Information-Request）查询小张的位置，HSS返回了S-CSCF-1的地址。I-CSCF尝试将呼叫请求转发给S-CSCF-1，但石沉大海。

  2. I-CSCF发起重选：I-CSCF再次向HSS发送LIR，但这次是为了请求S-CSCF的能力（capabilities）。

  3. 选择新S-CSCF并转发：HSS返回能力要求后，I-CSCF选择了一个新的、健康的S-CSCF-2，并将呼叫请求转发给它。

  4. 新S-CSCF的行为：

The HSS and this new S-CSCF shall behave as described in clause 4.3.2…

关键点来了：这个新上任的S-CSCF-2，对于小张来说是完全陌生的，它的内存中没有任何关于小张的信息。因此，当它收到这个被叫请求时，它的行为模式将完全等同于4.3.2中“重启后失忆”的场景。它会向HSS查询“未注册用户数据”，然后HSS返回恢复信息，S-CSCF-2重建上下文，并最终接通电话。

  • 深度解析：3GPP规范在这里展现了其设计的模块化和一致性。无论是S-CSCF“失忆”还是“失联”，最终都会收敛到同一个核心恢复逻辑：由一个对用户状态一无所知的S-CSCF，通过与HSS交互来重建完整的用户上下文。

2.3 现代化的高效恢复：SBI接口支持 (Chapter 4.3.4 SBI Support for S-CSCF Restoration after Failure)

在5G服务化架构（SBA）下，这个流程同样得到了优化。

If the I-CSCF is unable to contact the S-CSCF during terminating procedure, the I-CSCF shall reselect an S-CSCF and forward the terminating request to the new S-CSCF. The I-CSCF shall include a reselection indication in the request. … When receiving the reselection indication, the HSS shall allow the new S-CSCF to overwrite the current S-CSCF.

与传统流程相比，基于SBI的恢复：

  • 更直接：I-CSCF可以直接重选S-CSCF，无需二次查询能力。
  • 更明确：通过在信令中加入“reselection indication”（重选指示），清晰地告知HSS这是一个故障恢复场景，HSS会放心地让新S-CSCF覆盖旧的记录。

最终，新的S-CSCF-2收到呼叫请求后的行为，依然会回归到4.3.2的“失忆”恢复流程中。

3. 主叫考验：紧急呼出时的自我修复 (Chapter 4.4 UE Originating Procedure)

现在，小张接完了老板的电话，需要立刻呼叫助理。她点击了助理的号码。呼叫请求从她的手机发出，经过P-CSCF，将被送往S-CSCF。

3.1 状况一：S-CSCF重启后“失忆” (Chapter 4.4.2 S-CSCF Restoration after Restart)

故事背景：小张的呼叫请求被P-CSCF成功送达了S-CSCF-2，但S-CSCF-2又一次“失忆”了（例如，在处理完老板来电后再次发生了重启）。

If such a S-CSCF receives an originating request different from SIP REGISTER coming from the UE, the S-CSCF shall send SAR to the HSS with Server Assignment Type set to NO_ASSIGNMENT to restore the user data. … If there are S-CSCF restoration information … the HSS shall send the S-CSCF restoration information together with the user profile in the SAA to the S-CSCF.

这个流程与被叫场景（4.3.2）几乎是镜像的：

  1. S-CSCF-2发现未知主叫：收到小张的呼叫请求（一个SIP INVITE），但在自己的“记忆”里找不到小张。

  2. 请求恢复数据：它会立即向HSS发送一个SAR，类型为NO_ASSIGNMENT，明确要求获取该用户的恢复数据。

  3. HSS提供数据：HSS收到请求后，将备份的S-CSCF恢复信息和用户签约数据一起返回。

  4. 重建与呼叫继续：S-CSCF-2重建小张的上下文，然后验证该呼叫是否符合小张的签约策略（例如，是否有呼叫限制），最后将呼叫正确路由出去。小张成功联系上了她的助理。

同样，事后S-CSCF-2也会向UE和P-CSCF发送SIP NOTIFY消息，以确保状态的完全同步。

3.2 状况二：P-CSCF记录了错误的S-CSCF地址 (Chapter 4.4.3 S-CSCF Restoration after Failure)

故事背景：这是一个更棘手的场景。假设小张的手机在S-CSCF-1故障前完成的注册。因此，她的P-CSCF和手机中，记录的业务路由路径（Route Header）仍然指向那个已经“死亡”的S-CSCF-1。当小张发起呼叫时，P-CSCF会尝试将SIP INVITE发送给S-CSCF-1。

If the UE initiates an originating service request different from SIP REGISTER and the P-CSCF is unable to contact the S-CSCF in the Route, the P-CSCF shall return a specific error response to the UE to trigger a new registration.

这里的恢复机制发生了根本性的转变，恢复的发起者不再是核心网的I-CSCF或S-CSCF，而是边缘的P-CSCF和UE。

  1. P-CSCF尝试失败：P-CSCF向S-CSCF-1发送呼叫请求，超时失败。

  2. P-CSCF通知UE：P-CSCF不会自己去寻找新的S-CSCF。它选择了一个更根本的解决方案：直接向小张的手机返回一个特定的错误响应（例如 408 Request Timeout 或 503 Service Unavailable）。

  3. UE触发重注册：小张的手机（UE）的IMS客户端被设计为能够理解这个特定的错误响应。收到它后，UE会认为自己当前的IMS注册已经失效，因此会立即自动发起一次全新的IMS初始注册。

  4. 回归注册恢复流程：一旦UE发起了新的注册，整个故事就回到了我们第一篇文章的起点。I-CSCF会发现S-CSCF-1故障，然后为UE选择新的S-CSCF-2，完成注册。注册成功后，UE获得了指向S-CSCF-2的正确路由信息。

  5. UE自动重试呼叫：通常，UE在成功重注册后，会自动重拨刚才失败的呼叫。这一次，P-CSCF会将呼叫请求发送到正确的S-CSCF-2，呼叫成功建立。

  • 深度解析：这种“推倒重来”的机制虽然看起来“笨拙”，但却异常可靠。它不依赖P-CSCF具备复杂的故障检测和重选逻辑，而是利用了最基础、最稳健的IMS注册流程来完成自我修复。它确保了UE侧的路由信息始终是最新的，从根源上解决了问题。

4. 应用考验：当CRM系统发起呼叫 (Chapter 4.5 SIP-AS Originating Procedure)

最后，我们来看一个2B场景。小张公司的CRM系统（一个SIP应用服务器，AS）需要自动为她呼叫客户。

4.1 状况一：AS联系的S-CSCF“失忆”

这个场景与UE主叫时S-CSCF重启后失忆（4.4.2）非常相似。AS将请求发给正确的S-CSCF-2，但S-CSCF-2没有上下文。S-CSCF-2会向HSS请求恢复数据，重建上下文，然后处理呼叫。

…HSS and S-CSCF proceed as indicated in 3GPP TS 29.228, except that: if the Public User Identity is stored as registered in the HSS, and there is S-CSCF restoration information … the HSS shall send the S-CSCF restoration information…

规范明确指出其处理方式与之前的恢复流程一致，核心都是通过与HSS交互来恢复数据。

4.2 状况二：AS记录了错误的S-CSCF地址 (Chapter 4.5.3 S-CSCF Restoration after Failure)

故事背景：CRM系统（AS）通过第三方注册或查询HSS的Sh接口，也缓存了小张的S-CSCF地址，不幸的是，它缓存的是已经故障的S-CSCF-1的地址。

If the application server sends the originating service request on behalf of the user to the S-CSCF, and the S-CSCF can not be contacted, after timeout, the application server shall resend the originating service request to the I-CSCF.

这里的恢复机制又展示了第三种不同的智慧，发起者是**应用服务器（AS）**自身。

  1. AS尝试失败：AS向S-CSCF-1发送呼叫请求，超时失败。

  2. AS的智能重试：这个智能的AS被设计为在超时后，不会在同一个地址上重试。它会改变策略，将同一个呼叫请求重新发送给I-CSCF。

  3. I-CSCF接管恢复：I-CSCF是IMS网络中用于S-CSCF发现的权威入口。一旦请求到达I-CSCF，后续的流程就和被叫场景（4.3.3）完全一样了。I-CSCF会发现S-CSCF-1故障，选择新的S-CSCF-2，并将呼叫转发过去。由于S-CSCF-2对小张是陌生的，它会触发“失忆”恢复流程，最终建立呼叫。

  • 深度解析：这个机制体现了IMS生态的整体健壮性。不仅是核心网元，连应用层的AS都参与到了故障恢复的联动中。AS被赋予了“知道何时该求助于网络入口（I-CSCF）”的智能，从而将一个看似无解的请求重新拉回到标准化的恢复轨道上。

5. 总结

通过对小张在会议前这半小时内经历的三次通信考验的分析，我们深入理解了3GPP TS 23.380中关于S-CSCF故障后呼叫流程恢复的精髓。IMS的恢复机制远非单一的流程，而是一个多层次、多角色、多场景联动的立体防御体系：

  • 统一的核心恢复逻辑：无论是哪种场景，最终都可能收敛到“一个失忆的S-CSCF向HSS请求恢复数据”这一核心操作上，HSS是最终的数据权威。
  • 不同的故障发现者和恢复发起者：
    • 被叫场景：通常由I-CSCF发现故障并发起S-CSCF重选。
    • 主叫场景（P-CSCF有错址）：由P-CSCF发现故障，通过返回错误码触发UE发起重注册来完成恢复。
    • 应用发起场景（AS有错址）：由AS发现故障，通过将请求重定向到I-CSCF来完成恢复。
  • 主动与被动结合：网络不仅能在故障发生时被动恢复业务，还能通过SIP NOTIFY等机制，主动与终端同步状态，防患于未然。

正是这些看似繁复却逻辑严谨的规定，共同铸就了IMS网络强大的可靠性和业务连续性，确保了像小张这样的用户，即使在网络风暴中，其通信生命线也依然坚不可摧。

FAQ环节

Q1：S-CSCF“重启后失忆(Restart)”和“彻底失联(Failure)”这两种故障模式，在恢复流程上最根本的区别是什么？ A1：最根本的区别在于故障的发现者和恢复的发起者不同。

  • 在“重启后失忆”场景下，S-CSCF本身是可达的，但内部数据丢失。故障是在S-CSCF内部被“发现”的（因为它收到了一个自己不认识的会话请求）。恢复流程由这个S-CSCF自身通过向HSS查询恢复数据来发起。
  • 在“彻底失联”场景下，S-CSCF网络上不可达。故障是被外部实体（如I-CSCF, P-CSCF, AS）在尝试联系它时发现的。恢复流程由这些外部实体发起（例如I-CSCF重选，P-CSCF触发UE重注册等）。

Q2：在主叫场景下(4.4.3)，为什么P-CSCF不自己去查询新的S-CSCF，而是要“麻烦”UE去重注册？ A2：这主要是出于架构的清晰和简化P-CSCF功能的考虑。P-CSCF被定位为一个代理服务器，其核心职责是路由、安全和策略执行，它不直接与HSS交互获取S-CSCF地址。让P-CSCF去发现和选择S-CSCF会使其变得过于复杂，并破坏了I-CSCF作为S-CSCF发现唯一入口的架构设计。通过触发UE重注册，可以将问题抛给一个标准且成熟的流程来解决，这个流程（注册）天然就包含了I-CSCF的S-CSCF发现逻辑。这是一种“职责分离”的设计哲学，保证了系统的健壮性和可维护性。

Q3：S-CSCF在从HSS恢复数据后，为什么还要多此一举地向UE发送SIP NOTIFY来触发重注册？ A3：这是为了达到最终一致性和状态权威性。S-CSCF从HSS恢复的数据是HSS中存储的“备份”，它可能不是最新的。而UE（终端）作为业务的端点，其维护的注册状态（如NAT后协商出的IP和端口）是最鲜活、最准确的。通过发送NOTIFY强制UE重注册，S-CSCF实际上是在说：“我已经根据备份恢复了，现在请你（UE）用你的最新状态来和我进行一次权威的同步”。这可以消除任何潜在的数据不一致风险，确保后续业务的绝对稳定。

Q4：应用服务器(AS)在联系S-CSCF失败后，为什么不直接尝试联系另一个S-CSCF，而是要发给I-CSCF？ A4：因为AS通常不具备整个运营商IMS网络的拓扑视图和实时的S-CSCF负载信息。它不知道除了那个失败的S-CSCF外，还有哪些S-CSCF是可用的、哪个是最佳选择。而I-CSCF是专门设计来做这件事的，它是网络中S-CSCF发现的权威节点。AS将请求发给I-CSCF，相当于把专业的事情交给了专业的角色来处理，这使得AS应用本身可以更轻量，同时保证了S-CSCF选择的正确性和效率。

Q5：这些恢复机制能保证正在进行中的通话不会掉线吗？ A5：TS 23.380中描述的这些机制主要关注的是会话建立阶段的恢复，即确保一个呼叫能够成功发起或接听。对于一个已经建立、正在进行中的通话，如果其所在的S-CSCF发生故障，情况会更复杂。媒体流（语音/视频）通常是UE和对端UE之间（或通过媒体网关）直通的，不受S-CSCF控制，所以通话的媒体可能短时间内不会中断。但所有与会话相关的信令（如呼叫保持、转移、结束）都将失败。要实现通话中不掉线的恢复，需要更高级的机制，如IMS集中化业务（ICS）或数据层的冗余备份方案，这超出了本规范基础恢复流程的范畴。本规范的核心目标是保障业务可用性，即用户能重新发起或接收业务。

关系图谱