<!-- title: VoNR会话定时器422协商与刷新博弈 -->
<!-- domain: ims -->

# VoNR SIP Session Timer保活机制与422协商博弈

## 一、机制定位：为什么IMS需要Session Timer

在VoNR/VoLTE的IMS网络中，SIP会话建立在INVITE/200 OK握手之后，但**无线链路随时可能中断**——UE掉电、切换失败、覆盖空洞——而对端和网络侧可能毫不知情。如果没有主动保活机制，核心网将一直为这些"幽灵会话"占用RTP承载资源和IMS会话状态。

SIP Session Timer机制（RFC 4028，3GPP TS 24.229 Section 7.7引用）通过**周期性发送re-INVITE或UPDATE**来刷新会话状态。任何网元（UE、P-CSCF、S-CSCF、AS）在刷新超时后，有权单方面终止会话并释放资源。这个机制看似简单，实际上在IMS多跳架构中，**Min-SE与Session-Expires的协商博弈**和**refresher角色竞争**是网络工程师最常遇到的信令问题之一。

## 二、核心参数全景：Session-Expires与Min-SE的博弈关系

### 2.1 关键Header字段

| Header字段 | 方向 | 含义 | 典型取值 |
|---|---|---|---|
| `Session-Expires` (或简写`x`) | INVITE/UPDATE请求及2xx响应 | 提议/确认的会话刷新间隔（秒） | 600-1800 |
| `Min-SE` | INVITE请求/422响应/任意proxy插入 | 本端可接受的最小刷新间隔（秒） | 90-1800 |
| `refresher` (Session-Expires子参数) | 2xx响应中 | 指定由哪一方负责发起刷新：`uac`或`uas` | - |
| `Supported: timer` | 请求/响应 | 声明本端支持Session Timer扩展 | - |
| `Require: timer` | 请求 | 强制要求对端支持Session Timer | - |

### 2.2 参数博弈的三层关系

```mermaid
graph TD
    A[UAC提议 Session-Expires: 600<br/>Min-SE: 90] --> B{沿途Proxy检查}
    B -->|Session-Expires >= Proxy Min-SE| C[Proxy放行<br/>可上调Min-SE]
    B -->|Session-Expires < Proxy Min-SE| D[Proxy拒绝 422<br/>携带自己的Min-SE]
    C --> E{UAS检查}
    E -->|Session-Expires >= UAS Min-SE| F[UAS接受<br/>2xx携带协商后的Session-Expires<br/>指定refresher角色]
    E -->|Session-Expires < UAS Min-SE| G[UAS拒绝 422<br/>携带自己的Min-SE]
    D --> H[UAC用422中的Min-SE重发INVITE]
    G --> H
    F --> I[会话建立<br/>refresher方周期性re-INVITE/UPDATE]
```

## 三、完整信令时序图：VoNR Session Timer协商与刷新

### 3.1 建立阶段——含422拒绝的完整协商流

```text
sequenceDiagram
    participant UE1 as 主叫UE (UAC)
    participant PCSCF1 as P-CSCF (主叫侧)
    participant SCSCF1 as S-CSCF (主叫侧)
    participant SCSCF2 as S-CSCF (被叫侧)
    participant PCSCF2 as P-CSCF (被叫侧)
    participant UE2 as 被叫UE (UAS)

    Note over UE1,UE2: 阶段1: INVITE协商 — 首次尝试被422拒绝

    UE1->>PCSCF1: INVITE (SDP offer)<br/>Session-Expires: 600;refresher=uac<br/>Min-SE: 90<br/>Supported: timer
    Note right of PCSCF1: P-CSCF策略要求<br/>Min-SE >= 1800
    PCSCF1-->>UE1: 422 Session Interval Too Brief<br/>Min-SE: 1800
    Note left of UE1: UAC收到422后<br/>必须使用422中的Min-SE<br/>重新发起INVITE

    Note over UE1,UE2: 阶段2: 重发INVITE — 协商成功

    UE1->>PCSCF1: INVITE (SDP offer)<br/>Session-Expires: 1800<br/>Min-SE: 1800<br/>Supported: timer
    PCSCF1->>SCSCF1: INVITE (转发)<br/>Session-Expires: 1800<br/>Min-SE: 1800
    SCSCF1->>SCSCF2: INVITE (转发)
    SCSCF2->>PCSCF2: INVITE (转发)
    PCSCF2->>UE2: INVITE (转发)

    UE2->>PCSCF2: 180 Ringing
    PCSCF2->>SCSCF2: 180 Ringing
    SCSCF2->>SCSCF1: 180 Ringing
    SCSCF1->>PCSCF1: 180 Ringing
    PCSCF1->>UE1: 180 Ringing

    UE2->>PCSCF2: 200 OK (SDP answer)<br/>Session-Expires: 1800;refresher=uac
    PCSCF2->>SCSCF2: 200 OK (转发)
    SCSCF2->>SCSCF1: 200 OK (转发)
    SCSCF1->>PCSCF1: 200 OK (转发)
    PCSCF1->>UE1: 200 OK (转发)

    UE1->>PCSCF1: ACK
    PCSCF1->>SCSCF1: ACK → ... → UE2

    Note over UE1,UE2: 会话建立完成<br/>Session-Expires = 1800秒<br/>Refresher = UAC (主叫UE)

    Note over UE1,UE2: 阶段3: 周期性刷新 (1800秒后)

    UE1->>PCSCF1: re-INVITE (无SDP 或 带SDP)<br/>Session-Expires: 1800;refresher=uac
    PCSCF1->>SCSCF1: re-INVITE (转发)
    SCSCF1->>SCSCF2: re-INVITE (转发)
    SCSCF2->>PCSCF2: re-INVITE (转发)
    PCSCF2->>UE2: re-INVITE (转发)

    UE2->>PCSCF2: 200 OK<br/>Session-Expires: 1800;refresher=uac
    PCSCF2->>SCSCF2: 200 OK → ... → UE1

    UE1->>PCSCF1: ACK → ... → UE2
    Note over UE1,UE2: 刷新成功，定时器重置

    Note over UE1,UE2: 阶段4: 刷新失败场景

    UE1-xPCSCF1: re-INVITE (超时无响应)
    Note left of UE1: 定时器到期<br/>UE1发送BYE终止会话
    UE1->>PCSCF1: BYE
    PCSCF1->>SCSCF1: BYE → ... → UE2
    Note over UE1,UE2: 会话终止，资源释放
```

### 3.2 信令消息中的关键IE解析

**INVITE中的Session Timer相关Header：**

```
INVITE sip:callee@ims.mnc.mcc.3gppnetwork.org SIP/2.0
Via: SIP/2.0/UDP [5555::aaa:bbb:ccc:ddd]:5060;branch=z9hG4bK1234
Max-Forwards: 70
Route: <sip:pcscf.mnc.mcc.3gppnetwork.org:5060;lr>
Route: <sip:scscf.mnc.mcc.3gppnetwork.org:5060;lr>
Supported: timer, 100rel, precondition, update
Session-Expires: 1800;refresher=uac
Min-SE: 1800
Content-Type: application/sdp
```

**422拒绝响应：**

```
SIP/2.0 422 Session Interval Too Brief
Via: SIP/2.0/UDP [5555::aaa:bbb:ccc:ddd]:5060;branch=z9hG4bK1234
From: <sip:caller@ims.mnc.mcc.3gppnetwork.org>;tag=abc123
To: <sip:callee@ims.mnc.mcc.3gppnetwork.org>;tag=def456
Min-SE: 1800
```

**200 OK中的确认：**

```
SIP/2.0 200 OK
Via: SIP/2.0/UDP ...
Session-Expires: 1800;refresher=uac
```

## 四、422协商博弈的深层机制

### 4.1 为什么422可能形成循环

RFC 4028 Section 7.4定义了422的处理规则，但在IMS多跳架构中，**每一个proxy都可以独立设置自己的Min-SE**。考虑以下场景：

```
UE: Min-SE = 90
P-CSCF: Min-SE = 1800  
S-CSCF: Min-SE = 2400
AS (TAS/MRFC): Min-SE = 3600
```

| 跳数 | 触发422的网元 | 422中的Min-SE | UAC重发值 |
|---|---|---|---|
| 第1次 | P-CSCF | 1800 | Session-Expires: 1800 |
| 第2次 | S-CSCF | 2400 | Session-Expires: 2400 |
| 第3次 | AS | 3600 | Session-Expires: 3600 |

**RFC 4028规定**：UAC在收到422后，必须将`Session-Expires`设为不小于422响应中`Min-SE`的值。但规范并未限制沿途Proxy的Min-SE递增上限——这意味着如果各网元配置不一致，理论上可能出现**多次422往返**。

3GPP TS 24.229 Section 5.7.2.1对此做了IMS层面的约束：**P-CSCF作为接入侧的第一个信令锚点，应负责统一Min-SE策略**，在信令向S-CSCF转发前就完成Min-SE的统一调整。

### 4.2 Proxy的Min-SE插入权限

RFC 4028 Section 7.3定义了三种Proxy行为：

| 行为 | 条件 | 操作 |
|---|---|---|
| **插入Min-SE** | INVITE中无Min-SE，且Proxy有本地策略 | 添加Min-SE header |
| **增大Min-SE** | INVITE中Min-SE < Proxy本地策略 | 将Min-SE提升至本地策略值 |
| **拒绝并返回422** | INVITE中Session-Expires < Proxy本地Min-SE | 返回422，携带Proxy的Min-SE |

**设计意图**：Proxy作为中间网元，不能擅自缩短Session-Expires（这是端到端协商的结果），但可以通过Min-SE机制**提高下限**。这保证了网络运营商对流量的管控权——运营商可以通过配置P-CSCF的Min-SE来强制UE以合理的间隔刷新会话。

## 五、Refresher角色竞争与双盲场景

### 5.1 Refresher指定规则

Session-Expires的`refresher`参数决定了**谁负责发起周期性刷新**。确定规则如下：

```mermaid
flowchart TD
    A[INVITE携带 Session-Expires<br/>refresher参数?] -->|有, refresher=uac| B[UAS在2xx中确认 refresher=uac<br/>UAC负责刷新]
    A -->|有, refresher=uas| C[UAS在2xx中确认 refresher=uas<br/>UAS负责刷新]
    A -->|无refresher参数| D{UAS在2xx中指定<br/>refresher}
    D -->|UAS选择 uac| E[UAC负责刷新]
    D -->|UAS选择 uas| F[UAS负责刷新]
    A -->|无Session-Expires| G{UAS是否支持timer?}
    G -->|是, UAS主动添加| H[UAS在2xx中添加<br/>Session-Expires;refresher=uas]
    G -->|否| I[无Session Timer<br/>会话无保活]
```

### 5.2 "双盲竞争"问题

当INVITE和2xx都**没有指定refresher**时（即双方都声称支持timer但都不指定角色），RFC 4028 Section 7.2规定：

> 如果2xx响应中没有refresher参数，**UAC默认为refresher**。

这是为了避免双方都不刷新导致的会话泄漏。但在IMS实际部署中，更常见的做法是：**P-CSCF或S-CSCF作为B2BUA**，会主动在信令中插入或修改refresher参数，确保刷新责任明确。

### 5.3 UPDATE vs re-INVITE刷新选择

| 特性 | re-INVITE刷新 | UPDATE刷新 |
|---|---|---|
| SDP协商 | 可以携带SDP（刷新+修改编解码） | 必须携带SDP（RFC 3311） |
| 对目标URL的影响 | Target-Refresh请求，更新Contact | 非Target-Refresh，不更新路由 |
| 可靠性 | 需要可靠响应+ACK | 简单请求/响应 |
| IMS推荐 | TS 24.229默认推荐re-INVITE | 适用于SDP参数微调 |
| 误判风险 | re-INVITE用于刷新和修改混合，解析困难 | 目的明确 |

**3GPP TS 24.229 Section 5.1.3A**规定：UE应使用re-INVITE进行会话刷新，但也可以使用UPDATE。P-CSCF必须同时支持两种刷新方式。

## 六、状态转换图：Session Timer的完整生命周期

```mermaid
stateDiagram-v2
    [*] --> Idle: UE开机/无会话
    
    Idle --> Negotiating: 发送/接收INVITE<br/>携带Session-Expires
    
    Negotiating --> Rejected422: 收到422<br/>Session Interval Too Brief
    Rejected422 --> Negotiating: 重发INVITE<br/>使用422中的Min-SE
    
    Negotiating --> Established: 收到/发送2xx<br/>Session-Expires协商完成
    
    Established --> RefreshPending: Session Timer触发<br/>(到达过期前阈值)
    
    RefreshPending --> Refreshing: Refresher方发送<br/>re-INVITE/UPDATE
    
    Refreshing --> Established: 收到2xx<br/>定时器重置
    
    Refreshing --> RefreshFailed: 超时无响应<br/>或收到错误响应
    
    RefreshFailed --> Terminating: 定时器彻底到期<br/>发送BYE终止
    
    Established --> Terminating: 正常挂机<br/>发送/接收BYE
    
    Terminating --> Idle: 会话资源释放
    
    note right of Negotiating
        关键IE: Session-Expires
        Min-SE, Supported: timer
    end note
    
    note right of RefreshPending
        触发时机 = Session-Expires - δ
        δ通常为64*T1 (RFC 3261)
    end note
```

## 七、IMS各网元的Session Timer行为对比

| 网元 | TS 24.229章节 | 核心行为 | 可配置项 |
|---|---|---|---|
| **UE** | 5.1.3A | 支持timer扩展，支持re-INVITE/UPDATE刷新 | Session-Expires默认值、Min-SE |
| **P-CSCF** | 5.7.2.1 | 作为接入锚点，执行Min-SE策略强制；Gq接口通知PCRF承载资源状态 | 本地Min-SE策略、是否强制timer |
| **S-CSCF** | 5.7.1.2 | 转发Session Timer参数；可按用户订阅级别覆盖Min-SE | 按iFC触发的AS列表Min-SE |
| **AS/TAS** | 5.7.3 | B2BUA模式下可独立管理两腿的Session Timer；SIP AS模式下透明转发 | 业务逻辑相关Min-SE |
| **BGCF** | 5.7.4 | 透明转发Session Timer参数 | 通常不修改 |
| **MGCF** | 5.7.5 | ISUP/BICC与SIP的Session Timer互操作；ISUP无对应机制时MGCF自行管理 | CS域超时映射 |

### 7.1 P-CSCF的关键锚点作用

P-CSCF在Session Timer机制中承担了**最关键的策略执行角色**：

1. **上行方向（UE→网络）**：检查UE提议的Session-Expires，若低于运营商策略Min-SE，直接返回422
2. **下行方向（网络→UE）**：确保2xx响应中的Session-Expires不低于Min-SE
3. **刷新超时检测**：P-CSCF本地维护会话定时器，若refresher方未按时刷新，P-CSCF有权发起BYE释放资源
4. **资源联动**：P-CSCF通过Gq/A Rx接口通知PCRF/PCF，在Session Timer超时时触发承载删除

**这是3GPP在TS 24.229 Section 5.7.2.1中的强制要求**，确保IMS网络中不会出现P-CSCF不知道会话已经泄漏的情况。

## 八、实战抓包识别与故障排查

### 8.1 Wireshark过滤Session Timer相关信令

```bash
# 过滤422响应
sip.Status-Code == 422

# 过滤携带Session-Expires的INVITE
sip.Method == "INVITE" && sip.Header.Session-Expires exists

# 过滤re-INVITE（可能是刷新）
sip.Method == "INVITE" && sip.Header.Session-Expires exists && !sip.CSeq.method == "INVITE" 
# 更精确：通过CSeq识别re-INVITE（CSeq > 1）

# 过滤Min-SE header
sip.Header.Min-SE exists
```

### 8.2 常见故障模式

| 故障现象 | 根因分析 | 排查步骤 |
|---|---|---|
| **反复422循环** | P-CSCF和S-CSCF的Min-SE配置不一致，S-CSCF的Min-SE大于P-CSCF | 检查各网元Min-SE配置，确保P-CSCF >= S-CSCF >= AS |
| **会话建立后一段时间被BYE终止** | refresher方未按时发送re-INVITE/UPDATE | 检查UE的定时器实现；确认re-INVITE是否被中间网元拦截 |
| **re-INVITE触发编解码重新协商导致音频中断** | 刷新re-INVITE携带了新的SDP offer | UE应在不修改媒体参数时发送无SDP的re-INVITE或固定SDP |
| **被叫方也发送刷新导致冲突** | 双方都认为自己是refresher | 检查2xx中refresher参数是否正确 |
| **P-CSCF发送BYE但UE不响应** | P-CSCF本地定时器超时，但UE认为会话仍有效 | 确认P-CSCF与UE的Session-Expires值是否一致 |
## 九、与其他保活机制的对比

| 机制 | 协议层 | 检测粒度 | 刷新方式 | IMS适用性 |
|---|---|---|---|---|
| **SIP Session Timer** (RFC 4028) | SIP应用层 | 端到端+逐跳 | re-INVITE/UPDATE | VoNR/VoLTE标准机制 |
| **RTP/RTCP超时检测** | 媒体传输层 | 端到端 | 被动检测 | 辅助手段，无法主动释放 |
| **OPTIONS Ping** | SIP应用层 | 逐跳 | OPTIONS请求 | 网元间心跳，非会话级 |
| **SIP NOTIFY保活** | SIP应用层 | 订阅级 | NOTIFY | 仅限subscription场景 |
| **QoS监控 (PCF/PCRF)** | 策略控制层 | 承载级 | Gq/A Rx事件报告 | 与P-CSCF联动 |

SIP Session Timer的核心优势在于：它是在**SIP信令层面**实现的**端到端保活**，可以穿透NAT和防火墙，同时允许沿途每个proxy独立检测会话活性。这是RTCP超时检测等媒体层方案无法替代的。

## 十、TS 24.229 R18/R19的增强方向

3GPP TS 24.229在Rel-18中针对Session Timer的主要更新包括：

1. **5G IMS over N5接口的P-CSCF行为增强**：P-CSCF通过N5接口向PCF报告会话刷新状态，PCF可据此触发SMF进行PDU Session Modification
2. **Edge Computing场景下的本地P-CSCF重选**：当UE移动导致P-CSCF变更时，新P-CSCF需要接管Session Timer状态——TS 24.229 R18增加了P-CSCF间状态同步的要求
3. **Multi-Device/Multi-Identity场景**：一个IMS注册关联多个设备时，每个设备的Session Timer独立管理，共享的S-CSCF需要协调多设备的刷新时序

## 常见问题

**Q1: Session Timer的刷新阈值如何计算？**
A: RFC 4028规定，refresher方应在Session-Expires到期前发送刷新请求。具体触发时间为：`Session-Expires - δ`，其中`δ = 64 × T1`（T1是SIP事务定时器，默认500ms，所以δ ≈ 32秒）。也就是说，如果Session-Expires=1800秒，UE会在约1768秒时发起re-INVITE刷新。

**Q2: 422响应可以触发多少次重试？**
A: RFC 4028没有定义最大重试次数，理论上只要沿途还有更大Min-SE的网元，就会持续触发422。但IMS最佳实践要求：P-CSCF应配置为全网最大的Min-SE值，确保在接入侧就完成最终协商，避免422穿透到S-CSCF或AS。

**Q3: re-INVITE刷新时是否必须携带SDP？**
A: 不是。RFC 4028明确说明：刷新用的re-INVITE可以不携带SDP body（即"session refresh re-INVITE without SDP"）。这种情况下，对端在200 OK中也不携带SDP，双方媒体参数不变。这是推荐做法——避免刷新请求意外触发编解码重新协商。

**Q4: P-CSCF在Session Timer超时后能否不发送BYE直接释放资源？**
A: TS 24.229 Section 5.7.2.1要求P-CSCF在定时器超时后**必须发送BYE**通知对端，同时通过Rx/N5接口通知PCF释放承载资源。直接静默释放会导致对端网元的会话状态残留。

**Q5: VoNR和VoLTE在Session Timer机制上有何差异？**
A: 从SIP信令层面完全一致，差异在底层：VoNR的P-CSCF通过N5接口（5G）通知PCF，而VoLTE的P-CSCF通过Rx接口（4G）通知PCRF。P-CSCF检测到超时后通知的策略控制网元不同，但SIP层面的Session Timer行为完全相同。

## 参考来源

1. [RFC 4028: Session Timers in the Session Initiation Protocol (SIP)](https://www.rfc-editor.org/rfc/rfc4028) — Session Timer核心规范，定义Session-Expires、Min-SE、422协商机制
2. [3GPP TS 24.229 V18.8.0](https://www.etsi.org/deliver/etsi_ts/124200_124299/124229/18.08.00_60/ts_124229v180800p.pdf) — IMS SIP/SDP协议规范，Section 5.7定义各网元Session Timer行为
3. [draft-ietf-sipcore-rfc4028bis-06](https://www.ietf.org/archive/id/draft-ietf-sipcore-rfc4028bis-06.html) — RFC 4028更新草案，明确UPDATE刷新行为和边界条件
4. [Oracle SBC RFC 4028 Session Timers Configuration](https://docs.oracle.com/en/industries/communications/enterprise-session-border-controller/10.0.0/configuration/rfc-4028-session-timers1.html) — B2BUA模式下的Session Timer实现参考
5. [Cisco SIP Session Timer Support](https://www.cisco.com/c/en/us/td/docs/ios/ios_xe/voice_cube_-_ent/configuration/guide/vb_1369_xe.pdf) — CUBE网关的Session Timer处理及故障排查

---
> 本文由「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)