首页 › ims › VoNR主叫INVITE会话建立信令拆解

VoNR主叫SIP INVITE会话建立全链信令深度拆解

本文聚焦5G IMS（VoNR）主叫会话建立过程中 SIP INVITE 全链信令流，覆盖 UE → P-CSCF → I-CSCF → S-CSCF → AS → 被叫 的横向路由，以及 P-CSCF → PCF（N5）→ SMF（N7）→ UPF（N4） 的纵向QoS授权联动。规范依据：3GPP TS 23.228（IMS Stage 2）、TS 24.229（IMS SIP/SDP 呼叫控制）、TS 24.173（MMTel）、TS 23.501/23.502（5GS QoS Flow）、TS 29.514（Npcf_PolicyAuthorization / N5 SBI），并结合 IETF RFC 3261/3262/3311/3312/4566。

一、为什么VoNR的INVITE比"打个电话"复杂得多

很多人第一次看VoNR/VoLTE抓包会被一长串 100 Trying / 183 Session Progress / PRACK / UPDATE / 180 Ringing / 200 OK / ACK 搞晕。这背后是 两个约束的叠加：

媒体面与信令面解耦：SIP信令走默认QoS Flow（5QI=5），而语音RTP媒体必须走专用GBR QoS Flow（5QI=1）。专用承载要先于"振铃"建立，否则用户接起电话却没声音。
可靠临时响应机制（RFC 3262）：SIP的临时响应（1xx，如183）默认不可靠、可能丢失，而183里恰恰携带了SDP Answer——这是建承载的依据。必须用PRACK把它"可靠化"。

VoNR相对VoLTE的最大差异在于：P-CSCF向PCF授权不再走Diameter Rx接口，而是走SBI的N5参考点（Npcf_PolicyAuthorization，基于HTTP/2）；QoS承载也从EPS Bearer变成了5G的QoS Flow（SMF经N4 PFCP向UPF下发PDR/FAR/QER）。理解了这一点，VoNR信令流的"骨架"就清楚了。

二、全链信令时序图

下图展示VoNR主叫（MO）会话建立的完整信令流，包含双段SDP协商（Offer在INVITE、Answer在183）与资源预留确认（UPDATE），并嵌入P-CSCF→PCF→SMF→UPF的QoS授权联动：

sequenceDiagram
    autonumber
    participant UE as 主叫UE
    participant PCSCF as P-CSCF(主叫)
    participant SCSCF as S-CSCF(主叫)
    participant AS as MMTEL AS
    participant ICSCF as I-CSCF(被叫侧)
    participant PCF as PCF
    participant SMF as SMF
    participant UPF as UPF
    participant UE_B as 被叫UE

    Note over UE,UE_B: 阶段1: INVITE发起与路由(Service-Route已预存)
    UE->>PCSCF: INVITE (SDP Offer, Require:precondition, 100rel)
    PCSCF->>SCSCF: INVITE (增加P-Asserted-Identity/Topology-Hiding)
    SCSCF->>AS: INVITE (触发iFC)
    AS-->>SCSCF: INVITE (无修改)
    SCSCF->>ICSCF: INVITE
    ICSCF->>UE_B: INVITE (经被叫S-CSCF)

    Note over UE,UPF: 阶段2: 183携带SDP Answer + QoS授权联动
    UE_B-->>PCSCF: 183 Session Progress (SDP Answer, Require:100rel)
    Note right of PCSCF: P-CSCF解析SDP<br/>提取媒体流描述
    PCSCF->>PCF: POST /policies/authorization (N5, Npcf_PolicyAuthorization)
    PCF->>SMF: Npcf_SMPolicyControl_Update (N7, 下发PCC rule: 5QI=1)
    SMF->>UPF: PFCP Session Modification Req (N4, 建PDR/FAR/QER)
    UPF-->>SMF: PFCP Session Mod Resp
    SMF-->>PCF: N7 Ack (QoS Flow建立,FARTEID)
    PCF-->>PCSCF: 201 Created (授权成功)
    PCSCF-->>UE: 183 Session Progress (RSeq, SDP Answer)

    Note over UE,UE_B: 阶段3: 可靠临时响应与资源预留确认
    UE->>PCSCF: PRACK (RAck, 确认183)
    PCSCF->>UE_B: PRACK
    UE_B-->>PCSCF: 200 OK (PRACK)
    PCSCF-->>UE: 200 OK (PRACK)
    Note right of UE: 主叫本地资源预留完成
    UE->>PCSCF: UPDATE (SDP, curr状态=sendrecv)
    PCSCF->>UE_B: UPDATE
    UE_B-->>PCSCF: 200 OK (UPDATE)
    PCSCF-->>UE: 200 OK (UPDATE)

    Note over UE,UE_B: 阶段4: 振铃与应答
    UE_B-->>UE: 180 Ringing
    UE_B-->>PCSCF: 200 OK (INVITE)
    PCSCF-->>UE: 200 OK (INVITE)
    UE->>PCSCF: ACK
    PCSCF->>UE_B: ACK
    Note over UE,UE_B: 会话建立, 5QI=1专用QoS Flow双向导通

三、INVITE消息关键IE结构拆解

INVITE是整个会话的"种子"，其头部域决定了路由、鉴权身份、媒体能力和资源预留策略。下图展示VoNR主叫INVITE的关键Information Element组成：

flowchart TB
    subgraph INV["SIP INVITE 消息结构"]
        direction TB
        RL["Request-URI<br/>被叫tel:/sip: URI"]
        F["From / To / Call-ID / CSeq<br/>(Dialog标识三件套)"]
        VIA["Via<br/>(逐跳路由回程路径)"]
        SR["Route<br/>(松散路由, 来自Service-Route)"]
        PAI["P-Asserted-Identity<br/>(主叫已鉴权真实号码)"]
        PR["P-Preferred-Service<br/>(业务标识, 触发iFC)"]
        REQ["Require: precondition, 100rel<br/>(强制资源预留+可靠临时响应)"]
        ACC["Accept-Contact: +g.3gpp.icsi-ref<br/>(MMTel业务能力协商)"]
        SDP["Body: SDP Offer<br/>(m=audio, a=rtpmap EVS, <br/>a=curr/a=des qos status)"]
    end
    RL --> F --> VIA --> SR --> PAI --> PR --> REQ --> ACC --> SDP
    style SDP fill:#e8f5e9
    style REQ fill:#fff3e0
    style PAI fill:#e3f2fd

其中几个IE的设计意图值得强调：

Service-Route / Route：UE在IMS注册时从200 OK REGISTER里学到Service-Route头域，缓存为本地Route集，后续所有会话请求都做"松散路由"（loose routing，lr参数），保证请求依次穿过P-CSCF→S-CSCF，这是IMS拓扑隐藏和计费锚点的基础。
P-Asserted-Identity（PAI）：携带主叫已鉴权的真实身份。注意它与From不同——From是显示名（可自定义），PAI是网络强制写入的、用于被叫侧鉴权和计费的可信身份，P-CSCF会剥离或改写以保护隐私（配合Privacy头域）。
Require: precondition, 100rel：这一行是整条信令流复杂性的根源。100rel（RFC 3262）要求临时响应必须可靠传输；precondition（RFC 3312）要求会话建立必须满足资源预留前提条件——二者叠加才有了后面的PRACK/UPDATE舞蹈。
SDP中的a=curr与a=des：precondition框架的状态机。curr表示当前QoS状态（初始为none），des表示期望状态（sendrecv）。状态从none迁移到sendrecv的过程，就是UPDATE消息的职责。

四、SDP Offer/Answer与5G QoS Flow的纵向联动

下表梳理了会话建立过程中两段SDP协商（Offer在INVITE、Answer在183、二次确认在UPDATE）与5G QoS参数的映射关系，这是把"SIP层"翻译成"承载层"的核心：

SDP属性	INVITE(Offer)	183(Answer)	UPDATE(确认)	对应5G QoS参数
`m=audio`	端口待定(如9)	实际端口	锁定	触发专用QoS Flow建立
`a=rtpmap`	EVS/AMR-WB	EVS选中	保持	5QI=1 (GBR, 语音)
`a=curr:qos`	`none sendrecv`	`none sendrecv`	`sendrecv sendrecv`	QoS Flow已建立并双向导通
`a=des:qos`	`sendrecv`	`sendrecv`	`sendrecv`	目标GBR授权值(UL/DL)
`a=mid`/`a=group	多流(可选)	应答	锁定	多QoS Flow FlowID
`a=ice`/`a=rtcp`	候选地址	应答	锁定	N4 PDR匹配5-tuple

这张表的关键洞察是：SDP里的a=curr从none变成sendrecv，物理上对应着5G专用QoS Flow（5QI=1）从"未建立"变成"建立且双向导通"。SIP层的状态机和RAN/UPF承载层的状态机被precondition框架"焊接"在了一起。

五、P-CSCF→PCF→SMF→UPF的QoS授权联动流程

下图把"阶段2"中QoS授权的纵向流程放大，这是VoNR相对VoLTE最值得关注的部分（N5 SBI替代Rx Diameter）：

flowchart TD
    A["P-CSCF解析183<br/>SDP Answer"] -->|提取媒体5-tuple<br/>+GBR需求| B["N5: Npcf_PolicyAuthorization<br/>POST /policies/authorization"]
    B --> C{"PCF策略决策"}
    C -->|授权| D["N7: SM Policy Update<br/>下发PCC Rule<br/>(5QI=1, GBR UL/DL)"]
    D --> E["SMF决策QoS Flow<br/>分配QFI=1"]
    E -->|N4: PFCP Session Mod| F["UPF安装PDR/FAR/QER<br/>(应用检测+门控+限速)"]
    F --> G["SMF触发N2/N1<br/>PDU Session Mod<br/>建立专用QoS Flow"]
    G --> H["(RAN)DRB + (UE)QoS Rule<br/>就绪"]
    H --> I["PCF回N5: 201 Created"]
    I --> J["P-CSCF放行183给主叫UE"]

    style B fill:#fff3e0
    style D fill:#e3f2fd
    style F fill:#e8f5e9

设计意图解读：

为什么P-CSCF要"截获"SDP：P-CSCF是IMS域里唯一既懂SIP/SDP又离PCC策略最近的网元。它把应用层媒体描述（编解码、端口、带宽）翻译成网络层QoS需求，这是"应用感知承载"的核心。
为什么是5QI=1而非5QI=5：5QI=5（non-GBR）承载IMS信令（SIP），5QI=1（GBR，对话语音）承载RTP媒体。一个PDU会话里，信令走默认QoS Flow，语音走专用QoS Flow，二者共用同一个PDU Session但QFI不同。
门控（Gate）机制：PCF下发的PCC Rule含Gate Status，UPF据此在QoS Flow建立前"关门"（丢弃RTP），等183/PRACK/UPDATE完成、资源确认后才"开门"。这保证了用户接通瞬间即有媒体，不会出现"先喂、后断"的体验。

六、SIP会话状态转换

会话建立过程中，主叫UE的SIP Dialog/事务状态机如下（聚焦Early/Confirmed Dialog与precondition状态）：

stateDiagram-v2
    [*] --> Early: 发出INVITE(创建Early Dialog)
    Early --> Early: 收到183(可靠), 发PRACK
    Early --> Early: 收到200(PRACK)
    note right of Early
        precondition状态:
        curr=qos none → sendrecv
    end
    Early --> Early: 本地资源就绪, 发UPDATE
    Early --> Confirmed: 收到200(INVITE), 发ACK
    Confirmed --> [*]: BYE/会话结束
    Early --> [*]: CANCEL/超时(487)

注意"Early Dialog"的存在：在200 OK(INVITE)之前，Dialog已经通过To标签（来自183的tag）建立为Early状态，UPDATE/PRACK都跑在这个Early Dialog上。一旦收到200 OK(INVITE)并发ACK，Dialog才转为Confirmed。这是RFC 3261对话状态模型在IMS会话建立中的体现。

七、抓包实战：如何识别VoNR会话建立流程

在端到端抓包（UE侧或P-CSCF Gi/N5侧）识别该流程的要点：

过滤SIP：sip协议过滤器；会话建立的特征是连续出现 INVITE → 100 → 183 → PRACK → 200 → UPDATE → 200 → 180 → 200 → ACK 这组消息，且Call-ID一致。
定位N5授权：在P-CSCF与PCF之间，过滤 http.request.method == POST 且URI含 /policies/authorization（或老版本Diameter AAR），它一定紧跟在183之后、P-CSCF转发183给UE之前——这是"QoS授权发生在183放行前"的证据。
关联承载建立：在NGAP/N4侧，寻找 PDU Session Resource Modify（N2）和 PFCP Session Modification Request（N4），时间戳应在183与200 OK(INVITE)之间，QFI=1。
验证precondition闭环：检查UPDATE里的a=curr:qos sendrecv sendrecv是否在主叫本地资源就绪后发出，且被叫侧200 OK(UPDATE)确认——这是"双向资源就绪才振铃"的硬证据。

常见故障点与排错思路：

现象	可能原因	排错方向
183后长时间无180/200 OK	QoS Flow建立失败（N5/N7/N4任一环）	查PCF是否下发PCC Rule、SMF是否触发PDU Mod、UPF是否安装PDR
无专用QoS Flow（仅5QI=5）	P-CSCF未触发N5授权，或SDP解析失败	查P-CSCF日志是否解析出媒体流，N5请求是否发出
振铃后接通无声	Gate未打开/媒体5-tuple不匹配	查UPF QER门控状态、SDP端口与PDR匹配
一直卡在PRACK	对端不支持100rel，或Require协商失败	查INVITE的Require头域与对端能力
UPDATE后仍`curr=none`	本地资源预留失败（RAN拒绝GBR）	查NGAP拒绝原因值、CQI/无线资源
## 常见问题

Q1: VoNR和VoLTE的会话建立信令流程本质区别是什么？ A: SIP/SDP层面的INVITE/183/PRACK/UPDATE信令几乎一致（都基于RFC 3261/3262/3312）。本质区别在承载授权接口：VoLTE用P-CSCF↔PCRF的Rx（Diameter）；VoNR用P-CSCF↔PCF的N5（Npcf_PolicyAuthorization，SBI/HTTP），且承载从EPS Bearer变为5G QoS Flow（SMF经N4 PFCP控制UPF）。信令语义同构，承载机制换代。

Q2: 为什么非要PRACK和UPDATE两步，不能直接200 OK吗？ A: 因为183里的SDP Answer是建承载的依据，若临时响应不可靠（丢包则主叫永远收不到Answer），会话会僵死；PRACK（RFC 3262）让183可靠传输。UPDATE（RFC 3311）则在承载建好后更新precondition状态（curr: sendrecv），通知对端"我这边资源好了"。两步分别解决"可靠传输SDP"和"确认资源就绪"两个独立问题。

Q3: 5QI=1和5QI=5分别承载什么？为什么会话建立要建两个？ A: 5QI=5（non-GBR）在IMS注册/PDU会话建立时就建好，承载SIP信令（低优先级、尽力而为）。5QI=1（GBR，对话语音）在会话建立阶段（183后）按需建立，承载RTP媒体（保证比特率、低时延）。二者共用同一PDU Session但QFI不同，分别对应信令面和媒体面。

Q4: precondition状态none→sendrecv如果一直不满足会怎样？ A: 若precondition为mandatory，且本地资源在定时器内无法就绪（如无线拥塞、GBR被拒），UE会发CANCEL终止会话（487 Request Terminated），不会振铃——这正是precondition的设计意图：资源不可用时静默失败，避免用户接起电话却没声音。这也是VoNR"接通即有音"体验背后的协议保障。

参考来源

3GPP TS 24.229 — IP Multimedia Call Control based on SIP and SDP — IMS SIP呼叫控制协议主体规范，定义INVITE/183/PRACK/UPDATE处理。
3GPP TS 23.228 — IP Multimedia Subsystem (IMS) Stage 2 — IMS架构与会话建立Stage 2流程（含MO/MT会话建立）。
VoLTE Originating Call Flow and Procedure (MO Call) — rfwireless-world — MO呼叫信令流程图解，含INVITE到200OK全链。
SIP Signaling in VoLTE and VoNR: Registration, Call Setup, and QoS — 5G6G Academy — VoNR中P-CSCF经N5(SBI)与PCF交互的QoS授权机制解读。
Deep Dive: Policy Control in the VoLTE Call Flow — TelecomHall — PCC/Rx策略控制在呼叫流中的深度分析，QCI=1/5映射。

本文由「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学通信知识星球海报-扫码加入