Varför ett SIP-samtal registreras över en VPN men inte skickar ljud
Registrering och ljud följer olika vägar. Följ ett samtal genom tunneln för att se vilka adresser PBX:en kan använda och var RTP faktiskt stannar.
En lyckad registrering säger nästan ingenting om ljud. En softphone kan i timmar hålla en giltig bindning till kontorets PBX och ändå leverera tystnad. Tunneln bär bara de paket som någon medvetet skickar in i den, och ett samtal använder tre separata vägar: bindningen, dialoguppsättningen och RTP-strömmen. När du skiljer dem åt landar felet på en väg i stället för på ordet VPN.
Tänk dig en bärbar dator på hemmets Wi-Fi som ringer en kontorsanknytning genom en godkänd tunnel. PBX:en autentiserar användaren, accepterar REGISTER och anknytningen visas som tillgänglig, men ändå kopplas samtalet upp med död luft i en riktning.
Registrering binder en kontakt, inte en medieväg
En REGISTER-begäran ber registraren lagra en mappning mellan en adress-på-post och en eller flera kontakt-URI:er. Den mappningen svarar på en snäv fråga om vart en ny dialog ska skickas just nu. Den säger ingenting om var medier hör hemma, och en accepterad registrering bevisar inte att en senare INVITE bär en nåbar medieadress. Registreringar löper också ut på en timer, så en telefon som slutar förnya tappar inkommande samtal medan dess tunnel fortfarande ser frisk ut. Håll koll på kontaktens utgång i stället för tunnelns status.
När softphonen sitter bakom tunneln kan kontakt-headern bära en privat adress. En PBX som vidarebefordrar den till en annan ändpunkt skapar en dialog riktad mot ett nätverk som den uppringda inte kan nå. Att sätta rewrite_contact=yes på PJSIP-ändpunkten får PBX:en att ersätta den källadress den observerade, och det är ofta skillnaden mellan en ringsignal och en timeout.
Vad INVITE erbjuder och vem som kan använda det
En INVITE med SDP-body föreslår var den som ringer vill ta emot medier: en adress, en port och en kodeklista. Den uppringda svarar med sin egen adress och port, och sedan skickar varje sida RTP till det den andra föreslog. Om den som ringer föreslog en 192.168.x.x-adress som bara finns på hemnätverket har den uppringda ingenstans att skicka ljud, hur ren signaleringen än var. Maskering skriver om IP-headers när paket lämnar en router, men den skriver aldrig om texten inuti en SDP-body.
Det gapet förklarar det klassiska enkelriktade samtalet: signaleringen fungerar eftersom båda ändpunkterna når PBX:en, och ljudet misslyckas eftersom en ändpunkt blev tillsagd att skicka till en adress som bara finns bakom en annan 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 |
Vem som bär ljudet är ett konfigurationsval
Signalering och medier är separata roller. En proxy kan stanna på signaleringsvägen under ett helt samtal och aldrig röra ett enda RTP-paket. Om PBX:en blir en medierelay beror på konfigurationen, inte på om det finns en tunnel.
Med direkta medier utbyter ändpunkterna RTP själva, vilket fungerar bra på ett LAN och dåligt när en sida sitter bakom ett smalt portområde.
Att sätta direct_media=no tvingar PBX:en in på medievägen så att båda benen terminerar på en adress den kontrollerar, och byter bandbredd och CPU mot förutsägbar adressering. När den reläar måste PBX:en ändå annonsera en nåbar adress. På en multi-homed värd avgör external_media_address och external_signaling_address i pjsip.conf vad som visas i SDP och i Via-headers. Lämnar du dem oinställda kan PBX:en erbjuda sin LAN-adress till en som ringer och vars enda väg är tunnelns bortre sida.
Följ varje riktning innan du rör inställningarna
Börja med socket-tabellen på PBX:en medan ett samtal är aktivt: ss -uanp | grep -E '5060|10000' visar om RTP-portar är bundna och vilken lokal adress de använder. Om ingenting är bundet i medieområdet är relayen inte aktiverad och ändpunkterna talar direkt. Fånga sedan på softphone-sidan med tcpdump -ni any -s0 udp portrange 10000-20000 -w rtp.pcap. Utgående paket utan inkommande paket snävar in problemet till returvägen eller till adressen den bortre sidan blev tillsagd att använda, och en tom fångst betyder att medier aldrig nådde tunnelgränssnittet. En signaleringsfångst med sngrep svarar på den andra halvan genom att visa SDP-anslutningsraden sådan den skickades.
Jämför adressen i den anslutningsraden med adressen som den bortre sidan faktiskt kan routa till. Den enda jämförelsen löser de flesta enkelriktade ljudrapporter snabbare än någon konfigurationsgenomgång.
Kryptering stannar vid tunnelkanten
SIP över TLS skyddar det signaleringshopp det är konfigurerat för, SRTP skyddar medier när båda ändar förhandlar om det, och tunneln skyddar trafik mellan sina egna ändpunkter. Ingen av dem ger de andra. Ett samtal som är krypterat inne i tunneln kan lämna gatewayen i klartext mot PBX:en, och det är ett designval, inte en brist.
Innan du stänger ärendet, bekräfta tre saker i ordning: registreringen är färsk, SDP:n bär en adress som den bortre sidan kan nå, och paket flödar båda vägarna på medieportarna. Om något av detta är falskt är det inte i tunneln problemet bor. Rätta vägen som misslyckades och kör sedan om samma fångst för att bekräfta ändringen. Sparar du fångsterna före och efter blir nästa enkelriktade rapport en femminuterskontroll i stället för en hel eftermiddag.