VoNR(Voice over New Radio)是5G SA架构下的原生语音方案,基于IMS核心网承载语音业务。与OTT语音应用不同,运营商级语音必须在媒体面建立前确保端到端QoS资源已经预留成功——否则会出现"对方接听了电话但听不到声音"的严重用户体验问题。
这个"先建承载、后振铃"的保证机制,就是由RFC 3312定义的SIP Precondition机制实现的。在VoNR中,Precondition机制与5GC的PDU Session Modification + QoS Flow建立深度耦合,形成了一套跨IMS信令面和5GC用户面的双向握手验证流程。
本文将以 3GPP TS 24.229 Section 5.2.2A(主叫侧IMS会话建立)和 TS 23.502 Section 4.3.3(PDU Session Modification)为核心依据,逐步拆解VoNR SIP INVITE从发出到呼叫建立的完整信令交互。
下图展示了VoNR Mobile Originated Call的完整信令流程,涵盖SIP信令面与5GC承载面的交互:
sequenceDiagram
participant UE_A as UE-A (主叫)
participant P_CSCF_A as P-CSCF-A
participant PCF as PCF
participant S_CSCF as S-CSCF
participant P_CSCF_B as P-CSCF-B
participant UE_B as UE-B (被叫)
participant SMF as SMF
participant AMF as AMF
participant gNB as gNB
Note over UE_A,UE_B: Phase 1: SIP INVITE + SDP Offer(初始 offer)
UE_A->>P_CSCF_A: SIP INVITE (SDP Offer, precondition: none)
P_CSCF_A->>PCF: Npcf_PolicyAuthorization_Create (媒体描述)
PCF-->>P_CSCF_A: 201 Created (Policy Decision)
P_CSCF_A->>S_CSCF: SIP INVITE (转发)
S_CSCF->>P_CSCF_B: SIP INVITE (转发)
P_CSCF_B->>UE_B: SIP INVITE
Note over UE_A,UE_B: Phase 2: 183 Session Progress + SDP Answer
UE_B->>P_CSCF_B: SIP 183 Session Progress (SDP Answer)
P_CSCF_B->>PCF: Npcf_PolicyAuthorization_Create (被叫侧策略)
P_CSCF_B->>S_CSCF: SIP 183 (转发)
S_CSCF->>P_CSCF_A: SIP 183 (转发)
P_CSCF_A->>UE_A: SIP 183 Session Progress
Note over UE_A,UE_B: Phase 3: PRACK确认183
UE_A->>P_CSCF_A: SIP PRACK
P_CSCF_A->>S_CSCF: PRACK (转发)
S_CSCF->>P_CSCF_B: PRACK (转发)
P_CSCF_B->>UE_B: PRACK
UE_B-->>P_CSCF_B: 200 OK (PRACK)
P_CSCF_B-->>UE_A: 200 OK (PRACK) (逐跳转发)
Note over UE_A,gNB: Phase 4: 主叫侧资源预留 (5GC QoS Flow建立)
P_CSCF_A->>PCF: 通知资源授权完成
PCF->>SMF: Npcf_SMPolicyControl_Update (PCC Rule: 5QI=1)
SMF->>AMF: Namf_N1N2MessageTransfer (N1+N2 SM Container)
AMF->>gNB: N2 PDU Session Resource Setup (QoS Flow: 5QI=1, QFI)
gNB->>UE_A: RRC Reconfiguration (DRB建立)
UE_A-->>gNB: RRC Reconfiguration Complete
gNB-->>SMF: N2 PDU Session Resource Setup Response
Note over UE_A,UE_B: Phase 5: SIP UPDATE (主叫侧Precondition满足)
UE_A->>P_CSCF_A: SIP UPDATE (a=curr:qos local sendrecv)
P_CSCF_A->>S_CSCF: UPDATE (转发)
S_CSCF->>P_CSCF_B: UPDATE (转发)
P_CSCF_B->>UE_B: UPDATE
Note over UE_B,gNB: Phase 6: 被叫侧资源预留
P_CSCF_B->>PCF: 通知资源授权
PCF->>SMF: PCC Rule下发 (被叫侧5QI=1)
SMF->>AMF: PDU Session Modification
AMF->>gNB: N2 QoS Flow Setup (被叫侧)
UE_B-->>P_CSCF_B: 200 OK (UPDATE, a=curr:qos local sendrecv)
Note over UE_A,UE_B: Phase 7: 振铃与呼叫建立
UE_B->>P_CSCF_B: SIP 180 Ringing
P_CSCF_B->>S_CSCF: 180 Ringing (转发)
S_CSCF->>P_CSCF_A: 180 Ringing (转发)
P_CSCF_A->>UE_A: SIP 180 Ringing (回铃音)
UE_B->>P_CSCF_B: SIP 200 OK (INVITE)
P_CSCF_B->>S_CSCF: 200 OK (转发)
S_CSCF->>P_CSCF_A: 200 OK (转发)
P_CSCF_A->>UE_A: SIP 200 OK
UE_A->>P_CSCF_A: SIP ACK
P_CSCF_A->>S_CSCF: ACK (转发)→P_CSCF_B→UE_B
Note over UE_A,UE_B: ========== 双向语音通话建立 ==========
RFC 3312定义了三种关键SDP属性(a=行),用于描述QoS资源预留的状态和需求:
| 属性 | 语法 | 含义 |
|---|---|---|
a=curr |
a=curr:qos <status> <direction> |
当前QoS状态(none/sendrecv/sendonly/recvonly) |
a=des |
a=des:qos <strength> <direction> |
期望达到的QoS目标(strength: mandatory/optional/none/failure) |
a=conf |
a=conf:qos <direction> |
要求对端在状态变化时通知本端 |
根据TS 24.229 Section 5.2.2A.1.1,主叫UE在发送INVITE时,SDP Offer的结构如下:
v=0
o=- 32674926 32674926 IN IP4 10.1.2.3
s=-
c=IN IP4 10.1.2.3
t=0 0
m=audio 49152 RTP/AVP 96 97 98
b=AS:41
b=RS:600
b=RR:2000
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
a=rtpmap:96 EVS/16000/1
a=fmtp:96 br=5.9-24.4; bw=nb-wb; max-red=220
a=rtpmap:97 AMR-WB/16000/1
a=fmtp:97 mode-change-capability=2; max-red=220
a=rtpmap:98 telephone-event/16000
a=fmtp:98 0-15
a=ptime:20
a=maxptime:240
a=sendrecv
关键IE解析:
| IE | 值 | 设计意图 |
|---|---|---|
a=curr:qos local none |
主叫侧本地资源尚未预留 | 初始状态,标记资源尚未就绪 |
a=curr:qos remote none |
被叫侧远端资源尚未预留 | 初始状态 |
a=des:qos mandatory local sendrecv |
主叫侧必须完成双向资源预留 | strength=mandatory确保不达条件不振铃 |
a=des:qos mandatory remote sendrecv |
被叫侧也必须完成资源预留 | 端到端QoS保证 |
a=conf:qos remote sendrecv |
要求被叫确认资源预留状态 | 触发UPDATE机制 |
m=audio 96 97 98 |
编解码优先级:EVS > AMR-WB > DTMF | EVS为VoNR首选编码 |
b=AS:41 |
应用层最大带宽41kbps | EVS在WB模式下的典型带宽 |
被叫UE收到INVITE后,返回183 Session Progress携带SDP Answer(TS 24.229 Section 5.2.3A):
m=audio 49170 RTP/AVP 96 98
b=AS:41
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
a=rtpmap:96 EVS/16000/1
a=fmtp:96 br=5.9-24.4; bw=nb-wb
a=rtpmap:98 telephone-event/16000
a=sendrecv
注意:被叫选择了EVS(payload 96),去掉了AMR-WB(97),完成了编解码协商。两端同时确认a=curr:qos均为none,表示资源预留尚未开始。
整个Precondition机制的核心是一个双边四状态的状态机:
stateDiagram-v2
[*] --> INIT: INVITE发送
INIT --> LOCAL_RESERVED: 主叫侧QoS Flow建立成功
LOCAL_RESERVED --> BOTH_RESERVED: 被叫侧QoS Flow建立成功
BOTH_RESERVED --> RINGING: 180 Ringing
RINGING --> CONNECTED: 200 OK + ACK
LOCAL_RESERVED --> UPDATE_SENT: 发送UPDATE(a=curr:qos local sendrecv)
UPDATE_SENT --> BOTH_RESERVED: 收到200 OK(UPDATE)
state INIT {
[*] --> WaitLocalResource
note right of WaitLocalResource: a=curr:qos local none
}
state BOTH_RESERVED {
[*] --> PreconditionSatisfied
note right of PreconditionSatisfied: a=curr:qos local sendrecv\na=curr:qos remote sendrecv
}
P-CSCF收到INVITE后,在转发之前,需要通过N5接口(Npcf_PolicyAuthorization服务)向PCF请求媒体资源授权。这个过程在TS 29.513 Section 4.2.2中定义:
sequenceDiagram
participant P_CSCF as P-CSCF
participant PCF as PCF
participant SMF as SMF
P_CSCF->>PCF: POST /npcf-policyauthorization/v1/app-sessions<br/>(Media-Component-Descriptor)
Note right of P_CSCF: AF-Charging-Id<br/>Media-Type=Audio<br/>Codec=EVS<br/>BW=41kbps<br/>Flow-Status=ENABLED<br/>Reservation-Priority=1
PCF->>PCF: 1. 查找关联的PDU Session<br/>2. 检查用户订阅的QoS权限<br/>3. 生成PCC Rule
PCF-->>P_CSCF: 201 Created<br/>(App-Session-Id, Policies)
PCF->>SMF: Npcf_SMPolicyControl_Update<br/>(PCC Rule: 5QI=1, GFBR=41kbps)
SMF->>SMF: 1. 分配QFI<br/>2. 创建QoS Flow<br/>3. 生成N2 SM Info
Npcf_PolicyAuthorization_Create请求中的关键IE:
| IE名称 | 典型值 | 说明 |
|---|---|---|
afAppId |
"ims-3gpp" | 标识IMS应用 |
mediaComponents |
medCompN=1, medType=audio |
媒体描述 |
codecs |
"EVS" | 选定编解码 |
fDescs |
permit out 10.1.2.3 49152 |
SDF过滤器 |
marBw |
41000 (bps) | 最大授权带宽 |
flowStatus |
ENABLED-UPLINK | 初始为上行启用 |
tsnQosReq |
5QI=1 | 标识会话类语音QoS |
SMF收到PCC Rule后,发起网络侧发起的PDU Session Modification(TS 23.502 Section 4.3.3.1):
| 步骤 | 消息 | 关键内容 |
|---|---|---|
| 1 | SMF→AMF: Namf_Communication_N1N2MessageTransfer |
N1 SM Container (PDU Session Modification Command) + N2 SM Info (QoS Flow Setup) |
| 2 | AMF→gNB: N2 PDU Session Resource Setup |
QFI, 5QI=1, GFBR=41kbps, UL/DL SDF Filter |
| 3 | gNB→UE: RRC Reconfiguration |
新DRB建立,承载语音QoS Flow |
| 4 | UE→gNB: RRC Reconfiguration Complete |
DRB建立完成 |
| 5 | gNB→AMF: N2 PDU Session Resource Setup Response |
AN Tunnel Info |
| 6 | AMF→SMF: Nsmf_PDUSession_UpdateSMContext |
转发N2 Response |
| 7 | SMF→UPF: N4 Session Modification |
QER (QoS Enforcement Rule) for QFI |
| 参数 | VoNR语音 (5QI=1) | VoNR视频 (5QI=2) | IMS信令 (5QI=5) |
|---|---|---|---|
| 5QI | 1 | 2 | 5 |
| Resource Type | Guaranteed Bit Rate (GBR) | GBR | Non-GBR |
| Priority Level | 20 | 40 | 10 |
| Packet Delay Budget | 100ms | 150ms | 100ms |
| Packet Error Rate | 10⁻² | 10⁻³ | 10⁻⁶ |
| Default Max Data Burst | 2000 bytes | 2000 bytes | N/A |
| Typical GFBR | 41 kbps (EVS WB) | 2-10 Mbps | N/A |
当主叫UE-A的gNB完成DRB建立、QoS Flow激活后,UE-A在NAS层收到PDU Session Modification Command Accept,确认本地资源已就绪。此时UE-A发送SIP UPDATE消息(TS 24.229 Section 5.2.2A.2.1):
UPDATE sip:[email protected] SIP/2.0
Via: SIP/2.0/UDP 10.1.2.3:5060;branch=z9hG4bK1234
From: <sip:[email protected]>;tag=abc123
To: <sip:[email protected]>;tag=xyz789
Call-ID: [email protected]
CSeq: 2 UPDATE
Content-Type: application/sdp
v=0
o=- 32674926 32674927 IN IP4 10.1.2.3
s=-
c=IN IP4 10.1.2.3
t=0 0
m=audio 49152 RTP/AVP 96 98
a=curr:qos local sendrecv
a=curr:qos remote none
a=des:qos mandatory local sendrecv
a=des:qos mandatory remote sendrecv
a=conf:qos remote sendrecv
a=sendrecv
关键变化:a=curr:qos local sendrecv — 从none变为sendrecv,表明主叫侧的QoS资源已经预留成功。
被叫侧收到UPDATE后,其本地资源可能尚未就绪。被叫UE在收到UPDATE后,同步触发本端的PDU Session Modification建立QoS Flow。资源就绪后,被叫UE返回200 OK (UPDATE):
SIP/2.0 200 OK
Content-Type: application/sdp
v=0
m=audio 49170 RTP/AVP 96 98
a=curr:qos local sendrecv
a=curr:qos remote sendrecv
a=des:qos mandatory local sendrecv
a=des:qos mandatory remote sendrecv
a=sendrecv
此时两端Precondition均已满足(a=curr:qos local/remote sendrecv),被叫UE才会发出SIP 180 Ringing进行振铃提醒。
设计意图:这确保了被叫用户在接听电话之前,双向的语音承载已经建立完毕,避免了"ghost call"(幽灵来电)和"one-way audio"(单通)问题。
VoNR中的编解码协商发生在SDP Offer/Answer中,遵循TS 26.114(MTSI)定义的编解码优先级:
flowchart TD
A[UE-A: INVITE SDP Offer<br/>EVS, AMR-WB, telephone-event] --> B{UE-B能力检查}
B --> C[优先选择EVS<br/>Super-Wideband]
B --> D[回退AMR-WB<br/>Wideband]
B --> E[最低回退AMR-NB<br/>Narrowband]
C --> F[SDP Answer: 选定EVS<br/>fmtp参数协商]
D --> G[SDP Answer: 选定AMR-WB]
E --> H[SDP Answer: 选定AMR-NB<br/>VoNR不支持, EPS Fallback]
EVS(Enhanced Voice Services)是3GPP在Release 12引入的编解码,在TS 26.441中定义。VoNR中EVS的SDP参数协商表:
| 参数 | 说明 | 典型取值 |
|---|---|---|
br |
Bitrate range | 5.9-24.4 kbps (WB) / 9.6-128 kbps (SWB) |
bw |
Bandwidth | nb/wb/swb/fb |
max-red |
Maximum redundancy | 220 ms |
mode-set |
EVS mode set | 0 (Primary) |
hf-only |
Header-full only | 0 (允许Compact format) |
dtx |
Discontinuous Transmission | 0/1 |
ch-aw-recv |
Channel-Aware Mode | 2/3/5/7 |
| 特性 | EVS | AMR-WB |
|---|---|---|
| 编码带宽 | NB/WB/SWB/FB | WB |
| 比特率范围 | 5.9 - 128 kbps | 6.6 - 23.85 kbps |
| 典型VoNR速率 | 13.2 kbps (WB) / 24.4 kbps (SWB) | 12.65/23.85 kbps |
| AMR-WB兼容模式 | 支持(mode 8-14) | N/A |
| 抗抖动能力 | Channel-Aware模式 | 无 |
| MOS评分 (典型) | 4.2-4.5 | 3.8-4.1 |
| 3GPP定义 | TS 26.441 (Rel-12+) | TS 26.190 (Rel-6+) |
| 检查项 | 抓包位置 | 识别方法 |
|---|---|---|
| INVITE SDP Offer | UE↔P-CSCF (SIP) | 检查a=des:qos mandatory是否存在 |
| 183 SDP Answer | P-CSCF→UE (SIP) | 检查被叫是否选定了codec |
| PRACK | UE→P-CSCF (SIP) | 必须在183后立即发送 |
| PDU Session Modification | UE↔AMF (NAS) | NAS消息类型=0xD3 (Modification Command) |
| QoS Flow Setup | gNB↔AMF (N2/NGAP) | QFI字段,5QI=1 |
| SIP UPDATE | UE→P-CSCF (SIP) | 检查a=curr:qos local sendrecv |
| 180 Ringing时序 | SIP流 | 必须在UPDATE 200 OK之后 |
| 故障现象 | 根因 | 排查思路 |
|---|---|---|
| INVITE后无183 | 被叫不可达或IMS注册异常 | 检查S-CSCF路由、被叫注册状态 |
| 183后无UPDATE | 主叫QoS Flow建立失败 | 检查PCF策略授权、SMF PCC Rule、gNB资源 |
| UPDATE后无180 Ringing | 被叫QoS Flow建立失败 | 检查被叫侧PCF/SMF/gNB |
| 180后长时间无200 OK | 被叫用户未接听 | 终端层面问题,非网络问题 |
| 200 OK后单通 | UPF N4规则异常或媒体锚点错误 | 检查UPF N4 Session、RTP流方向 |
| Precondition超时 | gNB无线资源不足 | 检查gNB DRB建立成功率、PRB利用率 |
| ## 八、VoNR vs VoLTE Precondition差异对比 |
| 对比维度 | VoLTE (4G) | VoNR (5G) |
|---|---|---|
| 承载类型 | Dedicated EPS Bearer (EBI) | Dedicated QoS Flow (QFI) in PDU Session |
| QoS标识 | QCI=1 | 5QI=1 |
| 策略接口 | Rx (P-CSCF→PCRF) | N5/Npcf_PolicyAuthorization (P-CSCF→PCF) |
| GBR承载建立 | PCRF→PGW (Gx)→eNB | PCF→SMF (N7)→gNB (N2) |
| 默认承载 | IMS默认承载 (QCI=5) | IMS PDU Session默认QoS Flow (5QI=5) |
| 无线侧 | eNB: ERAB建立 | gNB: DRB建立 (PDCP/RLC/MAC配置) |
| 编解码优先 | AMR-WB (12.65/23.85kbps) | EVS (13.2/24.4kbps) |
| Precondition协议 | RFC 3312 + RFC 4032 | RFC 3312 + RFC 4032 (不变) |
| 呼叫建立时延目标 | <1.5s | <1.0s (5G KPI) |
classDiagram
class SIP_INVITE {
+Request-URI: sip:userB@ims...
+From: sip:userA@ims...;tag=abc
+To: sip:userB@ims...
+Call-ID: [email protected]
+CSeq: 1 INVITE
+Contact: sip:[email protected]
+Require: precondition
+Supported: 100rel, precondition
+Content-Type: application/sdp
+SDP_Offer
}
class SDP_Offer {
+Version: v=0
+Origin: o=- session-id IN IP4
+Connection: c=IN IP4 10.1.2.3
+Media: m=audio 49152 RTP/AVP 96 97 98
+Bandwidth: b=AS:41
+Precondition_Attrs
+Codec_Attrs
}
class Precondition_Attrs {
+curr:qos local none
+curr:qos remote none
+des:qos mandatory local sendrecv
+des:qos mandatory remote sendrecv
+conf:qos remote sendrecv
}
class Codec_Attrs {
+rtpmap:96 EVS/16000
+fmtp:96 br=5.9-24.4
+rtpmap:97 AMR-WB/16000
+rtpmap:98 telephone-event
+ptime:20
+maxptime:240
}
SIP_INVITE --> SDP_Offer
SDP_Offer --> Precondition_Attrs
SDP_Offer --> Codec_Attrs
一次完整的VoNR呼叫建立时延可分解为:
| 阶段 | 典型时延 | 占比 | 说明 |
|---|---|---|---|
| INVITE→183 (SDP协商) | 80-200ms | ~15% | 取决于IMS网络跳数 |
| 183→PRACK→200 OK | 50-100ms | ~10% | 确认可靠临时响应 |
| 主叫QoS Flow建立 | 100-300ms | ~25% | PDU Session Modification + DRB |
| UPDATE→200 OK | 50-150ms | ~10% | Precondition确认 |
| 被叫QoS Flow建立 | 100-300ms | ~25% | 被叫侧资源预留 |
| 180 Ringing→200 OK | 用户依赖 | ~15% | 被叫用户摘铃时间 |
| 总计(不含用户行为) | 380-1050ms |
5G VoNR的目标呼叫建立时延(不含用户行为)应低于1.0秒,相比VoLTE的1.5秒目标有显著提升。
Q1: Precondition的strength标签mandatory和optional有什么区别?
A: mandatory意味着该Precondition必须满足才能继续会话建立(振铃),如果不满足会导致会话失败。optional表示即使不满足也会继续。运营商通常对语音业务使用mandatory确保通话质量。none表示不关心该方向的Precondition,failure表示只要资源可用就通知但不阻塞。
Q2: 为什么需要PRACK消息?SIP的可靠性不够吗?
A: 标准SIP中,临时响应(1xx)是不可靠传输的,不会被确认。而183 Session Progress携带了关键的SDP Answer,丢失会导致后续Precondition流程无法进行。RFC 3262定义的PRACK机制(通过Require: 100rel头域触发)确保183的可靠传递。这在无线环境下尤为重要,因为空口丢包率高于有线网络。
Q3: 如果gNB无线资源不足,QoS Flow建立失败会怎样?
A: 主叫UE在等待PDU Session Modification Command的NAS响应超时后,会判断Precondition无法满足。此时主叫侧会发送SIP CANCEL取消会话,或者触发EPS Fallback将语音回落到4G LTE网络。PCF和SMF层面会记录QoS Flow建立失败事件,用于网络自优化。具体回落策略由运营商的Voice Fallback Policy决定(TS 23.502 Section 4.13.6)。
Q4: VoNR中EVS和AMR-WB编解码如何实现互通?
A: EVS编解码器内置了AMR-WB IO(Inter-Operable)模式(bitrate 6.6-23.85 kbps),可以与纯AMR-WB终端互通而无需转码器(Transcoder)。当VoNR终端与VoLTE终端通话时,SDP协商会回退到AMR-WB编解码。只有两端都支持EVS Primary模式时,才能使用EVS的高品质SWB/FB带宽。
Q5: P-CSCF如何在5G中识别并关联对应的PDU Session?
A: P-CSCF通过两种方式关联:① 在IMS Registration阶段,P-CSCF记录UE的IP地址与PDU Session的对应关系;② 当收到SIP INVITE时,P-CSCF从SDP的连接地址(c=行)提取UE IP,查找对应的PDU Session,然后通过N5接口向PCF发送策略授权请求时携带该PDU Session的标识信息。PCF内部维护了UE IP→SMF→PDU Session的映射关系(通过TS 29.513 Section 4.2.2定义的绑定机制)。
本文由「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 等场景全覆盖。
