<!-- title: IMS业务触发iFC机制拆解 -->
<!-- domain: ims -->

# IMS业务触发iFC机制拆解：S-CSCF过滤准则评估与第三方注册信令全链解析

## 一、为什么IMS需要iFC：呼叫控制与业务逻辑的彻底解耦

IMS（IP多媒体子系统）相比传统电路域交换最深刻的架构革命，不在于"全IP"，而在于它把**呼叫控制（Call Control）**和**业务逻辑（Service Logic）**做了物理上的解耦。在软交换时代，补充业务（呼叫前转、号码显示、多方通话）和智能网（IN/CAMEL）业务往往耦合在交换机或SCP里；IMS则引入了一条独立于用户面和控制面的**ISC接口（IMS Service Control）**，把所有增值业务下沉到应用服务器（AS，Application Server）执行，而S-CSCF（Serving-CSCF）只负责"判断该把这条SIP请求送到哪个AS、按什么顺序送"。

这个"判断"的依据，就是**初始过滤准则 iFC（Initial Filter Criteria）**。iFC是存储在HSS用户档案（Service Profile）里、用XML编码的一组规则，定义了"在什么条件下、把请求触发到哪一个AS"。iFC的stage 2定义在 **3GPP TS 23.218**（IM Session Handling; IM Call Model），其XML信元结构定义在 **TS 29.228**（Cx/Dx接口信令流与消息内容，附录含iFC XML Schema），而AS可经Sh接口（**TS 29.328/29.329**）向HSS查询透明数据。本文聚焦 iFC的数据结构、评估算法、**第三方注册（Third Party Registration）**触发流，以及**主叫会话AS循环触发流**两条核心信令链，全部对应到具体TS章节。

```mermaid
graph TD
    A[HSS 用户档案<br/>Service Profile] -->|Cx: SAA下载<br/>TS 29.228| B[S-CSCF<br/>本地缓存iFC集合]
    B --> C{评估每条SIP请求<br/>TS 23.218 5.4}
    C -->|TriggerPoint匹配| D[按优先级转发到AS<br/>ISC接口 / SIP]
    C -->|不匹配| E[正常路由转发]
    D --> F[AS 执行业务逻辑<br/>Proxy/B2BUA/UA]
    F -->|处理后回送| B
    style A fill:#e8f4f8,stroke:#2196F3
    style B fill:#fff3e0,stroke:#FF9800
    style D fill:#e8f5e9,stroke:#4CAF50
```

## 二、iFC的数据结构：Priority / TriggerPoint / ApplicationServer三件套

依据 **TS 23.218 Section 5.3**，一条完整的iFC（FilterCriteria）由以下顶层信元构成。理解这三个信元是理解整个业务触发机制的钥匙。

| iFC顶层信元 | 取值/类型 | 含义与作用 | 关联TS章节 |
|---|---|---|---|
| `Priority` | 正整数（越小越高） | iFC评估顺序，1为最高优先级；同优先级下评估顺序不定 | TS 23.218 5.3 |
| `TriggerPoint` | 可选，含一组SPT | 触发点，由若干SPT经逻辑运算组合而成；为空表示**无条件匹配** | TS 23.218 5.2 |
| `ApplicationServer` | 含ServerName等 | 命中后要触发的AS地址及失败处理策略 | TS 23.218 5.3 |
| `ProfilePartIndicator` | Shared / Public | 标识本iFC属于共享iFC还是私有iFC | TS 23.218 5.3 |
| `ExtensionType` | 扩展 | 后续版本预留 | TS 29.228 |

`ApplicationServer`内部进一步包含：

- **ServerName**：被触发AS的SIP URI，例如 `sip:tas1.home1.net`。第三方注册或业务触发时，它就是Request-URI的目标。
- **DefaultHandling**：默认处理策略，0=`SESSION_CONTINUE`（继续会话），1=`SESSION_TERMINATED`（终止会话）。当AS不可达（ISC超时无响应）时的兜底行为。
- **ServiceInfo**：透传给AS的业务信息字符串（可选），常携带业务标识。
- **ServiceInfoExtension**：扩展信息。

```mermaid
graph LR
    iFC[InitialFilterCriteria] --> P[Priority<br/>评估顺序]
    iFC --> TP[TriggerPoint<br/>触发点]
    iFC --> AS[ApplicationServer<br/>目标AS]
    TP --> CT[ConditionTypeCNF/DNF<br/>逻辑组合]
    TP --> SPT1[SPT: Method]
    TP --> SPT2[SPT: Session Case]
    TP --> SPT3[SPT: SIP Header]
    TP --> SPT4[SPT: Session Description]
    TP --> SPT5[SPT: Registration Type]
    AS --> SN[ServerName<br/>AS的SIP URI]
    AS --> DH[DefaultHandling<br/>Continue/Terminated]
    AS --> SI[ServiceInfo<br/>透传业务信息]
    style iFC fill:#fff3e0,stroke:#FF9800
    style TP fill:#e8f4f8,stroke:#2196F3
    style AS fill:#e8f5e9,stroke:#4CAF50
```

`TriggerPoint`通过`ConditionTypeCNF`（合取范式，组间OR、组内AND）或`ConditionTypeDNF`（析取范式，组间AND、组内OR）把若干SPT组合成一个布尔表达式。S-CSCF收到SIP请求后，就是逐条iFC、按Priority求值这个布尔表达式。

## 三、SPT服务点触发器：iFC的五种"探针"

依据 **TS 23.218 Section 5.2.1**，触发点（TriggerPoint）由一组**服务点触发器 SPT（Service Point Trigger）**构成。SPT共分五大类，每一类都对应SIP请求中可被S-CSCF检查的一个维度：

| SPT类型 | 检查对象 | 典型配置举例 | 说明 |
|---|---|---|---|
| **Method** | SIP请求方法 | `INVITE` / `REGISTER` / `MESSAGE` | 最常用，区分会话/注册/消息 |
| **Session Case** | 会话方向与注册状态 | `Originating` / `Terminating_Registered` 等 | 决定主叫/被叫/未注册场景 |
| **SIP Header** | 任意SIP头域 | `P-Asserted-Identity`、`From`、`Request-URI` | 可判断头存在性、内容、内容类型 |
| **Session Description** | SDP会话描述 | `m=video`、`a=rtpmap`、`b=AS` | 触发基于媒体类型/带宽的业务 |
| **Registration Type** | 注册子类型 | Initial / Re-/De-registration | 仅当Method=REGISTER时有意义 |

**Session Case**（TS 29.228 / TS 23.218）取值是理解主被叫业务触发的核心，它有四个枚举值：

| 值 | SessionCase | 含义 | 典型触发场景 |
|---|---|---|---|
| 0 | `ORIGINATING_SESSION` | 已注册用户发起的主叫 | 主叫侧TAS/补充业务 |
| 1 | `TERMINATING_REGISTERED` | 已注册用户的被叫 | 被叫前转、彩铃 |
| 2 | `TERMINATING_UNREGISTERED` | 未注册用户的被叫 | 未注册前转、语音邮箱 |
| 3 | `ORIGINATING_UNREGISTERED` | 未注册用户发起主叫 | 匿名/受限业务（少用） |

设计意图在于：同一个PUI（Public User Identity）在不同会话方向、不同注册状态下需要触发的业务截然不同。例如"呼叫前转无应答"只在`TERMINATING_REGISTERED`生效，而"未注册前转"只在`TERMINATING_UNREGISTERED`生效，两者共用同一个SPT框架但靠SessionCase区分，使iFC具有极强的表达力。

## 四、第三方注册（Third Party Registration）信令全链拆解

第三方注册是iFC最经典的应用之一，定义在 **TS 23.228 Section 5.x（Registration procedures）** 与 **TS 23.218 Section 6.3（S-CSCF handling of SIP registration）**，Stage 3的SIP构造细节在 **TS 24.229**（IMS Call Session Control Function）中。

当UE完成IMS初始注册、收到`200 OK`之后，S-CSCF并不会就此停下，而是要"通知"所有关心该用户注册状态的AS——这就是第三方注册。其本质是：**S-CSCF代表已注册用户，向AS再发一次REGISTER**，AS由此得知"该用户现在在线了"。

```mermaid
sequenceDiagram
    participant UE
    participant PCSCF as P-CSCF
    participant ICSCF as I-CSCF
    participant SCSCF as S-CSCF
    participant HSS
    participant TAS as TAS / AS
    participant SCC as SCC AS

    UE->>PCSCF: REGISTER (PUI, contact)
    PCSCF->>ICSCF: REGISTER
    ICSCF->>HSS: Cx: UAR (User-Authorization)
    HSS-->>ICSCF: Cx: UAA (选S-CSCF能力集)
    ICSCF->>SCSCF: REGISTER
    SCSCF->>HSS: Cx: MAR (Multimedia-Auth, 取鉴权向量)
    HSS-->>SCSCF: Cx: MAA
    Note over SCSCF,UE: 401 Challenge → 鉴权 → (省略)
    UE->>SCSCF: REGISTER(带响应, 二次)
    SCSCF->>HSS: Cx: SAR (Server-Assignment, 注册登记)
    HSS-->>SCSCF: Cx: SAA (下载Service Profile, 含iFC集合)
    SCSCF-->>UE: 200 OK (注册成功)

    Note over SCSCF: 评估iFC: Method=REGISTER<br/>且 Registration Type=Initial 匹配
    SCSCF->>TAS: 第三方 REGISTER<br/>R-URI=tas1.home1.net, From/To=PUI
    TAS-->>SCSCF: 200 OK
    SCSCF->>SCC: 第三方 REGISTER<br/>R-URI=scc.home1.net
    SCC-->>SCSCF: 200 OK
    Note over SCC: SCC AS 订阅 reg-event package<br/>感知后续注册状态变化
```

### 关键信令IE逐步解析

第三方REGISTER与UE原始REGISTER有几个决定性差异，这是抓包时识别它的关键：

| IE / 消息元素 | UE原始REGISTER | 第三方REGISTER | 说明 |
|---|---|---|---|
| **Request-URI** | registrar域名（`sip:home1.net`） | **AS域名**（`sip:tas1.home1.net`） | 这是区分两者最直接的标志 |
| **From / To** | UE的PUI | **UE的PUI**（S-CSCF代发） | 表明"谁被注册" |
| **P-Asserted-Identity** | 通常无 | **含已验证PUI** | S-CSCF鉴权后插入，证明身份可信 |
| **Contact** | UE的IP contact | 可能保留或置空 | 视实现而定 |
| **Via / Route** | 指向P-CSCF | 反映ISC路径 | 经ISC接口直达AS |
| **发起方** | UE | **S-CSCF** | 源自S-CSCF而非空口 |

### 设计意图

为什么不让AS直接监听Cx接口或UE的REGISTER？因为：第一，UE与registrar之间的REGISTER是用户与网络的私密信令，AS无权直接旁路；第二，AS关心的不是鉴权细节，而是"用户在线/离线"这一高层语义事件；第三，ISC基于标准SIP，复用SIP语义（REGISTER=注册），对AS实现友好。SCC AS（Service Centralization and Continuity）通常在收到第三方注册后立即向S-CSCF发起`SUBSCRIBE`（reg-event package），以便后续感知重注册/注销，实现SRVCC等连续性业务——这一步与"VoNR IMS注册信令"密切相关但属不同机制，此处不展开。

## 五、主叫会话AS循环触发（Originating iFC Loop）拆解

第三方注册解决"用户上线通知"，业务触发的另一条主线是**会话建立期间**的AS循环。依据 **TS 23.228 Section 5.5.4（Session origination, S-S#4）** 与 **TS 23.218 Section 5.4（Service Control in the IM CN Subsystem）**，当S-CSCF收到一条主叫INVITE时，会按优先级把请求"过一遍"所有匹配`ORIGINATING_SESSION`的iFC。

```mermaid
sequenceDiagram
    participant UE
    participant SCSCF as S-CSCF<br/>(主叫侧)
    participant AS1 as AS1<br/>Priority=1
    participant AS2 as AS2<br/>Priority=2
    participant TERM as 被叫侧<br/>I/S-CSCF

    UE->>SCSCF: INVITE (主叫)
    Note over SCSCF: 取iFC, 评估 SessionCase=Originating<br/>按Priority升序
    SCSCF->>AS1: INVITE (经ISC, Route指向AS1)
    Note over AS1: 业务处理<br/>如号码规整/预付费
    AS1-->>SCSCF: INVITE (可能改SDP/头)
    SCSCF->>AS2: INVITE (用AS1返回的请求继续)
    Note over AS2: 业务处理<br/>如彩铃/录音通知
    AS2-->>SCSCF: INVITE
    Note over SCSCF: Originating iFC评估完毕
    SCSCF->>TERM: INVITE (向被叫侧路由)
    Note over TERM: 被叫S-CSCF再评估<br/>Terminating iFC
```

这是一个典型的"穿透-回送"循环（sometimes called **SIP AS leg**）：S-CSCF把INVITE发给AS1，AS1以Proxy/B2BUA方式处理后**重新发回S-CSCF**，S-CSCF再依据AS1回送请求评估下一条iFC，直至全部匹配的Originating iFC处理完毕，才把请求路由向被叫域。到达被叫S-CSCF后，再对`TERMINATING_*`的iFC做一轮评估，最后下发给被叫UE。

### 关键设计意图

- **优先级保证业务顺序**：例如预付费AS（Priority=1）必须在号码显示AS（Priority=2）之前评估，否则用户可能听了一段彩铃才被告知余额不足。Priority字段正是为此而生。
- **AS角色的灵活性**：AS可扮演Originating UA、Terminating UA、Proxy、B2BUA或Redirect server（TS 23.218）。例如呼叫转移AS以B2BUA角色改写Request-URI，把呼叫"拐"到新号码。
- **状态隔离**：每条iFC独立评估、独立转发，AS间彼此透明，符合分层解耦哲学。

## 六、DefaultHandling：AS故障时的兜底状态机

依据 **TS 23.218 Section 5.4**，当某条iFC匹配、S-CSCF经ISC把请求发往AS但AS**无响应超时**（不可达）时，`DefaultHandling`决定后续动作，这是业务连续性的关键兜底机制。

```mermaid
stateDiagram-v2
    [*] --> 命中iFC
    命中iFC --> 发往AS经ISC
    发往AS经ISC --> AS响应: 正常
    AS响应 --> 继续下一条iFC
    发往AS经ISC --> 超时无响应: 不可达
    超时无响应 --> 判定DefaultHandling
    判定DefaultHandling --> SESSION_CONTINUE: DH=0<br/>跳过本AS继续
    判定DefaultHandling --> SESSION_TERMINATED: DH=1<br/>中止会话返回错误
    SESSION_CONTINUE --> 继续下一条iFC
    继续下一条iFC --> [*]
    SESSION_TERMINATED --> [*]
    正常 --> [*]
```

- **SESSION_CONTINUE（0）**：AS宕机不影响主流程，适合非关键业务（如彩铃）。用户仍能正常呼叫，只是该业务"静默丢失"。
- **SESSION_TERMINATED（1）**：AS不可达即拒绝整个会话，适合关键业务（如预付费、紧急呼叫、合规拦截），宁可阻断也不能放行。

运维上，DefaultHandling配置错误是高频故障源：把关键AS配成CONTINUE会留下业务漏洞，把装饰性AS配成TERMINATED则AS一抖动就大面积呼叫失败。

## 七、抓包识别与排错实战

### 如何在抓包中识别iFC触发

1. **第三方REGISTER**：在ISC接口（S-CSCF↔AS）抓包，看到S-CSCF主动发出的REGISTER，且Request-URI指向**AS域名而非registrar域名**、带`P-Asserted-Identity`，即为第三方注册。可借助TShark过滤器：`sip.Method == "REGISTER" && sip.Request-URI contains "as"`。
2. **主叫AS循环**：在同一次INVITE会话中，观察S-CSCF与多个AS之间出现反复的INVITE来回（多个Via/Record-Route），即可确认发生了多级AS触发。
3. **iFC本身不可见**：iFC是S-CSCF本地数据，不在SIP报文中显式传输；要确认iFC内容，需查Cx SAR/SAA（Service Profile下载）或厂商网管上的用户档案配置。

### 常见故障点

| 故障现象 | 根因方向 | 排查思路 |
|---|---|---|
| 用户注册成功但补充业务不生效 | 对应iFC未配置/未下发，或TriggerPoint不匹配 | 查Cx SAA是否含目标iFC；核对SessionCase、Method |
| 主叫呼叫随机失败 | 关键AS配成TERMINATED且抖动 | 检查DefaultHandling；查AS ISC可达性与超时 |
| 呼叫前转不生效 | SessionCase配错（如未注册前转配到了Registered） | 核对Terminating iFC的SessionCase值 |
| 第三方REGISTER未到AS | AS路由/ISC路由配置缺失；ServerName错误 | 验证DNS/SIP路由能解析ServerName |
| AS触发顺序混乱 | Priority未设或多条同优先级 | 显式设置Priority，避免依赖默认顺序 |
| HSS数据与S-CSCF缓存不一致 | 重启或Cx数据未刷新 | 触发重新注册强制SAR/SAA刷新 |
## 常见问题

**Q1：iFC和sFC（Subsequent Filter Criteria）有什么区别？**
A：iFC（Initial Filter Criteria）在每个**初始SIP请求**（INVITE、REGISTER等）到达S-CSCF时评估，决定初始触发哪个AS；sFC（Subsequent Filter Criteria）是后续规范（R7+）引入的，用于在**已建立的会话期间**对后续请求（如re-INVITE、MESSAGE mid-dialog）进行二次AS触发评估。绝大多数补充业务只用iFC，sFC用于需要会话中途持续控制的复杂业务。

**Q2：第三方REGISTER和UE的REGISTER在网络中走同一条路径吗？**
A：不走。UE的REGISTER走UE→P-CSCF→I-CSCF→S-CSCF（含Cx鉴权交互）；第三方REGISTER是S-CSCF在注册成功**之后**、经ISC接口**直接发往AS**，不经过P-CSCF/I-CSCF，也不回到空口。两者的Request-URI目标不同，是抓包区分的关键。

**Q3：一条iFC匹配后，AS处理完返回的请求，S-CSCF如何继续？**
A：S-CSCF用AS返回的（可能被改写过的）请求，继续评估**剩余的、优先级更低**的iFC。若AS以B2BUA角色彻底改写了目标（如呼叫转移到新号码），后续iFC仍按改写后的请求评估。这种"链式穿透"正是多业务叠加的基础。

**Q4：DefaultHandling选CONTINUE还是TERMINATED有没有通用原则？**
A：通用原则是"看该业务缺失是否会带来安全/计费/合规风险"。预付费、紧急呼叫、合法拦截等必须TERMINATED（宁阻不漏）；彩铃、彩像、录音通知等增强体验类业务应CONTINUE（容忍降级）。现网中因AS偶发抖动导致整网呼叫失败的案例，多数根因就是装饰性AS被错误配置为TERMINATED。

**Q5：iFC评估是主叫侧做还是被叫侧做？**
A：两边都做，但用不同的SessionCase子集。主叫S-CSCF评估`ORIGINATING_*`的iFC；请求路由到被叫域后，由被叫S-CSCF评估`TERMINATING_*`的iFC。一个跨域呼叫可能经历主叫侧n条+被叫侧m条AS触发，这正是端到端呼叫建立时延（post-dial delay）的重要组成。

## 参考来源

1. [3GPP TS 23.218 — IP Multimedia (IM) Session Handling; IM Call Model (Stage 2)](https://www.3gpp.org/dynareport/23218.htm) — iFC定义（5.3）、SPT定义（5.2.1）、Service Control（5.4）、S-CSCF注册处理（6.3）
2. [3GPP TS 23.228 — IP Multimedia Subsystem (IMS) Stage 2](https://www.3gpp.org/dynareport/23228.htm) — 注册流程与会话起源（5.5.4 S-S#4）、AS交互
3. [3GPP TS 29.228 — Cx and Dx interfaces; Signalling flows and message contents](https://www.3gpp.org/dynareport/29228.htm) — iFC XML Schema（附录）、Cx SAR/SAA信元、SessionCase取值
4. [3GPP TS 24.229 — IP Multimedia Call Control Protocol based on SIP and SDP (Stage 3)](https://www.3gpp.org/dynareport/24229.htm) — S-CSCF侧SIP处理、第三方REGISTER构造、iFC评估的Stage 3实现
5. [Initial Filter Criteria (IFC) — 3GPP Explorer Glossary](https://3gpp-explorer.com/glossary/ifc/) — iFC概念与SPT/SessionCase汇总解读
6. [IMS Routing with iFCs — Nick vs Networking](https://nickvsnetworking.com/ims-routing-with-ifcs/) — iFC结构与AS触发流程图解
7. [TS 23.218 Section 6.3 — S-CSCF handling of SIP registration | iTecSpec](https://itecspec.com/3gpp/23.218/s/6.3) — 第三方注册评估条文的逐句对照

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