<!-- title: VoNR主叫预条件与资源预留机制 -->
<!-- domain: ims -->

# VoNR主叫呼叫建立中的SDP预条件与资源预留机制全链拆解

> 本文聚焦 **3GPP TS 23.228（IMS Stage 2）** 的移动台主叫（MOC, Mobile Originated Call）会话发起流程，结合 **TS 24.229（基于SIP/SDP的IMS呼叫控制）** 的预条件（Precondition）处理、**RFC 3312/4032** 的资源管理集成框架，以及 **TS 23.503/TS 23.501** 中 P-CSCF 通过 Rx/N5 向 PCF 申请 QoS 授权的 PCC 机制，逐条消息拆解 VoNR 主叫从 INVITE 到 ACK 的完整信令链，重点解析为什么 VoNR 必须使用"预条件"机制、SDP offer/answer 中 `curr/des/conf` 三个属性的状态机含义，以及 SIP 层资源协商与 5G QoS Flow 建立的精确耦合点。

---

## 一、为什么VoNR必须使用预条件机制：设计意图溯源

很多协议工程师第一次接触 IMS 呼叫时都会产生一个疑问：**SIP 本身就是会话协商协议，为什么 3GPP 还要叠床架屋地引入一套"预条件"机制？** 这个问题的答案，恰恰揭示了移动通信语音业务与固定互联网语音的根本差异。

在固定互联网中，SIP 终端在 INVITE 中协商出编解码（codec）后，媒体就可以直接在已建立 IP 连通性的链路上发送——因为 IP 承载是"尽力而为"的，不存在"预留失败"的问题。但在移动网络中，语音媒体必须承载在**专用 GBR QoS Flow**（5G 中标准化 5QI=1，会话类语音，PDB=100ms，PER=10⁻²）上，而专用 QoS Flow 的建立是一个独立的、可能失败的过程：它需要 SMF 通过 N2 接口向 gNB 申请无线资源、需要 gNB 执行准入控制（Admission Control）、需要 UE 激活对应的专用 DRB。

如果把这两个过程解耦——先让被叫振铃、被叫接听，再去建立专用承载——就会出现一个致命问题：**用户已经"接通"，但专用承载建立失败，导致语音根本无法传递，用户体验是"接通即掉话、接通即静音"**。这在电信级语音服务中是不可接受的。

预条件机制（RFC 3312，由 RFC 4032 更新）的核心设计思想，就是把**"双向专用承载资源都已就绪"**作为一个**强制性前置条件（mandatory precondition）**，挂在 SDP 协商中。只有当主叫、被叫双方的本地资源都预留完成，会话才允许进入振铃（180 Ringing）和接通（200 OK）阶段。换句话说，预条件机制用 SIP 的会话状态机，把**承载资源预留的原子性**强制保证在了**用户感知层面之前**。

GSMA NG.114（VoNR IMS Profile）和早期的 IR.92（VoLTE IMS Profile）都把"预条件支持"列为**必选**能力。这也是为什么任何符合标准的 VoNR 终端，其 IMS 注册时都会在 SIP `Supported` 头域中声明 `precondition`，并在发起呼叫时默认采用 mandatory 预条件。

---

## 二、VoNR主叫端到端信令时序全链

下图是一条带双向 mandatory 预条件的 VoNR 主叫完整信令流。主叫 UE-A（发起方）与被叫 UE-B（终止方）各自经过"资源预留→UPDATE确认→振铃→接通"的标准节拍。

```mermaid
sequenceDiagram
    autonumber
    participant UE_A as 主叫 UE-A
    participant PCSCF_A as P-CSCF-A
    participant SCSCF as S-CSCF / I-CSCF
    participant PCSCF_B as P-CSCF-B
    participant UE_B as 被叫 UE-B

    Note over UE_A,UE_B: 阶段1：初始 INVITE 携带 SDP Offer（预条件未满足）
    UE_A->>PCSCF_A: INVITE (SDP Offer)<br/>curr:qos none / des:qos mandatory sendrecv
    PCSCF_A->>SCSCF: INVITE (前转, 并向 PCF 发 AAR 申请 QoS 授权)
    SCSCF->>PCSCF_B: INVITE
    PCSCF_B->>UE_B: INVITE

    Note over UE_A,UE_B: 阶段2：被叫回 183 Session Progress 携带 SDP Answer
    UE_B-->>PCSCF_B: 183 Session Progress (SDP Answer)<br/>des mandatory + conf:qos remote sendrecv
    PCSCF_B-->>SCSCF: 183
    SCSCF-->>PCSCF_A: 183 (PCSCF_A 向 PCF 发 AAR, 触发 UE-A 侧专用 QoS Flow 建立)
    PCSCF_A-->>UE_A: 183 Session Progress

    Note over UE_A,UE_B: 阶段3：可靠传送 183（100rel）+ 本地资源预留
    UE_A->>PCSCF_A: PRACK (确认 183)
    PCSCF_A->>SCSCF: PRACK
    SCSCF->>PCSCF_B: PRACK
    PCSCF_B->>UE_B: PRACK
    UE_B-->>UE_A: 200 OK (PRACK) 逐跳回传

    Note over UE_A,UE_B: 阶段4：UE-A 本地专用承载建立完成，发 UPDATE
    UE_A->>PCSCF_A: UPDATE (curr:qos local sendrecv)
    PCSCF_A->>SCSCF: UPDATE
    SCSCF->>PCSCF_B: UPDATE
    PCSCF_B->>UE_B: UPDATE

    Note over UE_A,UE_B: 阶段5：UE-B 本地承载建立完成，回 200(UPDATE)，双向预条件全部满足
    UE_B-->>PCSCF_B: 200 OK (UPDATE) (curr:qos local+remote sendrecv)
    PCSCF_B-->>SCSCF: 200 OK (UPDATE)
    SCSCF-->>PCSCF_A: 200 OK (UPDATE)
    PCSCF_A-->>UE_A: 200 OK (UPDATE)

    Note over UE_A,UE_B: 阶段6：预条件已满足，被叫安全振铃
    UE_B-->>UE_A: 180 Ringing (逐跳前转)
    Note over UE_B: 用户摘机应答
    UE_B-->>UE_A: 200 OK (INVITE)
    UE_A->>UE_B: ACK (双向媒体通路开启)
```

需要特别强调的三个关键节点：

1. **第 2 步（INVITE）**：主叫 UE-A 发送的 SDP Offer 中，`a=curr:qos` 全部为 `none`，`a=des:qos` 为 `mandatory`。这表示"我要求资源预留是强制性的，但现在双方资源都还没就绪"，因此**媒体通路方向此时是被挂起的**。
2. **第 4 步（UPDATE）**：UE-A 的本地专用承载（5QI=1 GBR QoS Flow）建立完成后，UE-A 主动发送 UPDATE，把 `a=curr:qos local` 翻成 `sendrecv`，向被叫宣告"我这边资源好了"。
3. **第 5 步（200 OK UPDATE）**：被叫 UE-B 在自己的本地承载也建立完成后回 200，把 `a=curr:qos remote` 也翻成 `sendrecv`。此时**四个预条件维度（local/remote × send/recv）全部满足**，被叫才允许进入第 6 步的振铃。

---

## 三、SDP Offer/Answer 与预条件三件套逐项拆解

预条件机制的全部精髓，都浓缩在 SDP 的三个属性行里。下面是一条真实的 VoNR 主叫 INVITE 中 SDP Offer 的核心片段（节选自 TS 24.229 5.1.2.2 与 RFC 3312 第 5 节）：

```text
v=0
o=- 4568 4568 IN IP4 10.20.30.40
s=-
c=IN IP4 10.20.30.40
t=0 0
m=audio 49170 RTP/AVP 97 96
b=AS:41
b=RS:600
b=RR:2000
a=rtpmap:97 EVS/16000
a=fmtp:97 br=5.9-24.4; bw=nb-wb; max-red=220
a=rtpmap:96 AMR-WB/16000
a=fmtp:96 mode-change-capability=2; max-red=0
a=ptime:20
a=maxptime:240
a=sendrecv
a=curr:qos local none
a=curr:qos remote none
a=des:qos mandatory local sendrecv
a=des:qos mandatory remote sendrecv
```

### 3.1 预条件三个属性的状态机语义

RFC 3312 定义了三类预条件属性，每个属性都有 **类型（type）+ 强度（strength）+ 方向（direction）** 三元组结构：

| SDP 属性行 | 语义 | 典型取值 | 作用阶段 |
|-----------|------|---------|---------|
| `a=curr:qos <dir> <status>` | **当前状态**：本端当前观察到的资源预留进度 | `curr:qos local none` → `curr:qos local sendrecv` | 每次 SDP 交换都更新 |
| `a=des:qos <strength> <dir> <status>` | **期望状态**：要求达到的目标，决定是否阻塞会话 | `des:qos mandatory local sendrecv` | Offer/Answer 中声明 |
| `a=conf:qos <dir> <status>` | **确认请求**：要求对端在满足时主动通知我 | `conf:qos remote sendrecv` | 触发对端发 UPDATE |

**strength（强度）的三档**决定了会话是否被阻塞：
- `mandatory`：必须满足，否则媒体方向被挂起（VoNR 默认采用此档）。
- `optional`：尽力满足，不阻塞媒体方向。
- `none`：不要求（用于取消预条件）。

**direction（方向标签）**是一个**状态标记**，不要和媒体方向 `sendrecv` 混淆。`curr:qos local sendrecv` 的正确读法是："我本地（local）这一侧的资源，在发送（send）和接收（recv）两个方向上都已经预留完成（sendrecv 状态）"。

### 3.2 local/remote 视角的相对性（最易踩坑点）

预条件属性总是**从产生该 SDP 的一方视角**来表述的：
- **UE-A 说的 `local`** = UE-A 自己接入侧的资源；UE-A 说的 `remote` = UE-B 接入侧的资源。
- **UE-B 说的 `local`** = UE-B 自己接入侧的资源；UE-B 说的 `remote` = UE-A 接入侧的资源。

这就产生了一个镜像关系：**UE-A 的 `local` == UE-B 的 `remote`**。所以当 UE-A 发 UPDATE 把自己 `curr:qos local` 置为 `sendrecv` 时，UE-B 收到后会把**自己视角下的 `remote`** 视为已满足。这种相对视角的交叉确认，正是双向预条件得以收敛的核心机制。

### 3.3 预条件状态机收敛过程

下面用状态图刻画四个维度（local/remote × send/recv）从 `none` 收敛到 `sendrecv` 的全过程：

```mermaid
stateDiagram-v2
    [*] --> 两侧均为none: INVITE Offer<br/>curr local none<br/>curr remote none
    两侧均为none --> A_local满足: UE-A 专用承载建立<br/>发 UPDATE (curr local sendrecv)
    A_local满足 --> A_local_B_remote同时满足: UE-B 收 UPDATE<br/>B 的 remote 自动满足
    A_local满足 --> B_local满足: UE-B 本地承载建立
    A_local_B_remote同时满足 --> 全部满足: UE-B 回 200(UPDATE)<br/>curr local+remote sendrecv
    B_local满足 --> 全部满足: UE-A 的 remote 满足
    全部满足 --> 振铃: 180 Ringing 被允许前转
    振铃 --> [*]: 200 OK (INVITE) + ACK<br/>双向媒体开启
```

---

## 四、SIP 层预条件与 5G 承载建立的精确耦合：P-CSCF 的 Rx/N5 角色

理解了 SDP 层的状态机，下一个关键问题是：**UE 怎么知道"本地资源预留完成"？** 在 5G VoNR 架构下，这个"完成"信号来自 SMF 通过 N1 接口给 UE 下发的 **PDU Session Modification Command**（TS 23.502 Section 4.3.3.3），其中激活了承载语音媒体的专用 QoS Flow（5QI=1）。而触发这条修改流程的源头，正是 **P-CSCF 通过 Rx/N5 接口向 PCF 申请的 QoS 授权**。

下图刻画了从 SIP 信令到 5G 无线资源建立的完整数据面/控制面耦合链路：

```mermaid
flowchart TD
    subgraph SIP["IMS 信令域 (SIP/SDP)"]
        UE1["UE-A"]
        PCSCF["P-CSCF\n(SDP 解析)"]
    end
    subgraph PCC["策略与计费控制 (PCC)"]
        PCF["PCF\n(Rx/N5 + N7)"]
        SMF["SMF\n(会话管理)"]
    end
    subgraph DPR["5G 数据面与无线"]
        UPF["UPF\n(N3/N9)"]
        gNB["gNB\n(DRB)"]
        UE2["UE-A 专用承载"]
    end

    UE1 -->|"INVITE/183\n携带 SDP"| PCSCF
    PCSCF -->|"AAR (Rx) / Npcf_PolicyAuthorization (N5)\n提取 media component"| PCF
    PCF -->|"N7 SM Policy Association\n下发 PCC rule (5QI=1, GBR)"| SMF
    SMF -->|"N4\n建立/修改 N3/N9 隧道"| UPF
    SMF -->|"N2 PDU Session Resource Setup\n(Ngap PDU Session Resource Setup Item)"| gNB
    SMF -->|"N1 QoS rule 激活\n(5QI=1)"| UE2
    gNB --> UE2
    UE2 -.->|"检测到本地专用承载激活\n触发 SIP UPDATE"| UE1
```

### 4.1 P-CSCF 的工作机制（TS 23.228 + TS 23.503）

P-CSCF 在收到 INVITE/183 携带的 SDP 后，并不只是简单前转，它要执行一项关键的**策略触发**动作：

1. **解析 SDP media 描述**：从 `m=` 行和 `c=` 行提取媒体类型（audio/video）、IP 五元组（源/目的 IP、端口）、编解码、带宽（`b=AS/RS/RR`）。
2. **构造 AAR（AA-Request, Diameter）**：在 4G 中走 Rx 接口；在 5G SBA 架构中，等价的 Npcf_PolicyAuthorization 服务通过 **N5** 参考点提供。AAR 携带 `Media-Component-Description` AVP，把媒体组件、`Flow-Status`、请求的 QoS（5QI=1、ARP、GBR/MBR）提交给 PCF。
3. **PCF 授权并下发 PCC Rule**：PCF 根据 SDP 授权 QoS 参数，通过 **N7（SM Policy Association Modification）** 把 PCC Rule 发给 SMF。这一步对应 TS 23.502 的"Policy Control Request trigger"。
4. **SMF 触发 PDU 会话修改**：SMF 通过 N4 向 UPF 建立/修改 N3 隧道，通过 N2 向 gNB 请求 PDU Session Resource Setup（无线侧建立专用 DRB），并通过 N1 向 UE 下发 QoS rule 激活专用 QoS Flow。
5. **UE-A 检测到承载激活**：当 UE-A 收到并确认 5QI=1 的专用 QoS Flow 已激活（对应 NAS `PDU Session Modification Command` 中相关 QoS rule 状态变更为 active），UE-A 判定**本地资源预留完成**，于是主动构造并发送 SIP **UPDATE**，把 `curr:qos local` 翻成 `sendrecv`。

这条耦合链路解释了一个极其重要的工程事实：**SIP UPDATE 的发送时机，完全由 5G 无线专用承载的建立速度决定**。在无线条件差、gNB 准入失败或 PCF 授权延迟的场景下，UPDATE 会被显著推迟，甚至触发预条件超时导致呼叫失败。

### 4.2 5QI=1 的 QoS 参数（TS 23.501 Table 5.7.4-1）

| 参数 | 取值 | 说明 |
|------|------|------|
| 标准化 5QI | 1 | 会话类语音（Conversational Voice） |
| 资源类型 | GBR | 保证比特率，需准入控制 |
| 优先级（Priority Level） | 20 | 较高优先级 |
| PDB（包延迟预算） | 100 ms | 端到端时延预算 |
| PER（包错误率） | 10⁻² | 语音可容忍 1% 丢包 |
| 默认平均窗口 | 2000 ms | GBR 测量窗口 |
| 典型 GBR | 约 5.9 kbps (AMR-WB) / 9.6~24.4 kbps (EVS) | 取决于协商的 EVS 模式 |

---

## 五、抓包识别与实战排错

### 5.1 Wireshark 中的识别方法

在抓包分析 VoNR 呼叫时，可以用如下显示过滤器快速定位关键消息：

- `sip.Method == "INVITE"` — 定位主叫发起
- `sip.Status-Code == 183` — 定位带 SDP Answer 的 Session Progress
- `sip.Method == "UPDATE"` — 定位预条件完成的标志消息
- `sip.Status-Code == 180` — 定位振铃
- `sdp.media.type == "audio"` 且 `sdp.attribute == "curr"` — 查看 `curr/des/conf` 行

一个健康的 VoNR 主叫，在 INVITE 与 180 Ringing 之间**必然存在一次 UPDATE 与 200(UPDATE) 交互**。如果抓包中 INVITE 之后直接出现 180 Ringing 而没有任何 UPDATE，基本可以判定预条件机制未启用（这在标准 VoNR 终端上属于异常）。

### 5.2 常见故障点与排错思路

| 故障现象 | 可能根因 | 排错切入点 |
|---------|---------|-----------|
| UPDATE 迟迟不发，呼叫卡在 183 | UE-A 专用承载未建立（PCF/SMF/N2 失败） | 查 Rx AAR 是否成功、N7 PCC Rule 是否下发、N2 是否失败（如 gNB 准入拒绝） |
| 183 后被叫直接 180，无 UPDATE | 预条件 capability 协商失败，UE 未启用 mandatory | 检查 Supported/Require 头域是否含 `precondition`；检查 IMS 注册时的协商参数 |
| 被叫 180 Ringing 未前转给主叫 | 早期媒体（Early Media）与 P-Early-Media 策略阻断 | 检查 P-CSCF 的 P-Early-Media 处理、180 是否被 PRACK 之外的策略拦截 |
| 双方 UPDATE 都发了但呼叫失败 | 预条件状态机未收敛（curr 与 des 方向不匹配） | 逐条比对双方 SDP 的 `curr/des` 方向标签，常见为 send/recv 方向写反 |
| 媒体单向通 | 仅一方向 des mandatory，另一方向 optional | 检查 offer/answer 中双方 des 方向是否对称为 sendrecv |

---
## 常见问题

**Q1：预条件机制（precondition）和 100rel（可靠临时响应）是一回事吗？**
A：不是。`precondition`（RFC 3312）解决的是"资源预留与媒体通路的同步"问题；`100rel`（RFC 3262，可靠传送 1xx 临时响应）解决的是"183 Session Progress 必须被可靠确认"的问题。两者在 VoNR 中**必须同时启用**：预条件机制依赖 183 携带 SDP Answer，而 183 的可靠传送又依赖 100rel（通过 PRACK 确认）。两者的交集体现在 Supported/Require 头域中同时出现 `precondition` 与 `100rel`。

**Q2：主叫和被叫都必须支持预条件吗？有一方不支持怎么办？**
A：是的，标准 VoNR 主被叫都应支持预条件（NG.114 强制要求）。在 offer/answer 协商时，若一方在 INVITE 中 `Require: precondition` 而另一方不支持，会直接返回 420 Bad Extension 拒绝。若双方都未声明 mandatory，则降级为"无预条件"呼叫——这在 5G VoNR 中属异常配置，应避免。

**Q3：UPDATE 消息在 RFC 3311 和预条件中扮演什么角色？**
A：UPDATE（RFC 3311）用于在 INVITE 尚未最终确认（200 OK/ACK 之前）阶段更新会话参数。在预条件机制中，UPDATE 的**唯一职责**是携带更新后的 SDP，通告 `curr:qos` 的状态翻转。它和 PRACK 不同：PRACK 确认 183，UPDATE 通告资源状态，两者在流程中先后出现、各司其职。

**Q4：为什么是 UE 主动发 UPDATE，而不是网络发？**
A：因为"本地资源预留完成"这个事件，只有 UE 自己能最准确地感知——5G 中 UE 通过 NAS `PDU Session Modification Command` 确认 5QI=1 QoS Flow 激活，网络侧（P-CSCF/SMF）并不直接驱动 SIP 层。这种设计保证了 SIP 层状态机与 UE 承载状态的一致性，也符合端到端协商原则。

**Q5：VoNR 的预条件和 VoLTE 有本质区别吗？**
A：机制层面完全一致，都基于 RFC 3312/4032。差异仅在承载层：VoLTE 触发的是 EPC 的专用 EPS Bearer（QCI=1）建立（通过 P-CSCF→PCRF 的 Gx/Rx）；VoNR 触发的是 5GS 的专用 QoS Flow（5QI=1）建立（通过 P-CSCF→PCF 的 N5 + N7）。SDP 层的 `curr/des/conf` 状态机、UPDATE 收敛逻辑完全相同，这是 3GPP 有意保持的 IMS 控制面与承载面解耦的延续。

---

## 参考来源

1. [3GPP TS 23.228 V18.x.x — IP Multimedia Subsystem (IMS) Stage 2](https://www.3gpp.org/dynareport/23228.htm) — Clause 5.2.2.3 移动台主叫会话发起流程、Clause 5.7 P-CSCF 与 Gm 接口
2. [3GPP TS 24.229 V18.x.x — IP multimedia call control protocol based on SIP and SDP](https://www.3gpp.org/dynareport/24229.htm) — Clause 5.1.2.2 主叫流程、Clause 5.1.3 预条件（Precondition）处理
3. [RFC 3312 — Integration of Resource Management and Session Initiation Protocol (SIP)](https://datatracker.ietf.org/doc/html/rfc3312) — 预条件框架定义；RFC 4032（更新）；RFC 5027（安全预条件）
4. [3GPP TS 23.503 V18.x.x — Policy and Charging Control Framework](https://www.3gpp.org/dynareport/23503.htm) — Rx/N5 接口、PCC Rule、PCF 与 SMF 的 N7 交互
5. [3GPP TS 23.501 V18.x.x — System Architecture for the 5G System](https://www.3gpp.org/dynareport/23501.htm) — Table 5.7.4-1 标准化 5QI（5QI=1 会话语音）；TS 23.502 Clause 4.3.3.3 PDU Session Modification

---
> 本文由「51学通信」技术团队出品。51学通信由通信行业18年老兵**爱卫生**（微信ID: gprshome201101）维护，聚焦5G/6G核心网、3GPP标准解读、通信前沿技术深度分析。
> 出版作品有《5G核心网原理与实践》《IMS原理与实践》等4本通信专业书籍。知识星球「51学通信」提供深度技术答疑和行业洞察。

> [!tip] 51学通信知识星球
> **星主：爱卫生**（微信：gprshome201101）——公众号「51学通信」创办者，19 年通信行业运维与讲师经验，著有《GPRS网络信令实例详解》《EPC原理与实践》《5G核心网原理与实践》三本纸质书（各大电商平台有售）。
> **星球定位**：深耕 5G 核心网、IMS、NFV/AI、云原生等 ICT 领域，主打运维岗位与信令分析。
> **当前规模**：5200 篇主题 / 990 个回答，198 元/年。
> **加入福利**：加入星球后请加爱卫生微信，拉您进知识星球年度陪伴与答疑群——不限量回复您的各种问题，另有群内分享。
> **AI 加持**：51学通信知识星球已作为 skill 接入 WorkBuddy，使用 deepseek-4-flash 在海量星球帖子中精准找贴、找视频、找 FAQ 和案例，做总结、找文档和 PPT 等场景全覆盖。

![51学通信知识星球海报-扫码加入](https://wiki.500nian.com/images/zhixingqiu_qrcode.png)