Hvorfor en SIP-samtale registreres over en VPN, men ikke sender lyd
Registrering og lyd følger ulike veier. Følg én samtale gjennom tunnelen for å se hvilke adresser PBX-en kan bruke, og hvor RTP faktisk stopper.
En vellykket registrering forteller nesten ingenting om lyd. En softphone kan i timer holde en gyldig binding til kontorets PBX og likevel levere stillhet. Tunnelen bærer bare pakkene som noen bevisst sender inn i den, og en samtale bruker tre separate veier: binding, dialogoppsett og RTP-strømmen. Når du skiller dem, lander feilen på én vei i stedet for på ordet VPN.
Se for deg en bærbar PC på hjemmets Wi-Fi som ringer en kontorforlengelse gjennom en godkjent tunnel. PBX-en autentiserer brukeren, godtar REGISTER, og forlengelsen vises som tilgjengelig, men likevel kobles samtalen opp med død luft i én retning.
Registrering binder en kontakt, ikke en medievei
En REGISTER-forespørsel ber registraren lagre en mapping mellom en adresse-på-post og én eller flere kontakt-URI-er. Den mappingen svarer på et smalt spørsmål om hvor en ny dialog skal sendes akkurat nå. Den sier ingenting om hvor medier hører hjemme, og en godtatt registrering beviser ikke at en senere INVITE bærer en nåbar medieadresse. Registreringer utløper også på en timer, så en telefon som slutter å fornye, mister innkommende samtaler mens tunnelen fortsatt ser sunn ut. Følg med på kontaktens utløp i stedet for tunnelens status.
Når softphonen sitter bak tunnelen, kan kontakt-headeren bære en privat adresse. En PBX som videresender den til et annet endepunkt, lager en dialog rettet mot et nettverk den oppringte ikke kan nå. Å sette rewrite_contact=yes på PJSIP-endepunktet får PBX-en til å erstatte kildeadressen den observerte, og det er ofte forskjellen på en ringetone og en timeout.
Hva INVITE tilbyr, og hvem som kan bruke det
En INVITE med SDP-body foreslår hvor den som ringer vil motta medier: en adresse, en port og en kodekliste. Den oppringte svarer med sin egen adresse og port, og deretter sender hver side RTP til det den andre foreslo. Hvis den som ringer foreslo en 192.168.x.x-adresse som bare finnes på hjemmenettet, har den oppringte ingen steder å sende lyd, uansett hvor ren signaleringen var. Maskering skriver om IP-headere når pakker forlater en ruter, men den skriver aldri om teksten inne i en SDP-body.
Dette gapet forklarer den klassiske enveissamtalen: signaleringen virker fordi begge endepunktene når PBX-en, og lyden feiler fordi det ene endepunktet ble bedt om å sende til en adresse som bare finnes bak en annen 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 |
Hvem som bærer lyden, er et konfigurasjonsvalg
Signalering og medier er atskilte roller. En proxy kan bli på signaleringsveien gjennom en hel samtale og aldri røre en eneste RTP-pakke. Om PBX-en blir en medierelay, avhenger av konfigurasjonen, ikke av om det finnes en tunnel.
Med direkte medier utveksler endepunktene RTP selv, noe som fungerer godt på ett LAN og dårlig når den ene siden sitter bak et smalt portområde.
Å sette direct_media=no tvinger PBX-en inn på medieveien slik at begge bena terminerer på en adresse den kontrollerer, og bytter båndbredde og CPU mot forutsigbar adressering. Når den relayer, må PBX-en fortsatt annonsere en nåbar adresse. På en multi-homed vert avgjør external_media_address og external_signaling_address i pjsip.conf hva som vises i SDP og i Via-headere. Lar du dem stå usatt, kan PBX-en tilby LAN-adressen sin til en som ringer og hvis eneste rute er tunnelens fjerne side.
Følg hver retning før du rører innstillinger
Start med socket-tabellen på PBX-en mens en samtale er aktiv: ss -uanp | grep -E '5060|10000' viser om RTP-porter er bundet og hvilken lokal adresse de bruker. Hvis ingenting er bundet i medieområdet, er relayen ikke aktivert, og endepunktene snakker direkte. Ta deretter opptak på softphone-siden med tcpdump -ni any -s0 udp portrange 10000-20000 -w rtp.pcap. Utgående pakker uten innkommende pakker snevrer problemet inn til returveien eller til adressen den fjerne siden ble bedt om å bruke, og et tomt opptak betyr at medier aldri nådde tunnelgrensesnittet. Et signaleringsopptak med sngrep svarer på den andre halvdelen ved å vise SDP-forbindelseslinjen slik den ble sendt.
Sammenlign adressen i den forbindelseslinjen med adressen den fjerne siden faktisk kan rute til. Den ene sammenligningen løser de fleste enveislydrapporter raskere enn noen konfigurasjonsgjennomgang.
Kryptering stopper ved tunnelkanten
SIP over TLS beskytter signaleringshoppet det er konfigurert for, SRTP beskytter medier når begge ender forhandler om det, og tunnelen beskytter trafikk mellom sine egne endepunkter. Ingen av dem gir de andre. En samtale som er kryptert inne i tunnelen, kan forlate gatewayen i klartekst mot PBX-en, og det er et designvalg, ikke en feil.
Før du lukker saken, bekreft tre ting i rekkefølge: registreringen er fersk, SDP-en bærer en adresse den fjerne siden kan nå, og pakker flyter begge veier på medieportene. Hvis noe av dette er usant, er ikke tunnelen der problemet bor. Rett veien som feilet, og kjør deretter det samme opptaket på nytt for å bekrefte endringen. Lagrer du opptakene fra før og etter, blir den neste enveisrapporten en femminutters sjekk i stedet for en hel ettermiddag.