VoNR（Voice over NR）的本质，是把 IMS 域的 SIP/SDP 会话控制层完整地搬到 5G NR 之上。从协议角度，VoNR 与 VoLTE 在 IMS 信令层面几乎完全同构——同样遵循 3GPP TS 23.228（IMS Stage 2）的会话建立流程、TS 24.229 的 SIP/SDP 编解码规则、TS 26.114 的 MTSI 媒体处理要求。真正的差异不在 SIP，而在底层承载：VoLTE 走 EPS 的专用承载（PCRF→PGW，Rx→Gx），VoNR 走 5G 的专用 QoS Flow（PCF→SMF→UPF，Rx→N7/N4），语音媒体用 5QI=1 的 GBR 承载。
语音是会话型实时业务，对端到端时延（PDB=100ms）和丢包极度敏感。这就引出一个根本性设计问题：如果允许 SIP 信令先把被叫"振铃→摘机"走完，再去网络里抢无线资源建承载，会出现两类灾难性故障——
因此 3GPP/IMS 的设计哲学是：把"会话协商"（SIP/SDP 协商编解码、IP/端口、QoS 需求）与"资源预留"（专用承载建立）解耦，并让前者"门控"后者——只有当双方都成功预留了专用资源，被叫才允许振铃、主叫才允许应答。这套"门控"机制，就是 RFC 3312 定义的 SDP precondition（前置条件）机制，并被 TS 26.114（MTSI）规定为 VoLTE/VoNR 的默认强制行为（GSMA IR.92 / IR.93 profile）。
本文聚焦 TS 23.228 clause 5.2.2.1 的移动主叫（MO, Mobile Originated）IMS 会话建立流程，逐消息拆解 SIP INVITE 全链信令、SDP precondition 的 IE 结构与状态机、以及与 5G 专用 QoS Flow 的 Rx/N7 联动。
下面给出一次完整的 VoNR 主叫（UE-A）→ 被叫（UE-B）会话建立信令，覆盖 precondition 的"offer→answer→UPDATE 确认"三阶段。本流程对应 TS 23.228 §5.2.2.1（Origination）与 §5.2.2.2（Termination），precondition 的可靠性由 RFC 3262（100rel/PRACK）和 RFC 3311（UPDATE）共同保障。
sequenceDiagram
autonumber
participant A as UE-A (主叫)
participant PA as P-CSCF-A
participant SA as S-CSCF-A
participant IB as I-CSCF-B
participant SB as S-CSCF-B
participant PB as P-CSCF-B
participant B as UE-B (被叫)
participant PCF as PCF/SMF (5G承载)
A->>PA: INVITE (SDP offer, EVS, precond:none→des:mandatory)
Note over PA,PCF: Rx AAR→PCF，发起主叫专用QoS Flow(5QI=1)预留
PA->>SA: INVITE (Route含S-CSCF)
SA->>IB: INVITE (按被叫域名查询)
IB->>SB: INVITE (Cx LIR/LIA定位)
SB->>PB: INVITE
PB->>B: INVITE
PA-->>A: 100 Trying (逐跳,抑制重传)
Note over B,PCF: 被叫侧Rx→PCF发起QoS Flow预留
B-->>A: 183 Session Progress (SDP answer, precond未满足, Require:100rel)
A->>B: PRACK (对183可靠确认)
B-->>A: 200 OK (PRACK)
Note over A,PCF: 主叫专用承载建立完成→local precond达成
A->>B: UPDATE (SDP: curr local sendrecv)
Note over B,PCF: 被叫专用承载建立完成→remote precond达成
B-->>A: 200 OK (UPDATE) (curr remote sendrecv→前置条件全部满足)
B-->>A: 180 Ringing (Require:100rel)
A->>B: PRACK (对180)
B-->>A: 200 OK (PRACK)
Note over B: 被叫摘机
B-->>A: 200 OK (INVITE)
A->>B: ACK
Note over A,B: 双向媒体在5QI=1 GBR承载上建立
① INVITE（初始 offer）：UE-A 构造初始 SDP offer，包含：
- m=audio 行给出媒体端口与 RTP payload type 列表（首选 EVS，回退 telephone-event）；
- a=rtpmap/a=fmtp 描述 EVS 编解码能力集（TS 26.445）；
- 一组 precondition 属性：a=curr:qos local none、a=curr:qos remote none、a=des:qos mandatory local sendrecv、a=des:qos mandatory remote sendrecv、a=conf:qos remote sendrecv；
- Route 头：携带注册时通过 Service-Route 学到的 P-CSCF、S-CSCF 地址（Route: <sip:pcscf.home.net;lr>、Route: <sip:[email protected];lr>）。
② 100 Trying：逐跳（hop-by-hop）临时响应，仅用于抑制 INVITE 重传，不携带 SDP，不端到端转发。这点与 183/180 不同，是抓包定位时最易混淆之处。
③ 183 Session Progress：被叫 UE-B 回送 SDP answer，确认编解码（EVS）、确认 precondition 为 mandatory，但 curr 仍为 none（资源尚未预留）。由于含 Require: 100rel，183 必须被可靠传送。
④⑤ PRACK / 200 OK(PRACK)：RFC 3262 对 183 的可靠确认。PRACK 自身也可携带更新 SDP（用于能力二次协商），但 precondition 的"达成"更新通常走 UPDATE。
⑥ UPDATE：主叫侧专用承载建好后，UE-A 用 UPDATE 携带更新 SDP，把 a=curr:qos local sendrecv 置位，表示本端 QoS 已达成。UPDATE 是 RFC 3311 定义的、在初始 INVITE 尚未 200 OK 之前修改会话参数的唯一合法手段（re-INVITE 只能在 dialog 建立后使用）。
⑦ 200 OK(UPDATE)：被叫侧承载也建好后回送，a=curr:qos remote sendrecv 置位。至此 local + remote 的 curr 全部 ≥ des，precondition 全部满足。
⑧ 180 Ringing：前置条件满足后，被叫才振铃，并带 Require: 100rel。
⑨ 200 OK(INVITE) + ACK：被叫摘机，会话建立，双向语音在 5QI=1 GBR 承载上流通。
precondition 机制的核心，是在 SDP 中嵌入三类属性，分别描述"当前状态""期望状态""确认请求"，由 RFC 3312 定义、TS 26.114 第 7 章对 MTSI 客户端给出强制要求。
| SDP 属性 | 含义 | 取值/示例 | 作用 |
|---|---|---|---|
a=curr:qos <dir> <status> |
当前 QoS 状态 | dir=local/remote；status=none/send/recv/sendrecv |
标识本端或对端当前已达到的资源状态 |
a=des:qos <strength> <dir> <status> |
期望 QoS 状态（目标） | strength=mandatory/optional；示例 mandatory local sendrecv |
定义为达成呼叫必须满足的目标，带强度标签 |
a=conf:qos <dir> <status> |
确认请求 | a=conf:qos remote sendrecv |
请求对端在达成 precondition 时主动通知本端（触发 UPDATE） |
| precondition 类型 | QoS 类前置条件 | 默认 qos（IANA 注册，见 RFC 4032） |
区分资源类与其他类前置条件 |
m=audio 50000 RTP/AVP 100 101
a=rtpmap:100 EVS/16000
a=fmtp:100 br=5.9-24.4; bw=nb-wb; dt=0; header=full
a=rtpmap:101 telephone-event/8000
a=sendrecv
a=ptime:20
a=maxptime:240
b=AS:88
a=curr:qos local none
a=curr:qos remote none
a=des:qos mandatory local sendrecv
a=des:qos mandatory remote sendrecv
a=conf:qos remote sendrecv
主叫在 offer 中把 local/remote 的 curr 都置 none，desired 都设为 mandatory sendrecv，并通过 a=conf:qos remote sendrecv 请求"被叫一旦完成资源预留，立即通知我"——这正是触发被叫回送 UPDATE/200OK 的钩子。
flowchart TD
S0[Offer/Answer交换完成<br/>curr local=none, remote=none] --> S1{各端并行预留专用承载}
S1 --> S2[主叫侧承载建立<br/>curr local=sendrecv]
S1 --> S3[被叫侧承载建立<br/>curr remote=sendrecv]
S2 -->|UPDATE 携带 curr local=sendrecv| S4{curr≥des 全部满足?}
S3 -->|200 OK UPDATE 携带 curr remote=sendrecv| S4
S4 -- 否 --> S5[保持等待, 不振铃<br/>超时则失败]
S4 -- 是 --> S6[前置条件达成<br/>允许 180 Ringing]
S6 --> S7[被叫摘机 → 200 OK → ACK → 媒体流通]
判定规则可形式化为：当且仅当对所有方向（local+remote）、所有流，curr 的状态集合 ⊇ des 要求的集合，且 mandatory 项全部达成，前置条件视为"满足"。optional 强度的项即使未达成也允许放行。
precondition 不是 SIP 层自说自话——它的 curr 状态由真实存在的专用承载支撑。在 VoNR 中，这个"真实资源"就是 5G 的 5QI=1 专用 QoS Flow，由 P-CSCF 通过 Rx 接口（TS 29.214）向 PCF 触发。
sequenceDiagram
autonumber
participant UE as UE
participant PCSCF as P-CSCF
participant PCF as PCF (Npcf)
participant SMF as SMF
participant UPF as UPF
participant NB as gNB
UE->>PCSCF: SIP INVITE (SDP含媒体描述+QoS需求)
PCSCF->>PCF: Diameter AAR (Rx)<br/>Media-Component/Flow-Description/<br/>Media-Sub-Component, 5QI=1, MBR/GBR
PCF->>SMF: 安装/更新PCC规则 (Npcf_SMPolicyControl, N7)
SMF->>UPF: N4 会话修改 (安装包检测/QoS执行规则)
SMF->>NB: PDU Session Resource Setup (N2)
NB->>UE: RRC Reconfiguration + NAS QoS规则分配
NB-->>SMF: PDU Session Resource Setup Response
SMF-->>PCF: 承载建立结果
PCF-->>PCSCF: RAR 通知资源已预留 (Rx)
Note over PCSCF,UE: curr local/remote 可置 sendrecv<br/>→驱动 UPDATE 完成 precondition
关键 IE 与参数：
AF-Application-Identifier（IMS 语音）、Media-Type（audio）、Flow-Description（IP 5 元组：源/目 IP、端口、协议 UDP）、Codec-Data（EVS）、Requested-QoS（5QI=1、上行/下行 MBR 与 GBR）。curr 永远无法置位，precondition 无法满足，呼叫干净失败而非带病接通。这就是 precondition 设计的根本收益：让"资源不足"在振铃前暴露，而不是在通话中暴露。
| 关注点 | Wireshark 过滤/方法 | 判读依据 |
|---|---|---|
| INVITE 与状态码 | sip.Method == "INVITE"、sip.Status-Code == 183 |
183 携带 SDP answer，100 Trying 不携带 |
| 编解码协商 | 展开 SDP m=audio、a=rtpmap、a=fmtp |
确认 EVS payload type 与能力集是否匹配 |
| precondition | 在 SDP 中搜 curr:qos/des:qos/conf:qos |
mandatory + local/remote sendrecv 即 VoNR 标准画像 |
| 路由信息 | 查看 Route、Via、Record-Route 头 |
校验 P-CSCF/S-CSCF/I-CSCF 寻址是否符合注册期 Service-Route |
| 承载联动 | 抓 NGAP PDU Session Resource Setup、N4、或 Diameter AAR/RAR |
确认专用 QoS Flow 是否成功建立 |
| RTCP/AVPF | sdp.media、a=tcap/a=pcfg（SDP 能力协商 RFC 5939） |
MTSI 使用 RTP/AVPF 做 RTCP 反馈 |
Call-ID+From tag+To tag（Dialog 标识）正确关联，避免 SDP answer 错配。| 维度 | VoNR（5G IMS） | VoLTE（EPS IMS） | 无 precondition（best-effort） |
|---|---|---|---|
| IMS 信令规范 | TS 23.228 + TS 24.229（相同） | TS 23.228 + TS 24.229 | TS 23.228（可选） |
| 承载建立 | 5G QoS Flow, 5QI=1, PCF→SMF→UPF (Rx→N7/N4) | EPS 专用承载, QCI=1, PCRF→PGW (Rx→Gx) | 走默认 best-effort 承载 |
| 资源保障 | GBR，PDB 100ms | GBR，PDB 100ms | 无 GBR 保证 |
| 振铃门控 | 强制 mandatory precondition（IR.93） | 强制（IR.92） | 无门控，可能先振铃后建路 |
| 起呼体验 | 起呼即双向清晰 | 起呼即双向清晰 | 易出现"喂喂听不见" |
Q1：VoNR 和 VoLTE 在 IMS 信令上到底有什么区别？ A：几乎无区别。两者都用 TS 23.228 的会话建立流程和 TS 24.229 的 SIP/SDP 规则，编解码都用 EVS。区别在承载：VoNR 用 5G 专用 QoS Flow（5QI=1）经 PCF/SMF/UPF，VoLTE 用 EPS 专用承载经 PCRF/PGW；媒体一个走 NR 空口，一个走 LTE 空口。
Q2：183 为什么一定要 PRACK？
A：183 携带 SDP answer，是后续资源预留与 precondition 协商的关键依据。若不可靠传送，183 丢失将使整个流程停滞。RFC 3262 的 100rel 机制（Require: 100rel）强制对端用 PRACK 确认，保证关键临时响应可靠到达。
Q3：为什么用 UPDATE 而不是 re-INVITE？ A：precondition 的状态更新发生在初始 INVITE 尚未被 200 OK/ACK 确认之前。re-INVITE 只能在已建立的 dialog 中使用，此时根本不可用。RFC 3311 的 UPDATE 是早期会话内修改参数的唯一合法手段。
Q4：空口无法接纳 GBR 承载时会怎样？
A：gNB 接纳控制拒绝该 QoS Flow，经 SMF→PCF→Rx 上报至 P-CSCF，导致 curr 无法置位、precondition 无法满足，呼叫干净失败（如超时或 503），而非带病接通。这正是 precondition 的价值——把"资源不足"暴露在振铃之前。
Q5：mandatory 和 optional precondition 的区别？ A：mandatory（强制）：在 QoS 未预留前，被叫不得振铃、主叫不得应答，是 VoLTE/VoNR 默认配置；optional（可选）：尽力而为，呼叫照常推进，资源未就绪也不阻断。两者可混合使用，但对语音默认用 mandatory。
本文由「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 等场景全覆盖。