SIP会话定时器（Session Timer）刷新与超时释放机制深度拆解

一、为什么 IMS 必须要有一套"会话定时器"

在传统电话网里，主叫挂机或者中继信令（ISUP REL）一旦发出，呼叫就结束了。但 SIP（RFC 3261）有一个先天的设计缺口：会话建立之后，SIP 本身并不维护会话的存活状态。一个已确认的 dialog（由 Call-ID、From-tag、To-tag 标识）如果没有任何后续报文交互，它就静静地躺在所有中间网元的会话表里——既不会自我声明"我还活着"，也不会主动消亡。

这在 IMS/VoLTE/VoNR 场景下是致命的。设想一个典型故障：用户在通话进行中手机突然掉电、或者驶入无覆盖的隧道、或者 UE 协议栈崩溃，此时 UE 根本来不及发送 BYE。如果没有补救机制，会发生三件糟糕的事情：

1. "幽灵会话"（ghost session）长期挂在 S-CSCF、P-CSCF 和 AS 的会话上下文里，吃内存、占计数；
2. 专用承载（5QI=1 / QCI=1 的 GBR 承载）不会被释放，无线和传输资源被白白占用；
3. 计费不停——离线 CDR 里这段通话会一直"在线"，在线计费继续扣单元。

为了让 SIP 能"自己发现会话已经死了"，IETF 在 RFC 4028（及其 bis 草案 draft-ietf-sipcore-rfc4028bis）中定义了 Session Timer（会话定时器）扩展，3GPP 则在 TS 24.229《IP 多媒体呼叫控制协议（基于 SIP/SDP），Stage 3》中将其纳入 IMS 协议栈作为 UE 与 CSCF 的强制能力，并在 TS 23.228、TS 23.380、TS 32.260 等规范中与 IMS 过程、Rx 接口授权、IMS 计费联动。

本文聚焦 TS 24.229 第 5.1.2 节（UE 发起/终结会话过程）与第 4.5 节（头域支持）中对 Session Timer 的具体过程要求，结合 RFC 4028 的协商/刷新/超时三大机制，做一次全链拆解。

二、核心 Information Element 详解

Session Timer 在协议面上一共引入了"两个新头域 + 一个 option-tag + 一个新响应码"，外加 refresher 参数。这些 IE 的精确语义是后续所有信令流程的基础。

下表把会话定时器与 IMS 中另外两类容易混淆的"保活/刷新"机制放在一起，帮助厘清边界：

可以看到，Session Timer 是唯一一个与媒体资源授权（Rx）和计费紧耦合的会话级存活机制，这也是它在 IMS 里不可被 Registration 或心跳替代的根本原因。

三、协商机制：从 INVITE 到 2xx，到底谁说了算

Session Timer 的核心是一次 Offer/Answer 风格的协商。规则可以浓缩为一句话：间隔只能被改小、不能被改大；谁是 refresher，最终由 2xx 一锤定音。

完整协商规则（源自 RFC 4028 §5、TS 24.229 §5.1.2）：

1. UAC 在初始 INVITE 中带 Supported: timer（或 Require: timer），并可选地携带 Session-Expires: <value>;refresher=uac|uas 和 Min-SE: <min>。
2. UAS 收到后，若间隔不小于自己声明的 Min-SE，则在 2xx 中回送最终的 Session-Expires（可等于或小于 UAC 提议值，不可更大）以及明确的 refresher 角色。
3. 若 UAC 提议值小于 UAS 的 Min-SE，UAS 直接回 422 Session Interval Too Small，并在响应里给出自己的 Min-SE；UAC 应据此重发 INVITE。
4. 中间代理（P-CSCF/S-CSCF）可以对经过的 INVITE/2xx 插入或改小 Session-Expires（但不能改大），用于实施运营商策略；代理不能担任 refresher。

下面是包含协商、刷新、超时三大阶段的完整时序：

sequenceDiagram
    autonumber
    participant UE as UE (UAC)
    participant PCSCF as P-CSCF
    participant SCSCF as S-CSCF
    participant UAS as 被叫UE (UAS)

    Note over UE,UAS: 阶段1：协商
    UE->>PCSCF: INVITE<br/>Supported: timer<br/>Session-Expires:1800;refresher=uac<br/>Min-SE:90
    Note over PCSCF: 策略校验/可改小间隔
    PCSCF->>SCSCF: INVITE (转发)
    SCSCF->>UAS: INVITE (转发)
    UAS-->>SCSCF: 200 OK<br/>Session-Expires:1800;refresher=uac
    SCSCF-->>PCSCF: 200 OK
    Note over PCSCF: 校验Rx授权一致
    PCSCF-->>UE: 200 OK (Session-Expires:1800;refresher=uac)
    UE->>PCSCF: ACK

    Note over UE,UAS: 阶段2：约半个间隔(900s)后刷新
    UE->>PCSCF: re-INVITE (无SDP变更)<br/>Session-Expires:1800
    PCSCF->>UAS: re-INVITE
    UAS-->>PCSCF: 200 OK (Session-Expires:1800)
    PCSCF-->>UE: 200 OK
    UE->>PCSCF: ACK
    Note over UE,UAS: 定时器重置，会话续命

    Note over UE,UAS: 阶段3：若刷新始终缺失则超时释放
    Note over PCSCF: 间隔到期仍未收到刷新
    PCSCF->>UE: BYE (Reason: 会话超时)
    Note over PCSCF: 触发Rx STR释放专用承载

设计意图：让间隔"只能减小"是为了防止被中间网元恶意拉长导致无法及时检测失效；让 2xx 拥有最终决定权，是因为被叫方（往往是被叫侧 SBC/UE）最清楚自己期望的刷新负担。Min-SE 与 422 的组合，则是为了避免双方陷入"你刷新太快、我也刷新太快"的资源浪费螺旋。

四、刷新流程：re-INVITE 与 UPDATE 的分工

确定 refresher 之后，refresher 一方承担周期性刷新义务。RFC 4028 给出的实践做法是：refresher 在约半个协商间隔处发送一次刷新请求（例如 1800s 的间隔，则在 ~900s 左右刷新），这样即便首次刷新丢失，仍有充足时间重试，避免误判。

刷新报文有两种选择，二者分工明确：

在确认后的通话里，re-INVITE（不带 SDP，或带与上次完全相同的 SDP）是最常见的纯刷新手段，因为它只刷新定时器而不触发媒体面任何动作。需要注意两个工程细节：

• 刷新请求同样要带回 Session-Expires，对端在 2xx 中再次确认（通常保持不变），定时器以最新一次 2xx 为基准重新计时。
• " glare"问题：若主被叫几乎同时各发一个 re-INVITE，RFC 3261 用 491 Request Pending 来裁决——后到的一方收到 491 后，按随机退避后重试，避免双向 INVITE 死锁。

下图给出 refresher 与非 refresher 双方的内部状态机，对工程实现和抓包诊断都很有用：

stateDiagram-v2
    [*] --> 协商中: 发送/接收 INVITE
    协商中 --> 活跃: 收到2xx<br/>确定refresher与间隔
    活跃 --> 等待刷新: 我是refresher,计时到半间隔
    等待刷新 --> 活跃: 发re-INVITE收到2xx
    等待刷新 --> 释放中: 刷新无响应(408/481)
    活跃 --> 释放中: 我是非refresher<br/>且间隔已满仍无刷新
    释放中 --> [*]: 发送/接收BYE<br/>拆除媒体与授权
    协商中 --> [*]: 422重试或拒绝

五、超时释放：从"幽灵会话"到 BYE 的完整链路

当 refresher 在整个会话间隔内都没有成功刷新（既可能是 UE 失联，也可能是刷新请求在网络中丢失且重试也失败），Session Timer 机制进入"超时释放"分支。这是该机制真正的价值所在，也是它与 IMS 用户面/计费面联动的关键点。

以主叫 UE 担任 refresher、但 UE 突然掉电为例，P-CSCF 侧会发生如下动作（结合 TS 23.228 与 TS 29.214 Rx 接口过程）：

sequenceDiagram
    autonumber
    participant UE as 主叫UE(refresher,已失联)
    participant PCSCF as P-CSCF
    participant PCRF as PCF/PCRF
    participant SMF as SMF (会话管理)
    participant SCSCF as S-CSCF

    Note over UE: 掉电/脱网,无法发出re-INVITE
    Note over PCSCF: 本地会话定时器到期,<br/>未收到任何刷新
    PCSCF->>PCRF: Rx STR (Session-Termination-Request)<br/>移除GBR承载授权
    PCRF-->>PCSCF: Rx STA
    PCRF->>SMF: 策略:释放5QI=1专用QoS流
    SMF->>SMF: 拆除专用承载/通知(R)AN
    PCSCF->>SCSCF: BYE (向IMS核心释放会话)
    SCSCF-->>PCSCF: 200 OK
    Note over PCSCF,SCSCF: AS侧触发CDR停止计费
    PCSCF-x UE: BYE (尽力发送,通常丢弃)

要点解析：

1. P-CSCF 是超时检测的实际执行者。因为 P-CSCF 既维护 SIP 会话上下文，又持有 Rx 接口的媒体授权（在呼叫建立时通过 AAR/AAA 申请了专用承载），它是唯一能同时感知"SIP 失活"与"拆除媒体授权"的网元。
2. 超时不是无脑发 BYE，而是"先停授权、再收会话"。P-CSCF 通过 Rx 接口向 PCF 发送 STR（Session Termination Request），PCF 再触发 SMF 释放专用 QoS 流（5G）/专用承载（4G），切断媒体面并停止在线计费；随后才在 SIP 层发 BYE 完成 IMS 会话清理。
3. S-CSCF 收到 BYE 后，按 iFC 触发 AS，停止应用层会话并生成离线 CDR 结束记录（TS 32.260 IMS 计费）。这样，"幽灵会话"在 SIP 层、媒体层、计费层被同时清除。

这套设计把"协议层存活检测"和"资源/计费回收"绑定在一起，是 IMS 区别于普通 SIP 网络的关键工程实践。

六、Session Timer 头域结构可视化

把上文 IE 与流程中用到的报文结构做一次可视化，便于在抓包时快速对位：

flowchart TB
    subgraph INV["初始INVITE相关头域"]
        A["Supported: timer"] --> A1["声明支持,非强制"]
        A2["Require: timer"] --> A2a["强制对端支持,否则420"]
        A3["Session-Expires: 1800"] --> A3a["delta-seconds"]
        A3 --> A3b["refresher=uac"]
        A4["Min-SE: 90"] --> A4a["可接受最小间隔"]
    end
    subgraph OK["2xx/刷新响应"]
        B["Session-Expires: 1800;refresher=uac"] --> B1["最终协商值,只能<=提议"]
        B --> B2["双方均以2xx为准重置定时器"]
    end
    subgraph ERR["异常响应"]
        C["422 Session Interval Too Small"] --> C1["回送Min-SE"]
        C --> C2["UAC据此放大间隔重试"]
        D["491 Request Pending"] --> D1[" glare退避后重试"]
        E["408/481"] --> E1["刷新失败,触发超时释放"]
    end

七、抓包识别与排错实战

在真实网络（UERANSIM/free5GC、爱立信/华为/中兴 IMS 核心网）抓包时，Session Timer 的指纹非常清晰：

1. 建立阶段：在 Wireshark 中按 sip.Session-Expires 过滤，初始 INVITE 的 2xx 必带 Session-Expires: N;refresher=...。若该头缺失且网络要求支持，说明 UE 没声明 Supported: timer。
2. 刷新阶段：通话中每隔约"间隔/2"会出现一次 Request: INVITE（CSeq 递增）紧跟 Status: 200 OK + ACK，且 SDP 与之前一致（或无 SDP）。这是最典型的续命三轮。
3. 超时阶段：长时间通话结束后若出现一次没有主动挂机的 BYE，且 P-CSCF 之前有 Rx STR/STA，即可判定为超时释放。

常见故障与排错思路：

Q1：Session Timer 和 SIP Registration 重注册有什么区别？ A：Registration 维护的是"用户是否在网络里注册"的绑定关系，周期通常很长（数十分钟到数小时），失败导致整个用户注销、所有会话失效；Session Timer 维护的是"单个媒体会话是否存活"，周期短（分钟级），只影响该会话本身。一个用户注册有效但某个通话的 Session Timer 超时，是完全正常的情况。

Q2：为什么 refresher 默认建议在"半个间隔"处刷新，而不是临近到期？ A：留出另一半时间作为容错窗口。若临近到期才刷新，一旦该刷新请求丢包，重试尚未成功定时器就到点，会误判释放健康会话。半间隔刷新保证即便首次失败也有充足时间重传。

Q3：422 和 420 都会让 INVITE 失败，二者区别？ A：420 Bad Extension 是"对端根本不支持这个 option-tag（timer）"；422 Session Interval Too Small 是"对端支持 timer，但嫌你提议的间隔太短"，并在响应里给出可接受的最小值 Min-SE，引导 UAC 放大间隔后重试。前者要改用法（Supported 而非 Require），后者要改数值。

Q4：刷新时用 re-INVITE 还是 UPDATE，标准上怎么界定？ A：确认后的 dialog 用 re-INVITE 刷新是惯例；UPDATE（RFC 3311）更常用于早期 dialog（含早期媒体）的刷新与媒体协商。RFC 4028 允许两者都用于刷新，但实践中 re-INVITE 不带 SDP 是"纯刷新"的最低开销方式。

Q5：在 5G/VoNR 里，Session Timer 触发的承载释放走哪条路？ A：仍是 P-CSCF →（Rx）→ PCF → SMF 的路径。PCF 通过 Npcf_SmPolicyControl 通知 SMF，SMF 发起 N4 会话修改，拆除 5QI=1 的专用 QoS Flow，并通知 (R)AN 释放对应 DRB；SIP 层同时发 BYE。这与 4G 经 PCRF→PGW→SGW 链路在概念上一一对应，只是网元名与接口换成了 5G SBA 体系。

参考来源

1. RFC 4028: Session Timers in the Session Initiation Protocol (SIP) — Session-Expires/Min-SE/refresher/422 的权威定义
2. draft-ietf-sipcore-rfc4028bis — Session Timer 的现行维护版本（含 491 glare 处理细节）
3. 3GPP TS 24.229 — IP multimedia call control protocol based on SIP and SDP — §4.5 头域支持、§5.1.2 UE 发起/终结会话中的 Session Timer 过程
4. 3GPP TS 23.228 — IP Multimedia Subsystem (IMS) — IMS 过程与会话释放上下文
5. SIP Session Timer 机制分析（洛笔达） 与 Cisco Community RFC4028 中文概要 — 工程视角的协商/刷新/超时解读

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