Dlaczego połączenie SIP rejestruje się przez VPN, ale nie wysyła dźwięku
Rejestracja i dźwięk podążają różnymi ścieżkami. Prześledź jedno połączenie przez tunel, aby zobaczyć, których adresów może użyć PBX i gdzie RTP naprawdę się zatrzymuje.
Udana rejestracja prawie nic nie mówi o dźwięku. Softphone może godzinami utrzymywać ważne powiązanie z PBX w biurze i wciąż dostarczać ciszę. Tunel przenosi tylko te pakiety, które ktoś świadomie do niego wysyła, a połączenie korzysta z trzech odrębnych ścieżek: powiązania, zestawienia dialogu i strumienia RTP. Gdy je rozdzielisz, awaria trafia na jedną ścieżkę, a nie na słowo VPN.
Wyobraź sobie laptopa w domowym Wi-Fi, który wybiera biurowy numer wewnętrzny przez zatwierdzony tunel. PBX uwierzytelnia użytkownika, przyjmuje REGISTER, a numer wewnętrzny pokazuje się jako dostępny, mimo to połączenie nawiązuje się z całkowitą ciszą w jednym kierunku.
Rejestracja wiąże kontakt, a nie ścieżkę mediów
Żądanie REGISTER prosi rejestrator o zapisanie odwzorowania między adresem zapisu a jednym lub kilkoma URI kontaktowymi. To odwzorowanie odpowiada na wąskie pytanie, gdzie nowy dialog ma zostać teraz wysłany. Nie mówi nic o tym, gdzie należą media, a przyjęta rejestracja nie dowodzi, że późniejsze INVITE niesie osiągalny adres mediów. Rejestracje wygasają też według licznika czasu, więc telefon, który przestaje odświeżać, traci połączenia przychodzące, choć jego tunel nadal wygląda zdrowo. Obserwuj wygaśnięcie kontaktu, a nie stan tunelu.
Gdy softphone znajduje się za tunelem, nagłówek kontaktu może nieść adres prywatny. PBX, który przekazuje go do innego punktu końcowego, tworzy dialog skierowany do sieci, do której odbiorca nie może dotrzeć. Ustawienie rewrite_contact=yes w punkcie końcowym PJSIP powoduje, że PBX podstawia zaobserwowany adres źródłowy, i to często jest różnica między dzwonieniem a przekroczeniem czasu.
Co oferuje INVITE i kto może z niego korzystać
INVITE z ciałem SDP proponuje, gdzie dzwoniący chce odbierać media: adres, port i listę kodeków. Odbiorca odpowiada własnym adresem i portem, a następnie każda strona wysyła RTP do tego, co zaproponowała druga. Jeśli dzwoniący zaproponował adres 192.168.x.x, który istnieje tylko w jego sieci domowej, odbiorca nie ma gdzie wysłać dźwięku, niezależnie od tego, jak czysta była sygnalizacja. Maskowanie przepisuje nagłówki IP, gdy pakiety opuszczają router, ale nigdy nie przepisuje tekstu wewnątrz ciała SDP.
Ta luka wyjaśnia klasyczne połączenie jednokierunkowe: sygnalizacja działa, bo oba punkty końcowe docierają do PBX, a dźwięk zawodzi, bo jednemu punktowi kazano wysyłać na adres, który istnieje tylko za innym NAT.
| 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 |
Kto przenosi dźwięk, jest wyborem konfiguracji
Sygnalizacja i media to odrębne role. Proxy może pozostać na ścieżce sygnalizacji przez całe połączenie i nigdy nie dotknąć ani jednego pakietu RTP. To, czy PBX staje się przekaźnikiem mediów, zależy od konfiguracji, a nie od obecności tunelu.
Przy mediach bezpośrednich punkty końcowe same wymieniają RTP, co działa dobrze w jednym LAN, a źle, gdy jedna strona znajduje się za wąskim zakresem portów.
Ustawienie direct_media=no wpycha PBX na ścieżkę mediów, aby obie nogi kończyły się na adresie, który kontroluje, wymieniając przepustowość i procesor na przewidywalne adresowanie. Gdy przekazuje, PBX nadal musi ogłaszać osiągalny adres. Na hoście z wieloma sieciami external_media_address i external_signaling_address w pjsip.conf decydują, co pojawia się w SDP i w nagłówkach Via. Jeśli pozostawisz je nieustawione, PBX może zaproponować swój adres LAN dzwoniącemu, którego jedyną trasą jest dalsza strona tunelu.
Prześledź każdy kierunek, zanim dotkniesz ustawień
Zacznij od tabeli gniazd na PBX, gdy połączenie jest aktywne: ss -uanp | grep -E '5060|10000' pokazuje, czy porty RTP są powiązane i jakiego adresu lokalnego używają. Jeśli w zakresie mediów nic nie jest powiązane, przekaźnik nie jest zaangażowany, a punkty końcowe rozmawiają bezpośrednio. Następnie przechwyć po stronie softphone'a za pomocą tcpdump -ni any -s0 udp portrange 10000-20000 -w rtp.pcap. Pakiety wychodzące bez przychodzących zawężają problem do ścieżki powrotnej lub adresu, którego drugiej stronie kazano użyć, a puste przechwycenie oznacza, że media nigdy nie dotarły do interfejsu tunelu. Przechwycenie sygnalizacji za pomocą sngrep odpowiada na drugą połowę, pokazując linię połączenia SDP taką, jaka została wysłana.
Porównaj adres w tej linii połączenia z adresem, do którego druga strona naprawdę może routować. To jedno porównanie rozwiązuje większość zgłoszeń jednokierunkowego dźwięku szybciej niż jakikolwiek przegląd konfiguracji.
Szyfrowanie zatrzymuje się na krawędzi tunelu
SIP przez TLS chroni przeskok sygnalizacji, dla którego został skonfigurowany, SRTP chroni media, gdy obie strony to negocjują, a tunel chroni ruch między własnymi punktami końcowymi. Żaden z nich nie daje pozostałych. Połączenie szyfrowane wewnątrz tunelu może opuścić bramę jawnym tekstem w stronę PBX, i jest to decyzja projektowa, a nie defekt.
Przed zamknięciem zgłoszenia potwierdź trzy rzeczy po kolei: rejestracja jest świeża, SDP niesie adres, do którego druga strona może dotrzeć, a pakiety płyną w obu kierunkach na portach mediów. Jeśli któreś z nich jest nieprawdziwe, problem nie leży w tunelu. Napraw ścieżkę, która zawiodła, a następnie uruchom ponownie to samo przechwycenie, aby potwierdzić zmianę. Zachowanie przechwyceń sprzed i po zamienia następne zgłoszenie jednokierunkowego dźwięku w pięciominutowe sprawdzenie zamiast całego popołudnia.