<!-- title: VoNR会话定时器刷新机制拆解 -->
<!-- domain: ims -->

# 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的复合机制，其规范来源分两层：

| 层级 | 规范 | 定位 |
|------|------|------|
| 协议语义层 | RFC 4028（draft-ietf-sipcore-rfc4028bis为其维护更新） | 定义头域、422响应、refresher协商、刷新规则 |
| IMS适配层 | 3GPP TS 24.229 §5.1.2.2.2、§5.4、§7.7 | 规定P-CSCF/UE如何使用、定时器默认值、与Rx接口联动 |
| 架构层 | 3GPP TS 23.228、TS 23.501 | P-CSCF在IMS/5G中的位置、与PCF的N5/Rx关系 |

**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结构总览图

```mermaid
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参数说明表

| IE/参数 | 所在消息 | 含义 | 典型值 | 设计意图 |
|---------|---------|------|--------|---------|
| `Supported: timer` | INVITE/200 OK | 声明本端支持会话定时器（软要求） | 固定标签 | 允许能力探测，不强制对端 |
| `Require: timer` | INVITE/200 OK | 强制对端启用定时器（硬要求） | 固定标签 | P-CSCF用于强制UE保活 |
| `Session-Expires: <sec>;refresher=<uac\|uas>` | INVITE、2xx | 会话总存活时间及刷新方角色 | 1800;refresher=uas | 单一协商点确定"活多久"+"谁续命" |
| `Min-SE: <sec>` | INVITE、422、响应 | 本端能接受的最小刷新间隔下限 | 90 | 防止对端用极短间隔制造信令风暴 |
| 422响应 | 对INVITE的拒绝 | "会话间隔太小"，**必须**回带Min-SE | — | 让发起方按新下限重试，避免盲目循环 |
| UPDATE（刷新载体） | 周期性 | 不改变Dialog状态的轻量刷新 | 无SDP或同SDP | 比re-INVITE开销小，不重协商媒体 |

---

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

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

```text
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往返中如何最终确定刷新方，以及异常分支。

```mermaid
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 常见故障点

| 故障现象 | 根因 | 排错思路 |
|---------|------|---------|
| 呼叫建立后~90秒自动断开 | 双方Min-SE/Session-Expires协商失败，一方按默认90秒超时 | 抓包核对422往返，确认UE是否真正采用了P-CSCF的Min-SE重试 |
| 长时间通话突然掉线 | 刷新UPDATE因切换/无线抖动丢失，重传耗尽 | 检查刷新报文是否穿越了NAT/SBC，UDP刷新是否被老化的NAT映射丢弃 |
| 双方都不刷新 / 双方都刷新 | refresher参数在2xx中未被正确解析 | 核对2xx中Session-Expires的refresher值，确认是否被某中间B2BUA篡改 |
| 跨域呼叫建立失败循环422 | 主被叫域Min-SE策略差异大 | 协调跨域Min-SE为统一值，或由IBCF归一化 |
| VoNR专用承载未释放 | P-CSCF超时发BYE但未触发AAR释放 | 检查P-CSCF↔PCF的Rx链路与会话绑定 |

---
## 九、常见问题

**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](https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetails.aspx?specificationId=1055) — §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)](https://www.rfc-editor.org/info/rfc4028/) — Session-Expires/Min-SE头域、422响应、refresher协商规则定义
3. [draft-ietf-sipcore-rfc4028bis-06](https://www.ietf.org/archive/id/draft-ietf-sipcore-rfc4028bis-06.html) — RFC 4028的维护更新，澄清UAC/UAS刷新间隔与重试规则
4. [ShareTechnote — 5G VoNR](https://www.sharetechnote.com/html/5G/5G_VoNR.html) — VoNR与VoLTE在IMS会话管理上的对照
5. [Cisco — SIP Session Timer Support (CUBE)](https://www.cisco.com/c/en/us/td/docs/ios/ios_xe/voice_cube_-_ent/configuration/guide/vb_1369_xe.pdf) — 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 等场景全覆盖。

![51学通信知识星球海报-扫码加入](https://wiki.500nian.com/images/zhixingqiu_qrcode.png)