VoNR（Voice over New Radio）是5G NR的原生语音方案，其呼叫建立依赖IMS SIP信令与5GC QoS Flow的紧密配合。一个核心问题摆在协议设计者面前：被叫振铃（180 Ringing）时，语音承载是否已就绪？
如果没有Preconditions机制，以下场景将频繁发生：
RFC 3312（Updated by RFC 4032）定义了SIP Preconditions框架，核心思想极其简洁：
不要在资源未就绪时通知用户。 网络资源预留必须在被叫振铃之前完成。
3GPP TS 24.229 Section 5.1.3.1（MO呼叫）和 Section 5.1.4.1（MT呼叫）将这一框架强制引入IMS语音呼叫：
"The preconditions mechanism should be supported by the terminating UE."
GSMA IR.92（IMS Profile for Voice and SMS）进一步规定：
"The UE must support the SIP preconditions framework, as specified in 3GPP TS 24.229."
RFC 3312定义了三组SDP属性（a=行），构成了Preconditions的状态机：
current-status = "a=curr:" precondition-type SP status-type SP direction-tag
desired-status = "a=des:" precondition-type SP strength-tag SP status-type SP direction-tag
confirm-status = "a=conf:" precondition-type SP status-type SP direction-tag
| 参数 | 取值范围 | 语义 |
|---|---|---|
| precondition-type | qos / token |
预留条件类型，VoNR固定使用qos |
| strength-tag | mandatory / optional / none / failure / unknown |
条件强度——mandatory表示必须满足 |
| status-type | e2e / local / remote |
状态视角——local为本端，remote为对端 |
| direction-tag | none / send / recv / sendrecv |
方向性——sendrecv表示双向资源已预留 |
Preconditions的满足判断遵循方向tag的包含关系：
sendrecv >= send
sendrecv >= recv
send >= none
recv >= none
sendrecv >= sendrecv
当 a=curr:qos local sendrecv >= a=des:qos mandatory local sendrecv 成立时，本端QoS条件满足。
stateDiagram-v2
[*] --> None: INVITE发送
None --> LocalReady: 主叫专用QoS Flow建立
LocalReady --> BothReady: 被叫专用QoS Flow建立
BothReady --> [*]: 180 Ringing可发送
state None {
note right of None: curr:qos local none\ncurr:qos remote none
}
state LocalReady {
note right of LocalReady: curr:qos local sendrecv\ncurr:qos remote none
}
state BothReady {
note right of BothReady: curr:qos local sendrecv\ncurr:qos remote sendrecv
}
以下是基于TS 24.229 Section 5.1.3.1和TS 23.502 Section 4.23.3的完整VoNR MO呼叫Preconditions信令流：
sequenceDiagram
participant UE_O as 主叫UE
participant PCSCF_O as P-CSCF(主叫侧)
participant SCSCF_O as S-CSCF(主叫侧)
participant SCSCF_T as S-CSCF(被叫侧)
participant PCSCF_T as P-CSCF(被叫侧)
participant UE_T as 被叫UE
participant PCF as PCF
participant SMF as SMF
participant AMF as AMF
participant gNB as gNB
rect rgb(240,248,255)
Note over UE_O,UE_T: Phase 1 — SIP INVITE + SDP Offer（含Preconditions）
UE_O->>PCSCF_O: SIP INVITE<br/>SDP Offer: a=des:qos mandatory local sendrecv<br/>a=des:qos mandatory remote sendrecv<br/>a=curr:qos local none<br/>a=curr:qos remote none<br/>Require: precondition
PCSCF_O->>SCSCF_O: INVITE转发
SCSCF_O->>SCSCF_T: INVITE路由
SCSCF_T->>PCSCF_T: INVITE转发
PCSCF_T->>UE_T: INVITE送达
end
rect rgb(255,248,240)
Note over UE_O,UE_T: Phase 2 — 183 Session Progress + SDP Answer
UE_T->>PCSCF_T: 183 Session Progress<br/>Require: 100rel, precondition<br/>SDP Answer: a=curr:qos local none<br/>a=curr:qos remote none<br/>a=des:qos mandatory local sendrecv<br/>a=des:qos mandatory remote sendrecv<br/>a=conf:qos remote sendrecv
PCSCF_T->>PCSCF_T: 触发AAR→PCF（被叫侧QoS授权）
PCSCF_T->>SCSCF_T: 183转发
SCSCF_T->>SCSCF_O: 183转发
SCSCF_O->>PCSCF_O: 183转发
PCSCF_O->>PCSCF_O: 触发AAR→PCF（主叫侧QoS授权）
PCSCF_O->>UE_O: 183 Session Progress送达
end
rect rgb(240,255,240)
Note over UE_O,UE_T: Phase 3 — PRACK确认183
UE_O->>PCSCF_O: SIP PRACK（确认183）
PCSCF_O->>SCSCF_O: PRACK转发
SCSCF_O->>SCSCF_T: PRACK转发
SCSCF_T->>PCSCF_T: PRACK转发
PCSCF_T->>UE_T: PRACK送达
UE_T->>PCSCF_T: 200 OK (PRACK)
PCSCF_T->>SCSCF_T: 200 OK转发
SCSCF_T->>SCSCF_O: 200 OK转发
SCSCF_O->>PCSCF_O: 200 OK转发
PCSCF_O->>UE_O: 200 OK (PRACK)
end
rect rgb(255,255,230)
Note over UE_O,gNB: Phase 4 — QoS Flow建立（并行）
par 主叫侧QoS Flow
PCSCF_O->>PCF: Rx AAR (QoS授权请求)
PCF->>SMF: N7 SM Policy Association<br/>授权5QI=1语音QoS Flow
SMF->>AMF: N2 SM Information<br/>PDU Session Modification
AMF->>gNB: N2 PDU Session Resource Setup
gNB->>UE_O: RRC Reconfiguration<br/>建立专用DRB
and 被叫侧QoS Flow
PCSCF_T->>PCF: Rx AAR (QoS授权请求)
PCF->>SMF: N7 SM Policy Association
SMF->>AMF: N2 SM Information
AMF->>gNB: N2 PDU Session Resource Setup
gNB->>UE_T: RRC Reconfiguration
end
end
rect rgb(240,240,255)
Note over UE_O,UE_T: Phase 5 — SIP UPDATE（本地条件满足）
UE_O->>PCSCF_O: SIP UPDATE<br/>SDP: a=curr:qos local sendrecv<br/>a=curr:qos remote none<br/>（主叫侧资源已预留）
PCSCF_O->>SCSCF_O: UPDATE转发
SCSCF_O->>SCSCF_T: UPDATE转发
SCSCF_T->>PCSCF_T: UPDATE转发
PCSCF_T->>UE_T: UPDATE送达
end
rect rgb(255,240,245)
Note over UE_O,UE_T: Phase 6 — 200 OK (UPDATE) + 远端条件确认
UE_T->>PCSCF_T: 200 OK (UPDATE)<br/>SDP: a=curr:qos local sendrecv<br/>a=curr:qos remote sendrecv<br/>（双方资源均已预留）
PCSCF_T->>SCSCF_T: 200 OK转发
SCSCF_T->>SCSCF_O: 200 OK转发
SCSCF_O->>PCSCF_O: 200 OK转发
PCSCF_O->>UE_O: 200 OK (UPDATE)送达
end
rect rgb(230,255,230)
Note over UE_O,UE_T: Phase 7 — 振铃与应答
UE_T->>UE_O: 180 Ringing (Require: 100rel)
UE_O->>UE_T: PRACK (确认180)
UE_T->>UE_O: 200 OK (PRACK)
UE_T->>UE_O: 200 OK (INVITE)
UE_O->>UE_T: ACK
Note over UE_O,UE_T: 双向RTP语音媒体建立
end
主叫UE在INVITE的SDP Offer中声明Preconditions需求：
INVITE sip:[email protected] SIP/2.0
Via: SIP/2.0/UDP [2001:db8::1]:5060;branch=z9hG4bK12345
From: <sip:[email protected]>;tag=abc123
To: <sip:[email protected]>
Call-ID: [email protected]
CSeq: 1 INVITE
Require: precondition
Supported: 100rel, precondition
Content-Type: application/sdp
v=0
o=- 123456 1 IN IP6 2001:db8::1
s=-
c=IN IP6 2001:db8::1
t=0 0
m=audio 49152 RTP/AVP 96 97 98
a=rtpmap:96 EVS/16000/1
a=rtpmap:97 AMR-WB/16000/1
a=rtpmap:98 AMR/8000/1
a=curr:qos local none ← 本端当前无资源
a=curr:qos remote none ← 对端当前无资源
a=des:qos mandatory local sendrecv ← 要求本端双向资源
a=des:qos mandatory remote sendrecv ← 要求对端双向资源
| IE名称 | 取值 | 作用 |
|---|---|---|
| Require: 100rel | 100rel | 要求主叫发送PRACK确认本消息 |
| Require: precondition | precondition | 声明本会话使用Preconditions |
| a=curr:qos local none | none | 被叫端尚未预留资源 |
| a=curr:qos remote none | none | 主叫端尚未预留资源 |
| a=des:qos mandatory local sendrecv | mandatory | 被叫端必须预留双向资源 |
| a=des:qos mandatory remote sendrecv | mandatory | 主叫端必须预留双向资源 |
| a=conf:qos remote sendrecv | sendrecv | 请求确认：主叫端资源预留完成后通知被叫 |
a=conf是关键触发器——它告诉主叫："当你预留好资源后，必须通过UPDATE通知我。"
主叫侧专用QoS Flow（5QI=1）建立后，UE发送UPDATE：
UPDATE sip:[email protected]:5060 SIP/2.0
Content-Type: application/sdp
v=0
m=audio 49152 RTP/AVP 96
a=curr:qos local sendrecv ← ★ 本端资源已就绪
a=curr:qos remote none ← 对端资源尚未确认
a=des:qos mandatory local sendrecv
a=des:qos mandatory remote sendrecv
被叫侧完成资源预留后，通过200 OK (UPDATE)确认：
SIP/2.0 200 OK
Content-Type: application/sdp
v=0
m=audio 49152 RTP/AVP 96
a=curr:qos local sendrecv ← 被叫端资源已就绪
a=curr:qos remote sendrecv ← 主叫端资源已确认就绪
a=des:qos mandatory local sendrecv
a=des:qos mandatory remote sendrecv
此时 curr:qos local/remote sendrecv >= des:qos mandatory local/remote sendrecv，双方Preconditions全部满足，被叫方可安全发送180 Ringing。
VoNR中Preconditions机制之所以能驱动QoS Flow建立，关键在于P-CSCF的Rx/N5接口触发。这一路径定义在TS 29.214（Rx接口）和TS 29.514（N5接口）。
sequenceDiagram
participant PCSCF as P-CSCF
participant PCF as PCF
participant SMF as SMF
Note over PCSCF: 收到183 Session Progress<br/>解析SDP获取媒体参数
PCSCF->>PCF: Diameter AAR<br/>AF-Application-Identifier=IMS<br/>Media-Component-Description:<br/> - Codec: EVS<br/> - Bandwidth: 64kbps<br/> - Flow-Status=ENABLED<br/> - Flow-Usage=NO_INFORMATION
PCF->>PCF: 策略决策：<br/>映射为5QI=1<br/>ARP优先级=1<br/>Guaranteed Bit Rate=64kbps
PCF->>SMF: N7 SM Policy Association Modify<br/>PCC Rule: QoS Flow 5QI=1<br/>SDF Filter: RTP/RTCP
SMF->>PCF: N7响应确认
PCF->>PCSCF: Diameter AAA<br/>Result-Code=DIAMETER_SUCCESS
Note over PCSCF: QoS授权完成<br/>等待SMF建立专用QoS Flow
| SDP参数 | PCF映射 | 5G QoS参数 |
|---|---|---|
| Codec: EVS (13.2kbps) | GFBR上行/下行 | 5QI=1, GFBR=13.2kbps |
| bw:32000 (AS) | MBR | MBR=64kbps |
| sendrecv | Flow-Status | ENABLED (双向) |
| ptime:20 | Frame Duration | 20ms RTP packetization |
| rtpmap:96 EVS/16000 | Service Data Flow | SDF Filter: RTP ports |
P-CSCF触发AAR后，5GC执行的完整PDU Session Modification流程（TS 23.502 Section 4.3.5）：
| 步骤 | 消息 | 关键IE |
|---|---|---|
| 1 | PCF→SMF: N7 Policy Association Modify | PCC Rule (5QI=1, GFBR, MBR, ARP) |
| 2 | SMF→UPF: N4 Session Modification | Packet Detection Rule, QoS Enforcement Rule |
| 3 | SMF→AMF: N1N2MessageTransfer | N2 SM Info (QoS Flow ID, 5QI=1) + NAS PDU Session Modify Command |
| 4 | AMF→gNB: N2 PDU Session Resource Setup | QoS Flow QoS Profile (5QI=1, GFBR) |
| 5 | gNB→UE: RRC Reconfiguration | 新DRB配置 (逻辑信道映射到5QI=1) |
| 6 | gNB→AMF: N2 PDU Session Resource Setup Response | 承载建立确认 |
| 7 | AMF→SMF: Nsmf_PDUSession_UpdateSMContext | 资源建立成功 |
| 8 | SMF→PCF: N7 Policy Association Modify响应 | 策略执行确认 |
| 维度 | Preconditions模式 | 非Preconditions模式 |
|---|---|---|
| 定义规范 | RFC 3312 + TS 24.229 §5.1.3.1 | 无额外约束 |
| QoS建立时序 | 183→PRACK→QoS Flow→UPDATE→180 | INVITE→180→QoS Flow→200 OK |
| 振铃时机 | 双方资源预留完成后 | 收到INVITE后即可振铃 |
| 幽灵振铃风险 | 极低 | 较高 |
| 呼叫建立时延 | 增加100-300ms（QoS建立等待） | 较短 |
| 信令开销 | 需要PRACK + UPDATE | 仅INVITE + 200 OK |
| 资源浪费 | 无——振铃即有承载 | 可能——振铃后承载建立失败 |
| 运营商成本 | 无线资源利用率高 | 无线资源可能浪费 |
| 典型应用 | VoNR/VoLTE（标准要求） | OTT VoIP（微信语音等） |
在Wireshark中过滤VoNR Preconditions流程：
# 过滤SIP INVITE中的Preconditions
sip.Request-Line contains "INVITE" && sdp contains "precondition"
# 过滤183 Session Progress
sip.Status-Code == 183
# 过滤UPDATE消息
sip.Method == "UPDATE"
# 完整VoNR呼叫链
sip.Method == "INVITE" || sip.Status-Code == 183 || sip.Method == "PRACK" || sip.Method == "UPDATE" || sip.Status-Code == 180 || sip.Status-Code == 200
| 故障现象 | 根因分析 | 排查方法 |
|---|---|---|
| 发出INVITE后无183返回 | 被叫UE不支持Preconditions，或P-CSCF路由失败 | 检查INVITE中Supported: precondition头部；追踪P-CSCF→S-CSCF转发日志 |
| 183返回但UPDATE始终未发 | 主叫侧QoS Flow建立失败（P-CSCF→PCF AAR失败，或gNB资源不足） | 检查PCF日志中AAR是否成功；检查N2 PDU Session Resource Setup是否超时 |
| UPDATE发出但无200 OK | 被叫侧资源预留失败 | 检查被叫侧SMF N4 Session Modification是否成功 |
| 180 Ringing后无200 OK (INVITE) | 被叫用户未接听，或SDP协商在后续阶段失败 | 检查180 Ringing后是否有CANCEL或超时 |
| 双方振铃但无语音 | RTP端口映射错误，或UPF N4规则未生效 | 检查UPF的Packet Detection Rule是否匹配RTP流 |
| ## 八、Preconditions与5G QoS Flow的时序博弈 |
Preconditions机制引入的核心时序博弈：
curr:qos local仍为nonemandatory改为optional允许在资源不足时继续呼叫建立，但牺牲了"零幽灵振铃"保证gantt
title VoNR MO呼叫建立时序分解（典型值）
dateFormat X
axisFormat %L ms
section SIP信令
INVITE→183 :a1, 0, 150
183→PRACK→200OK :a2, 150, 200
UPDATE→200OK(UPDATE) :a3, 500, 600
180 Ringing :a4, 600, 700
200OK(INVITE)→ACK :a5, 3000, 3100
section 5GC QoS
P-CSCF→PCF AAR/AAA :b1, 150, 250
PCF→SMF N7 Modify :b2, 250, 300
SMF→gNB N2 Setup :b3, 300, 400
gNB→UE RRC Reconfig :b4, 400, 500
典型VoNR呼叫建立时延分布：
| 阶段 | 典型时延 | 占比 |
|---|---|---|
| INVITE → 183 | 100-200ms | 10-15% |
| QoS Flow建立（双端并行） | 200-400ms | 25-35% |
| UPDATE → 200 OK (UPDATE) | 50-100ms | 5-10% |
| 等待用户接听 | 1000-5000ms | 40-60% |
| 200 OK (INVITE) → ACK | 50-100ms | 5% |
3GPP Release 18/19中针对VoNR呼叫建立优化的主要方向包括：
Q1: Preconditions中mandatory和optional的区别是什么？
A: mandatory要求资源预留必须成功，否则呼叫失败（返回580 Precondition Failure）。optional允许在资源预留失败时继续呼叫建立，但可能导致振铃后无语音。3GPP要求VoNR/VoLTE使用mandatory。
Q2: 为什么183 Session Progress需要PRACK确认，而180 Ringing也需要？
A: 183携带SDP Answer（包含Preconditions参数），属于关键信令，需要可靠传输。Require: 100rel头部强制主叫发送PRACK确认。180 Ringing也携带Require: 100rel因为振铃事件对用户体验至关重要，不可丢失。
Q3: UPDATE和re-INVITE在Preconditions中有什么区别？ A: UPDATE（RFC 3311）在会话建立早期阶段（INVITE未收到200 OK前）修改SDP参数，不改变对话状态。re-INVITE只能在会话已建立后使用。Preconditions机制中资源预留确认必须使用UPDATE，因为此时INVITE事务尚未完成。
Q4: 如果被叫UE不支持Preconditions会怎样？ A: 根据TS 24.229和GSMA IR.92，被叫UE应支持Preconditions。如果不支持，P-CSCF可以降级为非Precondition模式，但运营商可能选择拒绝呼叫（取决于策略配置）。被叫UE不得依赖主叫使用Preconditions。
Q5: P-CSCF如何知道QoS Flow已经成功建立？ A: P-CSCF通过Rx/N5接口的RAR（Re-Auth-Request）/ RAA（Re-Auth-Answer）或N5 Notification从PCF/SMF获得QoS Flow状态通知。部分实现中P-CSCF也可通过订阅PCF的事件通知获取承载状态变化。
本文由「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 等场景全覆盖。