Vì sao cuộc gọi SIP đăng ký qua VPN nhưng không gửi âm thanh
Đăng ký và âm thanh đi theo những đường khác nhau. Theo dõi một cuộc gọi qua đường hầm để xem PBX có thể dùng những địa chỉ nào và RTP thực sự dừng ở đâu.
Đăng ký thành công hầu như không cho biết gì về âm thanh. Một softphone có thể giữ liên kết hợp lệ với PBX của văn phòng trong nhiều giờ mà vẫn truyền sự im lặng. Đường hầm chỉ chở những gói mà ai đó cố ý gửi vào, và một cuộc gọi dùng ba đường riêng biệt: liên kết, thiết lập hội thoại và luồng RTP. Khi tách chúng ra, lỗi rơi vào một đường thay vì vào chữ VPN.
Hãy hình dung một laptop trên Wi-Fi ở nhà quay số máy lẻ của văn phòng qua một đường hầm đã được phê duyệt. PBX xác thực người dùng, chấp nhận REGISTER, và máy lẻ hiện là khả dụng, nhưng cuộc gọi kết nối với sự im lặng hoàn toàn ở một chiều.
Đăng ký ràng buộc một liên hệ, không phải đường truyền phương tiện
Yêu cầu REGISTER đề nghị máy đăng ký lưu một ánh xạ giữa địa chỉ ghi danh và một hoặc nhiều URI liên hệ. Ánh xạ đó trả lời một câu hỏi hẹp về nơi cần gửi hội thoại mới ngay bây giờ. Nó không nói gì về nơi phương tiện thuộc về, và một đăng ký được chấp nhận không chứng minh rằng INVITE sau đó mang địa chỉ phương tiện có thể tới được. Đăng ký cũng hết hạn theo bộ đếm thời gian, nên điện thoại ngừng làm mới sẽ mất các cuộc gọi đến trong khi đường hầm của nó vẫn trông khỏe mạnh. Hãy theo dõi thời hạn của liên hệ thay vì trạng thái đường hầm.
Khi softphone nằm sau đường hầm, tiêu đề liên hệ có thể mang địa chỉ riêng. Một PBX chuyển tiếp nó tới một điểm cuối khác sẽ tạo hội thoại hướng tới mạng mà bên được gọi không thể tới. Đặt rewrite_contact=yes trên điểm cuối PJSIP khiến PBX thay thế địa chỉ nguồn mà nó quan sát được, và đó thường là khác biệt giữa chuông và hết thời gian.
INVITE đề nghị gì và ai có thể dùng nó
Một INVITE có phần thân SDP đề xuất nơi người gọi muốn nhận phương tiện: một địa chỉ, một cổng và danh sách codec. Bên được gọi trả lời bằng địa chỉ và cổng của chính mình, sau đó mỗi bên gửi RTP tới nơi bên kia đề xuất. Nếu người gọi đề xuất một địa chỉ 192.168.x.x chỉ tồn tại trong mạng gia đình, bên được gọi không có nơi nào để gửi âm thanh, dù tín hiệu có sạch đến đâu. Việc che địa chỉ viết lại tiêu đề IP khi gói rời bộ định tuyến, nhưng không bao giờ viết lại văn bản bên trong phần thân SDP.
Khoảng trống đó giải thích cuộc gọi một chiều kinh điển: tín hiệu hoạt động vì cả hai điểm cuối đều tới được PBX, và âm thanh thất bại vì một điểm cuối được lệnh gửi tới địa chỉ chỉ tồn tại sau một NAT khác.
| Path | Who picks the address | Typical failure |
|---|---|---|
| REGISTER | Softphone, rewritten by the registrar if configured | Binding expires or points at a private address |
| INVITE and SDP | Each endpoint in its own offer or answer | Offer names a media address nobody can route to |
| RTP | PBX relay policy or the two endpoints | Port range blocked, or no return path |
Ai mang âm thanh là một lựa chọn cấu hình
Tín hiệu và phương tiện là hai vai trò riêng. Một proxy có thể ở trên đường tín hiệu suốt cuộc gọi và không bao giờ chạm vào một gói RTP nào. Việc PBX trở thành bộ chuyển tiếp phương tiện phụ thuộc vào cấu hình, không phải vào sự tồn tại của đường hầm.
Với phương tiện trực tiếp, các điểm cuối tự trao đổi RTP, cách này hoạt động tốt trên một LAN và tệ khi một bên nằm sau một dải cổng hẹp.
Đặt direct_media=no đẩy PBX vào đường phương tiện để cả hai chặng kết thúc tại địa chỉ nó kiểm soát, đổi băng thông và CPU lấy địa chỉ hóa dự đoán được. Khi chuyển tiếp, PBX vẫn phải quảng bá một địa chỉ có thể tới được. Trên máy chủ nhiều mạng, external_media_address và external_signaling_address trong pjsip.conf quyết định điều gì xuất hiện trong SDP và trong tiêu đề Via. Nếu để chúng chưa đặt, PBX có thể đề nghị địa chỉ LAN của mình cho người gọi mà đường duy nhất là phía xa của đường hầm.
Theo dõi từng chiều trước khi chạm vào cài đặt
Bắt đầu với bảng socket trên PBX khi cuộc gọi đang diễn ra: ss -uanp | grep -E '5060|10000' cho thấy các cổng RTP có được gắn hay không và dùng địa chỉ cục bộ nào. Nếu không có gì được gắn trong dải phương tiện, bộ chuyển tiếp không tham gia và các điểm cuối nói chuyện trực tiếp. Sau đó bắt gói ở phía softphone bằng tcpdump -ni any -s0 udp portrange 10000-20000 -w rtp.pcap. Các gói đi ra mà không có gói đi vào thu hẹp vấn đề vào đường quay về hoặc vào địa chỉ mà phía xa được lệnh dùng, và một bản bắt rỗng nghĩa là phương tiện chưa bao giờ tới giao diện đường hầm. Bản bắt tín hiệu bằng sngrep trả lời nửa còn lại bằng cách hiển thị dòng kết nối SDP như đã gửi.
So sánh địa chỉ trong dòng kết nối đó với địa chỉ mà phía xa thực sự có thể định tuyến tới. Chỉ một so sánh đó giải quyết hầu hết báo cáo âm thanh một chiều nhanh hơn bất kỳ đợt xem lại cấu hình nào.
Mã hóa dừng ở rìa đường hầm
SIP trên TLS bảo vệ chặng tín hiệu mà nó được cấu hình, SRTP bảo vệ phương tiện khi cả hai đầu thương lượng, và đường hầm bảo vệ lưu lượng giữa các điểm cuối của chính nó. Không cái nào trao cho cái kia. Một cuộc gọi được mã hóa bên trong đường hầm vẫn có thể rời cổng ra dưới dạng văn bản rõ về phía PBX, và đó là quyết định thiết kế, không phải khiếm khuyết.
Trước khi đóng phiếu, xác nhận ba điều theo thứ tự: đăng ký còn mới, SDP mang địa chỉ mà phía xa có thể tới, và các gói chảy cả hai chiều trên cổng phương tiện. Nếu bất kỳ điều nào sai, đường hầm không phải nơi vấn đề trú ngụ. Sửa đường đã hỏng, rồi chạy lại đúng bản bắt đó để xác nhận thay đổi. Giữ các bản bắt trước và sau biến báo cáo một chiều tiếp theo thành một lần kiểm tra năm phút thay vì cả buổi chiều.