# 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` 搞晕。这背后是 **两个约束**的叠加： 1. **媒体面与信令面解耦**：SIP信令走默认QoS Flow（5QI=5），而语音RTP媒体必须走专用GBR QoS Flow（5QI=1）。专用承载要先于"振铃"建立，否则用户接起电话却没声音。 2. **可靠临时响应机制（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授权联动： ```mermaid 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
提取媒体流描述 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组成： ```mermaid flowchart TB subgraph INV["SIP INVITE 消息结构"] direction TB RL["Request-URI
被叫tel:/sip: URI"] F["From / To / Call-ID / CSeq
(Dialog标识三件套)"] VIA["Via
(逐跳路由回程路径)"] SR["Route
(松散路由, 来自Service-Route)"] PAI["P-Asserted-Identity
(主叫已鉴权真实号码)"] PR["P-Preferred-Service
(业务标识, 触发iFC)"] REQ["Require: precondition, 100rel
(强制资源预留+可靠临时响应)"] ACC["Accept-Contact: +g.3gpp.icsi-ref
(MMTel业务能力协商)"] SDP["Body: SDP Offer
(m=audio, a=rtpmap EVS,
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）： ```mermaid flowchart TD A["P-CSCF解析183
SDP Answer"] -->|提取媒体5-tuple
+GBR需求| B["N5: Npcf_PolicyAuthorization
POST /policies/authorization"] B --> C{"PCF策略决策"} C -->|授权| D["N7: SM Policy Update
下发PCC Rule
(5QI=1, GBR UL/DL)"] D --> E["SMF决策QoS Flow
分配QFI=1"] E -->|N4: PFCP Session Mod| F["UPF安装PDR/FAR/QER
(应用检测+门控+限速)"] F --> G["SMF触发N2/N1
PDU Session Mod
建立专用QoS Flow"] G --> H["(RAN)DRB + (UE)QoS Rule
就绪"] 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状态）： ```text 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侧）识别该流程的要点： 1. **过滤SIP**：`sip`协议过滤器；会话建立的特征是连续出现 `INVITE → 100 → 183 → PRACK → 200 → UPDATE → 200 → 180 → 200 → ACK` 这组消息，且Call-ID一致。 2. **定位N5授权**：在P-CSCF与PCF之间，过滤 `http.request.method == POST` 且URI含 `/policies/authorization`（或老版本Diameter `AAR`），它一定紧跟在183之后、P-CSCF转发183给UE之前——这是"QoS授权发生在183放行前"的证据。 3. **关联承载建立**：在NGAP/N4侧，寻找 `PDU Session Resource Modify`（N2）和 `PFCP Session Modification Request`（N4），时间戳应在183与200 OK(INVITE)之间，QFI=1。 4. **验证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"接通即有音"体验背后的协议保障。 ## 参考来源 1. [3GPP TS 24.229 — IP Multimedia Call Control based on SIP and SDP](https://www.3gpp.org/dynareport?24229.htm) — IMS SIP呼叫控制协议主体规范，定义INVITE/183/PRACK/UPDATE处理。 2. [3GPP TS 23.228 — IP Multimedia Subsystem (IMS) Stage 2](https://www.3gpp.org/dynareport?23228.htm) — IMS架构与会话建立Stage 2流程（含MO/MT会话建立）。 3. [VoLTE Originating Call Flow and Procedure (MO Call) — rfwireless-world](https://www.rfwireless-world.com/terminology/volte-originating-call-flow) — MO呼叫信令流程图解，含INVITE到200OK全链。 4. [SIP Signaling in VoLTE and VoNR: Registration, Call Setup, and QoS — 5G6G Academy](https://www.5g6gacademy.com/learn/sip-volte-vonr) — VoNR中P-CSCF经N5(SBI)与PCF交互的QoS授权机制解读。 5. [Deep Dive: Policy Control in the VoLTE Call Flow — TelecomHall](https://www.telecomhall.net/t/deep-dive-policy-control-in-the-volte-call-flow/31822) — 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 等场景全覆盖。