VoNR SIP会话定时器（Session Timer）刷新机制全链拆解

一、为什么IMS会话需要一个"心跳"

SIP协议本身是一个无状态的呼叫建立协议——它只负责协商出一个会话（通过INVITE/200 OK/ACK三向握手），此后媒体流由RTP承载，信令面就"沉默"了。这种设计带来一个致命问题：当某一侧崩溃、断电、无线链路中断或信令链路被悄悄拆除时，对端无从感知，会话状态会一直挂在网络里，成为"僵死会话"（ghost call / stale session）。

在VoLTE/VoNR场景下，一个僵死会话的代价远超企业IP电话：它持续占用着一个专用QoS流（5QI=1的GBR承载），消耗着传输资源、P-CSCF/会话状态机内存，以及为该会话授权的保证比特率（GBR）。运营商网络的呼损率、寻呼容量、无线资源调度都会因此恶化。

为根治这个问题，IETF在RFC 4028《Session Timers in the Session Initiation Protocol (SIP)》中定义了会话定时器（Session Timer）扩展，3GPP在其IMS呼叫控制规范 TS 24.229 中将其强制纳入UE与P-CSCF的必选能力。本文聚焦VoNR/VoLTE网络中会话定时器的协商、刷新与超时释放全信令链，逐一拆解每个Information Element的设计意图与工程实战。

二、协议根基：RFC 4028 与 3GPP TS 24.229

会话定时器是一个跨IETF与3GPP的复合机制，其规范来源分两层：

3GPP TS 24.229 Section 7.7（SIP定时器）明确列出：会话定时器相关的 Min-SE 默认取值为 90秒，Session-Expires 由UE与P-CSCF协商确定，典型值在VoNR网络中为 1800秒（30分钟） 或 3600秒（1小时）。P-CSCF被要求在所有发往UE的INVITE/UPDATE中插入或校验 Session-Expires 头域，这是VoNR中"网络侧主导会话活性管理"的法律依据。

三、核心机制：三个头域与一个响应码

会话定时器的全部威力浓缩在三个SIP头域和一个响应码中。

3.1 IE结构总览图

graph TD
    A["会话定时器IE体系<br/>RFC 4028 / TS 24.229"] --> B["Session-Expires 头域"]
    A --> C["Min-SE 头域"]
    A --> D["Supported/Require: timer 选项标签"]
    A --> E["422 Session Interval Too Small 响应"]

    B --> B1["参数: delta-seconds<br/>会话存活总时长(秒)"]
    B --> B2["参数: refresher=uac/uas<br/>指定谁发起刷新"]

    C --> C1["参数: delta-seconds<br/>可接受的最小刷新间隔"]
    C --> C2["默认值: 90秒<br/>(TS 24.229 §7.7)"]

    D --> D1["Supported: timer<br/>声明支持会话定时器"]
    D --> D2["Require: timer<br/>强制对端启用"]

    E --> E1["触发条件: Session-Expires < 对端Min-SE"]
    E --> E2["必须携带Min-SE告知重试值"]

    style B fill:#e1f5ff,stroke:#0277bd
    style E fill:#fff3e0,stroke:#ef6c00
    style C fill:#f3e5f5,stroke:#6a1b9a

3.2 关键IE参数说明表

四、完整信令时序：从协商到超时释放

下图为VoNR网络中一次会话定时器完整生命周期的时序，覆盖了初始协商失败→422重协商→正常刷新→超时强制释放四种路径。

sequenceDiagram
    autonumber
    participant UE as UE(主叫)
    participant PCSCF as P-CSCF
    participant SCSCF as S-CSCF
    participant Term as 被叫UE

    Note over UE,PCSCF: 阶段1: 初始INVITE(间隔过小)
    UE->>PCSCF: INVITE<br/>Supported: timer<br/>Session-Expires: 60;refresher=uac<br/>Min-SE: 60
    Note right of PCSCF: P-CSCF策略Min-SE=90<br/>60 < 90 → 拒绝
    PCSCF-->>UE: 422 Session Interval Too Small<br/>Min-SE: 90
    Note left of UE: 学习到对端Min-SE

    Note over UE,PCSCF: 阶段2: 重协商INVITE(合规)
    UE->>PCSCF: INVITE(重试)<br/>Require: timer<br/>Session-Expires: 1800;refresher=uac<br/>Min-SE: 90
    PCSCF->>SCSCF: INVITE<br/>Session-Expires: 1800;refresher=uac
    SCSCF->>Term: 透传INVITE
    Term-->>SCSCF: 200 OK<br/>Session-Expires: 1800;refresher=uas
    Note right of SCSCF: UAS可反转refresher角色
    SCSCF-->>PCSCF: 200 OK
    PCSCF-->>UE: 200 OK<br/>Session-Expires: 1800;refresher=uas
    UE->>PCSCF: ACK

    Note over UE,PCSCF: 阶段3: 周期刷新(由refresher=uas方发起)
    Note right of PCSCF: 间隔1/2处(900s)发起刷新<br/>P-CSCF自荐为UAS刷新方
    PCSCF->>UE: UPDATE(Session-Expires: 1800;refresher=uas)
    UE-->>PCSCF: 200 OK(Session-Expires: 1800;refresher=uas)
    PCSCF->>PCSCF: 重置会话时钟

    Note over UE,PCSCF: 阶段4: 超时/刷新失败 → 强制释放
    Note right of PCSCF: 刷新UPDATE无响应<br/>T1重传耗尽 + 等待至间隔到期
    PCSCF->>PCSCF: 触发Rx会话终止<br/>AAR(NAS-Request)释放GBR承载
    PCSCF-->>UE: BYE(Reason: timer)
    Note left of UE: 会话状态机清理

4.1 逐步解析关键消息

步骤1-2：初始协商与422拒绝。 UE在初始INVITE中提议 Session-Expires: 60 并自荐为uac刷新方。P-CSCF根据TS 24.229本地策略（Min-SE=90）发现60秒低于下限，不修改INVITE直接以422回拒，并在422中回带 Min-SE: 90。RFC 4028规定：422是Session Timer协商失败的唯一正确响应，且必须携带Min-SE，否则UE无法知道该用多大的间隔重试，会陷入"猜测—被拒"的死循环。

步骤3-8：合规重协商。 UE以 Session-Expires: 1800 重发INVITE。注意被叫UE在200 OK中将 refresher 从 uac 反转为 uas——RFC 4028允许UAS在2xx中修改refresher角色，2xx中的Session-Expires头域为最终生效值。这意味着最终由被叫侧（在VoNR中通常就是P-CSCF代为发起）承担刷新责任。

步骤9-11：周期刷新。 refresh方在会话间隔的约一半时刻发起UPDATE（本例900秒）。RFC 4028规定刷新方在间隔1/2处首次尝试，若失败则按T1定时器（500ms）重传，直到间隔到期仍未成功才判定会话失效。UPDATE相比re-INVITE的优势是不触发媒体重协商、不改变Dialog ID，开销极小。

步骤12-14：超时强制释放。 当刷新UPDATE持续无响应直至间隔到期，P-CSCF判定会话已僵死，先通过Rx/N5接口向PCF发送AAR释放该会话的专用QoS流，再向UE发BYE。这一步是VoNR区别于企业SIP的核心：会话定时器不仅清理信令状态，更联动释放无线与传输面资源。

五、Refresher角色协商状态机

"谁来刷新"是会话定时器最易出错的部分。下图描绘UAC与UAS在INVITE/2xx往返中如何最终确定刷新方，以及异常分支。

stateDiagram-v2
    [*] --> 发起INVITE: UAC插入<br/>Session-Expires;refresher=uac

    发起INVITE --> 收到2xx: 协商成功
    发起INVITE --> 收到422: 间隔过小
    发起INVITE --> [*]: 其他失败响应

    收到422 --> 发起INVITE: 按Min-SE调整后重试
    note right of 收到422
        RFC4028: UAC不得用旧值重试
        必须采用422中的Min-SE
    end note

    收到2xx --> 判定refresher
    note right of 判定refresher
        优先级规则:
        1) 2xx带refresher → 以2xx为准
        2) 仅INVITE带refresher → UAC刷新
        3) 都没带 → 双方都不刷新(向后兼容)
    end note

    判定refresher --> UAC刷新: refresher=uac
    判定refresher --> UAS刷新: refresher=uas

    UAC刷新 --> 周期UPDATE_UAC: 间隔1/2处
    UAS刷新 --> 周期UPDATE_UAS: 间隔1/2处

    周期UPDATE_UAC --> 会话存活: 收到2xx
    周期UPDATE_UAS --> 会话存活: 收到2xx

    周期UPDATE_UAC --> 释放会话: 超时无响应
    周期UPDATE_UAS --> 释放会话: 超时无响应

    释放会话 --> [*]: 发送BYE + 释放QoS
    会话存活 --> [*]: 正常挂断BYE

设计意图解读： RFC 4028之所以把"刷新方"也放进协商而非固定由UAC负责，是为了让网络能力更强、电源不受限的一方（如P-CSCF）主动承担刷新，避免移动终端因频繁发送re-INVITE而耗电。这也是为什么运营商网络中P-CSCF几乎总是通过 Require: timer 并在2xx中把自己设为 refresher=uas 的原因。

六、VoNR中的工程集成：P-CSCF如何"主导"会话活性

在5G VoNR架构中，P-CSCF（通过SMF+UPF接入，经N3IWF或直接5G接入）扮演会话定时器的执行中心角色，其行为严格遵循TS 24.229 §5.1.2.2.2：

1. 强制启用：P-CSCF对所有IMS语音会话插入 Require: timer，即使UE只声明 Supported: timer。这是运营商策略，确保无一台"懒惰终端"能逃过保活。
2. 自荐刷新方：P-CSCF作为B2BUA（背靠背用户代理），在向UE的下游2xx中将自己设为 refresher=uas，由网络侧周期下发UPDATE，减轻UE负担。
3. 联动PCF释放承载：当会话定时器超时，P-CSCF不止发BYE，更通过 Rx/N5接口的AAR（Abort-Request语义） 通知PCF，PCF经SMF触发N4会话修改，释放该PDU会话内5QI=1的GBR专用QoS流。这条链路是VoNR中Session Timer价值的"兑现点"。
4. 最小间隔策略：P-CSCF的Min-SE通常配置为90~120秒，既防止信令风暴，又保证UE在切换/重建后能在合理时间内重新对齐。

值得注意的是，在5G非可信非3GPP接入（经N3IWF）场景下，re-INVITE/UPDATE需穿越IPSec隧道，刷新报文的延迟和丢包概率高于5G NR直连，因此运营商倾向于为非3GPP接入配置更短的Session-Expires（如600秒），以更快感知UE掉线。

七、抓包识别与故障排错

7.1 抓包如何识别会话定时器流程

在Wireshark中过滤SIP，识别会话定时器的关键标志： - INVITE中含 Session-Expires 或 Supported/Require: timer → 会话定时器已启用； - 出现422响应 → 协商失败，检查422中的Min-SE； - 周期性出现的UPDATE，且无SDP或SDP未变 → 刷新报文； - 会话超时后的BYE，Reason头含 cause=200;text="timer" → 定时器触发的释放。

可用显示过滤表达式：sip.Session_Expires or sip.Min_SE or sip.Status-Code == 422。

7.2 常见故障点

九、常见问题

Q1：会话定时器和RTP/RTCP保活、媒体面DFD（Dead UE Detection）是什么关系？ A：二者互补。会话定时器工作在信令面（SIP re-INVITE/UPDATE），保证SIP状态机和P-CSCF对会话活性的认知；RTP/RTCP保活工作在媒体面，靠RTCP RR/SR或RTP静默包检测媒体链路是否通畅。VoNR中两者都启用：信令面超时发BYE，媒体面长时间无RTP同样可触发P-CSCF的"媒体超时"释放。会话定时器是"信令级"的兜底。

Q2：为什么被叫UE在200 OK里把refresher从uac改成了uas，这是规范允许的吗？ A：允许。RFC 4028明确：UAS可在2xx响应中重新指定refresher角色，2xx中的Session-Expires（含refresher参数）为最终生效值。这一设计让网络侧（P-CSCF）能在不修改UE发起INVITE的前提下，主动接管刷新责任以节省终端电量。UAC必须接受2xx中的refresher指定。

Q3：UPDATE和re-INVITE都能刷新会话，VoNR网络偏好哪个？ A：VoNR网络几乎统一偏好UPDATE。原因是UPDATE不触发Offer/Answer媒体重协商、不改变Dialog、不要求对方重新协商编解码和QoS，信令开销约为re-INVITE的一半。re-INVITE仅在需要同时刷新会话并改媒体参数（如切换编码）时才使用。

Q4：如果UE不支持会话定时器（没带Supported: timer），P-CSCF怎么办？ A：根据TS 24.229，P-CSCF仍会插入 Session-Expires 并自荐为uas刷新方。由于UE未声明支持，刷新UPDATE可能被UE忽略或回488。此时P-CSCF依赖媒体面超时（长时间无RTP）和会话级绝对定时器来兜底释放。运营商通常要求入网UE强制支持timer选项标签，不支持者不予IMS语音授权。

Q5：422 Session Interval Too Small 在5G漫游场景下为何容易反复出现？ A：漫游时主叫归属网络（HPLMN）P-CSCF与被叫拜访/远端网络P-CSCF的Min-SE策略可能不一致，若中间无IBCF做Min-SE归一化，UE提议的间隔会"两头不讨好"。标准做法是在IBCF或互通SBC上配置统一的Min-SE下限，并对穿越的INVITE做Min-SE改写，避免422在跨域链路上反复弹跳。

参考来源

1. 3GPP TS 24.229 — IP multimedia call control protocol based on SIP and SDP — §5.1.2.2.2 P-CSCF行为、§5.4 会话释放、§7.7 SIP定时器与Min-SE默认值
2. RFC 4028: Session Timers in the Session Initiation Protocol (SIP) — Session-Expires/Min-SE头域、422响应、refresher协商规则定义
3. draft-ietf-sipcore-rfc4028bis-06 — RFC 4028的维护更新，澄清UAC/UAS刷新间隔与重试规则
4. ShareTechnote — 5G VoNR — VoNR与VoLTE在IMS会话管理上的对照
5. Cisco — SIP Session Timer Support (CUBE) — refresher参数在2xx中的确定、SBC实现与排错

本文由「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 等场景全覆盖。