在VoNR/IMS架构中,UE完成SIP REGISTER并获得200 OK仅意味着传输层注册成功——S-CSCF知道了UE的Contact地址和IPSec SA参数。但IMS业务的真正激活发生在注册成功之后:S-CSCF从HSS下载用户签约数据中的Filter Criteria(过滤准则),并依据这些规则向应用服务器(AS)发起Third-Party Registration(第三方注册),由AS完成补充业务的初始化配置。
这一机制定义在 TS 23.228 Section 5.3.5(Third-Party Registration)、TS 29.228 Annex A(Filter Criteria XML Schema)和 TS 24.229 Section 5.1.1.6(Third-Party Registration Procedures),是连接"用户可达性"与"业务可用性"的核心纽带。
| 场景 | 无Third-Party Registration | 有Third-Party Registration |
|---|---|---|
| 呼叫前转(CFU) | 需用户每次呼叫时自行指定前转号码 | AS自动根据签约数据执行前转 |
| 呼叫等待(CW) | 无法动态激活/去激活 | AS通过SIP SUBSCRIBE/NOTIFY推送状态 |
| 主叫号码显示(CNAP) | 无个性化配置 | AS根据用户偏好定制显示策略 |
| 欠费停机 | 无法实时生效 | ODB触发AS拒绝呼入/呼出 |
| 多终端注册 | 无法关联同一IMPU下的多设备 | TAS维护多设备绑定关系 |
设计意图:将"注册管理"(S-CSCF职责)与"业务逻辑"(AS职责)彻底解耦。S-CSCF作为无状态的信令路由器,不维护业务状态;AS作为有状态的业务引擎,通过Third-Party Registration感知用户在线状态并初始化业务上下文。
S-CSCF在IMS-AKA认证成功后,通过Cx SAR/SAA接口从HSS下载完整用户签约数据(TS 29.228 Section 7.6.2)。下载的核心数据结构如下:
graph TB
subgraph "IMS User Data (TS 29.228 Annex A)"
UD["User Data<br/>XML Document"]
UD --> SP["Service Profile"]
UD --> PI["Public Identity Set"]
SP --> FC1["Filter Criteria 1"]
SP --> FC2["Filter Criteria 2"]
SP --> FC3["Filter Criteria N..."]
FC1 --> TP1["Trigger Point<br/>(SPT集合)"]
FC1 --> AS1["Application Server<br/>sip:tas.ims.mnc000.mcc460.3gppnetwork.org"]
FC1 --> PR1["Profile Part Indicator<br/>(Registered/Unregistered)"]
TP1 --> SPT1["SPT: Method = REGISTER"]
TP1 --> SPT2["SPT: Session Case = Originating"]
TP1 --> SPT3["SPT: Session Description<br/>Line = a=sendrecv"]
PI --> IMPU1["IMPU: sip:+86138xxx@ims"]
PI --> IMPU2["IMPU: tel:+86138xxx"]
PI --> Barring["Barring Indication<br/>(是否允许注册)"]
end
style UD fill:#e3f2fd
style SP fill:#fff3e0
style FC1 fill:#e8f5e9
style FC2 fill:#e8f5e9
style TP1 fill:#fce4ec
style AS1 fill:#f3e5f5
以下是一个典型的Filter Criteria XML片段,对应 MMTel语音补充业务的触发规则:
<FilterCriteria>
<Priority>0</Priority>
<TriggerPoint>
<ConditionTypeCNF>0</ConditionTypeCNF> <!-- 0=AND, 1=OR -->
<SPT>
<ConditionNegated>0</ConditionNegated> <!-- 0=不取反 -->
<Group>0</Group>
<Method>REGISTER</Method>
</SPT>
<SPT>
<ConditionNegated>0</ConditionNegated>
<Group>0</Group>
<Header>
<HeaderName>Content-Type</HeaderName>
<HeaderContent>application/reginfo+xml</HeaderContent>
</Header>
</SPT>
</TriggerPoint>
<ApplicationServer>
<ServerName>sip:tas.ims.mnc000.mcc460.3gppnetwork.org</ServerName>
<DefaultHandling>0</DefaultHandling> <!-- 0=继续会话, 1=终止会话 -->
<ServiceInfo>ims-mmtel-voice</ServiceInfo>
</ApplicationServer>
<ProfilePartIndicator>0</ProfilePartIndicator> <!-- 0=Registered -->
</FilterCriteria>
Filter Criteria的核心匹配逻辑由SPT(Service Point Trigger)定义。每个SPT对应SIP消息中的一个可检测字段:
| SPT类型 | XML标签 | 匹配对象 | 示例 |
|---|---|---|---|
| Method | <Method> |
SIP方法名 | REGISTER, INVITE, SUBSCRIBE |
| Session Case | <SessionCase> |
会话方向 | 0=Originating, 1=Terminating, 2=Originating_Unregistered |
| Session Description | <SessionDescription> |
SDP行内容 | s=, a=sendrecv |
| SIP Header | <Header> |
SIP头部字段 | Content-Type: application/sdp |
| Request-URI | <RequestURI> |
请求URI中的用户部分 | +8613800138000 |
| Registration Type | <RegistrationType> |
注册事件类型 | 0=Initial, 1=Re-registration, 2=De-registration |
多个SPT之间通过 ConditionTypeCNF 决定组合逻辑:
| 值 | 含义 | 匹配规则 |
|---|---|---|
| 0 | CNF(合取范式) | 所有SPT必须同时满足(AND逻辑) |
| 1 | DNF(析取范式) | 任意SPT满足即可(OR逻辑) |
Group字段进一步允许将SPT分组:同一Group内的SPT之间是OR关系,不同Group之间是AND关系。这提供了极强的匹配灵活性。
以下基于 TS 23.228 Section 5.3.5.1 的完整Third-Party Registration流程:
sequenceDiagram
participant UE
participant PCSCF as P-CSCF
participant SCSCF as S-CSCF
participant HSS
participant TAS as TAS/AS
participant MMTel as MMTel AS
participant SCC as SCC AS
Note over UE,SCSCF: 前置条件: IMS注册200 OK已返回UE
Note over SCSCF: S-CSCF已通过Cx SAA获取<br/>User Data + Filter Criteria
Note over SCSCF,TAS: 阶段1: 评估Filter Criteria - REGISTER触发
SCSCF->>SCSCF: 遍历Filter Criteria列表<br/>按Priority排序
SCSCF->>SCSCF: 匹配SPT: Method=REGISTER<br/>SessionCase=Originating<br/>ProfilePartIndicator=Registered
Note over SCSCF,TAS: 阶段2: 向TAS发起Third-Party REGISTER
SCSCF->>TAS: SIP REGISTER<br/>(From: S-CSCF, To: IMPU,<br/>Contact: IMPU@S-CSCF,<br/>expires=3600, Call-ID: scscf-tas-1)
Note right of SCSCF: S-CSCF充当UA<br/>代表UE向AS注册
TAS->>TAS: 验证S-CSCF身份<br/>检查用户签约数据
TAS->>TAS: 初始化用户业务上下文<br/>加载CFU/CFC/CW/CLIR配置
TAS-->>SCSCF: 200 OK (REGISTER)
Note over SCSCF,MMTel: 阶段3: 向MMTel AS发起Third-Party REGISTER
SCSCF->>MMTel: SIP REGISTER<br/>(From: S-CSCF, To: IMPU,<br/>expires=3600)
MMTel->>MMTel: 激活MMTel语音补充业务<br/>OIP/OIR/CDIV/CW
MMTel-->>SCSCF: 200 OK (REGISTER)
Note over SCSCF,SCC: 阶段4: 向SCC AS发起Third-Party REGISTER
SCSCF->>SCC: SIP REGISTER<br/>(From: S-CSCF, To: IMPU,<br/>expires=3600)
SCC->>SCC: 注册T-ADS功能<br/>建立Multi-Device绑定
SCC-->>SCSCF: 200 OK (REGISTER)
Note over SCSCF,TAS: 阶段5: Filter Criteria中的INVITE触发规则生效
Note over SCSCF: 后续UE发起INVITE时:<br/>匹配Filter Criteria(方法=INVITE,<br/>SessionCase=Originating)<br/>→ SIP INVITE先路由到TAS<br/>→ TAS执行补充业务逻辑<br/>→ TAS转发到目标
S-CSCF向AS发送的Third-Party REGISTER与UE的初始REGISTER有本质区别:
| IE | UE REGISTER | Third-Party REGISTER |
|---|---|---|
| From | <sip:IMPU@ims...>;tag=ue-tag |
sip:scscf.ims...;tag=scscf-tag |
| To | <sip:IMPU@ims...> |
<sip:IMPU@ims...> |
| Contact | <sip:IMPU@[UE_IP]:port> |
<sip:[email protected]...> |
| Call-ID | UE生成 | S-CSCF生成(独立命名空间) |
| CSeq | S-CSCF内部分配 | S-CSCF内部分配 |
| Expires | UE请求的值 | 与UE注册有效期同步 |
| Route | 无(P-CSCF已添加) | 可能包含AS的Route信息 |
| P-Charging-Vector | 无 | icid-value=xxx;orig-ioi=xxx |
| P-Visited-Network-ID | 无 | 拜访网络标识 |
关键区别:Third-Party REGISTER中,S-CSCF扮演UA角色,From头是S-CSCF自身,Contact指向S-CSCF而非UE。AS因此知道用户已注册,且后续SIP请求需经由该S-CSCF路由。
Third-Party Registration建立了"用户在线"的感知,而真正的业务逻辑在后续SIP请求触发时执行。以下以主叫INVITE触发TAS为例:
flowchart TD
INVITE["UE → P-CSCF → S-CSCF<br/>SIP INVITE"] --> EVAL["S-CSCF评估<br/>Filter Criteria列表"]
EVAL --> FC1{"FC Priority=0<br/>Method=INVITE<br/>SessionCase=Originating"}
FC1 -->|"匹配"| ROUTE1["路由到TAS<br/>执行OCSI逻辑"]
FC1 -->|"不匹配"| FC2
ROUTE1 --> TAS_CHECK["TAS检查:<br/>- CLIR是否激活?<br/>- 呼叫限制?<br/>- CDIV触发?"]
TAS_CHECK -->|"无前转"| FORWARD["TAS → S-CSCF<br/>→ I-CSCF → 被叫"]
TAS_CHECK -->|"有CFU"| DIVERT["TAS执行呼叫前转<br/>修改Request-URI<br/>重新路由到前转目标"]
TAS_CHECK -->|"有呼出限制"| REJECT["TAS返回<br/>SIP 603 Decline<br/>或403 Forbidden"]
FC2{"FC Priority=1<br/>Method=INVITE<br/>SessionCase=Terminating"} -->|"匹配"| ROUTE2["路由到TAS<br/>执行TCSI逻辑"]
ROUTE2 --> TAS_T["TAS检查:<br/>- CFB/CFNR/CFNL?<br/>- 呼叫等待?<br/>- OIP/OIR?"]
style INVITE fill:#e1f5fe
style TAS_CHECK fill:#fff3e0
style TAS_T fill:#fce4ec
S-CSCF对Filter Criteria的评估分两个独立维度:
| 触发类型 | 全称 | 触发时机 | 典型业务 |
|---|---|---|---|
| OCSI | Originating CAMEL Subscription Information | UE发起INVITE(主叫侧) | CLIR、呼出限制、预付费计费 |
| TCSI | Terminating CAMEL Subscription Information | INVITE到达被叫S-CSCF | CFB/CFNR/CFNL、呼入限制、CNAP |
注:OCSI/TCSI术语源自CAMEL智能网架构(TS 23.008),IMS中通过Filter Criteria的SessionCase字段实现等价功能。
sequenceDiagram
participant UE_O as UE (Calling)
participant PCSCF_O as P-CSCF (O)
participant SCSCF_O as S-CSCF (O)
participant TAS_O as TAS (Originating)
participant ICSCF_T as I-CSCF (T)
participant SCSCF_T as S-CSCF (T)
participant TAS_T as TAS (Terminating)
participant PCSCF_T as P-CSCF (T)
participant UE_T as UE (Called)
UE_O->>PCSCF_O: SIP INVITE
PCSCF_O->>SCSCF_O: SIP INVITE
Note over SCSCF_O: 匹配Filter Criteria<br/>SessionCase=Originating<br/>Method=INVITE → Route to TAS
SCSCF_O->>TAS_O: SIP INVITE (OCSI触发)
Note over TAS_O: 执行主叫侧业务逻辑:<br/>1. 检查CLIR<br/>2. 检查呼出限制(ODB)<br/>3. 预付费扣费授权
TAS_O->>SCSCF_O: SIP INVITE (业务处理完成,继续路由)
SCSCF_O->>ICSCF_T: SIP INVITE (跨域路由)
ICSCF_T->>SCSCF_T: SIP INVITE
Note over SCSCF_T: 匹配Filter Criteria<br/>SessionCase=Terminating<br/>Method=INVITE → Route to TAS
SCSCF_T->>TAS_T: SIP INVITE (TCSI触发)
Note over TAS_T: 执行被叫侧业务逻辑:<br/>1. 检查CFB/CFNR<br/>2. 检查呼入限制<br/>3. 呼叫等待判断
TAS_T->>SCSCF_T: SIP INVITE (无前转,继续路由)
SCSCF_T->>PCSCF_T: SIP INVITE
PCSCF_T->>UE_T: SIP INVITE
stateDiagram-v2
[*] --> User_Data_Download: Cx SAA<br/>(IMS注册认证成功)
User_Data_Download --> FC_Evaluation: 解析Filter Criteria<br/>按Priority排序
FC_Evaluation --> TP_Reg: FC匹配REGISTER<br/>ProfilePartIndicator=Registered
FC_Evaluation --> TP_UnReg: FC匹配REGISTER<br/>ProfilePartIndicator=Unregistered
TP_Reg --> 3rd_Reg_TAS: Third-Party REGISTER → TAS
TP_Reg --> 3rd_Reg_MMTel: Third-Party REGISTER → MMTel AS
TP_Reg --> 3rd_Reg_SCC: Third-Party REGISTER → SCC AS
3rd_Reg_TAS --> AS_Context_Active: TAS业务上下文激活<br/>(CFU/CW/CLIR配置加载)
3rd_Reg_MMTel --> AS_Context_Active
3rd_Reg_SCC --> AS_Context_Active
AS_Context_Active --> INVITE_Trigger: 后续INVITE匹配FC<br/>触发到AS
AS_Context_Active --> ReReg_Trigger: UE重注册<br/>触发Third-Party REGISTER刷新
AS_Context_Active --> DeReg_Trigger: UE去注册/注册过期<br/>触发Third-Party De-Register
DeReg_Trigger --> AS_Context_Cleanup: AS清除业务上下文
AS_Context_Cleanup --> [*]
TP_UnReg --> UnReg_Service: 未注册业务处理<br/>(如未注册呼入前转至语音信箱)
UnReg_Service --> [*]
当IMS注册过期或UE主动去注册时,S-CSCF必须向所有已发起Third-Party Registration的AS发送REGISTER with expires=0:
REGISTER sip:tas.ims.mnc000.mcc460.3gppnetwork.org SIP/2.0
From: <sip:scscf.ims.mnc000.mcc460.3gppnetwork.org>;tag=de-reg-001
To: <sip:[email protected]>
Contact: <sip:[email protected]>
Expires: 0
Call-ID: [email protected]
CSeq: 2 REGISTER
TAS收到expires=0后,执行以下清理:
1. 释放用户业务上下文
2. 停止所有激活的补充业务计时器
3. 若用户签约了"未注册"状态的Filter Criteria(ProfilePartIndicator=Unregistered),则激活未注册业务处理(如将呼入前转至语音信箱)
IMS注册完成后,UE可通过SIP SUBSCRIBE订阅reg事件包(registration event package)(RFC 3680),获取自身注册状态变化通知:
SUBSCRIBE sip:[email protected] SIP/2.0
Event: reg
Accept: application/reginfo+xml
Expires: 3600
Contact: <sip:+8613800138000@[UE_IP]:port_us>
S-CSCF通过NOTIFY返回当前注册状态:
<?xml version="1.0"?>
<reginfo xmlns="urn:ietf:params:xml:ns:reginfo" state="full" version="0">
<registration aor="sip:[email protected]"
id="reg1" state="active">
<contact id="c1" state="active" event="registered" expires="3600">
<uri>sip:+8613800138000@[UE_IP]:port_us</uri>
</contact>
</registration>
</reginfo>
AS(如TAS)在收到Third-Party Registration后,也可向S-CSCF订阅reg事件包,以感知UE的去注册事件:
sequenceDiagram
participant TAS
participant SCSCF as S-CSCF
participant UE
TAS->>SCSCF: SIP SUBSCRIBE (Event: reg)<br/>订阅IMPU注册状态
SCSCF-->>TAS: 200 OK (SUBSCRIBE)
Note over UE: UE网络异常断开<br/>注册超时
SCSCF->>TAS: SIP NOTIFY<br/>(reginfo: state=terminated)
Note over TAS: TAS感知UE离线<br/>激活未注册前转逻辑
Note over UE: UE重新上线<br/>完成IMS注册
SCSCF->>SCSCF: 触发Third-Party REGISTER刷新
SCSCF->>TAS: Third-Party REGISTER (expires=3600)
SCSCF->>TAS: SIP NOTIFY<br/>(reginfo: state=active)
TS 24.173定义了MMTel补充业务通过SIP SUBSCRIBE/NOTIFY和SIP PUBLISH进行配置。以呼叫前转无条件(CFU)为例:
UE激活CFU:
PUBLISH sip:[email protected] SIP/2.0
Content-Type: application/xml
<?xml version="1.0"?>
<ims-3gpp-completedata xmlns="urn:xml:ns:ims-3gpp-completedata">
<communication-diversion-condition>
<diversion-not-reason></diversion-not-reason>
<forward-to>
<target>sip:[email protected]</target>
</forward-to>
</communication-diversion-condition>
</ims-3gpp-completedata>
业务流程链:UE PUBLISH → S-CSCF(匹配Filter Criteria: Method=PUBLISH)→ TAS → TAS存储CFU配置 → 200 OK。后续呼入INVITE到达TAS时,TAS执行前转逻辑。
当多条Filter Criteria同时匹配时,S-CSCF按以下规则处理:
| 规则 | 说明 |
|---|---|
| Priority值越小越优先 | Priority=0最高,依次递增 |
| 同Priority按AS地址排序 | 字典序排列,确保确定性 |
| 高优先FC处理完成后继续 | 除非AS返回终止指示 |
| DefaultHandling决定失败策略 | 0=继续后续FC评估,1=终止会话 |
| Priority | Method | SessionCase | 目标AS | 业务 |
|---|---|---|---|---|
| 0 | REGISTER | Originating | TAS | Third-Party Registration |
| 1 | REGISTER | Originating | MMTel AS | MMTel业务初始化 |
| 2 | INVITE | Originating | TAS | 主叫补充业务(CLIR/呼出限制) |
| 3 | INVITE | Terminating | TAS | 被叫补充业务(CFB/CFNR/呼入限制) |
| 4 | INVITE | Terminating | SCC AS | T-ADS多设备路由决策 |
| 5 | SUBSCRIBE | Originating | TAS | 补充业务订阅管理 |
| 6 | PUBLISH | Originating | TAS | 补充业务配置更新 |
| 7 | *(任意) | Unregistered | Voicemail AS | 未注册呼入前转语音信箱 |
# 过滤Third-Party REGISTER(S-CSCF → AS)
sip.Method == "REGISTER" && sip.From contains "scscf"
# 过滤特定IMPU的所有Filter Criteria触发
sip.To contains "+8613800138000"
# 过滤Cx Diameter交互(Filter Criteria下载)
diameter.Command-Code == 301 # SAR/SAA
# 过滤SIP NOTIFY(reg事件包)
sip.Method == "NOTIFY" && sip.Event == "reg"
# 过滤SIP PUBLISH(补充业务配置)
sip.Method == "PUBLISH"
| 观察点 | Third-Party REGISTER特征 | UE REGISTER特征 |
|---|---|---|
| From头 | S-CSCF URI | UE IMPU |
| Contact头 | S-CSCF地址 | UE IP:Port |
| IPSec保护 | 无(网络内部) | 有(受保护端口) |
| 路径 | S-CSCF → AS(直连) | UE → P-CSCF → I-CSCF → S-CSCF |
| P-Charging-Vector | 有 | 可选 |
| 故障现象 | 可能原因 | 排错方法 |
|---|---|---|
| IMS注册成功但补充业务不生效 | Third-Party REGISTER未发出或AS未响应 | 检查S-CSCF日志中的FC评估记录;检查S-CSCF→AS的SIP REGISTER;检查AS是否返回200 OK |
| 呼叫前转不执行 | TAS未正确存储CFU配置 | 检查UE PUBLISH是否到达TAS;检查TAS日志中的CFU规则;验证Filter Criteria中INVITE→TAS规则存在 |
| 主叫INVITE被错误路由 | Filter Criteria Priority配置冲突 | 检查HSS用户签约数据中的FC Priority顺序;确认S-CSCF按Priority评估 |
| 用户已去注册但呼入仍振铃 | S-CSCF未发送Third-Party De-Register | 检查S-CSCF在注册过期后是否向AS发送REGISTER expires=0 |
| AS收到INVITE但无用户上下文 | Third-Party REGISTER被AS拒绝 | 检查AS日志中REGISTER处理结果码;检查AS与HSS之间的Sh接口用户数据同步 |
| 未注册前转不工作 | ProfilePartIndicator=Unregistered的FC缺失 | 检查HSS签约数据中是否配置了Unregistered类型的Filter Criteria |
| ## 九、Sh接口与Cx接口协同 |
AS需要用户业务配置数据来执行补充业务逻辑,有两种获取途径:
| 途径 | 接口 | 协议 | 数据来源 | 适用场景 |
|---|---|---|---|---|
| Cx接口 | I-CSCF/S-CSCF ↔ HSS | Diameter | HSS直出 | 注册/认证相关 |
| Sh接口 | AS ↔ HSS | Diameter | HSS直出 | 业务数据查询/更新 |
Sh接口(TS 29.328)允许AS主动查询和更新用户数据,关键命令:
| 命令 | 用途 |
|---|---|
| UDR/UDA | 用户数据查询(User-Data-Request/Answer) |
| PUR/PUA | 用户数据更新(Profile-Update-Request/Answer) |
| SNR/SNA | 订阅通知(Subscribe-Notifications-Request/Answer) |
AS → HSS: Sh-UDR (User-Data-Request)
- User-Identity: sip:+8613800138000@ims...
- Data-Reference: RepositoryData (0)
- Service-Indication: "MMTel-CDIV"
HSS → AS: Sh-UDA (User-Data-Answer)
- User-Data:
<RepositoryData>
<ServiceIndication>MMTel-CDIV</ServiceIndication>
<ServiceData>
<CDIV active="true">
<ForwardTo>sip:+8613900139000@ims...</ForwardTo>
<NoReplyTimer>20</NoReplyTimer>
</CDIV>
</ServiceData>
</RepositoryData>
AS通过Sh接口获取CDIV(Communication Diversion)配置后,在呼入INVITE到达时执行前转判断。
| 维度 | VoNR (5GC) | VoLTE (EPC) |
|---|---|---|
| Filter Criteria来源 | HSS (via Cx) | HSS (via Cx),相同机制 |
| Third-Party Reg传输承载 | 5QI=5 QoS Flow | QCI=5 EPS Bearer |
| AS间通信 | ISC接口(SIP) | ISC接口(SIP),相同 |
| Sh接口 | Diameter(与4G相同) | Diameter |
| 策略控制联动 | PCF (N7) → SMF | PCRF (Gx) → PGW |
| 计费接口 | Nchf (HTTP/JSON) | Rf/Ro (Diameter) |
| AS发现方式 | DNS/NAPTR + S-CSCF路由 | 相同 |
| Multi-Device支持 | SCC AS + T-ADS | 相同机制 |
核心结论:Third-Party Registration和Filter Criteria机制在5GC和EPC中完全一致——它们是IMS层面的机制,与底层承载技术(QoS Flow vs EPS Bearer)无关。这是IMS架构"接入无关性"的典型体现。
Q1: Third-Party Registration和UE的SIP REGISTER有什么关系?是否独立?
A: 完全独立但有时序依赖。UE的REGISTER建立UE与S-CSCF之间的注册绑定;Third-Party REGISTER发生在UE注册成功后,由S-CSCF自动发起到AS,UE完全不感知。Third-Party REGISTER的From头是S-CSCF而非UE,它们使用不同的Call-ID命名空间。但Third-Party REGISTER的expires值必须与UE注册的expires同步——UE重注册时,S-CSCF同步刷新所有Third-Party Registration。
Q2: 如果AS不可达,S-CSCF如何处理INVITE?
A: 取决于Filter Criteria中的DefaultHandling字段(TS 29.228 Annex A):
- DefaultHandling=0(继续会话):S-CSCF跳过该AS,继续评估后续Filter Criteria并正常路由INVITE。业务降级但呼叫不中断。
- DefaultHandling=1(终止会话):S-CSCF直接返回SIP 503 Service Unavailable,呼叫失败。适用于关键AS(如预付费计费),不可跳过。
Q3: 用户为什么感觉不到Third-Party Registration的存在?
A: 因为Third-Party Registration是网络内部行为,完全在S-CSCF和AS之间完成,不涉及UE。UE的IMS注册延迟中已包含了Third-Party Registration的耗时(通常增加50-200ms),但对用户透明。UE只知道注册成功或失败,不知道后台有多少个AS被通知。
Q4: Filter Criteria中的SessionCase=Unregistered有什么特殊用途?
A: 当用户未注册但有呼入时,S-CSCF仍会评估ProfilePartIndicator=Unregistered的Filter Criteria。典型场景是:用户关机/离线后,呼入INVITE到达S-CSCF,匹配Unregistered FC,路由到语音信箱AS或执行CFU(无条件前转)。这确保了即使用户不在线,呼入业务也能正常处理。
Q5: 一个用户最多能配置多少条Filter Criteria?实际网络中典型配置是多少?
A: 3GPP规范未定义硬性上限,但各厂商有实现限制(通常32-64条/用户)。实际网络中,普通VoNR用户的典型配置为3-5条:Third-Party Reg→TAS、Third-Party Reg→MMTel、INVITE(O)→TAS、INVITE(T)→TAS、INVITE(T)→SCC AS。企业用户或VIP用户可能增加预付费计费AS、录音AS等触发规则,达到8-10条。
本文由「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 等场景全覆盖。
