好的，我们继续进行深度拆解。这是本系列的第二十一篇文章，将聚焦于最后一个纯信令优化方案——Solution #16。

深度解析 3GPP TR 23.700-19：6.16 Solution #16: 通过预配置SDP参数降低呼叫建立时间

本文技术原理深度参考了3GPP TR 23.700-19 V1.0.0 (2025-09) Release 20规范。在我们已经探讨了多种通过简化SIP消息和流程来优化呼叫建立时间的方案之后，本文将深入解读 6.16 Solution #16。这个方案将优化的矛头精准地指向了IMS呼叫建立过程中最“臃肿”、最耗时的部分——SDP（Session Description Protocol）协商。它提出了一种极具创意的“先礼后兵”策略：在通话前，就通过带外（out-of-band）的方式，预先配置好SDP参数，从而在真正的呼叫过程中，实现“零协商”或“极简协商”。

引言：从“当场谈判”到“预签合同”

让我们再次回到Alex的团队。他们已经通过Solution 15等方案，将SIP信令的“信封”（头域）压缩到了极致。但信封里的“信件内容”（消息体），特别是用于媒体协商的SDP，依然占据了大量的空间和交互时间。

“我们每次打电话，都像是在进行一场复杂的商业谈判，” Alex在一次性能分析会上打了个比方，“主叫（UE）在INVITE里递上一份厚厚的‘合同草案’（SDP Offer），列出自己支持的所有媒体格式、编解码器、端口号。被叫方收到后，要逐条审阅，然后拟定一份‘回复函’（SDP Answer），选定最终的合作条款。这一来一回，在高时延的GEO链路上，耗费的时间和带宽都非常可观。”

“Solution 16的工程师们就在思考：” Alex继续说道，“对于GEO卫星通信这种场景单一、选择有限（可能只有一两种专用编解码器）的‘合作’，我们真的需要每次都这么隆重地‘当场谈判’吗？我们能不能在‘建立商业关系’（IMS注册）的时候，或者在‘正式会谈’（通话）前，就提前把这份‘媒体合同’签好？”

这个“预签合同”的思想，正是Solution 16的核心。它试图将耗时的SDP协商过程，从关键的呼叫路径上剥离出去，从而实现呼叫建立时间的飞跃式提升。

1. 方案总纲：6.16.0 High-level solution Principles (高层解决方案原则)

本节明确了方案的目标，并提出了三种实现“预配置”的可选路径。

This solution addresses Key Issue #2: “IMS Enhancements for GEO NB-IoT NTN Access”. This solution aims to reduce the Call Setup Time by introducing SDP pre-configuration procedure… There can be several options to achieve early configuration of SDP parameters… Option 1: Pre-configuration during SIP registration. Option 2: Pre-configuration by pre-call SIP message flow. Option 3: Using pre-define SDP parameters.

Alex为团队解读这三大路径：

1. 选项一：在SIP注册时预配置。

   • 时机: 在UE进行IMS注册（REGISTER）的流程中。
   • 方式: 通过在注册信令中扩展新的消息体，UE和P-CSCF“顺便”就把后续通话要用的SDP参数（如IP地址、端口、编解码器）协商和交换完毕。
   • 比喻: 在办理“公司入职手续”时，就把未来所有项目的“标准合作条款”签好了。

2. 选项二：通过呼叫前的SIP消息流预配置。

   • 时机: 在注册完成后、实际通话前的任意时刻。
   • 方式: UE可以主动发起一次特殊的SIP消息交换（如INFO或OPTIONS），专门用于协商和配置SDP参数。
   • 比喻: 在项目正式启动前，专门组织一次“预备会议”，敲定所有技术细节。

3. 选项三：使用预定义的SDP参数。

   • 时机: 无需实时协商。
   • 方式: UE和P-CSCF都基于一套运营商预先定义好的、固化的SDP模板。例如，规定所有GEO卫星通话，都使用Codec-X，端口范围在Y-Z之间。
   • 比喻: 所有项目都直接套用公司法务部制定的“标准合同模板”，无需任何谈判。

“这三个选项，代表了从‘高度动态’到‘完全静态’的三种不同程度的预配置策略，” Alex总结道，“它们的共同目标只有一个：让真正的INVITE消息尽可能地‘轻’，甚至不带SDP，从而跑得更快。”

2. 方案详述：6.16.1 Description

本节进一步阐述了方案的设计动机。

Since the network resource is limited when using GEO satellite access, it’s considered that there might be only few options for SDP parameters (such as for codec capability, parameters for media transfer…) and the SDP parameters can be simple and semi-fixed within the same IMS registration period.

这段话解释了“为什么预配置是可行的”：

• 选择有限: GEO卫星场景下的媒体选项非常有限，可能只有一到两种超低比特率的专用编解码器。
• 参数半固定: 在一次IMS注册会话的生命周期内（通常是几小时甚至几天），UE的IP地址、可用的端口等信息通常是稳定不变的。

既然选项不多，参数又相对固定，那么每次通话都重新进行一次完整的、复杂的协商，就显得非常冗余和低效。这为“预配置”提供了坚实的逻辑基础。

3. 流程剖析：6.16.2 Procedures - “预签合同”的三种方式

本节通过详细的流程图，展示了三种预配置选项的具体实现。

3.1 选项一：在SIP注册时预配置 (6.16.2.1)

规范的 “Figure 6.16.2.1-1: Registration Procedure with ‘SDP pre-config’ feature” 详细描绘了这一流程。

1. 步骤 1-2: 开启“预配置”协商

   • UE在SIP REGISTER消息中，包含一个新的feature tag，例如+g.3gpp.sdp-pre-config，表明“我支持SDP预配置”。
   • P-CSCF如果也支持，它会在401 Unauthorized响应中，同样带上这个feature tag，回应“同意，我们来谈谈细节吧”。

2. 步骤 3: UE上报“草案”

   • UE再次发送REGISTER消息。这次，除了标准的鉴权信息，它还在消息体中携带了一个XML格式的SDP Offer。
   • 这个XML体中包含了UE为后续通话提议的媒体参数，如：UE's IP address/port, UE codec info等。

3. 步骤 4: P-CSCF返回“终稿”

   • P-CSCF收到后，根据网络策略和自身能力，选择最终的SDP参数（例如，为网络侧的媒体网关预留IP地址和端口，选定双方都支持的编解码器）。
   • P-CSCF在返回的200 OK消息中，同样以XML格式携带一个SDP Answer，将网络侧选定的媒体参数告知UE。

4. 步骤 5: “合同”生效

   • 注册完成后，UE和P-CSCF双方都缓存了这份“预签”的SDP“合同”。
   • 在后续的实际通话中，INVITE消息就可以不再携带SDP体，或者只携带一个指向这份“合同”的引用。P-CSCF收到无SDP的INVITE后，会自动从缓存中取出预配置的SDP信息，构建出一个完整的INVITE再发往核心网。

规范的 Figure 6.16.2.1-1a 给出了一个具体的XML消息示例，展示了如何通过XML来承载c-line, m-line, a-line等SDP核心信息。

3.2 选项二：通过呼叫前消息预配置 (6.16.2.2)

规范的 “Figure 6.16.2.2-1: Pre-configuration Procedure with pre-call SIP message flow” 描绘了这种方式。

• 流程: 流程与选项一非常相似，唯一的区别在于承载SDP协商的不再是REGISTER和200 OK(REGISTER)，而是一次独立的SIP消息交互，例如：
  • UE → P-CSCF: INFO (with SDP Offer in XML body)
  • P-CSCF → UE: 200 OK(INFO) (with SDP Answer in XML body)
• 优势: 更加灵活。UE可以在任何它认为合适的时机（如刚从IDLE态唤醒，或网络状况较好时）来发起这次预配置，而不必等到下一次重新注册。

3.3 选项三：使用预定义的SDP参数 (6.16.2.3)

For the UE using GEO satellite access, the SDP parameters are pre-defined. The following call initiation can based on the pre-defined SDP. That is, the UE can sent SIP INVITE without the SDP and the P-CSCF can help to restore the SDP for GEO satellite access.

• 流程: 这是最简单的方式。UE和P-CSCF都内置了一套写死的（hard-coded）或通过配置下发的SDP模板。
• 优势: “零”协商开销。UE直接发送无SDP的INVITE，P-CSCF直接套用模板来构建出站的INVITE。
• 劣势: 缺乏灵活性。无法动态协商IP地址和端口，可能需要依赖P-GW/SBC进行NAT转换或端口映射，增加了媒体面处理的复杂性。

3.4 预配置后的呼叫流程 (6.16.2.4)

规范的 “Figure 6.16.2.4-1: MO Call Setup Procedure with SDP pre-configuration applied” 展示了“预签合同”后的呼叫流程是何等简洁：

1. UE → P-CSCF: 发送一个无SDP或带极简SDP的INVITE。
2. P-CSCF: 从缓存中取出预配置的SDP信息，构建一个带完整SDP Offer的标准INVITE，发往核心网。
3. 后续流程: 按照标准的IMS流程进行，但P-CSCF在收到183/200 OK(SDP Answer)后，可能不再需要将其完整地转发给UE，因为UE已经通过预配置知道了媒体参数，P-CSCF可能只需要转发一个不带SDP的183/200 OK即可。

3.5 性能收益估算 (6.16.2.5)

本节再次进行了量化分析，展示了SDP预配置带来的巨大收益。 Table 6.16.2.5-3 对比了有/无SDP预配置的完整呼叫流程（无Precondition）的总信令尺寸：

• 原始流程总尺寸: 12,678 字节
• 预配置后流程总尺寸: 2,046 字节

信令总量减少了惊人的 84%！

By applying SDP pre-configuration and the flow without pre-condition, the total message size for call set up can be reduced by 84%…

这个数字雄辩地证明了SDP协商是IMS呼叫建立中最大的开销来源，而“预配置”是解决这一问题的最有效手段之一。

4. 影响分析：6.16.3 Impacts on Services, Entities and Interfaces

Solution 16的改动再次高度集中于UE和P-CSCF。

• UE:
  • 需要支持在注册或呼叫前流程中，通过XML等格式协商SDP参数的逻辑。
  • 需要缓存预配置的SDP参数，并在发起呼叫时使用它们。
• P-CSCF:
  • 核心改动: 需要支持SDP预配置的协商流程（如解析XML，生成响应）。
  • 核心改动: 需要为每个注册的UE，缓存一套完整的SDP上下文。
  • 在处理无SDP的INVITE时，需要具备从缓存中恢复SDP并构建标准INVITE的能力。

5. 结论：“预言家”的智慧

Alex最后对Solution 16进行了总结：“Solution 16为我们展示了一种‘预言家’的智慧。它通过在通话发生前就‘预见’并‘固化’媒体协商的结果，成功地将最复杂的SDP协商环节，从实时、关键的呼叫路径上移除，从而实现了呼叫建立效率的指数级提升。”

“它的优点是目标精准，效果显著：”

• “大幅降低呼叫建立时间： 通过消除或极大简化SDP协商，它直接攻击了呼叫流程中最大的时延和带宽‘杀手’，其带来的性能提升（信令量减少84%）是其他任何头域简化方案都无法比拟的。”
• “架构清晰： 无论是通过注册、呼叫前消息还是预定义模板，其实现逻辑都相对清晰，且可以与B2BUA架构完美结合。”

“其挑战则在于状态的维护和协商的灵活性：”

• “P-CSCF的状态负担： P-CSCF需要为海量的注册用户维护一套SDP上下文，这对P-CSCF的存储和处理能力提出了更高的要求，使其变成了一个更重的‘有状态’节点。”
• “灵活性的权衡： 预配置的粒度和时机需要在灵活性和效率之间做出权衡。注册时配置最省事，但不够灵活；呼叫前配置最灵活，但增加了额外的信令交互；预定义模板最快，但完全牺牲了灵活性。”

“总而言之，Solution 16是继‘禁用Precondition’之后，IMS信令优化的又一柄‘大杀器’。它与Solution #15（SIP头域简化）的结合，几乎构成了应用层信令优化的‘完全体’。一个在信封上‘精打细算’，一个在信纸上‘惜墨如金’。这两者的组合，将为在GEO NB-IoT这种极限网络下提供可用的语音服务，铺平最后的道路。”

---

FAQ

Q1：Solution 16的核心思想是什么？它要解决什么问题？ A1：Solution 16的核心思想是SDP（会话描述协议）预配置。它旨在解决IMS呼叫建立过程中，因实时进行SDP Offer/Answer协商而导致的巨大信令开销和时延问题。通过在实际通话前（如注册时或通过专用消息），提前协商和缓存好通话所需的媒体参数（如IP、端口、编解码器），从而使得真正的通话信令（INVITE）可以不带或只带极简的SDP，大幅缩短呼叫建立时间。

Q2：方案提出了三种预配置选项，它们各有什么优缺点？ A2：

• Option 1 (注册时配置): 优点是流程融合，没有额外的信令往返，效率高。缺点是不够灵活，如果通话过程中媒体能力需要变化（例如，UE移动到了一个不同的网络），可能需要重新注册才能更新。
• Option 2 (呼叫前消息配置): 优点是最灵活，UE可以在任何时候按需更新其SDP参数。缺点是引入了额外的SIP消息交互，本身也会产生一定的信令开销。
• Option 3 (预定义参数): 优点是“零协商”，速度最快，实现最简单。缺点是完全没有灵活性，无法适应动态变化的网络地址和端口，可能需要依赖NAT等额外的网络功能，并限制了业务的演进。

Q3：SDP预配置后，INVITE消息可以不带SDP体吗？这符合SIP标准吗？ A3：是的，INVITE消息可以不带SDP体。这在SIP标准（RFC 3261）中是允许的，通常用于发起一个需要后续协商的呼叫（例如，INVITE不带Offer，等待对方在200 OK中返回Offer）。但在本方案的上下文中，情况有所不同：UE发送一个无SDP的INVITE，是基于它与P-CSCF之间的一个“默契”——即P-CSCF知道如何为这个INVITE“凭空”创造出一个SDP Offer。这个行为本身是在P-CSCF B2BUA的框架下实现的，P-CSCF朝向核心网发送的INVITE依然是标准的、带有SDP Offer的。因此，它通过B2BUA的隔离，实现了对空口的优化和对核心网的兼容。

Q4：为什么说SDP协商是呼叫建立中最大的开销来源？ A4：因为SDP是文本格式的，其内容可能非常冗长。一个典型的SDP Offer需要描述会话版本、发起方、会话名称、连接信息（IP地址）、时间、以及一个或多个媒体流的详细信息（m=行），每个媒体流又包含多种编解码器选项（多个a=rtpmap行）和参数（a=fmtp行）等。所有这些信息加起来，可以轻易地使一个SIP消息的体积增加数百甚至上千字节。在信令总量只有一两千字节的简化流程中，SDP占据了“半壁江山”，因此优化它带来的收益是最大的。

Q5：这个方案与Solution #15（SIP头域简化）是什么关系？ A5：它们是互补关系，可以被看作是IMS信令“瘦身”的“一体两面”。

• Solution #15 专注于简化SIP头部（Headers），相当于精简信件的“信封”和“抬头落款”。
• Solution #16（本方案） 专注于简化**SIP消息体（Body）**中的SDP部分，相当于精简信件的“正文内容”。 将这两个方案结合起来，可以实现对SIP消息从头到脚、从内到外的全方位压缩，从而达到最佳的信令优化效果。一个经过双重优化的INVITE消息，可能只剩下几十个字节的核心信息，这在GEO NB-IoT的极端链路上，意义非凡。