# VoNR SIP会话释放与QoS Flow去激活端到端信令全链拆解 ## 一、为什么"挂断"这一下值得拆解 在VoNR/VoLTE的整套IMS信令体系里，被反复讲解的几乎都是"呼叫建立"——INVITE、183、PRACK、 precondition、Rx授权、资源预留……而"挂机释放"这一段往往被一句话带过："发个BYE就行了"。但真正在实验室抓包、现网排障时，**70%以上的疑难语音故障都出现在释放阶段**：挂不断、僵尸媒体面、漏收话单、QoS Flow残留导致后续呼叫重建失败、跨网回落时话音吞字……这些问题的根因，全部藏在BYE这一条看似简单的请求所牵出的**两条并行链路**里： 1. **IMS控制面链路**：`BYE → 200 OK` 穿越P-CSCF、S-CSCF、AS（经iFC触发）、对端直至MGCF的端到端会话终结； 2. **5GC策略与承载链路**：P-CSCF（作为AF）通过N5向PCF发起 `Npcf_PolicyAuthorization_Delete`，PCF经N7驱动SMF，SMF经N4/N2驱动UPF与(R)AN，最终把承载语音媒体的 **GBR QoS Flow（5QI=1）** 去激活——而承载SIP信令的 **5QI=5** 默认QoS Flow则保留。 这两条链路在时序上必须协同：控制面过早终结会导致媒体面孤儿流，媒体面过早去激活又会掐断最后几百毫秒的话音包。本文依据 **TS 24.229（IMS呼叫控制）、TS 23.228（IMS架构与释放原则）、TS 29.514（Npcf_PolicyAuthorization）、TS 29.512（Npcf_SMPolicyControl）、TS 23.502（5GC流程）** 把这条全链逐信令、逐IE地拆开。 --- ## 二、机制全景：一条BYE引出两条链路 VoNR会话释放本质上是 **"双轨去激活"**： - **轨道A（控制面）**：由SIP BYE（RFC 3261 §15）触发，经TS 24.229第5章定义的各实体逐跳处理，携带 `Reason` 头（RFC 3326）传递释放原因码，并携带 `P-Charging-Vector` 完成跨域计费关联。AS依据iFC（Initial Filter Criteria）对BYE做业务触发——例如预付费AS在余额耗尽时**主动发起**BYE。 - **轨道B（媒体/承载面）**：P-CSCF在收到/发出BYE后，必须把此前为媒体组件授权的资源交还给网络。5G中这一动作通过 **N5 = Npcf_PolicyAuthorization** 接口（功能上等价于EPC时代的Rx，TS 29.214）完成；PCF再经 **N7 = Npcf_SMPolicyControl** 通知SMF，SMF执行 **PDU Session Modification** 流程（TS 23.502 §4.3.3），只释放语音GBR QoS Flow，而非整个PDU Session。 ```mermaid graph TB A[UE-A 发起 BYE
挂断请求] --> B{P-CSCF-A} B -->|轨道A: SIP控制面| C[S-CSCF-A] C --> D[AS-A 经iFC触发] D --> C C -->|经I-CSCF| E[S-CSCF-B / P-CSCF-B] E --> F[UE-B 收到 BYE] F -->|200 OK| E B -.->|轨道B: 5GC承载面| G[PCF Npcf_PolicyAuthorization_Delete] G --> H[SMF Npcf_SMPolicyControl_UpdateNotify] H --> I[UPF N4 Session Modification] H --> J[RAN N2 PDU Session Resource Modify] J --> K[UE-A RRC Reconfig 释放语音DRB] style A fill:#e8f5e9 style F fill:#fff3e0 style K fill:#fce4ec ``` 上图清晰展示了BYE请求在控制面（实线）与承载面（虚线）的双轨分发。下面分别拆解。 --- ## 三、轨道A：SIP BYE端到端信令时序 下图是 **UE-A（主叫）正常发起挂断**的完整时序，囊括了iFC业务触发与MGCF跨网场景： ```mermaid sequenceDiagram participant UEA as UE-A (主叫) participant PCSCFA as P-CSCF-A participant SCSCFA as S-CSCF-A participant AS as AS (iFC触发) participant SCSCFB as S-CSCF-B participant PCSCFB as P-CSCF-B participant UEB as UE-B (被叫) UEA->>PCSCFA: BYE (Route, Reason, P-Charging-Vector) Note over PCSCFA: ① 暂存或直转
② 触发承载面QoS去激活 PCSCFA->>SCSCFA: BYE SCSCFA->>AS: BYE (匹配iFC, 触发业务逻辑) AS-->>SCSCFA: 200 OK (BYE) 或继续透传 SCSCFA->>SCSCFB: BYE (经S-CSCF路由, 可能经I-CSCF) SCSCFB->>PCSCFB: BYE PCSCFB->>UEB: BYE UEB-->>PCSCFB: 200 OK (BYE) PCSCFB-->>SCSCFB: 200 OK SCSCFB-->>SCSCFA: 200 OK SCSCFA-->>PCSCFA: 200 OK PCSCFA-->>UEA: 200 OK (BYE) Note over UEA,UEB: 会话状态: Terminated
各实体释放对话状态(Dialog State) ``` ### 3.1 逐跳处理要点 - **UE-A → P-CSCF-A**：BYE的Request-URI指向对端Contact，`Route`头携带P-CSCF在注册时下发的Service-Route集，确保第一跳回到服务自己的P-CSCF。`From/To`的tag必须与建立会话时INVITE/200 OK的tag完全一致——这是Dialog识别的依据（RFC 3261 §12）。 - **P-CSCF-A**：作为AF，它在收到BYE后有两个关键动作——(a) 关闭/移除本端媒体门控（gating），(b) 通过N5通知PCF去激活QoS（见第四节）。注意P-CSCF**可以先转发BYE再异步做QoS去激活**，也可先去激活再转发，实现差异取决于厂商对"末段话音完整性"与"资源及时释放"的权衡。 - **S-CSCF-A → AS**：S-CSCF依据该用户的iFC对BYE做触发。BYE是"会话级"请求，通常匹配那些 `Trigger Point` 中包含 `Session Case = Terminating/Originating` 且方法集含BYE的过滤规则。预付费AS、录音AS、计费AS常在此挂接，用于**关闭计费表（stop charging）**。 - **跨域/跨网**：若被叫在CS域（如回落用户），BYE在MGCF处映射为ISUP **REL**（Release），并完成SIP Reason到 **Q.850 cause** 的转换（TS 29.163）。 --- ## 四、BYE消息关键IE解析 BYE虽不携带SDP（按RFC 3261，BYE禁止携带会话描述），但其头部IE信息密度极高。下表给出每个关键IE的作用、规范来源与抓包识别要点。 | IE / 头域 | 规范来源 | 作用 | 抓包识别要点 | |---|---|---|---| | `Reason` | RFC 3326 / TS 24.229 | 传递释放原因码，支持SIP/Q.850两种cause空间 | `Reason: Q.850;cause=16;text="Normal Clearing"` 为正常挂断；cause=17/21/88 分别对应忙/拒接/不兼容 | | `P-Charging-Vector` | TS 24.229 §5.6 | 携带icid/ioi，跨域跨实体关联计费话单 | 必须与INVITE时生成的 `icid` 一致；BYE的term_ioi标识释放发起域 | | `Route` | RFC 3261 / TS 24.229 | 严格路由回Service-Route集 | 失踪或错误会导致BYE被错误路由甚至丢失 | | `From/To + tag` | RFC 3261 §12 | Dialog标识 | tag不匹配=对话不存在，应答481 Call/Transaction Does Not Exist | | `P-Asserted-Identity` | RFC 3325 | 标识真实主叫 | BYE中携带便于AS/计费核对身份 | | `Session-Expires / Min-SE` | RFC 4028 | 会话定时器协商结果 | 若会话因定时器超时释放，REFRESH失败会触发BYE | | `Max-Forwards` | RFC 3261 | 防环路计数 | 现网常见配70；持续递减到0说明存在环 | > **设计意图**：把"原因码"独立成 `Reason` 头而非塞进BYE体，是为了在 **不破坏端到端透明性** 的前提下，让沿途每个实体（含AS、MGCF、计费网关）都能无歧义地解读释放原因。而 `P-Charging-Vector` 把一次性icid随每个请求/响应携带，则是3GPP为了在"无状态代理"的SIP哲学下仍能**端到端关联计费**而专门设计的钩子（hook）。 --- ## 五、轨道B：5GC QoS Flow去激活子链 这是VoNR区别于VoLTE、也最容易被忽视的一段。下图给出 **语音GBR QoS Flow（5QI=1）去激活** 的完整时序，注意5QI=5（IMS信令）默认QoS Flow保持不动： ```mermaid sequenceDiagram participant PCSCF as P-CSCF (AF) participant PCF as PCF participant SMF as SMF participant UPF as UPF participant RAN as gNB participant UE as UE-A PCSCF->>PCF: DELETE /policies/{appSessionId}
(Npcf_PolicyAuthorization_Delete) Note over PCF: 移除该AppSession关联的
PCC规则(媒体组件) PCF->>SMF: Npcf_SMPolicyControl_UpdateNotify
(删除5QI=1对应PCC规则) Note over SMF: 识别QoS Flow QFI=voice
发起PDU Session Modification SMF->>UPF: N4 Session Modification
(移除对应N4规则,关闭门控) SMF->>RAN: N2 PDU Session Resource Modify
(释放QFI=voice的QoS Flow) RAN->>UE: RRC Reconfiguration
(释放语音DRB) UE-->>RAN: RRC Reconfiguration Complete RAN-->>SMF: N2 PDU Session Resource Modify Response Note over UE: 语音媒体承载断开
IMS信令(5QI=5)仍在 ``` ### 5.1 关键服务操作与接口 - **Npcf_PolicyAuthorization_Delete（N5）**：定义于 **TS 29.514**。P-CSCF用HTTP `DELETE` 方法移除AppSession资源；PCF据此删除关联的PCC规则（即呼叫建立时 `Npcf_PolicyAuthorization_Create` 创建的语音媒体组件授权）。注意在5G中此接口即 **N5**，规范服务名为Npcf_PolicyAuthorization，但业界仍习惯沿用"Rx"叫法。 - **Npcf_SMPolicyControl_UpdateNotify（N7）**：定义于 **TS 29.512**。PCF以PCF发起的方式通知SMF修改SM策略，下发"删除PCC规则"指令。SMF据此找到对应的 **QFI**（语音QoS Flow）。 - **N4 Session Modification**：SMF→UPF（TS 29.244 PFCP）。移除该QoS Flow的N4规则，关闭门控（apply-action中的 `DROP`/`FORW` 移除），停止媒体转发。 - **N2 PDU Session Resource Modify**：这是 **PDU Session Modification流程**（TS 23.502 §4.3.3），而非PDU Session Release。SMF通过 `PDUSessionResourceModifyList` 携带要释放的QFI，gNB据此释放语音DRB并回RRC Reconfiguration给UE。**整个IMS PDU Session（5QI=5信令承载）仍然存活**，这是VoNR"挂断不影响后续注册/呼叫信令"的关键。 ### 5.2 IE结构：N2 PDU Session Resource Modify 携带的释放信息 下图展示SMF经N2下发时，修改请求中与"语音QoS Flow去激活"相关的IE层级结构： ```mermaid graph TD N2[N2 PDUSessionResourceModifyRequest] --> P[PDU Session ID] N2 --> ML[PDU Session Resource Modify List] ML --> Item[PDUSessionResourceModifyItem] Item --> CID[PDU Session Resource Setup/Modify Transfer] CID --> QFList[QosFlowModifyList] QFList --> QFI[Qos Flow Identifier
QFI=voice, 5QI=1] QFList --> Op[操作类型: REMOVE] QFList --> UL[对应UL/TEID与DRB映射移除] style Op fill:#ffe0b2 style QFI fill:#c8e6c9 ``` > **设计意图**：3GPP用"PDU Session Modification"而非"Release"来处理单媒体流释放，是为了**复用同一IMS PDU Session**承载多条会话的信令。一次通话结束只摘掉5QI=1这条GBR腿，5QI=5这条non-GBR腿继续跑SIP——下一次呼叫建立时无需重新建PDU Session，显著降低后续呼叫的接入时延。这就是为什么"挂断后立刻重拨"通常比"冷启呼叫"快。 --- ## 六、会话状态机：从Confirmed到Terminated 从协议状态视角看，释放是UE与各CSCF实体 **Dialog FSM** 的最后一次迁移。下图以UE侧会话状态为例： ```mermaid stateDiagram-v2 [*] --> Early: 183/PRACK 完成(预条件满足) Early --> Confirmed: 200 OK(INVITE) + ACK Confirmed --> Terminating: 发送或接收 BYE / 4xx·5xx·6xx Confirmed --> Terminating: 无线承载丢失(P-CSCF代发BYE) Terminating --> Terminated: 收/发 200 OK(BYE) 且 QoS已去激活 Terminating --> Terminated: 超时未收响应 → 清理本地状态 Terminated --> [*]: 释放Dialog, 删除路由状态, 计费落单 ``` 值得注意的是**第4条迁移（无线承载丢失→P-CSCF代发BYE）**：当UE掉网（如进电梯、RLF无法恢复），UE根本来不及发BYE。此时gNB→SMF感知链路断，PCF经 `Npcf_PolicyAuthorization_Notify`（事件订阅）回报P-CSCF"资源已不可用"，**P-CSCF代表UE向对端发起BYE**（TS 24.229，携带适当Reason）。这是VoNR"幽灵通话"防护的核心机制——没有它，对端会一直听到静音直到会话定时器超时（默认可能数分钟）。 --- ## 七、三种典型释放场景对比 实际网络中释放并非千篇一律，下表对照三种最常见场景，突出"谁发BYE""QoS去激活方向""话单处理"的差异： | 维度 | 场景一：UE正常挂断 | 场景二：网络/AS主动释放 | 场景三：无线丢失触发的网络释放 | |---|---|---|---| | 触发源 | 用户按挂断键 | 预付费余额耗尽、AS业务逻辑、运营商介入 | RLF/覆盖丢失、gNB判定UE不可达 | | 谁发BYE | UE-A | AS（经S-CSCF注入）或P-CSCF | **P-CSCF代发**（UE已失联） | | 典型Reason | `Q.850;cause=16` Normal Clearing | `SIP;cause=403` 或 `cause=503`/业务自定义 | `Q.850;cause=41/47/127` 临时失败/资源不可用/互操作 | | QoS去激活方向 | P-CSCF→PCF→SMF（主被叫双向） | 由发起AS侧触发，向两侧扇出 | gNB→SMF先感知，再反向通知P-CSCF | | 话单处理 | 正常停止计费，MSCC final unit | AS生成业务话单，CTF生成最终话单 | 需特别标记"异常释放"，避免错误计费 | | 排障关注点 | 200 OK是否回齐 | iFC是否匹配、AS是否及时回200 | Notify是否到达、代发BYE时延 | --- ## 八、实战连接：抓包识别与常见故障 ### 8.1 抓包如何识别释放流程 在5GC综合抓包（N1 NAS + N2 NGAP + N4 PFCP + N7/N5 SBI HTTP/2 + SIP）中，定位一次VoNR挂断的关键锚点： 1. **N1/N2侧**：找到 `PDU Session Resource Modify Command`，展开 `QosFlowModifyList`，若某条QFI标记 `REMOVE` 且该QoS Flow的5QI=1，即为语音承载去激活。若同时整个PDU Session Release，则说明连信令腿一起拆了（通常是注销场景）。 2. **N7/N5侧（HTTP/2）**：搜索 `DELETE` 方法访问 `.../policies/...` 或 `.../app-sessions/...` 路径，对应 `Npcf_PolicyAuthorization_Delete`；PCF→SMF侧则看 `POST .../sm-policies/.../update` 通知。 3. **SIP侧**：一条BYE + 回200 OK，检查 `Reason`、`P-Charging-Vector` 的icid是否与INVITE一致。若icid不一致，几乎可断定计费会脱节。 ### 8.2 常见故障点与排错思路 - **挂断后有约200ms"尾巴"杂音或吞字**：多为P-CSCF**先转发BYE再去激活QoS**，导致对端收到BYE前媒体门控已提前关闭，或反向残留流。排查P-CSCF的去激活时序策略。 - **QoS Flow残留（资源泄漏）**：N5 DELETE发出但PCF未驱动N7，或SMF N4未及时清理。表现为gNB侧DRB未释放、后续呼叫重建失败。重点查 `Npcf_PolicyAuthorization_Delete` 的HTTP响应码与SMF侧日志。 - **僵尸会话/幽灵通话**：场景三的代发BYE链路未生效——UE已掉线但P-CSCF未收到Notify或未代发。检查PCF事件订阅（`QOS_NOTIFICATION`/资源不可用事件）是否正确订阅与上报。 - **跨网回落时REL/BYE映射错**：MGCF处cause码映射错误，导致对端显示"对方正忙"实为"正常挂断"。核对TS 29.163的cause映射表与MGCF配置。 ## 九、常见问题 **Q1：挂断时为什么通常只释放5QI=1，而不释放整个PDU Session？** A：因为IMS PDU Session的5QI=5默认QoS Flow承载SIP信令，需要为后续注册刷新、新呼叫建立、补充业务信令保持通道。整PDU Session只在IMS注销或紧急呼叫专用承载等少数场景才拆除。这是PDU Session Modification（TS 23.502 §4.3.3）而非Release的应用。 **Q2：N5、Rx、Npcf_PolicyAuthorization到底什么关系？** A：Rx（TS 29.214）是EPC时代P-CSCF与PCRF之间的参考点；到了5G，等价功能演化为P-CSCF(AF)与PCF之间的N5接口，规范服务名为 **Npcf_PolicyAuthorization**（TS 29.514）。功能本质相同（媒体组件授权、门控、事件订阅），所以业界文档常混用"Rx"指代。本文涉及的删除操作即 `Npcf_PolicyAuthorization_Delete`。 **Q3：BYE为什么不能带SDP做最后的编解码协商？** A：RFC 3261 §15.1明确禁止BYE携带消息体。会话描述的任何变更（如改EVS速率）必须在会话**存在期间**用 re-INVITE 或 UPDATE 完成；BYE一旦发出即表示对话终结，再协商无意义。若需在释放前切换媒体参数，规范要求先UPDATE再BYE。 **Q4：无线丢失时UE没发BYE，对端怎么知道通话结束？** A：依赖 **P-CSCF代发BYE**。gNB/SMF感知UE不可达，PCF经事件订阅回报P-CSCF，P-CSCF代表失联UE向对端发BYE并携带Reason（如cause=41/47）。这是防止幽灵通话的关键，配置上要确保P-CSCF订阅了PCF的资源状态事件。 **Q5：Reason头里cause=16和SIP的200是一回事吗？** A：不是。`Reason: Q.850;cause=16` 是 **ISUP/Q.850原因码空间**（Normal Clearing），而BYE的SIP响应码是200（表示"成功处理了BYE请求"）。前者描述"为什么结束会话"，后者描述"BYE这个请求处理结果"。二者正交——网络主动异常释放时，BYE本身仍回200，但Reason可能是403/503等。 --- ## 参考来源 1. [3GPP TS 24.229 — IP multimedia call control protocol based on SIP and SDP](https://www.3gpp.org/dynareport/24229.htm) — 第5章 IP multimedia call related procedures，含BYE/Reason/P-Charging-Vector处理与各CSCF实体释放流程 2. [3GPP TS 23.228 — Service requirements for the IP Multimedia Core Network Subsystem](https://www.3gpp.org/dynareport/23228.htm) — IMS架构与会话释放基本原则（含P-CSCF代发BYE场景） 3. [3GPP TS 29.514 — Npcf_PolicyAuthorization Service](https://www.3gpp.org/dynareport/29514.htm) — 5G AF(PCF)授权服务，定义Create/Update/Delete/Notify操作（VoNR的N5接口） 4. [3GPP TS 29.512 — Npcf_SMPolicyControl Service](https://www.3gpp.org/dynareport/29512.htm) — PCF↔SMF策略修改，QoS Flow级PCC规则下发与删除 5. [3GPP TS 23.502 — Procedures for the 5G System](https://www.3gpp.org/dynareport/23502.htm) — §4.3.3 PDU Session Modification、§4.3.4 PDU Session Release 6. [5G Voice Architecture, IMS, VoNR Call Flow — 3GLTEInfo](https://www.3glteinfo.com/5g/architecture/vonr/) — VoNR端到端架构与呼叫/释放流程图解 7. [RFC 3261 (SIP) §15 & RFC 3326 (Reason Header Field)](https://www.rfc-editor.org/rfc/rfc3261) — BYE语义与Reason头规范基础 --- > 本文由「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 等场景全覆盖。