好的，通信学院的专家讲师。我将继续为您撰写SIP协议深度解析系列的第九篇。本篇将深入剖析 SIP 协议中承载媒体协商的基石——SDP 协议，以及 VoLTE 网络为保障电信级 QoS 所引入的 Precondition 机制。
VoLTE高清语音技术精要（九）：媒体协商基石：SDP 协议与 Precondition 模型
1. 导论：从信令控制到媒体描述的桥梁
在前面的课程中，我们深入解析了 SIP（Session Initiation Protocol）协议如何通过 INVITE、BYE 等方法，以及 From, To, Call-ID 等头域来控制会话的信令面（Call Control）。然而，SIP 协议本身并不描述实际传输的媒体流（如语音 RTP 包）的细节。
SIP 协议设计上采用分层哲学：SIP 负责“如何建立连接”，而 **SDP（Session Description Protocol，会话描述协议）**则负责回答“连接中传输什么”。SDP 协议的消息体被封装在 SIP 消息（主要是 INVITE 和 200 OK）中，用于描述媒体类型、编解码器、传输协议、IP 地址和端口等信息。
在 VoLTE/VoNR 这类追求电信级服务质量（QoS）的网络中，媒体协商的成功与否，直接关联到承载网络的资源预留。因此，IMS 引入了基于 SDP 的 Precondition（先决条件）机制，确保只有在专用的 QoS 承载资源就绪后，呼叫才能接通。
2. SDP 协议基础：媒体的蓝图
SDP 协议（遵循 RFC 4566）是一种纯文本协议，结构化地描述了多媒体会话的关键参数。它在 SIP 消息中通过 Content-Type: application/sdp 头域进行标识。
2.1 SDP 消息体的结构化字段
SDP 消息体由多个描述行组成，每行由一个单字母字段名、一个等号（=）和一个值组成。核心结构分为会话级别描述和媒体级别描述。
| SDP 字段名 | 全称/含义 | 核心作用（IMS 场景） | 示例 |
|---|---|---|---|
| v | Version | 协议版本，通常为 0。 | v=0 |
| o | Origin | 会话发起者信息。包含用户 ID、会话 ID、版本号、网络类型和地址类型等。 | o=ORIGUA 1073773079 1073773081 IN IP4 10.184.113.12 |
| s | Session Name | 会话名称，可选。 | s=SIP Call |
| c | Connection Data | 媒体流的目的 IP 地址和网络类型。 | c=IN IP4 10.184.134.38 |
| t | Timing | 会话的起始时间和终止时间，IMS 通常设为永久会话。 | t=0 0 |
| m | Media Description | 媒体描述行。定义媒体类型（audio/video）、端口、传输协议（RTP/AVP）以及编解码器列表。 | m=audio 52712 RTP/AVP 8 |
| a | Attribute | 属性行。用于提供媒体的额外信息，如编解码器映射（rtpmap）、媒体流方向（sendrecv）、DTMF 支持（telephone-event）和 Precondition 状态（des, curr）。 | a=rtpmap:8 PCMA/8000 |
2.2 编解码器协商与 DTMF
- 编解码器映射：
m=行列出了 UE 支持的媒体格式的 Payload Type (PT) 列表。a=rtpmap属性行将这些 PT 映射到具体的编解码器（Codec），例如a=rtpmap:97 EVS/16000/1。在 VoLTE 中，EVS、AMR-WB 等高清编解码器是主要的协商目标。 - DTMF 协商：IMS 强烈建议使用带内 DTMF（RFC 2833/4733），即通过 RTP 封装的 DTMF 事件。这通过在 SDP 中包含
a=rtpmap:101 telephone-event/8000等语句进行协商。
3. Offer/Answer 模型：会话能力的交换
SIP 利用 SDP 实现**提议/应答（Offer/Answer）**模型（RFC 3264）。会话的建立必须经历一次完整的 Offer/Answer 交换。
| 步骤 | SIP 消息 | SDP 内容 | 作用 | 来源 |
|---|---|---|---|---|
| 提议 (Offer) | INVITE (或 Re-INVITE/UPDATE) | 包含 SDP 净荷 | 提议方列出其支持的媒体类型、编解码器和资源需求。 | UAC 或 UAS |
| 应答 (Answer) | 183 Session Progress (或 200 OK) | 包含 SDP 净荷 | 应答方从 Offer 中选择它支持且愿意使用的媒体参数，并指定自己的接收地址和端口。 | UAS 或 UAC |
| 最终确认 | ACK (针对 200 OK) 或 PRACK (针对 183) | 通常不携带 SDP | 确认 SDP 协商的最终结果。 | UAC 或 UAS |
重要提示：
- 如果
INVITE请求中包含 SDP Offer，则响应（1xx 或 2xx）中必须包含 SDP Answer。 - 在 VoLTE 中，SDP Answer 通常在
183 Session Progress中携带，目的是为了提前完成媒体协商，从而尽早触发底层专用 QoS 承载的建立。
4. 电信级 QoS 保障：Precondition 机制
由于 IMS 呼叫（如 VoLTE 语音）需要专用的 QoS 承载（如 QCI=1 承载）来保证带宽和时延，必须确保媒体流在资源预留成功后才能发送。Precondition 机制（RFC 3312）解决了这个问题。
4.1 Precondition 的核心原理
Precondition 机制的哲学是：通信双方必须通过信令确认彼此的本地和远端网络资源都已就绪，呼叫才能进入振铃和接通阶段。
该机制通过 SDP 的 a= 属性行来表达：
| SDP 属性 | 格式 | 含义 |
|---|---|---|
a=des | a=des:qos <本地期望> <远端期望> | 描述会话发起方对本地和远端资源状态的期望。例如，a=des:qos mandatory local sendrecv 表示本地和远端都期望资源达到双向发送接收 (sendrecv) 的强制要求。 |
a=curr | a=curr:qos <本地当前状态> <远端当前状态> | 描述会话发起方当前的资源状态。例如，初始状态通常是 a=curr:qos local none remote none，表示资源尚未就绪。 |
4.2 PRACK 与 UPDATE 在 Precondition 中的作用
Precondition 流程需要借助 SIP 扩展方法来完成资源状态的同步：
4.2.1 可靠临时响应（100rel 和 PRACK）
在 Precondition 流程中，183 Session Progress 是携带 SDP Answer 的关键消息，通常要求可靠传输。
- 能力声明：
INVITE请求通常携带Supported: 100rel, precondition。 - 可靠性要求：
183 Session Progress响应携带Require: 100rel, precondition和RSeq序列号。 - 确认：主叫 UA 收到可靠的
183响应后，必须回复PRACK请求进行确认。
4.2.2 资源状态更新（UPDATE）
当一方的底层承载资源（专用 QoS 流）建立成功后，它需要通过 UPDATE 消息来通知对端其当前状态已满足期望。
- 资源建立成功：例如，主叫侧 P-CSCF 收到承载网（PCRF/PCF）资源建立成功的通知后。
- 发送 UPDATE：主叫 UA 发送
UPDATE请求，新的 SDP 净荷将更新a=curr:qos local sendrecv。这表示“我这边的 VIP 通道已经铺好了”。 - 对端确认：被叫 UA 收到
UPDATE后，如果其自身的资源也已就绪，将回复200 OK (for UPDATE)，携带最终的 SDP，确认资源同步。
只有当双方都确认 a=curr:qos local sendrecv 和 a=curr:qos remote sendrecv 时，会话才能继续进入振铃或接通阶段。
5. IMS 网元在媒体协商中的职责
IMS 核心网元，特别是 CSCF 和 AS，在媒体协商过程中扮演着资源控制和业务干预的角色。
5.1 P-CSCF/S-CSCF 对 SDP 的检查
P-CSCF 和 S-CSCF 作为 SIP 代理，需要对 SDP 负载进行检查，这主要是为了：
- 媒体授权：检查提议的编解码器是否符合运营商策略或用户签约。
- 安全：IMS 明确要求 UE 不能对 SDP 负载进行加密。
5.2 媒体协商与计费关联（ACR [Interim]）
媒体参数的变更，包括 SDP 的更新，会触发 IMS 计费更新：
- P-CSCF：P-CSCF 在收到来自终端的
reINVITE或UPDATE请求，并将请求发送到 S-CSCF 时，应在P-Charging-Vector头中包含更新过的access-network-charging-info参数。 - S-CSCF：S-CSCF 收到
reINVITE或UPDATE请求后，应保存更新了的P-Charging-Vector消息头里的access-network-charging-info参数，并在转发给 AS 时包含该参数。 - 计费触发：当 P-CSCF/S-CSCF 收到
UPDATE消息的200 OK响应后，会触发向 CDF 发送ACR [Interim]（中间计费请求）消息，用于通知计费系统会话属性（如媒体改变）发生了修改。
5.3 AS/MRF 在媒体流中的干预
应用服务器（AS）和多媒体资源功能（MRF）通过充当 B2BUA 角色，在媒体协商中进行关键干预：
- 呼叫保持（Call Hold）：AS 收到呼叫保持请求（reINVITE/UPDATE）时，会修改 SDP 的媒体流方向（如将
sendrecv改为sendonly或recvonly），并与 MRF 交互，申请播放保持音。 - 彩铃业务：彩铃 AS 在播放彩铃/彩振时，会在
183 Session Progress响应中插入 SDP Offer，将媒体地址指向 MRF，同时携带p-early-media头域。如果主叫终端回复的 SDP 视频媒体行端口变为 0，彩铃平台会提示被叫用户：视频通话将回落为语音通话。
6. 信令日志实战分析：UPDATE 资源同步
我们通过一个启用 Precondition 机制的呼叫流程片段，聚焦于 UPDATE 消息如何完成资源状态的同步。
场景： 主叫 UE（A）和被叫 UE（B）正在建立呼叫，主叫侧 QoS 资源已建立成功，通过 UPDATE 告知被叫侧。
6.1 初始 INVITE (Offer) 中的 SDP 描述（省略部分 SIP 头域）
主叫 UE 发送的 INVITE 携带了初始 SDP Offer，期望和当前状态如下：
INVITE sip:[email protected] SIP/2.0
Content-Type: application/sdp
...
a=rtpmap:97 EVS/16000/1
a=des:qos mandatory local sendrecv remote sendrecv // 期望双方资源就绪
a=curr:qos local none remote none // 当前双方资源均未就绪
6.2 UPDATE 请求：主叫侧资源就绪通知
当主叫侧的承载资源（QCI=1）建立完成后，主叫 UE 发送 UPDATE 请求，通知网络：
| 消息行/头域 | 示例值 | 关键作用分析 | 来源 |
|---|---|---|---|
| 请求行 | UPDATE sip:S-CSCF.home.net SIP/2.0 | 方法：UPDATE，用于会话属性修改。 | |
| CSeq | 3 UPDATE | 事务：独立的非 INVITE 事务。 | |
| SDP 属性 | a=curr:qos local sendrecv remote none | 状态更新：本地资源已从 none 变为 sendrecv，但远端（被叫侧）状态仍未知。 | |
| P-Charging-Vector | icid-value=...;access-network-charging-info=... | 计费更新：P-CSCF/S-CSCF 保存并转发更新了的承载计费信息。 | P-CSCF/S-CSCF |
6.3 UPDATE 200 OK 响应：被叫侧资源就绪确认
被叫侧 UE 收到 UPDATE 后，如果其本地资源也已建立成功，则返回 200 OK 响应：
| 消息行/头域 | 示例值 | 关键作用分析 | 来源 |
|---|---|---|---|
| 状态行 | SIP/2.0 200 OK | 事务：UPDATE 事务成功。 | |
| CSeq | 3 UPDATE | 匹配：确认针对 CSeq 3 的 UPDATE 请求。 | |
| SDP 属性 | a=curr:qos local sendrecv remote sendrecv | 最终状态：被叫侧确认本地资源就绪（local sendrecv），并确认主叫侧资源已就绪（remote sendrecv），双方资源同步完成。 |
后续流程： 一旦资源同步完成，呼叫将继续，最终通过 200 OK (for INVITE) 消息建立会话。
7. P-CSCF/S-CSCF 的容灾与 SIP 定时器
媒体协商和资源预留的可靠性依赖于底层信令链的可靠性，而 SIP 定时器（如 Timer B 和 Timer F）是确保可靠性的关键：
- P-CSCF 故障接管：在 P-CSCF 容灾场景中，如果终端发起
INVITE请求，但在 Timer B 定时器内没有收到 P-CSCF 的响应，终端将结束当前呼叫，当前呼叫失败，然后重新发起初始注册到备用 P-CSCF。 - 短信始呼容灾：如果终端发起短信始呼请求，但在 Timer F 定时器内没有收到 P-CSCF 的响应，终端会结束当前短信始呼，当前短信始呼失败，然后重新发起初始注册到备用 P-CSCF。
- UPDATE/reINVITE 响应：P-CSCF 对所有
reINVITE请求均应回送100 (Trying)响应。P-CSCF 也可以对reINVITE请求返回100 (Trying)临时响应。
8. 本章小结
IMS 媒体会话的建立由 SIP 和 SDP 协议协同完成：
- SDP 协议（Session Description Protocol）作为 SIP 的消息体，结构化地描述了媒体流的参数、编解码器和传输地址。
- Offer/Answer 模型 确定了通信双方都能接受的媒体参数。
- Precondition 机制 是 VoLTE/VoNR 保证电信级 QoS 的关键，它通过 SDP 属性 (
a=des,a=curr) 来同步资源预留状态。 PRACK/100rel确保了包含 SDP Answer 的183 Session Progress临时响应的可靠传输。UPDATE方法在资源预留成功后，用于通知对端资源状态的变更，并触发 P-CSCF/S-CSCF 对P-Charging-Vector中access-network-charging-info参数的更新，进而触发计费系统的ACR [Interim]消息。
工程师进阶思考 (FAQ)
Q1：P-CSCF 收到目标刷新请求（reINVITE/UPDATE）时，除了更新 Contact 地址和 CSeq 序列号外，为什么还需要更新 P-Charging-Vector 中的 access-network-charging-info 参数？
A1： P-CSCF/S-CSCF 更新 P-Charging-Vector 消息头中的 access-network-charging-info 参数是为了计费的准确性和会话上下文的完整性。目标刷新请求通常伴随着媒体参数的修改（如编解码器改变、媒体流方向改变）或移动性事件引起的底层承载信息变更（通过 PANI 间接体现）。
- 计费关联：S-CSCF 收到
reINVITE或UPDATE请求时，应保存更新了的P-Charging-Vector消息头里的access-network-charging-info参数，并在请求转发给 AS 时包含该参数。 - 触发中间计费：S-CSCF 和 P-CSCF 在收到
UPDATE或reINVITE的200 OK响应后，会向 CDF 发送ACR [Interim]消息。这个中间计费记录需要包含最新的会话信息，包括变更后的承载网络信息（如果适用）。
Q2：在 IMS 互通场景中，MGCF 接收到 INVITE 请求，若其中 Supported 头的值为 100rel 时，MGCF 在向 IMS 域发送 183 Session Progress 响应时，需要包含哪些关键的 P-Header 计费信息？
A2： 当 MGCF 收到 INVITE 且支持 100rel 时，它在向 IMS 域发送 183 Session Progress 响应时，必须执行计费信息的存储和插入操作：
- 存储信息：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 还必须在 183 Session Progress 中将 Require 头设成 100rel，确保可靠传输。
Q3：P-CSCF 收到发往 UE 的对话初始请求（MT INVITE）时，在转发 INVITE 请求前和收到响应后，会执行哪些 Via 列表相关的操作，以确保事务的可靠性？
A3： P-CSCF 在处理发往 UE 的请求（UE 终结的请求）时，执行严格的 Via 列表操作：
- 转发前（Request）：P-CSCF 必须将 P-CSCF 的地址填加到 Via 头域最顶端并保存该列表。
- 收到响应（Response）：P-CSCF 收到上述请求的任何响应（1xx 或 2xx）时，必须确认 Via 列表是否与同一对话的请求消息中保存的 Via 列表匹配。
- 异常处理：如果 Via 列表不匹配，P-CSCF 应该丢弃该响应，或者替换成保存的 Via 列表。
这些操作确保了 SIP 响应能够准确地沿着 Via 列表记录的路径返回，维护了信令事务的可靠性。
请您发出“请继续”指令，我将开始撰写第十篇。