RTP & Signaling Flow trong 2G / 4G / IMS

1. RTP âm thanh 2G có qua GMSC không?

2G thoại (CS voice) mặc định không dùng RTP — dùng TDM/PCM (64kbps) hoặc voice nén qua TRAU. RTP chỉ xuất hiện nếu A-interface/Nb-interface chạy trên IP (NGN).

1.1. Kiến trúc GSM cổ điển (TDM thuần, pre-NGN)

MS ── Um ── BTS ── Abis ── BSC ── A ── MSC ── (nếu cần) ── GMSC ── ISUP/TDM ── PSTN/PLMN khác

• MSC là tổng đài circuit-switch thật, thoại đi qua dưới dạng TDM timeslot.
• GMSC chỉ được chèn vào khi cuộc gọi cần đi ra ngoài PLMN (gọi PSTN/mạng khác, hoặc cuộc gọi vào cần tra HLR để định tuyến — GMSC dùng MAP SendRoutingInfo).
• Nếu GMSC nằm trên đường đi, cả báo hiệu (ISUP) lẫn kênh thoại (bearer TDM) đều đi qua switch matrix của GMSC.
• Cuộc gọi intra-PLMN (cùng MSC/VLR) → không cần qua GMSC.

1.2. Kiến trúc NGN / Bearer-Independent CS Core (3GPP TS 23.205)

BSC ── A-over-IP (RTP) ── MGW ◄── H.248/Mc ── MSC-Server / GMSC-Server ── (BICC/SIP-I signaling)

• MSC/GMSC tách thành Server (chỉ signaling) + MGW (chỉ media/bearer).
• GMSC-Server chỉ xử lý báo hiệu (BICC/SIP-I), điều khiển MGW qua H.248.
• RTP không nhất thiết đi qua GMSC-Server — đi qua MGW, node vật lý riêng.
• Kỹ thuật Optimal Media Routing / TrFO (Transcoder-Free Operation): hai MGW hai đầu bắt tay trực tiếp, tránh trombone qua MGW gắn GMSC → RTP có thể không đi qua node GMSC luôn.

1.3. Tóm lại

2. RTP trong 4G/VoLTE đi qua đâu?

Toàn bộ IP transport, RTP được đóng gói trong GTP-U tunnel xuyên suốt EPC.

UE ── Uu (RoHC-compressed RTP/UDP/IP trên PDCP) ── eNodeB
                                                        │
                                                    S1-U (GTP-U tunnel)
                                                        │
                                                       SGW
                                                        │
                                                    S5/S8 (GTP-U tunnel)
                                                        │
                                                       PGW
                                                        │
                                                       SGi
                                                        │
                                            P-CSCF (IMS-ALG/IMS-AGW) ── media anchor
                                                        │
                                    (nếu liên mạng) IBCF/TrGW ── mạng đối phương

Điểm quan trọng:

1. SGW/PGW không “hiểu” RTP — chỉ router cho GTP-U tunnel dựa trên TEID, forward nguyên payload IP/UDP/RTP. RTP chỉ “nhìn thấy” ở hai đầu tunnel (eNodeB, PGW).
2. Dedicated bearer QCI=1 (GBR) dành riêng cho thoại, tách biệt với default bearer (QCI=5, dùng cho SIP signaling). Được trigger qua PCRF (Rx từ P-CSCF → Gx xuống PGW).
3. Sau SGi, vào domain IMS: IMS-AGW (điều khiển bởi P-CSCF qua Iq) làm nhiệm vụ anchor media, NAT traversal, đôi khi transcoding — đây là điểm để hook LI content-of-communication hoặc phân tích RTP thật (SGW/PGW chỉ có GTP-U-encapsulated RTP, cần decap TEID trước).
4. Phân biệt: GTP-U tunnel correlation (SGW↔PGW, dựa PAA/IP + F-TEID) khác với RTP stream correlation trong IMS (dựa SDP c=/m= line trong SIP INVITE/200 OK).

3. LI chèn qua iFC — luồng hoạt động

3.1. Mô hình A — LI chuẩn 3GPP (TS 33.107 §7.3, không cần đụng iFC)

P-CSCF/S-CSCF có sẵn Internal Interception Function (IIF)
        │
        ├── IRI (SIP signaling copy) ──► DF2 (X2) ──► LEA
        └── CC  (RTP content copy)   ──► DF3 (X3) ──► LEA

ADMF kích hoạt target (IMSI/IMPU/IMPI) trực tiếp trên CSCF qua X1, không cần sửa profile thuê bao ở HSS.

3.2. Mô hình B — chèn qua iFC (Application Server insertion)

HSS (Sh) ──provision iFC cho IMPU target──► S-CSCF (Cx: User-Profile download)
                                                    │
                                        SIP request khớp SPT (Service Point Trigger)
                                                    │
                                              ISC interface
                                                    │
                                          LI-AS (đóng vai B2BUA/SIP AS)
                                              │              │
                                    Copy IRI (SIP msg)   Anchor media (SDP rewrite
                                    → Mediation → DF2         c=/m= line trỏ về mình)
                                                                    │
                                                              RTP thật đi qua LI-AS
                                                              → tap CC → DF3

Các bước:

1. HSS provision iFC cho subscriber bị target — chèn Initial Filter Criteria mới vào iFC list, với Service Point Trigger đủ rộng (match tất cả INVITE gốc/đến, hoặc theo Session Case originating/terminating).
2. S-CSCF download lại profile khi thuê bao REGISTER (hoặc bị Sh-Push force refresh) — nhận iFC mới qua Cx (Server-Assignment-Answer).
3. SIP request khớp trigger → S-CSCF forward qua ISC tới AS chỉ định trong iFC.
4. AS xử lý:
   • Chỉ IRI: AS đóng vai SIP proxy trong suốt, tap bản copy signaling → DF2.
   • Cần CC: AS phải là B2BUA thật, sửa SDP để thay c=/m= bằng địa chỉ của chính nó.
5. Rủi ro/lưu ý:
   • Tăng độ trễ, thêm 1 hop RTP → có thể phát hiện qua đo RTT/jitter.
   • iFC priority phải đặt đúng chỗ trong chain.
   • Sh-Push force refresh cần HSS hỗ trợ push notification.
   • Đây là kỹ thuật operator-specific, không phải cách 3GPP khuyến nghị chính thức (33.107 khuyến nghị tap tại CSCF, không đụng subscriber profile) — sửa iFC để lại dấu vết trong HSS provisioning log.

3.3. Luồng RTP khi AS đã anchor SDP

Trước khi có AS (bình thường):

UE-A ── RTP ──► IMS-AGW (P-CSCF anchor A) ── RTP ──► IMS-AGW (P-CSCF anchor B) ── RTP ──► UE-B

Sau khi LI-AS chèn qua iFC và rewrite SDP (2 chiều):

IMS-AGW(A) ──RTP──► LI-AS (B2BUA) ◄──RTP── IMS-AGW(B)
                        │
                        ├─► relay RTP tiếp sang phía kia (giữ call sống)
                        └─► fork 1 bản copy → Mediation Function → DF3 (X3) → LEA

Cơ chế:

1. SDP offer (INVITE của A) qua LI-AS → thay c=/m= bằng địa chỉ RTP của chính AS trước khi forward.
2. SDP answer (200 OK của B) qua AS → thay c=/m= của B bằng địa chỉ AS (cổng khác) trước khi trả về A.
3. Kết quả: cả A và B đều gửi RTP tới AS — AS trở thành RTP relay/mixer bắt buộc giữa hai IMS-AGW.
4. AS relay RTP giữa hai bên, đồng thời fork từng gói gửi song song sang Mediation Function → đóng gói HI3 (ETSI TS 102 232-3) → LEA.
5. RTCP cũng phải được anchor tương tự (port RTP+1).

Lưu ý kỹ thuật:

• Passthrough vs transcode: passthrough → latency nhỏ (~1-3ms), khó phát hiện. Transcode → delay tăng đáng kể, có thể lộ qua MOS/jitter.
• Timing correlation HI2/HI3: IRI và CC phải gắn cùng CommunicationIdentifier để ghép đúng transcript.
• Double anchoring: RTP đi qua 2 lớp anchor (IMS-AGW rồi LI-AS) → thêm 1 hop nữa so với mô tả đơn giản, dễ lộ qua đo RTT.

4. Danh sách node chính xác mà RTP đi qua (có LI-AS chèn qua iFC)

1. UE-A
      │ (Uu, RTP nén qua RoHC trên PDCP)
2. eNodeB (A)
      │ (S1-U, GTP-U tunnel)
3. SGW (A)
      │ (S5/S8, GTP-U tunnel)
4. PGW (A)
      │ (SGi, RTP/UDP/IP thô — hết GTP-U)
5. IMS-AGW (A)  ← điều khiển bởi P-CSCF (A) qua Iq/H.248, media anchor lớp 1
      │ (RTP/UDP/IP, transport network domain — Gm/Mw core)
6. LI-AS (B2BUA)  ← media anchor lớp 2, S-CSCF route tới qua ISC (matched iFC)
      │ ├─ relay RTP tiếp
      │ └─ fork copy → Mediation Function → DF3 → LEA
7. IMS-AGW (B)  ← điều khiển bởi P-CSCF (B)
      │ (SGi, RTP/UDP/IP thô)
8. PGW (B)
      │ (S5/S8, GTP-U tunnel)
9. SGW (B)
      │ (S1-U, GTP-U tunnel)
10. eNodeB (B)
      │ (Uu)
11. UE-B

Lưu ý:

• Node 5 và 7 (IMS-AGW) luôn có mặt trong VoLTE bình thường — không liên quan LI.
• Nếu A/B cùng P-CSCF/AGW cluster, node 5 và 7 có thể gộp thành 1 AGW vật lý (tùy vendor: Ericsson, Huawei, Nokia).
• S-CSCF không nằm trên đường RTP — chỉ route SIP signaling.
• MRF/MRFP chỉ xuất hiện khi conference call/announcement.
• Liên mạng (interconnect) → thêm IBCF/TrGW ở biên, thêm 1 lớp anchor nữa.

Dấu hiệu phát hiện LI-AS chèn bất thường: IP đích RTP trong SDP answer không khớp IP media thật của UE-B (không thuộc dải IP AGW/PGW quen thuộc của B, trỏ về subnet lạ).

5. Tại sao I-CSCF không nằm trên đường RTP

S-CSCF quan trọng trên đường signaling (SIP) nhưng không trên đường bearer (RTP) — control plane/user plane tách biệt hoàn toàn.

Đường SIP signaling (S-CSCF bắt buộc):

UE-A → P-CSCF(A) → S-CSCF(A)... [Mw/Mm/ISC]
                       │
    (nếu match iFC) → route qua ISC tới LI-AS
                       │
                       └──► ...S-CSCF(B, nếu khác) → P-CSCF(B) → UE-B

S-CSCF xử lý INVITE, 200 OK, ACK, BYE, download iFC từ HSS qua Cx, quyết định route request — thuần bản tin SIP dạng text, không đụng gói RTP.

Đường RTP media (S-CSCF vắng mặt):

S-CSCF chỉ đọc/forward SDP body (payload text trong bản tin SIP), không phải điểm RTP packet chạy qua. Địa chỉ IP:port trong c=/m= trỏ tới AGW hoặc AS, không trỏ tới S-CSCF (S-CSCF không có socket RTP).

Node thật sự mở port RTP: IMS-AGW (điều khiển bởi P-CSCF qua Iq/H.248), LI-AS (nếu chèn, đóng vai B2BUA), MRFP (nếu conference/announcement).

6. Tại sao phải chia P-CSCF / I-CSCF / S-CSCF

Nguyên tắc thiết kế: separation of concerns — mỗi CSCF giải quyết một vấn đề kiến trúc riêng.

6.1. P-CSCF — điểm truy nhập cố định, gắn với vị trí UE

Giải quyết vấn đề UE roaming, di chuyển qua nhiều access network:

• Xác thực đăng ký (Security Association qua IPsec/TLS).
• Nén/giải nén SIP (SigComp).
• Policy control (Rx tới PCRF) — biết chính xác UE ở access network nào.
• Điều khiển IMS-AGW để anchor media, topology hiding, NAT traversal.

Nếu không tách riêng: mỗi lần roaming phải đổi cả S-CSCF → phá vỡ mô hình home routing.

6.2. S-CSCF — bộ não dịch vụ, gắn với subscriber, luôn ở home network

Giải quyết vấn đề:

• Giữ session state + subscriber profile (từ HSS qua Cx) — quyết định service logic (iFC nào trigger AS nào).
• Luôn ở home network dù UE roaming → operator giữ toàn quyền kiểm soát dịch vụ/billing.

Nếu gộp P-CSCF + S-CSCF: mỗi access point phải tải toàn bộ profile mọi thuê bao roaming tới → không scale.

6.3. I-CSCF — cổng vào ẩn danh, bảo vệ topology nội bộ

Giải quyết vấn đề:

• INVITE từ mạng ngoài không được biết S-CSCF cụ thể nào đang phục vụ thuê bao (topology hiding, THIG).
• Nhận request tại biên, hỏi HSS (Cx: LIR/LIA), route nội bộ tới đúng S-CSCF.
• Load-balancing/S-CSCF assignment lúc REGISTER lần đầu.

Nếu không có I-CSCF: mạng ngoài phải biết chính xác S-CSCF nào phục vụ từng thuê bao → lộ topology nội bộ.

6.4. Bảng tóm tắt

7. Thứ tự signaling qua các CSCF

Không phải I → P → S. Đúng là P → I → S (và các biến thể theo tình huống).

UE khám phá P-CSCF ngay từ lúc thiết lập PDN connectivity (P-CSCF discovery qua DHCP option hoặc PCO, TS 24.229 Annex B) — trước khi biết bất kỳ thứ gì khác. UE không biết I-CSCF/S-CSCF, chỉ có địa chỉ P-CSCF.

7.1. REGISTER lần đầu

UE → P-CSCF → I-CSCF → [Cx: UAR/UAA hỏi HSS chọn S-CSCF] → S-CSCF
                                                                │
                                            [Cx: SAR/SAA — Server-Assignment,
                                             S-CSCF tải profile + iFC]
                                                                │
        UE ◄── P-CSCF ◄── I-CSCF ◄──────────────────────────── (200 OK)

• P-CSCF nhận REGISTER từ UE, forward tới I-CSCF (chưa biết S-CSCF nào serve).
• I-CSCF hỏi HSS (UAR/UAA) → HSS trả về S-CSCF được chọn (hoặc capability để I-CSCF tự chọn).
• I-CSCF forward REGISTER tới đúng S-CSCF.
• Từ 200 OK trở đi, P-CSCF lưu địa chỉ S-CSCF (qua Service-Route header) → các INVITE originating sau này không cần qua I-CSCF nữa.

7.2. INVITE originating (UE-A tự gọi, đã REGISTER)

UE-A → P-CSCF(A) → S-CSCF(A)   ← I-CSCF KHÔNG tham gia

7.3. INVITE terminating (cuộc gọi đến cho UE-B)

[mạng ngoài / S-CSCF(A)] → I-CSCF(B)  [Cx: LIR/LIA hỏi HSS S-CSCF nào đang serve UE-B]
                                │
                                └──► S-CSCF(B) → P-CSCF(B) → UE-B

I-CSCF là entry point đầu tiên của mạng B (bên gọi tới không biết P-CSCF/S-CSCF nào của B).

7.4. Bảng tóm tắt thứ tự

I-CSCF không bao giờ đứng trước P-CSCF trên đường từ UE — vì UE vốn không biết địa chỉ I-CSCF.

8. Giải thích các cụm từ viết tắt

8.1. Node mạng / thực thể

8.2. Giao diện / Interface

8.3. Giao thức / Bản tin

8.4. LI / Lawful Interception

8.5. Khác