首页 › ims › VoNR会话释放信令全链拆解

VoNR SIP会话释放与QoS Flow去激活端到端信令全链拆解

一、为什么"挂断"这一下值得拆解

在VoNR/VoLTE的整套IMS信令体系里，被反复讲解的几乎都是"呼叫建立"——INVITE、183、PRACK、 precondition、Rx授权、资源预留……而"挂机释放"这一段往往被一句话带过："发个BYE就行了"。但真正在实验室抓包、现网排障时，70%以上的疑难语音故障都出现在释放阶段：挂不断、僵尸媒体面、漏收话单、QoS Flow残留导致后续呼叫重建失败、跨网回落时话音吞字……这些问题的根因，全部藏在BYE这一条看似简单的请求所牵出的两条并行链路里：

IMS控制面链路：BYE → 200 OK 穿越P-CSCF、S-CSCF、AS（经iFC触发）、对端直至MGCF的端到端会话终结；
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。

graph TB
    A[UE-A 发起 BYE<br/>挂断请求] --> 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跨网场景：

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: ① 暂存或直转<br/>② 触发承载面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<br/>各实体释放对话状态(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保持不动：

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}<br/>(Npcf_PolicyAuthorization_Delete)
    Note over PCF: 移除该AppSession关联的<br/>PCC规则(媒体组件)
    PCF->>SMF: Npcf_SMPolicyControl_UpdateNotify<br/>(删除5QI=1对应PCC规则)
    Note over SMF: 识别QoS Flow QFI=voice<br/>发起PDU Session Modification
    SMF->>UPF: N4 Session Modification<br/>(移除对应N4规则,关闭门控)
    SMF->>RAN: N2 PDU Session Resource Modify<br/>(释放QFI=voice的QoS Flow)
    RAN->>UE: RRC Reconfiguration<br/>(释放语音DRB)
    UE-->>RAN: RRC Reconfiguration Complete
    RAN-->>SMF: N2 PDU Session Resource Modify Response
    Note over UE: 语音媒体承载断开<br/>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层级结构：

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<br/>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侧会话状态为例：

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挂断的关键锚点：

N1/N2侧：找到 PDU Session Resource Modify Command，展开 QosFlowModifyList，若某条QFI标记 REMOVE 且该QoS Flow的5QI=1，即为语音承载去激活。若同时整个PDU Session Release，则说明连信令腿一起拆了（通常是注销场景）。
N7/N5侧（HTTP/2）：搜索 DELETE 方法访问 .../policies/... 或 .../app-sessions/... 路径，对应 Npcf_PolicyAuthorization_Delete；PCF→SMF侧则看 POST .../sm-policies/.../update 通知。
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等。

参考来源

3GPP TS 24.229 — IP multimedia call control protocol based on SIP and SDP — 第5章 IP multimedia call related procedures，含BYE/Reason/P-Charging-Vector处理与各CSCF实体释放流程
3GPP TS 23.228 — Service requirements for the IP Multimedia Core Network Subsystem — IMS架构与会话释放基本原则（含P-CSCF代发BYE场景）
3GPP TS 29.514 — Npcf_PolicyAuthorization Service — 5G AF(PCF)授权服务，定义Create/Update/Delete/Notify操作（VoNR的N5接口）
3GPP TS 29.512 — Npcf_SMPolicyControl Service — PCF↔SMF策略修改，QoS Flow级PCC规则下发与删除
3GPP TS 23.502 — Procedures for the 5G System — §4.3.3 PDU Session Modification、§4.3.4 PDU Session Release
5G Voice Architecture, IMS, VoNR Call Flow — 3GLTEInfo — VoNR端到端架构与呼叫/释放流程图解
RFC 3261 (SIP) §15 & RFC 3326 (Reason Header Field) — 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 等场景全覆盖。

51学通信知识星球海报-扫码加入