Blog02-iFC — Giải thích chi tiết
IMSSipTelecom MusingsTản Mạn Viễn Thông
#Sip
#CSCF
#IMS
#Telecom Musings
#Core Network
#Radio Telecom
Bố cục bài viết
02-iFC — Giải thích chi tiết
1. Cấu trúc iFC
Tổng quan
[1] Priority
[2] Trigger Point — Service Point Triggers (SPT)
Các loại SPT
Ví dụ kết hợp SPT
[3] Application Server URI
[4] Default Handling
Ví dụ đầy đủ 4 iFC rules của một subscriber
2. Interface Cx — S-CSCF ↔ UDM/HSS
Cx là gì?
Các Cx message quan trọng
a) MAR / MAA — Multimedia Auth Request/Answer
b) SAR / SAA — Server Assignment Request/Answer
c) LIR / LIA — Location Info Request/Answer
d) UAR / UAA — User Authorization Request/Answer
e) PPR / PPA — Push Profile Request/Answer
f) RTR / RTA — Registration Termination Request/Answer
Cx trong 5G — UDM thay HSS
3. Cách S-CSCF chạy iFC chain
Nguyên tắc chạy chain
Chi tiết: AS trả về gì sau khi xử lý?
Ví dụ chạy chain cho MT INVITE
Subsequent Request Filter (sFC)
4. ISC Interface — S-CSCF ↔ TAS
ISC là gì?
Cơ chế routing trong ISC
Sau khi TAS xử lý — trả về S-CSCF
ISC với nhiều AS trong chain
5. TAS xử lý các dịch vụ
5.1 Call Forwarding (CF)
5.2 Call Barring
5.3 CLIP / CLIR
5.4 Call Hold / Resume
5.5 Conference (3-way call)
Tóm tắt toàn bộ
Trang này
Sunex
10/08/2026 · 17 phút đọc
Ngày tạo
10/08/2026
Cập nhật
Lượt xem
5
Đọc
17m
02-iFC — Giải thích chi tiết
1. Cấu trúc iFC
Tổng quan
Mỗi subscriber trong UDM/HSS có một Service Profile, bên trong chứa một danh sách các iFC rules (Initial Filter Criteria).
UDM / HSS
└── Subscriber: IMPU = sip:+84901234567@ims.operator.com
└── Service Profile
├── iFC rule #1 (Priority=1)
├── iFC rule #2 (Priority=2)
├── iFC rule #3 (Priority=5)
└── iFC rule #4 (Priority=10)
Mỗi iFC rule gồm 4 thành phần chính:
+-------------------------------------------------------+
| iFC Rule |
| |
| [1] Priority : integer (0 = cao nhất) |
| [2] Trigger Point : SPT conditions (AND/OR) |
| [3] Application Server: URI của AS/TAS |
| [4] Default Handling : SESSION_CONTINUED / |
| SESSION_TERMINATED |
+-------------------------------------------------------+
[1] Priority
- Số nguyên không âm
- Càng nhỏ càng được chạy trước
- S-CSCF sắp xếp iFC theo priority tăng dần rồi chạy tuần tự
- Nếu hai rule có cùng priority → thứ tự không xác định (vendor-dependent)
Priority=1 --> chạy đầu tiên
Priority=2 --> chạy thứ hai
Priority=5 --> chạy thứ ba
Priority=10 --> chạy cuối
[2] Trigger Point — Service Point Triggers (SPT)
Trigger Point là điều kiện để rule được kích hoạt. Một Trigger Point chứa một hoặc nhiều SPT (Service Point Trigger), các SPT kết hợp bằng logic AND hoặc OR với nhau.
Các loại SPT
a) Method
Method = INVITE
Method = REGISTER
Method = SUBSCRIBE
Method = MESSAGE
Method = UPDATE
b) Session Case — chiều cuộc gọi
+----------------------------+---------------------------------------------+
| Session Case | Ý nghĩa |
+----------------------------+---------------------------------------------+
| ORIGINATING | UE đang gọi đi (MO) |
| TERMINATING_REGISTERED | UE đang được gọi, đã đăng ký |
| TERMINATING_UNREGISTERED | UE đang được gọi, chưa đăng ký |
| ORIGINATING_UNREGISTERED | UE chưa đăng ký, có outgoing |
+----------------------------+---------------------------------------------+
c) Request-URI
Request-URI = sip:+84901234567@ims.operator.com
-- hoặc regex pattern
Request-URI contains "+849"
d) SIP Header
Header-Name = P-Asserted-Identity
Header-Value = sip:+84901234567@ims.operator.com
Header-Name = Reason
Header-Value = SIP;cause=486
e) Session Description (SDP)
Line-Type = a
Line-Value = sendrecv
-- dùng để filter theo media type hoặc direction
Ví dụ kết hợp SPT
Trigger Point (AND):
SPT-1: Method = INVITE
SPT-2: SessionCase= TERMINATING_REGISTERED
--> match khi: INVITE đến UE đã đăng ký
Trigger Point (OR):
SPT-1: Method = INVITE
SPT-2: Method = UPDATE
--> match khi: INVITE hoặc UPDATE
Trigger Point phức tạp (AND+OR):
(Method=INVITE AND SessionCase=TERMINATING)
OR
(Method=UPDATE AND Header Reason=cause=480)
[3] Application Server URI
URI của TAS hoặc AS sẽ nhận SIP message khi trigger match:
sip:tas.ims.operator.com -- TAS chính (CF, barring, CLIR)
sip:voicemail.ims.operator.com -- Voicemail AS
sip:presence.ims.operator.com -- Presence AS
sip:rcs.ims.operator.com -- RCS AS
sip:emergency.ims.operator.com -- Emergency AS
sip:conference.ims.operator.com -- Conference AS
S-CSCF sẽ fork SIP message tới URI này qua ISC interface. AS xử lý xong trả về S-CSCF để tiếp tục chain.
[4] Default Handling
Hành động khi AS không phản hồi hoặc trả lỗi:
+------------------------+-----------------------------------------------+
| Giá trị | Hành động |
+------------------------+-----------------------------------------------+
| SESSION_CONTINUED | Bỏ qua AS, tiếp tục route SIP bình thường |
| | Dùng khi AS là optional (CF, CLIR...) |
+------------------------+-----------------------------------------------+
| SESSION_TERMINATED | Hủy cuộc gọi, trả 500 Internal Server Error |
| | Dùng khi AS là mandatory (barring, billing) |
+------------------------+-----------------------------------------------+
Ví dụ đầy đủ 4 iFC rules của một subscriber
Subscriber: sip:alice@ims.operator.com
--- iFC Rule #1 ---
Priority : 1
Trigger Point : Method=INVITE AND SessionCase=TERMINATING_REGISTERED
AS URI : sip:tas.ims.operator.com
Default Handling: SESSION_CONTINUED
Mô tả : Mọi INVITE đến → TAS kiểm tra CF/barring/CLIR
--- iFC Rule #2 ---
Priority : 2
Trigger Point : Method=INVITE AND SessionCase=ORIGINATING
AS URI : sip:tas.ims.operator.com
Default Handling: SESSION_CONTINUED
Mô tả : Mọi INVITE đi → TAS kiểm tra CLIR, BAOC
--- iFC Rule #3 ---
Priority : 3
Trigger Point : Method=INVITE AND SessionCase=TERMINATING_REGISTERED
AND Header Reason=SIP;cause=480
AS URI : sip:voicemail.ims.operator.com
Default Handling: SESSION_CONTINUED
Mô tả : UE không reachable → redirect voicemail
--- iFC Rule #4 ---
Priority : 10
Trigger Point : Method=REGISTER
AS URI : sip:rcs.ims.operator.com
Default Handling: SESSION_CONTINUED
Mô tả : Mỗi lần REGISTER → báo cho RCS AS
2. Interface Cx — S-CSCF ↔ UDM/HSS
Cx là gì?
Cx là interface giữa S-CSCF (hoặc I-CSCF) và UDM/HSS, dùng để tải iFC, quản lý đăng ký IMS, và xác thực.
S-CSCF / I-CSCF UDM / HSS
| |
|------- Cx interface ----------|
| (Diameter in 4G/IMS) |
| (HTTP/2 SBI in 5G pure) |
| |
Trong 4G/IMS truyền thống: Diameter protocol (RFC 6733) Trong 5G SBA: UDM expose HTTP/2 SBI, nhưng nhiều vendor vẫn giữ Cx Diameter hoặc dùng một adapter layer.
Các Cx message quan trọng
a) MAR / MAA — Multimedia Auth Request/Answer
Dùng khi: UE gửi SIP REGISTER — S-CSCF cần xác thực UE.
S-CSCF UDM/HSS
| |
|-- Cx MAR (User-Name=IMPU, |
| SIP-Auth-Data-Item) |
| |
| [UDM tạo auth vector]
| [5G-AKA hoặc AKA] |
| |
|<-- Cx MAA (auth vectors, |
| Result-Code=2001) |
| |
| [S-CSCF gửi 401 challenge về UE]
Cx MAR chứa:
User-Name : IMPU (sip:alice@ims.operator.com)
Public-Identity : IMPU
Private-Identity : IMPI (alice@ims.operator.com)
Server-Name : URI của S-CSCF
SIP-Number-Auth-Items: số lượng auth vector cần
SIP-Auth-Data-Item : algorithm (AKAv1-MD5, AKAv2-SHA256...)
b) SAR / SAA — Server Assignment Request/Answer
Dùng khi: UE REGISTER thành công — S-CSCF cần tải service profile. Đây là lúc iFC được tải xuống.
S-CSCF UDM/HSS
| |
|-- Cx SAR (User-Name=IMPU, |
| Server-Name=S-CSCF, |
| Assignment-Type= |
| REGISTRATION) |
| |
| [UDM lưu binding: |
| IMPU → S-CSCF URI] |
| |
|<-- Cx SAA ( |
| User-Data = |
| Service Profile: |
| iFC #1, iFC #2, ... |
| Charging-Info, |
| Result-Code=2001) |
| |
| [S-CSCF cache toàn bộ iFC |
| cho IMPU này] |
SAR Assignment-Type values:
+-------------------------------+----------------------------------+
| Assignment-Type | Khi nào dùng |
+-------------------------------+----------------------------------+
| REGISTRATION | UE register lần đầu |
| RE_REGISTRATION | UE re-register (refresh) |
| UNREGISTERED_USER | Có MT call cho UE chưa register |
| TIMEOUT_DEREGISTRATION | Registration timer hết hạn |
| USER_DEREGISTRATION | UE gửi REGISTER expires=0 |
| DEREGISTRATION_TOO_MUCH_DATA | Service profile quá lớn |
+-------------------------------+----------------------------------+
c) LIR / LIA — Location Info Request/Answer
Dùng khi: I-CSCF nhận INVITE và cần tìm S-CSCF nào đang phục vụ UE.
I-CSCF UDM/HSS
| |
|-- Cx LIR (Public-Identity= |
| sip:alice@ims.op) |
| |
|<-- Cx LIA ( |
| Server-Name= |
| sip:scscf1.ims.op, |
| Result-Code=2001) |
| |
| [I-CSCF route INVITE |
| tới scscf1.ims.op] |
d) UAR / UAA — User Authorization Request/Answer
Dùng khi: I-CSCF nhận SIP REGISTER và cần biết nên chọn S-CSCF nào.
I-CSCF UDM/HSS
| |
|-- Cx UAR (User-Name, |
| Public-Identity, |
| Visited-Network-ID) |
| |
|<-- Cx UAA ( |
| Server-Name= |
| sip:scscf1.ims.op, |
| Server-Capabilities) |
| |
e) PPR / PPA — Push Profile Request/Answer
Dùng khi: UDM/HSS chủ động push service profile mới về S-CSCF (ví dụ operator thay đổi iFC của subscriber).
UDM/HSS S-CSCF
| |
|-- Cx PPR (User-Data= |
| new service profile |
| with updated iFC) |
| |
|<-- Cx PPA (Result-Code=2001)--|
| |
| [S-CSCF update cache iFC] |
f) RTR / RTA — Registration Termination Request/Answer
Dùng khi: UDM/HSS yêu cầu S-CSCF hủy đăng ký của UE (ví dụ operator deactivate subscriber, hay UE đăng ký trên S-CSCF mới).
UDM/HSS S-CSCF
| |
|-- Cx RTR (User-Name, |
| Deregistration-Reason)
| |
| [S-CSCF gửi SIP NOTIFY |
| hoặc force deregister UE] |
| |
|<-- Cx RTA (Result-Code=2001)--|
Cx trong 5G — UDM thay HSS
4G IMS: 5G IMS:
S-CSCF S-CSCF
| |
| Cx (Diameter) | Cx (Diameter) -- vẫn dùng
| | HOẶC
HSS | Nudm_SDM (HTTP/2 SBI)
| |
UDR UDM
(lưu service profile) |
UDR
(lưu service profile + iFC)
Trong thực tế 5G SA: nhiều vendor implement UDM bao gồm cả HSS function (gọi là UDM+HSS combo), expose cả Cx Diameter lẫn HTTP/2 SBI để phục vụ đồng thời 5GC NFs và IMS NFs.
3. Cách S-CSCF chạy iFC chain
Nguyên tắc chạy chain
S-CSCF nhận SIP message
|
v
Lấy iFC list của IMPU từ cache
(đã load khi REGISTER qua Cx SAA)
|
v
Sắp xếp iFC theo Priority tăng dần
|
v
Với mỗi iFC (theo thứ tự):
|
+-- Trigger Point match? --NO--> bỏ qua, next iFC
|
YES
|
v
Fork SIP message tới AS URI (qua ISC)
|
+-- AS trả lời? --NO (timeout)--> Default Handling
| SESSION_CONTINUED: next iFC
| SESSION_TERMINATED: trả 500, dừng
YES
|
v
AS trả về SIP response:
|
+-- 1xx / 2xx / 3xx --> S-CSCF xử lý theo response
+-- 4xx / 5xx / 6xx --> hủy call (nếu AS quyết định)
+-- AS forward lại request mới --> S-CSCF tiếp tục với request mới
|
v
Còn iFC nào không? --YES--> next iFC
|
NO
v
Hết chain → route SIP bình thường
Chi tiết: AS trả về gì sau khi xử lý?
AS (TAS) có thể trả về S-CSCF theo 3 cách:
Cách 1: Trả 1xx/2xx — tiếp tục route
S-CSCF TAS
| |
|-- INVITE ----->|
| | [TAS kiểm tra: không có CF, không barring]
|<-- 100 Trying--|
| |
| [S-CSCF tiếp tục next iFC hoặc route đi]
Cách 2: Trả 3xx — redirect
S-CSCF TAS
| |
|-- INVITE ----->|
| | [TAS phát hiện CFU → target là sip:+849xxx]
|<-- 302 Moved--|
| Contact: sip:+849xxx@ims.operator.com
| |
| [S-CSCF route INVITE tới target mới]
Cách 3: AS gửi lại request mới (re-originate)
S-CSCF TAS
| |
|-- INVITE ----->|
| | [TAS rewrite R-URI]
| |-- INVITE (R-URI mới) -->
| | (gửi về S-CSCF như origination mới)
| |
| [S-CSCF nhận request mới, chạy lại chain]
Ví dụ chạy chain cho MT INVITE
UE Alice đang đăng ký, có 3 iFC:
iFC#1 (P=1): INVITE+Terminating → TAS (CF/barring)
iFC#2 (P=3): INVITE+Terminating+Reason=480 → Voicemail
iFC#3 (P=10): REGISTER → RCS AS
S-CSCF nhận INVITE tới Alice:
Step 1: iFC#1 match? (INVITE + Terminating) → YES
S-CSCF fork INVITE tới sip:tas.ims.operator.com
TAS kiểm tra: không có CF, không barring → tiếp tục
TAS trả 100 Trying về S-CSCF
Step 2: iFC#2 match? (cần Reason=480, chưa có) → NO
bỏ qua
Step 3: iFC#3 match? (REGISTER, không phải INVITE) → NO
bỏ qua
Step 4: hết chain → S-CSCF route INVITE tới UE Alice bình thường
--- Nếu UE trả 480 ---
S-CSCF nhận 480 từ UE Alice:
Chạy lại iFC chain với context Reason=480:
iFC#1: đã chạy rồi, không chạy lại
iFC#2: INVITE+Terminating+Reason=480 → YES
S-CSCF fork INVITE tới sip:voicemail.ims.operator.com
Voicemail AS nhận, trả 200 OK
iFC#3: REGISTER → NO
→ Cuộc gọi được redirect vào voicemail
Subsequent Request Filter (sFC)
Ngoài iFC cho initial request, còn có sFC cho subsequent request (re-INVITE, BYE):
Initial request → iFC chain chạy
Subsequent request (re-INVITE trong dialog) → sFC chain chạy
sFC ít được dùng hơn, chủ yếu cho:
- Media modification monitoring
- Call hold/resume notification tới billing AS
- Conference state tracking
4. ISC Interface — S-CSCF ↔ TAS
ISC là gì?
ISC (IMS Service Control) là interface giữa S-CSCF và Application Server (TAS). Thực chất ISC là SIP — không có protocol đặc biệt, chỉ có một số convention về header và routing.
S-CSCF TAS (AS)
| |
|------- ISC (SIP) ------------>|
| |
| S-CSCF thêm Route header |
| trỏ tới TAS URI |
| TAS xử lý và trả về |
| |
Cơ chế routing trong ISC
S-CSCF thêm Route header với địa chỉ TAS vào SIP message:
INVITE sip:alice@ims.operator.com SIP/2.0
Via: SIP/2.0/UDP scscf.ims.operator.com
Route: <sip:tas.ims.operator.com;lr> <-- S-CSCF thêm vào
From: sip:bob@ims.operator.com
To: sip:alice@ims.operator.com
Call-ID: abc123@scscf
CSeq: 1 INVITE
P-Served-User: <sip:alice@ims.operator.com>;sescase=term;regstate=reg
Header P-Served-User đặc biệt quan trọng:
P-Served-User: <sip:alice@ims.operator.com>
;sescase=term ← session case: terminating
;regstate=reg ← registration state: registered
TAS dùng P-Served-User để biết:
- Đang xử lý cho subscriber nào
- Session case là originating hay terminating
- UE có đang registered không
Sau khi TAS xử lý — trả về S-CSCF
TAS gửi lại request về S-CSCF với Route header đã bỏ TAS URI:
TAS gửi lại:
INVITE sip:alice@ims.operator.com SIP/2.0
Via: SIP/2.0/UDP tas.ims.operator.com
Via: SIP/2.0/UDP scscf.ims.operator.com
Route: <sip:scscf.ims.operator.com;lr> <-- route về S-CSCF
From: sip:bob@ims.operator.com
To: sip:alice@ims.operator.com
...
S-CSCF nhận lại, tiếp tục iFC chain.
ISC với nhiều AS trong chain
S-CSCF TAS-1 (CF/barring) TAS-2 (voicemail)
| | |
|-- INVITE ----->| |
| Route: TAS-1 | |
| | |
| | [kiểm tra CF: không]
| |-- INVITE ---------->
| | Route: S-CSCF |
| | (TAS-1 xong việc) |
|<-- INVITE -----| |
| | |
| [S-CSCF: iFC#1 xong, next iFC#2? |
| iFC#2 = Reason=480, chưa có] |
| → route INVITE tới Alice bình thường
5. TAS xử lý các dịch vụ
5.1 Call Forwarding (CF)
TAS nhận iFC trigger, hỏi UDM lấy CF config:
TAS UDM
| |
|-- Nudm_SDM_Get (SUPI, |
| dataset=SMF-Selection-Data) |
| HOẶC |
| Cx SAR-like query |
| |
|<-- CF config: |
| CFU=off |
| CFB=on, target=+849xxx |
| CFNR=on, target=+849xxx, |
| timer=15s |
| CFNRc=on, target=+849xxx |
TAS decision tree:
Nhận INVITE (Terminating):
|
+-- CFU active? --YES--> rewrite R-URI → fwd target
| return new INVITE về S-CSCF
NO
|
+-- attempt MT (page UE qua AMF)
|
+-- UE trả 486 Busy? --YES (CFB active)--> rewrite R-URI → fwd target
|
+-- Timer 15s hết (CFNR)? --YES--> rewrite R-URI → fwd target
|
+-- 480 Not Reachable (CFNRc)? --YES--> rewrite R-URI → fwd target
|
NO, UE trả lời bình thường --> 200 OK, call setup
Rewrite R-URI trong SIP:
INVITE trước khi TAS xử lý:
INVITE sip:alice@ims.operator.com
INVITE sau khi TAS rewrite (CFU):
INVITE sip:+84901111111@ims.operator.com
History-Info: <sip:alice@ims.operator.com>;index=1
Diversion: <sip:alice@ims.operator.com>
-- History-Info và Diversion cho biết đã có forwarding
5.2 Call Barring
Các loại barring TAS kiểm tra:
+------------------+------------------------------+------------------+
| Loại | Check khi nào | Action nếu match |
+------------------+------------------------------+------------------+
| BAOC | iFC Originating + INVITE | 403 Forbidden |
| BOIC | iFC Orig + INVITE | 403 Forbidden |
| | + Request-URI là intl number | |
| BAIC | iFC Terminating + INVITE | 603 Decline |
| BIC-Roam | iFC Terminating + INVITE | 603 Decline |
| | + P-Access-Network-Info=roam | |
| ODB-HPLMN-AO | iFC Originating + INVITE | 403 Forbidden |
| | (operator set, not subscriber)| |
+------------------+------------------------------+------------------+
Luồng BAOC (Bar All Outgoing):
UE-Alice S-CSCF TAS UDM
| | | |
|== INVITE ====>| | |
| |-- ISC: iFC#2 (Originating) -->|
| | | |
| | |-- Nudm: get barring config
| | |<-- BAOC=on
| | | |
| | | [BAOC active → reject]
| |<-- 403 Forbidden (ISC) --------|
|<== 403 Forbidden =========== | |
| "Call barred" | |
5.3 CLIP / CLIR
CLIR — Caller hides their number:
UE-Bob (CLIR=on) S-CSCF TAS UE-Alice
| | | |
|== INVITE ====>| | |
| From: Bob | | |
| P-Asserted- | | |
| Identity:Bob | | |
| |-- ISC iFC (Originating) ------>|
| | | |
| | | [CLIR=on → add Privacy header]
| | | |
| |<-- INVITE (modified) ----------|
| | Privacy: id | |
| | (P-Asserted-Identity removed |
| | or anonymized) |
| | | |
| |================================>|
| | INVITE arrives Alice: |
| | From: "Anonymous" <sip:anonymous@anonymous.invalid>
5.4 Call Hold / Resume
Hold — UE-A giữ máy:
UE-A S-CSCF TAS UE-B
| | | |
| [UE-A bấm Hold] | |
|== re-INVITE =>| | |
| SDP: | | |
| a=sendonly | | |
| | [sFC trigger nếu có, |
| | hoặc TAS monitor từ dialog] |
| | | |
| |== re-INVITE ==> |
| | a=sendonly | |
| | |== re-INVITE ==>
| | | a=sendonly |
| | |<== 200 OK ====|
| |<== 200 OK ====| |
|<== 200 OK ====| | |
| | | |
| [RTP từ UE-A dừng] | |
| [TAS có thể bật MOH — Music On Hold] |
| | |== RTP MOH ===>|
MOH (Music on Hold) — TAS inject audio:
TAS UE-B (on hold)
| |
| [TAS có media server tích hợp]|
| hoặc redirect tới MRFP |
| |
|== RTP (MOH audio stream) ====>|
| codec: AMR-WB |
| nội dung: nhạc chờ máy |
5.5 Conference (3-way call)
TAS dùng REFER để kéo thêm người:
UE-A TAS (conf) UE-B UE-C
| | | |
| [Call A-B đang active] | |
| | | |
|== REFER =====>| | |
| Refer-To: | | |
| sip:UE-C | | |
| | | |
|<== 202 Accepted == | |
| | | |
| |== INVITE =====================>|
| |<== 200 OK ====================|
| |== ACK ========================>|
| | | |
| [TAS mix 3 RTP streams] | |
| | | |
|<== NOTIFY ====| | |
| (REFER result: success) | |
| | | |
| [UE-A, UE-B, UE-C đều nghe thấy nhau]
| | | |
|<== RTP (mixed audio) =========| |
| | | |
Kiến trúc media của conference:
UE-A ====RTP====> | |
| MRFP |====RTP====> UE-A (mixed A+B+C)
UE-B ====RTP====> | (mixer) |====RTP====> UE-B (mixed A+C)
| |====RTP====> UE-C (mixed A+B)
UE-C ====RTP====> | |
MRFP = Media Resource Function Processor
= decode tất cả streams → mix PCM → encode lại → gửi cho mỗi UE
= mỗi UE nhận audio của những người còn lại (không nghe tiếng mình)
Tóm tắt toàn bộ
+-------------------+------------------------------------------------+
| Thành phần | Vai trò |
+-------------------+------------------------------------------------+
| iFC Priority | Thứ tự chạy — nhỏ hơn = trước |
| iFC SPT | Điều kiện lọc: Method, SessionCase, |
| | Request-URI, SIP Header, SDP |
| iFC AS URI | Địa chỉ TAS/AS nhận SIP khi trigger match |
| iFC Default Handle| SESSION_CONTINUED / SESSION_TERMINATED |
| | khi AS không trả lời |
+-------------------+------------------------------------------------+
| Cx MAR/MAA | Xác thực UE khi REGISTER |
| Cx SAR/SAA | Tải iFC (service profile) về S-CSCF |
| Cx LIR/LIA | I-CSCF tìm S-CSCF của UE |
| Cx UAR/UAA | I-CSCF chọn S-CSCF cho REGISTER |
| Cx PPR/PPA | UDM push iFC mới về S-CSCF |
| Cx RTR/RTA | UDM yêu cầu S-CSCF hủy đăng ký UE |
+-------------------+------------------------------------------------+
| iFC chain | S-CSCF duyệt iFC theo Priority, |
| | fork INVITE tới từng AS qua ISC |
| ISC | SIP interface S-CSCF ↔ TAS |
| | dùng Route header + P-Served-User |
+-------------------+------------------------------------------------+
| TAS: CF | Rewrite R-URI, 3 loại: CFU/CFB/CFNR |
| TAS: Barring | Trả 403/603 nếu subscriber bị barring |
| TAS: CLIR | Thêm Privacy:id, ẩn P-Asserted-Identity |
| TAS: Hold | Xử lý re-INVITE a=sendonly, inject MOH |
| TAS: Conference | REFER handling, kéo MRFP mixer vào |
+-------------------+------------------------------------------------+