Các vấn đề về NAT, RTP và âm thanh
Các vấn đề về NAT, RTP và âm thanh
Điều đầu tiên cần lưu ý là SIP KHÔNG được thiết kế để hoạt động với NAT .
Chà nếu bạn đang bận tâm khi đọc điều này, có thể là do bạn đang gặp phải hoặc đã gặp sự cố âm thanh với điện thoại SIP VoIP của mình. Đó hoàn toàn là do sự giám sát lớn này của các nhà thiết kế SIP. Mặt khác, nếu bạn nhìn vào Skype, giao thức độc quyền của họ có tỷ lệ các vấn đề âm thanh nhỏ hơn nhiều. Các nhà thiết kế giao thức Skype đã phải nỗ lực rất nhiều để đưa ra một thiết kế thực dụng (tất nhiên đó là lợi ích của họ vì họ đang hướng tới việc kiếm lợi nhuận). Họ thậm chí còn đi xa đến mức cho phép lưu lượng truy cập của họ được đào qua các proxy HTTPS để các cuộc gọi có cơ hội tốt hoạt động sau tường lửa của công ty; không có cơ hội điều đó với SIP ngay cả bây giờ.
Nếu ai đó phải cộng thêm chi phí trong giờ làm việc của công nhân kỹ thuật, thì sự thất vọng của người dùng và các cuộc gọi VoIP bị lỗi do tiêu chuẩn SIP gây ra thì đó là một điều phi thường. Là một người đã từng điều hành một công ty VoIP trong quá khứ, tôi ước tính rằng đâu đó từ 30 đến 50% tất cả các vấn đề hỗ trợ là do âm thanh một chiều hoặc các vấn đề liên quan đến NAT khác.
Điều đầu tiên cần xem xét là cách một cuộc gọi VoIP SIP được cho là hoạt động trong một kịch bản lý tưởng (đây là kịch bản duy nhất mà tiêu chuẩn SIP thích ứng).
Cuộc gọi SIP - Kịch bản lý tưởng
Trong sơ đồ trên, thiết bị SIP của người dùng cuối và máy chủ SIP đều nằm trên địa chỉ IP công cộng và mọi thứ đều ổn. Để hiểu sơ đồ và các sơ đồ tiếp theo, chú thích là:
Các hộp màu xám ở hai bên đại diện cho tải trọng của Giao thức mô tả phiên (SDP) được thực hiện trong các yêu cầu và phản hồi của SIP INVITE,
Các vòng tròn màu đỏ trên các hộp màu xám đánh dấu thông tin quan trọng trong SDP là địa chỉ IP và số cổng mà thiết bị gửi sẽ sử dụng để gửi và nhận RTP của nó,
Các đường màu xanh lam đại diện cho một đường truyền SIP,
Đường màu xanh lục biểu thị một luồng RTP,
Một dòng màu đỏ đại diện cho một luồng RTP không thể được thiết lập,
Công khai hoặc Riêng tư cho biết loại địa chỉ IP mà máy chủ hoặc tác nhân người dùng đang sử dụng.
Trong trường hợp lý tưởng, cả hai đầu của cuộc gọi SIP đều đặt một ổ cắm IP có thể truy cập công khai trong SDP của họ và thiết bị ở mỗi đầu cuộc gọi không có vấn đề gì khi gửi và nhận đến và từ ổ cắm của người kia và tất cả đều tốt.
Khoảng thời gian duy nhất bạn gặp tình huống lý tưởng được hiển thị ở trên là cho các trung kế SIP giữa hai Nhà cung cấp VoIP. Kết nối internet trung bình dành cho khu dân cư và doanh nghiệp sử dụng NAT và điều đó làm thay đổi cảnh quan cho cuộc gọi SIP về bề ngoài một cách tinh tế nhưng hiệu quả đáng kể.
NAT Scenario cơ bản
Điểm mấu chốt bây giờ là Điện thoại SIP ở bên trái đang hoạt động trên một địa chỉ IP riêng và đó là những gì nó đã đặt trong SDP của mình. Cuộc gọi tiến hành tương tự như trong kịch bản lý tưởng nhưng khi thiết bị SIP ở đầu kia, trong trường hợp này là SIP Softswitch, cố gắng gửi RTP đến điện thoại thì không thể vì SDP chứa địa chỉ riêng không thể định tuyến được. Internet công cộng.
Biểu đồ này thể hiện tình huống âm thanh một chiều cổ điển. Người trên Điện thoại IP không thể nghe thấy người ở đầu bên kia của cuộc gọi. Người ở phía máy chủ có thể nghe thấy người trên Điện thoại IP vì điện thoại đang vui vẻ gửi RTP đến ổ cắm SDP công cộng của máy chủ.
Để SIP được sử dụng trong thế giới thực, rõ ràng nó phải vượt qua vấn đề NAT được hiển thị trong sơ đồ trước (tôi có lẽ không nên nói rõ ràng vì nó dường như không rõ ràng như vậy khi SIP được phát minh). Thực tế có một số cách khác nhau mà NAT có thể được khắc phục với SIP nhưng chúng được chia thành hai loại:
Loại đầu tiên là nơi các thiết bị SIP trên địa chỉ IP riêng cố gắng xác định địa chỉ IP công cộng của chúng và sau đó sử dụng địa chỉ đó trong SDP thay vì địa chỉ riêng tư của chúng. STUN là một giao thức được thiết kế cho mục đích này. Một số thiết bị cho phép người dùng chỉ định địa chỉ IP công cộng theo cách thủ công và có những cơ chế khác. Việc thiết bị SIP lấy địa chỉ IP công khai không quan trọng lắm chỉ cần nó đặt nó vào SDP khi thực hiện hoặc trả lời cuộc gọi,
Loại thứ hai là nơi Máy chủ SIP sẽ cố gắng đối phó với việc khách hàng gửi cho họ các gói SDP với địa chỉ IP riêng thường thay thế địa chỉ riêng bằng địa chỉ công cộng mà gói đó đến.
Điều quan trọng cần nhận ra là không có cơ chế nào trong số này là hoàn hảo. Và điều đó đáng phải nhắc lại: không có cơ chế hoàn hảo 100% nào có thể đảm bảo một cuộc gọi SIP có thể đối phó với NAT . Mặc dù hầu hết thời gian nó có thể. Lý do không có cơ chế đảm bảo là do bản chất của NAT và cụ thể hơn là NAT sử dụng Port Address Translation (PAT). Nó được giải thích thêm một chút về phần này nhưng nếu NAT dịch cổng trên luồng RTP đi của thiết bị SIP thì điều đó có nghĩa là cổng được đặt trong SDP bây giờ bị sai và việc gửi RTP đến ổ cắm được yêu cầu sẽ không thành công và dẫn đến một- cách âm thanh.
Chúng ta hãy xem xét một trong các cơ chế từ loại thứ hai mà Máy chủ SIP có thể sử dụng để đối phó với cuộc gọi từ một thiết bị riêng.
Xử lý NAT - Server Mangling
Trong sơ đồ này, văn bản nhỏ không thể đọc được ở bên phải giải thích cách Máy chủ SIP được cấu hình để nhận ra các địa chỉ IP riêng trong SDP và thay thế chúng bằng địa chỉ IP mà yêu cầu đã được nhận. Máy chủ ảo thuật làm chính xác điều đó. Vấn đề là nó không phải là một cơ chế đặc biệt mạnh mẽ. Ví dụ, nếu một SIP Proxy nằm giữa thiết bị cuối và Máy chủ SIP đang thực hiện việc xáo trộn thì địa chỉ IP công cộng của Proxy sẽ được đặt vào SDP và RTP sẽ không bao giờ đến được thiết bị cuối. Hoặc như đôi khi xảy ra lỗi NAT sẽ thực sự để lại địa chỉ IP nguồn của các gói mà nó truyền đi dưới dạng địa chỉ IP riêng, cho phép Máy chủ SIP lựa chọn giữa địa chỉ SDP riêng và địa chỉ gốc riêng (có thể giống nhau nên không có lựa chọn nào thực sự ).
Một điều phổ biến khác phá vỡ nỗ lực của Máy chủ SIP trong việc sử dụng địa chỉ gốc yêu cầu cho RTP là địa chỉ được ám chỉ trước đây, PAT.
NAT Mangling - Bị phá vỡ bởi PAT
Trong sơ đồ trên, Máy chủ SIP đã phát hiện chính xác địa chỉ IP công cộng của điện thoại và đã cố gắng gửi các gói RTP của nó đến đó. Tuy nhiên, vì NAT phía trước điện thoại đã thực hiện dịch cổng trên luồng RTP của điện thoại nên NAT không có ánh xạ cho socket mà Máy chủ đang cố gắng gửi đến và chỉ đơn giản là bỏ các gói. Kết quả lại là âm thanh một chiều.
Vì vậy, mangling có ích và tốt hơn là không phải lúc nào nó cũng hoạt động tùy thuộc vào loại thiết bị NAT phía trước điện thoại của bạn. Bởi vì dịch vụ phân tích kỹ thuật chỉ giao dịch với SIP chứ không phải RTP nên việc xử lý dữ liệu là điều DUY NHẤT mà nó có thể làm. Không có phép thuật nào khác mà nó có thể làm để thử và kết nối các luồng RTP. Lời khuyên tốt nhất cho âm thanh một chiều và sử dụng tính năng ảo thuật là thử và thiết lập bộ định tuyến của bạn để KHÔNG thực hiện các bản dịch cổng trên phạm vi điện thoại của bạn sử dụng cho RTP .
Cơ chế tiếp theo mà Máy chủ SIP có thể sử dụng để đối phó với NAT là quên đi việc xáo trộn gói và phản ánh lại RTP cho bất kỳ ổ cắm nào mà nó nhận được.
NAT - Phản ánh RTP
Trong sơ đồ trên, Máy chủ SIP sẽ bắt đầu gửi RTP đến bất kỳ ổ cắm nào được chỉ định trong SDP của yêu cầu cuộc gọi bất kể đó có phải là địa chỉ riêng tư hay không. Sau đó, ngay khi nó nhận được một gói RTP từ đầu kia, nó sẽ cho rằng đó là socket mà nó nên gửi RTP của chính nó đến và chuyển sang đó. Đây là cơ chế mà Asterisk sử dụng khi bạn đặt nat = yes trên tài khoản SIP. Nó đặt ra một lỗ hổng bảo mật tiềm ẩn trong đó kẻ tấn công có thể giám sát lưu lượng SIP và sau đó cố gắng lấy gói RTP đến Máy chủ SIP trước thiết bị chính hãng và do đó chiếm quyền điều khiển luồng RTP. Trong thực tế, có nhiều cách dễ dàng hơn để đột nhập vào hệ thống SIP, do đó, kẻ tấn công không muốn làm phiền với cách tiếp cận đó trong các trường hợp bình thường.
Cơ chế phản chiếu này tốt hơn so với thao tác sai vì nó xoay quanh bất kỳ bản dịch cổng nào mà NAT phía trước điện thoại của người dùng cuối có thể đã thực hiện. Như đã đề cập ở trên, máy chủ sipsorcery không thể sử dụng cơ chế này vì nó không bao giờ thấy bất kỳ RTP nào, tuy nhiên khi Máy chủ SIP ở cuối cuộc gọi đang sử dụng cơ chế này thì máy chủ sipsorcery không cần thực hiện bất kỳ thao tác xử lý NAT nào. Nếu bạn đang gặp sự cố âm thanh một chiều, bạn không nên thử tìm Nhà cung cấp SIP có máy chủ của họ được định cấu hình để sử dụng cơ chế phản xạ RTP. Nó giúp bạn không phải loay hoay với bộ định tuyến của mình và về mặt thực tế là sẽ đối phó với hầu hết các NAT.
Nói chung, trong đó một đầu của cuộc gọi là Máy chủ SIP trên địa chỉ IP công cộng, các vấn đề âm thanh một chiều sẽ có thể giải quyết được. Các trường hợp chúng thường không liên quan đến NAT bị lỗi (có nhiều thứ hơn bạn nghĩ) hoặc trường hợp điện thoại có nhiều NAT. Điều thứ hai có thể xảy ra khi ISP chạy NAT trong suốt trên mạng của họ vì chúng thiếu địa chỉ IP hoặc vì một số lý do khác. Về lý thuyết, nhiều NAT cũng nên được xử lý bằng cách xử lý RTP Reflection nhưng trên thực tế khi số lượng NAT trên đường dẫn âm thanh tăng lên trên một, nguy cơ các sự cố âm thanh dường như tăng theo cấp số nhân!
Một tình huống phổ biến khác với người dùng sipsorcery là không có SIP Server trong cuộc gọi và thay vào đó cuộc gọi diễn ra giữa hai thiết bị người dùng cuối. Hầu hết mọi người nghĩ rằng đây sẽ là một tình huống đơn giản hơn và họ sẽ ít có khả năng gặp sự cố âm thanh hơn nhưng không phải vậy và thực tế thì ngược lại. Bây giờ thay vì có một thiết bị trên một địa chỉ IP riêng, chúng thường sẽ là hai thiết bị.
NAT - Tác nhân người dùng đến Tác nhân người dùng
Sơ đồ trên minh họa một cuộc gọi giữa hai người dùng ảo thuật trong đó điện thoại của mỗi người dùng trên một mạng riêng. Trong trường hợp này, cả hai người dùng đều có NAT đang thực hiện việc dịch cổng và cả hai luồng RTP đều không vượt qua được nên cả hai người dùng đều không nghe thấy gì. Phổ biến hơn là chỉ một trong số các NAT của người dùng thực hiện dịch cổng, vì vậy một trong số chúng sẽ nhận được âm thanh và cái còn lại thì không. Trong tình huống này, sự thành công của cuộc gọi phụ thuộc vào cả máy chủ ảo thuật có thể quản lý SDP để nó chứa địa chỉ IP công cộng và các NAT liên quan KHÔNG thực hiện dịch cổng. Nếu một trong hai điều kiện đó không được đáp ứng thì một hoặc cả hai luồng RTP và do đó luồng âm thanh sẽ không thành công.
Tôi có thêm sơ đồ và giải thích cho các tình huống NAT xung quanh các phiên bản được cài đặt cục bộ của máy chủ ảo thuật, thậm chí còn phức tạp hơn vì bây giờ thậm chí máy chủ không nằm trên địa chỉ IP công cộng. Tuy nhiên, tôi sẽ để lại chúng cho bài viết tiếp theo.
Lời khuyên tốt nhất mà tôi có thể đưa ra cho bất kỳ ai gặp sự cố âm thanh nhất quán trong các cuộc gọi VoIP là hãy google mô hình bộ định tuyến của họ và xem liệu có bất kỳ người nào khác gặp vấn đề tương tự không và liệu họ có thể khắc phục được không. Nếu điều đó không mang lại kết quả gì, hãy thử mượn một bộ định tuyến khác từ một người bạn và xem liệu âm thanh có tốt hơn với điều đó không. Nếu đó là cá nhân tôi muốn thay thế bộ định tuyến vì sự thất vọng lâu dài của các vấn đề âm thanh trong các cuộc gọi vượt xa mức 100 đô la trở xuống trên một bộ định tuyến mới.
Tin tức liên quan
- Các vấn đề Nat trong tổng đài Voice IP (Asterisk, FreePBX, Yearstar, Grandstream,)
- Các gói cước miễn phí 20 phút gọi nội mạng - Áp dụng cho AutoCall của EzCall
- Tổng đài điện thoại giá rẻ
- Tổng đài điện thoại cho doanh nghiệp mới thành lập
- Giải pháp tổng đài điện thoại
- Tổng quan các loại tổng đài điện thoại trên thị trường
- Giải pháp tổng đài cho tiêm chủng
- Giải pháp tổng đài IP