Tweet
Khi thực hiện một cuộc gọi VoIP, chúng ta thường nghĩ âm thanh được truyền trực tiếp từ IP Phone này sang IP Phone khác. Nhưng trước khi hai bên có thể nói chuyện, hệ thống phải thực hiện hàng loạt công việc: tìm người nhận, thiết lập cuộc gọi, thương lượng codec, xác định địa chỉ media và cuối cùng kết thúc phiên.
Một trong những giao thức quan trọng nhất đảm nhiệm phần signaling đó chính là SIP – Session Initiation Protocol. SIP thực sự làm gì?
SIP là một signaling protocol được sử dụng để:
Establish → Manage/Modify → Terminate
các session chạy trên mạng IP.
SIP được định nghĩa cốt lõi trong RFC 3261, đồng thời dựa trên và được mở rộng bởi nhiều RFC khác.
Điểm rất quan trọng:
Trong một cuộc gọi VoIP điển hình:
SIP Signaling
Phone A ←────────────→ Phone B
│
│
Thiết lập cuộc gọi
Phone A ══════════════ Phone B
RTP
Voice Media
SIP lo phần "gọi cho ai và thiết lập cuộc gọi như thế nào", còn voice media thường được vận chuyển bằng RTP; nếu mã hóa media, thường dùng SRTP.
SIP sử dụng message dạng text
Một đặc điểm khiến SIP tương đối dễ học và troubleshoot là message có cấu trúc dạng text, về lịch sử được mô tả là ASCII-based.
Ví dụ một SIP Request:
INVITE sip:2002@example.com SIP/2.0
Via: SIP/2.0/UDP 10.10.10.20
From: <sip:2001@example.com>
To: <sip:2002@example.com>
Call-ID: ...
CSeq: 1 INVITE
Network Engineer có thể capture traffic bằng Wireshark và đọc khá trực quan.
User Agent – Hai vai trò cơ bản của SIP
Một SIP endpoint hoạt động dưới hai vai trò logic:
UAC – User Agent Client: tạo SIP Request.
UAS – User Agent Server: nhận Request và tạo Response.
Ví dụ Phone A gọi Phone B:
Phone A Phone B
UAC UAS
│ │
│------------ INVITE ------------>│
│<--------- 180 Ringing ----------│
│<----------- 200 OK -------------│
│------------- ACK -------------->│
Khi kết thúc cuộc gọi, một bên gửi BYE và phía kia phản hồi 200 OK.
SIP Request và Response
SIP hoạt động theo mô hình Request/Response, khá giống tư duy của HTTP.
Một số SIP Method quan trọng:
Response sử dụng mã trạng thái như:
100 Trying
180 Ringing
200 OK
401 Unauthorized
404 Not Found
486 Busy Here
503 Service Unavailable
Nhìn vào các mã này, kỹ sư Collaboration có thể nhanh chóng xác định cuộc gọi đang thất bại ở giai đoạn nào.
SDP – SIP gọi điện, nhưng ai thương lượng media?
Đây là điểm rất dễ nhầm.
SIP thực hiện signaling, còn thông tin mô tả media thường được trao đổi bằng:
SDP – Session Description Protocol.
SDP có thể cho hai bên biết:
Ví dụ:
Phone A:
"Tôi hỗ trợ G.711 và Opus,
hãy gửi RTP đến IP/port này."
↓ SDP
Phone B:
"Tôi đồng ý với codec phù hợp."
Sau khi thương lượng hoàn tất, RTP có thể bắt đầu truyền media.
Offer/Answer Model
Việc thương lượng media thường tuân theo Offer/Answer Model.
Một bên gửi Offer:
Bên kia gửi Answer:
Đây là nền tảng của quá trình media negotiation trong SIP.
Early Offer và Delayed Offer
Trong Early Offer, SDP Offer được gửi ngay trong INVITE.
INVITE + SDP Offer
↓
200 OK + SDP Answer
Trong Delayed Offer, INVITE ban đầu không chứa SDP Offer; việc trao đổi SDP diễn ra ở bước sau của call setup.
Khái niệm này rất quan trọng khi troubleshoot SIP Trunk, CUBE, CUCM và kết nối với Service Provider, vì hai phía cần có hành vi signaling/media tương thích.
Early Media là gì?
Đôi khi người gọi nghe được âm thanh trước khi cuộc gọi chính thức được answer.
Ví dụ:
Đây là Early Media.
Trong SIP, early media thường liên quan đến provisional responses như 183 Session Progress cùng thông tin SDP phù hợp.
DTMF Relay – Bấm phím 1, 2, 3...
Trong thực tế, người dùng thường gặp:
Các digit này gọi là DTMF – Dual-Tone Multi-Frequency.
Trong môi trường VoIP, DTMF có thể được truyền theo nhiều cơ chế khác nhau, chẳng hạn RTP telephone-event (RFC 4733, kế thừa RFC 2833) hoặc SIP INFO tùy hệ thống.
Nếu hai bên cấu hình DTMF không tương thích, cuộc gọi vẫn nghe nói bình thường nhưng:
Đây là một lỗi SIP/VoIP rất điển hình.
🎯 Cách nhớ SIP đơn giản nhất
Hãy hình dung một cuộc gọi như sau:
SIP
"Bạn có muốn nói chuyện không?"
↓
SDP
"Nói bằng codec nào?
RTP gửi tới IP/port nào?"
↓
RTP/SRTP
"Bắt đầu truyền voice."
↓
SIP BYE
"Kết thúc cuộc gọi."
Vì vậy, khi troubleshoot VoIP, hãy tách bài toán thành hai phần:
Một cuộc gọi có thể setup thành công nhưng không có tiếng. Khi đó, đừng chỉ nhìn SIP; hãy kiểm tra tiếp SDP, RTP, codec, IP/port, Firewall, NAT và routing của media.
Đây chính là tư duy nền tảng khi troubleshooting CUCM, CUBE, SIP Trunk, SBC và hệ thống VoIP hiện đại.
Một trong những giao thức quan trọng nhất đảm nhiệm phần signaling đó chính là SIP – Session Initiation Protocol. SIP thực sự làm gì?
SIP là một signaling protocol được sử dụng để:
Establish → Manage/Modify → Terminate
các session chạy trên mạng IP.
SIP được định nghĩa cốt lõi trong RFC 3261, đồng thời dựa trên và được mở rộng bởi nhiều RFC khác.
Điểm rất quan trọng:
SIP chủ yếu điều khiển phiên giao tiếp; SIP không phải giao thức mang luồng âm thanh của cuộc gọi.
Trong một cuộc gọi VoIP điển hình:
SIP Signaling
Phone A ←────────────→ Phone B
│
│
Thiết lập cuộc gọi
Phone A ══════════════ Phone B
RTP
Voice Media
SIP lo phần "gọi cho ai và thiết lập cuộc gọi như thế nào", còn voice media thường được vận chuyển bằng RTP; nếu mã hóa media, thường dùng SRTP.
SIP sử dụng message dạng text
Một đặc điểm khiến SIP tương đối dễ học và troubleshoot là message có cấu trúc dạng text, về lịch sử được mô tả là ASCII-based.
Ví dụ một SIP Request:
INVITE sip:2002@example.com SIP/2.0
Via: SIP/2.0/UDP 10.10.10.20
From: <sip:2001@example.com>
To: <sip:2002@example.com>
Call-ID: ...
CSeq: 1 INVITE
Network Engineer có thể capture traffic bằng Wireshark và đọc khá trực quan.
User Agent – Hai vai trò cơ bản của SIP
Một SIP endpoint hoạt động dưới hai vai trò logic:
UAC – User Agent Client: tạo SIP Request.
UAS – User Agent Server: nhận Request và tạo Response.
Ví dụ Phone A gọi Phone B:
Phone A Phone B
UAC UAS
│ │
│------------ INVITE ------------>│
│<--------- 180 Ringing ----------│
│<----------- 200 OK -------------│
│------------- ACK -------------->│
Khi kết thúc cuộc gọi, một bên gửi BYE và phía kia phản hồi 200 OK.
SIP Request và Response
SIP hoạt động theo mô hình Request/Response, khá giống tư duy của HTTP.
Một số SIP Method quan trọng:
- INVITE: thiết lập hoặc thay đổi session.
- ACK: xác nhận phản hồi cuối cho INVITE.
- BYE: kết thúc session.
- REGISTER: đăng ký vị trí/contact của endpoint.
- CANCEL: hủy một request đang chờ.
- OPTIONS: kiểm tra khả năng hoặc trạng thái SIP của thiết bị.
Response sử dụng mã trạng thái như:
100 Trying
180 Ringing
200 OK
401 Unauthorized
404 Not Found
486 Busy Here
503 Service Unavailable
Nhìn vào các mã này, kỹ sư Collaboration có thể nhanh chóng xác định cuộc gọi đang thất bại ở giai đoạn nào.
SDP – SIP gọi điện, nhưng ai thương lượng media?
Đây là điểm rất dễ nhầm.
SIP thực hiện signaling, còn thông tin mô tả media thường được trao đổi bằng:
SDP – Session Description Protocol.
SDP có thể cho hai bên biết:
- IP nhận media
- RTP port
- Loại media
- Codec được hỗ trợ
Ví dụ:
Phone A:
"Tôi hỗ trợ G.711 và Opus,
hãy gửi RTP đến IP/port này."
↓ SDP
Phone B:
"Tôi đồng ý với codec phù hợp."
Sau khi thương lượng hoàn tất, RTP có thể bắt đầu truyền media.
Offer/Answer Model
Việc thương lượng media thường tuân theo Offer/Answer Model.
Một bên gửi Offer:
Tôi hỗ trợ những codec và thông số media này.
Bên kia gửi Answer:
Tôi chọn các thông số tương thích này.
Đây là nền tảng của quá trình media negotiation trong SIP.
Early Offer và Delayed Offer
Trong Early Offer, SDP Offer được gửi ngay trong INVITE.
INVITE + SDP Offer
↓
200 OK + SDP Answer
Trong Delayed Offer, INVITE ban đầu không chứa SDP Offer; việc trao đổi SDP diễn ra ở bước sau của call setup.
Khái niệm này rất quan trọng khi troubleshoot SIP Trunk, CUBE, CUCM và kết nối với Service Provider, vì hai phía cần có hành vi signaling/media tương thích.
Early Media là gì?
Đôi khi người gọi nghe được âm thanh trước khi cuộc gọi chính thức được answer.
Ví dụ:
- Ringback tone
- Announcement
- "Số máy quý khách vừa gọi..."
- Thông báo từ nhà mạng
Đây là Early Media.
Trong SIP, early media thường liên quan đến provisional responses như 183 Session Progress cùng thông tin SDP phù hợp.
DTMF Relay – Bấm phím 1, 2, 3...
Trong thực tế, người dùng thường gặp:
"Nhấn phím 1 để gặp phòng kinh doanh."
Các digit này gọi là DTMF – Dual-Tone Multi-Frequency.
Trong môi trường VoIP, DTMF có thể được truyền theo nhiều cơ chế khác nhau, chẳng hạn RTP telephone-event (RFC 4733, kế thừa RFC 2833) hoặc SIP INFO tùy hệ thống.
Nếu hai bên cấu hình DTMF không tương thích, cuộc gọi vẫn nghe nói bình thường nhưng:
Bấm phím IVR lại không hoạt động.
Đây là một lỗi SIP/VoIP rất điển hình.
🎯 Cách nhớ SIP đơn giản nhất
Hãy hình dung một cuộc gọi như sau:
SIP
"Bạn có muốn nói chuyện không?"
↓
SDP
"Nói bằng codec nào?
RTP gửi tới IP/port nào?"
↓
RTP/SRTP
"Bắt đầu truyền voice."
↓
SIP BYE
"Kết thúc cuộc gọi."
Vì vậy, khi troubleshoot VoIP, hãy tách bài toán thành hai phần:
Signaling có đúng không? → SIP
Media có đi đúng không? → RTP/SRTP
Media có đi đúng không? → RTP/SRTP
Một cuộc gọi có thể setup thành công nhưng không có tiếng. Khi đó, đừng chỉ nhìn SIP; hãy kiểm tra tiếp SDP, RTP, codec, IP/port, Firewall, NAT và routing của media.
Đây chính là tư duy nền tảng khi troubleshooting CUCM, CUBE, SIP Trunk, SBC và hệ thống VoIP hiện đại.
Attached Files