CẨM NANG TOÀN DIỆN VỀ GIAO THỨC SIP VÀ SDP TRONG MẠNG LÕI IMS (VoLTE/VoNR)

Tài liệu này tổng hợp toàn bộ kiến thức chuyên sâu, cấu trúc bản tin mẫu chi tiết và cơ chế định tuyến thực tế của giao thức SIP (Session Initiation Protocol) kết hợp SDP (Session Description Protocol) trong môi trường mạng viễn thông thế hệ mới (IMS - IP Multimedia Subsystem).

PHẦN 1: TỔNG QUAN VỀ SIP INVITE VÀ PAYLOAD SDP

Mô hình thiết lập cuộc gọi thoại/video IP hoạt động dựa trên sự phối hợp chặt chẽ giữa hai giao thức độc lập nhưng lồng ghép vào nhau: SIP (Lớp Báo hiệu) đóng vai trò như vỏ phong bì, và SDP (Lớp Truyền thông) đóng vai trò như bức thư chứa nội dung thỏa thuận bên trong.

1. Bản chất sự phối hợp cấu trúc

• SIP INVITE (Signaling): Định hướng hành chính cho cuộc gọi. Nó xác định ai đang gọi (From), gọi cho ai (To), đi qua các bưu cục tổng đài nào (Via, Route), mã định danh định danh phiên (Call-ID, CSeq) và khai báo loại nội dung đi kèm thông qua Header Content-Type: application/sdp.
• SDP Payload (Media Offer): Nằm hoàn toàn trong phần thân (Body) của bản tin SIP INVITE. SDP chịu trách nhiệm đàm phán các tham số kỹ thuật truyền thông bao gồm: địa chỉ IP nhận luồng RTP, số cổng cổng UDP (Port), các loại thuật toán mã hóa âm thanh/hình ảnh (Codecs) hỗ trợ và băng thông yêu cầu.

2. Mô hình đàm phán Offer/Answer (RFC 3264)

Quá trình thống nhất các thông số truyền thông giữa hai thiết bị đầu cuối bắt buộc phải tuân theo nguyên tắc: Bên chủ gọi đưa ra lời đề nghị (Offer) và Bên bị gọi phản hồi lại bằng một lựa chọn duy nhất được chấp nhận (Answer). Có hai hình thức triển khai phổ biến:

• Early Offer (Cơ chế Phổ thông / Mặc định mạng IMS):
  1. Máy A gửi INVITE có chứa SDP Offer (Liệt kê tất cả codec máy A có).
  2. Máy B nhận tin, chọn ra 1 codec chung duy nhất và gửi lại SDP Answer nằm trong gói 183 Session Progress hoặc 200 OK.
  3. Máy A xác nhận bằng gói ACK (Không cần chứa SDP nữa).
• Delayed Offer (Cơ chế Đề nghị Muộn):
  1. Máy A gửi INVITE không có SDP (Thân bản tin rỗng, Content-Length: 0).
  2. Máy B đổ chuông hoặc nhấc máy, gửi gói 200 OK chứa SDP Offer (Liệt kê các codec máy B hỗ trợ).
  3. Máy A chọn codec phù hợp nhất từ danh sách của B, đóng gói thành SDP Answer gửi đi trong bản tin ACK.

PHẦN 2: PHÂN TÍCH CHUYÊN SÂU DÒNG THUỘC TÍNH a= TRONG SDP

Dòng thuộc tính a= (Attributes) là trường thông tin có số lượng xuất hiện nhiều nhất trong phần thân SDP. Nó đóng vai trò mở rộng và định nghĩa chi tiết cho dòng mô tả phương tiện m= (Media). Nếu không có dòng a=, thiết bị nhận sẽ không thể hiểu được các con số định danh codec trong dòng m= tương ứng với công nghệ mã hóa nào.

1. Định nghĩa và Bản đồ hóa Codec (rtpmap)

Dòng m=audio 49170 RTP/AVP 0 8 101 sử dụng các số tĩnh hoặc số động (Payload Type) để khai báo thứ tự ưu tiên. Dòng a=rtpmap sẽ ánh xạ các con số này ra tên kỹ thuật cụ thể:

• a=rtpmap:0 PCMU/8000: Định nghĩa Payload số 0 là codec G.711 tỷ lệ mẫu 8kHz, băng thông cố định 64 Kbps (phổ biến ở Bắc Mỹ).
• a=rtpmap:8 PCMA/8000: Định nghĩa Payload số 8 là codec G.711 A-law tỷ lệ mẫu 8kHz (phổ biến ở Châu Âu và Việt Nam).
• a=rtpmap:102 AMR-WB/16000/1: Định nghĩa Payload số 102 là codec thoại độ phân giải cao HD Voice (Adaptive Multi-Rate Wideband), tần số lấy mẫu 16kHz, truyền chế độ đơn luồng (Mono). Đây là codec tiêu chuẩn bắt buộc cho cuộc gọi VoLTE chất lượng cao.
• a=rtpmap:101 telephone-event/8000: Định nghĩa Payload số 101 dùng cho việc truyền tín hiệu phím bấm DTMF (bấm số 1, 2, 3 khi gọi tổng đài trả lời tự động) theo tiêu chuẩn RFC 4733 thay vì truyền âm thanh trực tiếp nhằm tránh méo tiếng.

2. Định hướng luồng truyền thông (Direction Attributes)

Thuộc tính hướng quyết định trạng thái thu phát dữ liệu của cổng UDP được khai báo ở dòng m=:

• a=sendrecv: Chế độ mặc định của cuộc gọi bình thường. Thiết bị sẵn sàng vừa truyền gói tin RTP đi (Send) vừa nhận gói tin RTP từ đối phương về (Receive).
• a=sendonly: Thiết bị thông báo chỉ gửi dữ liệu ra ngoài, không tiếp nhận dữ liệu đổ về cổng UDP này. Trường hợp này dùng khi hệ thống phát nhạc chờ (Music on Hold) hoặc một thành viên trong phòng hội nghị chỉ muốn nói mà không nghe.
• a=recvonly: Thiết bị thông báo chỉ nghe/nhận dữ liệu từ đối phương, không phát bất kỳ gói tin RTP nào đi. Trạng thái này tự động kích hoạt khi người dùng bấm nút Mute (Tắt micro của mình nhưng vẫn nghe đầu dây bên kia nói).
• a=inactive: Tạm dừng truyền thông cả hai chiều. Luồng RTP bị ngắt hoàn toàn tạm thời nhưng phiên báo hiệu SIP vẫn được giữ nguyên. Thường dùng khi chuyển mạch cuộc gọi hoặc xử lý trung gian.

3. Cấu hình tham số mở rộng (fmtp)

Trường a=fmtp (Format Parameters) cung cấp các thông số tinh chỉnh bổ sung cho một codec cụ thể:

• a=fmtp:101 0-16: Cấu hình riêng cho Payload 101 (telephone-event), thông báo thiết bị hỗ trợ nhận diện đầy đủ các sự kiện phím bấm từ số 0-9, phím *, # và các phím hệ thống A-D.
• a=fmtp:102 mode-set=0,1,2; mode-change-capability=2: Cấu hình riêng cho Codec thoại AMR-WB, giới hạn băng thông chỉ hoạt động trên các mức cấu hình (Mode) quy định nhằm tối ưu hóa tài nguyên tài nguyên vô tuyến của trạm phát sóng di động.

4. Thiết lập khóa bảo mật mã hóa (crypto)

Trong các cuộc gọi yêu cầu bảo mật cao sử dụng giao thức truyền thông an toàn SRTP (Secure RTP), dòng a= gánh vác trách nhiệm trao đổi thông tin mật mã:

• a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:WjFhZ...: Khai báo thuật toán mã hóa AES chuỗi 128-bit kết hợp hàm băm xác thực SHA1, đi kèm chuỗi khóa (Master Key) được mã hóa Base64 truyền trực tiếp dưới dạng tường minh (inline). Đầu nhận sẽ dùng khóa này để giải mã luồng âm thanh RTP tương ứng.

PHẦN 3: CƠ CHẾ THƯƠNG LƯỢNG TRÙNG NHAU (OFFER / ANSWER NEGOTIATION)

Khi hai thiết bị đầu cuối có năng lực phần cứng và phần mềm khác nhau thực hiện kết nối, hệ thống phải trải qua quy trình đàm phán tự động để tìm ra tiếng nói chung lớn nhất.

1. Thuật toán duyệt danh sách Codec thoại

Quá trình thương lượng diễn ra hoàn toàn dựa trên sự tôn trọng thứ tự ưu tiên của Bên chủ gọi (Caller / Máy A):

1. Máy A phát hành Offer: Khai báo dòng m=audio 49170 RTP/AVP 102 8 0 nghĩa là Máy A thích dùng AMR-WB (102) nhất, nếu không được thì dùng PCMA (8), bần cùng lắm mới dùng PCMU (0).
2. Máy B xử lý Offer: Tổng đài hoặc Máy B nhận được danh sách, sẽ tiến hành quét từ trái qua phải theo đúng thứ tự của A.
3. Đối chiếu năng lực: Máy B so sánh mã số với danh sách codec mà phần cứng chip của nó hỗ trợ. Giả sử máy B chỉ hỗ trợ PCMA (8) và G.729 (18).
   • Kiểm tra mã 102 (AMR-WB) ➔ Máy B không có ➔ Loại bỏ.
   • Kiểm tra mã 8 (PCMA) ➔ Máy B có hỗ trợ ➔ Khớp thành công (Match).
4. Máy B phát hành Answer: Máy B khóa mục tiêu vào PCMA. Trong gói phản hồi 200 OK, nó chỉ giữ lại duy nhất mã 8 tại dòng m=audio 5004 RTP/AVP 8 và loại bỏ toàn bộ các dòng a=rtpmap không liên quan đến PCMA ra khỏi cơ thể SDP bản tin trả về.

2. Xử lý kịch bản xung đột hoàn toàn (Codec Mismatch Error)

Nếu Máy A gửi danh sách chỉ gồm các codec HD chất lượng cao (AMR-WB, EVS) nhưng Máy B là một thiết bị IP Phone đời cũ chỉ hỗ trợ codec băng hẹp chuẩn PSTN (G.711, G.723):

• Máy B duyệt từ đầu đến cuối danh sách của A nhưng kết quả trùng khớp bằng rỗng.
• Máy B lập tức từ chối thiết lập cuộc gọi bằng cách gửi ngược lại một bản tin phản hồi lỗi hệ thống: SIP/2.0 488 Not Acceptable Here.
• Cuộc gọi kết thúc ngay lập tức tại tầng báo hiệu, không có bất kỳ kênh âm thanh nào được mở ra, điện thoại người gọi sẽ báo âm bận (Busy Tone) kèm thông điệp ngắt kết nối.

PHẦN 4: KỊCH BẢN THAY ĐỔI THUỘC TÍNH GIỮA CUỘC GỌI (RE-INVITE)

Một cuộc gọi SIP không cố định thông số từ đầu đến cuối. Khi người dùng tương tác với màn hình điện thoại, hệ thống sẽ thực hiện đàm phán lại bằng cách gửi gói Re-INVITE (Bản tin INVITE gửi bên trong một phiên Dialog đang hoạt động) hoặc gói UPDATE (RFC 3311).

1. Kịch bản Người dùng bấm nút “Hold” (Giữ cuộc gọi / Nhạc chờ)

Khi Thuê bao A đang nói chuyện và có việc bận cần bấm nút “Hold” để giữ máy:

  Thuê bao A (Chủ Hold)                    Mạng Core IMS / Thuê bao B
        |                                              |
        |--- Re-INVITE (SDP: a=sendonly) ------------->|
        |    (A báo: Tôi chỉ phát nhạc chờ)            |
        |                                              |
        |<-- 200 OK (SDP: a=recvonly) -----------------|
        |    (B trả lời: Tôi đồng ý chỉ nhận âm thanh)  |
        |                                              |
        |--- ACK (Xác nhận thông luồng) -------------->|
        |                                              |
        |========== LUỒNG RTP: A phát nhạc chờ sang B =======>|

• Trạng thái Unhold: Khi A giải quyết xong việc và bấm “Unhold”, máy A sẽ phát tiếp một gói Re-INVITE thứ hai, đưa thuộc tính quay trở lại trạng thái ban đầu: a=sendrecv. Máy B phản hồi 200 OK với a=sendrecv. Luồng thoại hai chiều của người dùng được khôi phục hoàn toàn.

2. Kịch bản Nâng cấp Cuộc gọi thoại lên Cuộc gọi Video

Khi hai bên đang đàm thoại bằng giọng nói, Thuê bao A muốn bấm nút “Bật Camera” để nhìn thấy hình ảnh đối phương:

• Hành động của máy A: Phát một gói Re-INVITE chứa cấu hình SDP được mở rộng thêm một khối Phương tiện hoàn toàn mới (khối m=video).

  m=audio 49170 RTP/AVP 102
  a=rtpmap:102 AMR-WB/16000/1
  m=video 49172 RTP/AVP 96
  a=rtpmap:96 H264/90000
  a=sendrecv
  

• Phản hồi từ phía máy B:
  • Trường hợp B đồng ý xem video: Máy B bật camera của mình lên, gửi lại gói 200 OK chứa đầy đủ thông số cho cả m=audio (Cổng nhận tiếng) và m=video (Cổng nhận hình kèm codec H264). Cuộc gọi chính thức nâng cấp thành Video Call thành công.
  • Trường hợp B từ chối xem video (hoặc máy B không có camera mặt trước): Máy B muốn giữ lại cuộc gọi thoại thông thường. B bắt buộc phải trả lời gói 200 OK nhưng tiến hành vô hiệu hóa luồng video bằng cách đặt tham số Port của dòng video về con số 0:

    m=audio 5002 RTP/AVP 102
    a=rtpmap:102 AMR-WB/16000/1
    m=video 0 RTP/AVP 96
    

    Khi máy A nhận thấy dòng m=video 0, nó hiểu rằng đối phương từ chối chức năng hình ảnh. Máy A tắt luồng truyền video từ camera của mình, giữ nguyên luồng thoại audio hoạt động bình thường.

PHẦN 5: TỔNG QUAN LUỒNG BÁO HIỆU TRONG MẠNG LÕI IMS (VoLTE/VoNR)

Trong mạng di động 4G (VoLTE) và 5G (VoNR), báo hiệu SIP được chuẩn hóa nghiêm ngặt bởi tổ chức 3GPP nhằm đảm bảo tính năng di động, chất lượng dịch vụ ưu tiên hàng đầu (QoS) và quản lý tính cước viễn thông thông qua hạ tầng mạng lõi IMS (IP Multimedia Subsystem).

1. Sơ đồ định tuyến qua các nút lõi chức năng (CSCF)

Bản tin SIP không đi trực tiếp giữa thiết bị đầu cuối A và B mà bắt buộc phải tuần tự đi qua các nút chức năng quản lý cuộc gọi:

+------------+      +------------+      +------------+      +------------+      +------------+
|  Thiết bị  | ---> |   P-CSCF   | ---> |   S-CSCF   | ---> |   S-CSCF   | ---> |  Thiết bị  |
|  Chủ gọi A |      | (Mạng Gọi) |      | (Mạng Gọi) |      | (Mạng Nhận)|      | Bị gọi B   |
+------------+      +------------+      +------------+      +------------+      +------------+

• P-CSCF (Proxy Call Session Control Function): Điểm tiếp xúc đầu tiên (Session Border Controller) bảo mật lớp IP (IPsec) kết nối trực tiếp điện thoại thông qua trạm sóng 4G/5G. Nó bổ sung Header vị trí trạm sóng hiện tại của người dùng.
• S-CSCF (Serving Call Session Control Function): Bộ não trung tâm điều khiển phiên cuộc gọi, chịu trách nhiệm xác thực người dùng, tải cấu hình dịch vụ từ kho dữ liệu HSS/UDM, định tuyến cuộc gọi đến đúng vùng mạng của người nhận và gửi dữ liệu sang hệ thống tính cước độc lập (Billing).

2. Luồng tiến trình 6 bước thiết lập cuộc gọi IMS tiêu chuẩn

Để thiết lập một cuộc gọi VoLTE/VoNR thành công đảm bảo chất lượng phần cứng, hệ thống phải thực hiện đầy đủ chuỗi báo hiệu sau:

Thuê bao A                     Mạng Lõi IMS (CSCF)                  Thuê bao B
    |                                   |                                   |
    |--- 1. INVITE (Offer) ------------>|--- 1. INVITE (Offer) ------------>|
    |                                   |                                   |
    |<-- 2. 183 Session Progress -------|<-- 2. 183 Session Progress -------|
    |                                   |                                   |
    |--- 3. PRACK --------------------->|--- 3. PRACK --------------------->|
    |<-- 4. 200 OK (cho PRACK) ---------|<-- 4. 200 OK (cho PRACK) ---------|
    |                                   |                                   |
    |   [ Mạng tự động thiết lập kênh mang chất lượng cao Dedicated Bearer QoS ]
    |                                   |                                   |
    |<-- 5. 180 Ringing ----------------|<-- 5. 180 Ringing ----------------|
    |   (A nghe tiếng tút tút)          |                                   (B đổ chuông)
    |                                   |                                   |
    |<-- 6. 200 OK (Nhấc máy) ----------|<-- 6. 200 OK (Nhấc máy) ----------|
    |                                   |                                   |
    |--- 7. ACK ----------------------->|--- 7. ACK ----------------------->|
    |                                   |                                   |
    |<====================== THÔNG THOẠI LUỒNG RTP ========================>|

• Cơ chế Điều kiện tiên quyết (QoS Precondition - RFC 3312): Trong mạng IMS di động, gói 183 Session Progress mang thông điệp cam kết chất lượng mạng. Sau bước số 4, mạng lõi di động sẽ kích hoạt tạo luồng dữ liệu ưu tiên đặc biệt (QoS Class Identifier - QCI=1 cho thoại). Khi hai đầu máy điện thoại xác nhận hạ tầng mạng đã cấp đủ băng thông ưu tiên (Precondition Met), điện thoại bên B mới được phép phát lệnh đổ chuông thực tế (180 Ringing). Điều này giúp loại bỏ hoàn toàn hiện tượng nghẹn tiếng hoặc rớt gói tin lúc mới nhấc máy.

PHẦN 6: MẪU CẤU TRÚC BẢN TIN (SAMPLE TRACE) ĐẦY ĐỦ TRONG IMS

Dưới đây là mã nguồn cấu trúc văn bản chuẩn của các bản tin chủ chốt trong một phiên kết nối IMS thực tế.

1. Bản tin INVITE (Gói tin khởi tạo từ Thuê bao A)

INVITE sip:+84912345678@ims.vinaphone.com.vn;user=phone SIP/2.0
Via: SIP/2.0/UDP [2001:db8::1]:5060;branch=z9hG4bKimsA-01
Max-Forwards: 70
Route: <sip:pcscf.ims.vinaphone.com.vn:5060;lr>
From: <sip:+84910000001@ims.vinaphone.com.vn>;tag=1111aa
To: <sip:+84912345678@ims.vinaphone.com.vn>
Call-ID: call-id-ims-12345@2001:db8::1
CSeq: 101 INVITE
Contact: <sip:[2001:db8::1]:5060>
Supported: 100rel, precondition, timer
P-Preferred-Identity: <sip:+84910000001@ims.vinaphone.com.vn>
P-Access-Network-Info: 3GPP-E-UTRAN-FDD; utran-cell-id-3gpp=452020101010101
P-Charging-Vector: icid-value=ims-icid-99999f99f99;icid-generated-at=pcscf
Content-Type: application/sdp
Content-Length: 215

v=0
o=userA 5365536 5365536 IN IP6 2001:db8::1
s=IMS Voice Call
c=IN IP6 2001:db8::1
t=0 0
m=audio 49170 RTP/AVP 102 101
a=rtpmap:102 AMR-WB/16000/1
a=fmtp:102 mode-change-capability=2; max-red=220
a=rtpmap:101 telephone-event/8000
a=curr:qos local none
a=curr:qos remote none
a=des:qos mandatory local sendrecv
a=des:qos mandatory remote sendrecv

2. Bản tin 183 Session Progress (Gói đàm phán phản hồi từ Mạng)

SIP/2.0 183 Session Progress
Via: SIP/2.0/UDP [2001:db8::1]:5060;branch=z9hG4bKimsA-01
From: <sip:+84910000001@ims.vinaphone.com.vn>;tag=1111aa
To: <sip:+84912345678@ims.vinaphone.com.vn>;tag=2222bb
Call-ID: call-id-ims-12345@2001:db8::1
CSeq: 101 INVITE
Require: 100rel, precondition
RSeq: 9001
Contact: <sip:[2001:db8::2]:5002>
Content-Type: application/sdp
Content-Length: 178

v=0
o=userB 5365538 5365538 IN IP6 2001:db8::2
s=IMS Voice Call
c=IN IP6 2001:db8::2
t=0 0
m=audio 50002 RTP/AVP 102 101
a=rtpmap:102 AMR-WB/16000/1
a=fmtp:102 mode-change-capability=2; max-red=220
a=rtpmap:101 telephone-event/8000
a=curr:qos local none
a=curr:qos remote none
a=des:qos mandatory local sendrecv
a=des:qos mandatory remote sendrecv

3. Bản tin PRACK (Gói tin xác nhận bắt buộc cho phản hồi tạm thời)

PRACK sip:[2001:db8::2]:5002 SIP/2.0
Via: SIP/2.0/UDP [2001:db8::1]:5060;branch=z9hG4bKimsA-02
Max-Forwards: 70
Route: <sip:pcscf.ims.vinaphone.com.vn:5060;lr>
From: <sip:+84910000001@ims.vinaphone.com.vn>;tag=1111aa
To: <sip:+84912345678@ims.vinaphone.com.vn>;tag=2222bb
Call-ID: call-id-ims-12345@2001:db8::1
CSeq: 102 PRACK
RAck: 9001 101 INVITE
Content-Length: 0

4. Bản tin 200 OK (Xác nhận Thuê bao B bấm nút đồng ý nghe cuộc gọi)

SIP/2.0 200 OK
Via: SIP/2.0/UDP [2001:db8::1]:5060;branch=z9hG4bKimsA-02
From: <sip:+84910000001@ims.vinaphone.com.vn>;tag=1111aa
To: <sip:+84912345678@ims.vinaphone.com.vn>;tag=2222bb
Call-ID: call-id-ims-12345@2001:db8::1
CSeq: 101 INVITE
Contact: <sip:[2001:db8::2]:5002>
P-Access-Network-Info: 3GPP-E-UTRAN-FDD; utran-cell-id-3gpp=452020202020202
Content-Length: 0

5. Bản tin ACK (Chốt chặn hoàn tất bắt tay 3 bước để thông luồng thoại)

ACK sip:[2001:db8::2]:5002 SIP/2.0
Via: SIP/2.0/UDP [2001:db8::1]:5060;branch=z9hG4bKimsA-03
Max-Forwards: 70
Route: <sip:pcscf.ims.vinaphone.com.vn:5060;lr>
From: <sip:+84910000001@ims.vinaphone.com.vn>;tag=1111aa
To: <sip:+84912345678@ims.vinaphone.com.vn>;tag=2222bb
Call-ID: call-id-ims-12345@2001:db8::1
CSeq: 101 ACK
Content-Length: 0

PHẦN 7: PHÂN BIỆT TOÀN DIỆN CÁC TRƯỜNG HEADERS TRONG BẢN TIN SIP

Việc hiểu sai chức năng của các tiêu đề (Headers) là nguyên nhân hàng đầu dẫn đến việc cấu hình sai hệ thống Core, tạo ra lỗi định tuyến vòng hoặc hiện tượng cuộc gọi tự động ngắt kết nối sau 30 giây (Lỗi mất gói ACK).

1. Nhóm định tuyến và Kiểm soát hành trình (Via, Record-Route, Route)

• Via (Nhật ký chặng bay của gói tin hiện tại):
  • Chức năng: Ghi lại danh sách tất cả các trạm máy chủ mà bản tin yêu cầu cụ thể này vừa đi ngang qua. Mỗi khi qua một Proxy, Proxy đó tự động đè IP của nó lên đỉnh danh sách Via.
  • Mục đích duy nhất: Giúp bản tin phản hồi (Response như 200 OK) biết chính xác con đường cũ để quay ngược trở về đích xuất phát. Nó chỉ có giá trị cho một cặp giao dịch (Transaction) hiện tại rồi tự hủy, không duy trì qua toàn cuộc gọi.
• Record-Route (Lời đề nghị giữ lộ trình cho toàn bộ phiên):
  • Chức năng: Do các Proxy trung gian (như P-CSCF) chèn vào gói tin INVITE ban đầu trên đường đi. Nó hoạt động giống như một thông báo: “Tôi là nút quản lý cước và bảo mật. Tôi yêu cầu tất cả các lệnh phát sinh tiếp theo trong cuộc gọi này bắt buộc phải đi qua tôi”.
  • Mục đích: Giúp hai thiết bị đầu cuối xây dựng nên bản đồ đường đi cố định cho cả phiên gọi (Session).
• Route (Bản đồ hành trình bắt buộc cho lệnh kế tiếp):
  • Chức năng: Do chính Thiết bị đầu cuối (máy A hoặc máy B) tự xây dựng khi phát đi các lệnh tiếp theo (như ACK, BYE, Re-INVITE). Thiết bị đầu cuối lấy danh sách Record-Route đã lưu trước đó, đảo ngược thứ tự lại và chèn vào tiêu đề Route.
  • Mục đích: Ép gói tin phải bay tuần tự qua đúng các bưu cục Proxy trung gian quy định, không cho phép gói tin tự ý bay tắt trực tiếp giữa hai dải IP của người dùng.

2. Nhóm Định danh Hành chính và Quản lý Trạng thái

• From / To (Định danh gốc cuộc gọi):
  • From: Xác định danh tính logic của người gọi (SIP URI) đi kèm tham số tag độc nhất tạo ra từ máy gọi.
  • To: Xác định danh tính logic của người nhận đích thực. Lưu ý quan trọng: Ở gói INVITE ban đầu, trường To chưa có tham số tag. Tham số To-tag chỉ xuất hiện kể từ khi máy đầu dây bên kia nhận được gói tin và phản hồi về (180 Ringing hoặc 200 OK).
  • Quy tắc SIP Dialog: Bộ ba giá trị [Call-ID + From-tag + To-tag] được gọi là ID của một Dialog. Nếu một bản tin BYE gửi lên tổng đài mà sai lệch một trong 3 thông số này, hệ thống lập tức từ chối bằng lỗi 481 Call/Transaction Does Not Exist.
• Request-URI (Mục tiêu chặng kế tiếp):
  • Là dòng đầu tiên nằm ở đỉnh cao nhất của bản tin SIP yêu cầu (Ví dụ: INVITE sip:+84912345678@ims.com SIP/2.0). Trường này rất dễ bị nhầm với trường To. Thực tế, trường To luôn giữ cố định số điện thoại đích từ đầu đến cuối, trong khi dòng Request-URI sẽ bị thay đổi địa chỉ liên tục qua mỗi chặng nhảy Proxy để chỉ đường cho lớp mạng biết gói tin cần chuyển tiếp đến địa chỉ IP nào ở giây tiếp theo.
• Call-ID (Mã định danh cuộc gọi toàn cầu):
  • Chuỗi ký tự ngẫu nhiên kết hợp IP máy (call-id-12345@2001:db8::1) bảo đảm tính duy nhất trên toàn cầu. Tất cả hàng trăm bản tin báo hiệu chạy qua lại phục vụ cho duy nhất một cuộc gọi này bắt buộc phải mang chung một mã Call-ID cố định để hệ thống Wireshark hoặc kỹ sư mạng có thể gom nhóm (Filter) phân tích tiến trình dễ dàng.
• CSeq (Số thứ tự lệnh điều khiển):
  • Gồm một chữ số tăng dần kèm tên phương thức lệnh (Ví dụ: CSeq: 101 INVITE). Nó giúp hệ thống xếp thứ tự các hành động logic, chống ghi đè lệnh cũ và giúp đầu nhận phân biệt gói 200 OK trả về là đang đồng ý cho lệnh khởi tạo cuộc gọi (INVITE) hay lệnh dập máy (BYE).
• Contact (Địa chỉ kết nối trực tiếp):
  • Khai báo địa chỉ IP và số cổng Port thực tế chạy trên phần cứng của thiết bị gửi bản tin. Nó cho biết vị trí định vị thực tế của thiết bị trong không gian mạng IP.
• Max-Forwards (Bộ đếm chặng tối đa chống lặp vòng):
  • Số nguyên giới hạn chặng đi (mặc định bằng 70). Mỗi khi gói tin đi qua một máy chủ Proxy, giá trị này tự động bị giảm đi 1 đơn vị. Nếu hệ thống mạng lõi bị lỗi cấu hình định tuyến vòng tròn khiến gói tin bay quanh quẩn, khi Max-Forwards chạm mốc 0, Proxy hiện tại sẽ lập tức hủy gói tin và trả về lỗi SIP 483 Too Many Hops, ngăn chặn hoàn toàn việc treo hệ thống do nghẽn gói tin lặp vô hạn.