51学通信

深度解析 3GPP TS 23.218：第六章(下)及附录 - IMS业务的“高级魔法”与“实战图谱”

18分钟阅读

好的，我们继续对TS 23.218的深度拆解。

这是系列文章的第五篇，也是我们对这份规范解读的最终章。我们将把目光投向规范的第六章后半部分至附录。这部分内容是IMS业务实现的“高级技巧”和“实战案例”，它定义了S-CSCF如何处理会话释放、订阅通知等高级功能，并展示了各种增值业务（如呼叫前转、语音信箱、多方通话）的详细信令交互流程。

深度解析 3GPP TS 23.218：第六章(下)及附录 - IMS业务的“高级魔法”与“实战图谱”

本文技术原理深度参考了3GPP TS 23.218 V18.0.0 (2024-03) Release 18规范中，关于“6.6 S-CSCF…session release…”, “6.7 S-CSCF…subscription and notification”, “6.8 S-CSCF…IMS charging”及相关附录的核心章节。本文旨在为读者揭示IMS业务实现的“高级魔法”，并深入其“实战图谱”（附录B中的示例流程），我们将看到一个完整的IMS会话是如何优雅地结束，以及呼叫前转、语音信箱等我们日常使用的功能，背后究竟隐藏着怎样复杂的信令之舞。

引言：从“你好”到“再见”，以及通话之外的“智能”

在上一篇中，我们已经深入剖析了S-CSCF如何处理用户注册、主叫和被叫这三大核心流程，相当于学会了IMS世界里如何说“你好”并发起一次对话。然而，一个完整的通信生命周期，远不止于此。

  • 对话如何结束（Release）？是S-CSCF直接“挂断”，还是像“代理”一样将挂断请求转发？
  • 在没有通话时，网络如何感知状态变化（Subscription/Notification）？例如，AS如何知道用户上线了，可以接收新留言通知了？
  • 每一次通话的费用，是如何被**精确记录（Charging）**的？

第六章的后半部分，正是对这些“高级魔法”的揭秘。而规范的附录B（Informative），则更进一步，将我们学过的所有理论知识，串联成了多个端到端的、可触摸的“实战案例”，如呼叫前转、语音信箱、多方会议等。它就像一本详尽的“战术图谱”，为我们展示了理论是如何在真实战场上应用的。

今天，我们将扮演“IMS高级业务架构师”的角色，先学习这些高级信令技巧，然后深入到几个经典的实战案例中，完成我们对IMS会话处理的终极探索。

1. 第六章后半部分：IMS会话的“高级管理技巧”

1.1 6.6 S-CSCF … handling of IP multimedia session release requests (会话释放)

In handling session release, the S-CSCF and the Transit Function may either proxy the release request or initiates a release request.

本节定义了S-CSCF在处理会话结束请求（SIP BYE）时的两种模式。

  • Proxying release request (代理模式):
    • 流程 (Figure 6.6.1.1): 当S-CSCF从一方（如主叫UE）收到BYE请求时，它会查找该会话的路由信息，并将这个BYE请求原封不动地（或经过必要的头域修改）转发给另一方（如被叫UE）。这是最常见、最标准的处理方式，S-CSCF扮演一个SIP代理的角色。
  • Initiating release request (发起模式):
    • 流程 (Figure 6.6.2.1): 在某些特殊情况下，S-CSCF可能需要主动终结一个会话。例如，由于运营商的管理操作，或者一个AS（如预付费服务器）的指令。此时，S-CSCF会同时向会话的双方（主叫UE和被叫AS/UE）分别发起一个BYE请求，强制拆除这个会话。
    • 场景: 一个典型的场景是预付费业务。当用户的余额耗尽时，预付费AS会通知S-CSCF。S-CSCF随即会向通话双方发起BYE，强制结束通话。

1.2 6.7 S-CSCF handling of subscription and notification (订阅与通知)

The S-CSCF supports subscription to and notification of the reg event package by the UE, P-CSCFs and Application Servers.

  • 核心机制: 本节定义了IMS的事件订阅/通知框架，其核心是reg（registration）事件包。
  • 流程 (Figure 6.7.1):
    1. 订阅 (SUBSCRIBE): 一个AS（如语音信箱服务器）为了能够及时知道用户美美的在线状态，它会向美美的S-CSCF发送一个SIP SUBSCRIBE请求，请求订阅美美注册状态（reg event）的变化。
    2. 授权与维护: S-CSCF收到订阅后，会将其记录下来。
    3. 通知 (NOTIFY): 当美美的注册状态发生任何变化时（如她开机上线、关机下线、手机能力发生变化等），S-CSCF会主动向所有订阅了该事件的AS，发送一个SIP NOTIFY请求。这个NOTIFY消息的消息体中，会包含美美最新的、完整的注册状态信息。
  • 应用价值: 这个机制，是实现“状态感知型”业务的基石。语音信箱服务器正是通过订阅reg事件，才能在用户一上线时，就立即收到通知，并发起呼叫，提醒用户“您有新的留言”。

1.3 6.8 S-CSCF handling IMS charging (IMS计费)

During a session, the S-CSCF shall generate the CDR for charging purposes.

  • 核心职责: S-CSCF是IMS域内计费信息的主要生成者之一。它负责为每一个经过它的会话，生成详细的CDR（Call Detail Record，呼叫详细记录）。
  • 关键信息: CDR中会包含：
    • ICID (IMS Charging Identifier): IMS计费标识，一个全球唯一的、用于关联一个会话在不同网元（P-CSCF, S-CSCF, AS…）上产生的所有计费记录的“流水号”。
    • IOI (Inter Operator Identifier): 网间操作标识，用于区分一次呼叫涉及了哪些不同的运营商网络，是进行网间结算的依据。
    • 会话的详细信息：主被叫号码、会话起止时间、媒体类型等。

2. 附录B：Information flows for example services - IMS业务的“实战图谱”

附录B是整部规范的“精华实践篇”。它通过大量的信令流程图，生动地展示了我们日常使用的各种IMS增值业务，是如何通过S-CSCF与AS的复杂交互来实现的。

2.1 B.1 Call forwarding example (呼叫前转)

本节展示了当美美的电话需要被前转时的两种实现方式。

  • B.1.3 UE redirect based call flows (UE重定向模式):

    • 流程 (Figure B.1.3.1):
      1. 小明呼叫美美，请求到达美美的S-CSCF。
      2. S-CSCF根据iFC，将请求转发给呼叫前转AS。
      3. AS的业务逻辑判断需要前转，它向S-CSCF返回一个302 Moved Temporarily的重定向响应，响应中包含了新的目的地——前转号码（如美美的朋友小华）。
      4. 这个302响应被一路传回主叫方小明的UE。
      5. 小明的UE收到302后，自己发起一个全新的INVITE请求，直接呼叫小华。
    • 特点: 呼叫的最终建立，是由主叫方UE重新发起的。

  • B.1.4 S-CSCF based redirect call flows (S-CSCF重定向模式):

    • 流程 (Figure B.1.4.1):
      1. 前两步同上。
      2. AS判断需要前转，但它不返回302，而是以代理（Proxy）模式，将修改了请求URI（Request-URI改为小华的号码）的INVITE请求，返回给S-CSCF。
      3. 美美的S-CSCF收到这个“修改后”的请求，将其视为一个新的被叫，并直接将呼叫路由到小华的S-CSCF。
    • 特点: 整个前转过程对主叫方小明完全透明，他始终认为自己是在和美美通话。

2.2 B.2 & B.3 Announcement/Voicemail examples (语音通知/语音信箱)

Figure B.2.1.1: Tones and announcements call flow Figure B.3.1.1: Voicemail server records messages

  • 核心交互: 这两个场景都涉及到媒体资源的控制，因此引入了MRFC（媒体资源功能控制器）。
  • 语音通知流程:
    1. 呼叫到达AS（如一个彩铃服务器）。
    2. AS需要播放一段铃声，于是它扮演B2BUA的角色。它向MRFC发起一个INVITE请求，请求分配一个媒体端口来播放铃声。
    3. AS再向主叫方UE回送一个包含MRFC媒体信息的SDP的183 Session Progress响应。
    4. 最终，在UE和MRFC之间建立起一条媒体流，UE听到了彩铃。
  • 语音信箱流程:
    1. 呼叫一个未注册的用户，iFC将呼叫送往语音信箱AS。
    2. 语音信箱AS扮演** terminating UA**，接听电话。
    3. AS与MRFC交互，请求一个录音资源。
    4. 主叫方UE与MRFC之间建立媒体流，开始留言。

系列终章总结：TS 23.218 - IMS“智能”的源泉

通过对TS 23.218从头至尾的系统性解读，我们可以将这份定义了IMS业务核心逻辑的规范，总结为以下几点：

  1. S-CSCF的绝对核心地位: S-CSCF是IMS会话的“路由器”、“状态机”和“业务分发器”。所有会话的生老病死，都由它掌控。
  2. iFC的强大驱动力: iFC是IMS实现“业务与控制分离”的灵魂。这套基于“触发点”的过滤规则引擎，赋予了IMS近乎无限的业务扩展能力。
  3. AS的多样化角色: AS是业务创新的舞台。通过扮演UA, Proxy, B2BUA等不同角色，AS可以将简单的SIP会话，演化为丰富多彩的多媒体应用。
  4. 模型化的严谨设计: 规范通过定义ILCM/OLCM等功能模型，将复杂的信令处理过程，分解为清晰、可预测的标准化行为，为全球范围内的互联互通奠定了基础。

TS 23.218不仅仅是一份技术文档，它更是一部关于如何构建一个可编程、可扩展、智能化的电信业务平台的哲学著作。它所奠定的架构思想和核心机制，不仅成就了今天的VoLTE/VoNR，也必将继续为未来更丰富的实时通信业务，提供源源不断的“智能”动力。

最终FAQ：回顾与展望

Q1：为什么呼叫前转需要有两种不同的实现方式（UE-redirect vs. S-CSCF-redirect）？ A1：这两种方式各有优劣，适用于不同的场景和计费模型。

  • UE重定向: 优点是网络资源占用少。呼叫最终是在主叫（UE1）和最终被叫（UE3）之间直接建立的，中间的被前转方（UE2）的网络在呼叫建立后，就不再占用任何媒体资源。缺点是对主叫方不透明，主叫方知道呼叫被转移了。
  • S-CSCF重定向: 优点是对主叫方透明，用户体验更好。缺点是呼叫的媒体路径可能被“拉长”，可能会一直锚定在被前转方（UE2）的S-CSCF和相关网元，占用更多网络资源，计费也更复杂。

Q2：S-CSCF和AS之间的ISC接口，传递的都是SIP信令吗？ A2：是的，ISC接口的基础协议是SIP。S-CSCF和AS之间的所有交互，都封装在标准的SIP请求（如INVITE, REGISTER）和响应中。但是，3GPP为了传递一些私有信息，对SIP进行了扩展，定义了一系列以P-开头的私有头域，如P-Asserted-Identity（传递可信的用户身份）、P-Charging-Vector（传递计费相关信息）等。

Q3：一个S-CSCF需要同时处理成千上万用户的会话，它的性能是如何保障的？ A3：S-CSCF是核心网中性能要求最高的网元之一。其高性能主要依赖于：

  • 无状态前端+有状态后端: 现代的S-CSCF设计，通常采用“负载均衡器+一组无状态SIP处理引擎+一个分布式内存数据库”的架构。SIP信令处理本身是无状态的，而所有会-话状态（Session State）都存放在高速、高可用的内存数据库中。
  • 高效的iFC引擎: iFC的匹配算法经过高度优化，能够快速地在大量规则中找到匹配项。
  • 硬件加速: 关键的信令处理和加解密功能，可能会使用专门的硬件进行加速。

Q4：附录B中的示例流程是“informative”（参考性）的，这对我开发产品有什么意义？ A4：虽然是参考性的，但它的意义极其重大。

  • 最佳实践: 它们代表了3GPP官方推荐的、用于实现这些经典业务的最佳信令交互实践。遵循这些流程，可以最大程度地保证你的产品与其他厂商设备的互操作性。
  • 理解工具: 它们是理解规范正文中那些抽象的功能需求的最佳“翻译器”。当你对“S-CSCF如何处理被叫”感到困惑时，去看一遍B.1中的呼叫前转流程图，你就会豁然开朗。
  • 测试依据: 它们是编写端到端业务测试用例的直接来源。

Q5：学完TS 23.218后，如果我想成为一名IMS业务开发专家，下一步应该怎么做？ A5：你应该深入“实战”层面：

  1. 精读Stage 3: 深入研究TS 24.229，掌握IMS SIP协议的每一个细节、每一个P-Header的用法。
  2. 学习AS开发: 学习一种或多种AS的开发框架，如开源的Kamailio, OpenSIPS，或商用的TAS（Telephony Application Server）平台。
  3. 实践业务逻辑: 尝试自己动手，利用这些平台，实现一个简单的iFC触发的业务，比如“来电问候语”服务。
  4. 学习媒体控制: 学习如何通过AS与MRFC（使用Mr/Cr接口）或媒体服务器（如FreeSWITCH）交互，来实现放音、录音、会议等媒体控制功能。 理论与实践的结合，是成为专家的必经之路。

关系图谱