Waarom een SIP-gesprek zich via een VPN registreert maar geen audio verstuurt
Registratie en audio volgen verschillende paden. Volg één gesprek door de tunnel om te zien welke adressen de PBX kan gebruiken en waar RTP echt stopt.
Een geslaagde registratie zegt bijna niets over audio. Een softphone kan urenlang een geldige binding met de PBX van kantoor houden en toch stilte leveren. De tunnel draagt alleen de pakketten die iemand er bewust in stuurt, en een gesprek gebruikt drie afzonderlijke paden: de binding, het opzetten van de dialoog en de RTP-stroom. Zodra je die scheidt, valt de fout op één pad in plaats van op het woord VPN.
Stel je een laptop op thuis-Wi-Fi voor die via een goedgekeurde tunnel een kantoorextensie belt. De PBX authenticeert de gebruiker, accepteert het REGISTER en de extensie verschijnt als beschikbaar, maar toch komt het gesprek tot stand met doodse stilte in één richting.
Registratie bindt een contact, geen mediapad
Een REGISTER-verzoek vraagt de registrar om een koppeling op te slaan tussen een adres-van-record en een of meer contact-URI's. Die koppeling beantwoordt een smalle vraag: waar een nieuwe dialoog nu naartoe moet. Ze zegt niets over waar media thuishoort, en een geaccepteerde registratie bewijst niet dat een later INVITE een bereikbaar media-adres draagt. Registraties verlopen ook op een timer, dus een telefoon die stopt met vernieuwen verliest inkomende gesprekken terwijl de tunnel er nog gezond uitziet. Let op het verlopen van het contact, niet op de tunnelstatus.
Wanneer de softphone achter de tunnel zit, kan de contact-header een privéadres dragen. Een PBX die hem doorstuurt naar een ander eindpunt maakt een dialoog die op een netwerk is gericht dat de gebelde niet kan bereiken. rewrite_contact=yes instellen op het PJSIP-eindpunt laat de PBX het waargenomen bronadres vervangen, en dat is vaak het verschil tussen een ring en een time-out.
Wat het INVITE biedt en wie het kan gebruiken
Een INVITE met een SDP-body stelt voor waar de beller media wil ontvangen: een adres, een poort en een codelijst. De gebelde antwoordt met zijn eigen adres en poort, en daarna stuurt elke kant RTP naar wat de ander voorstelde. Als de beller een 192.168.x.x-adres voorstelt dat alleen binnen zijn thuisnetwerk bestaat, heeft de gebelde nergens om audio naartoe te sturen, hoe schoon de signalering ook was. Maskering herschrijft IP-headers wanneer pakketten een router verlaten, maar ze herschrijft nooit de tekst in een SDP-body.
Dat gat verklaart het klassieke eenrichtingsgesprek: signalering werkt omdat beide eindpunten de PBX bereiken, en audio faalt omdat één eindpunt te horen kreeg te sturen naar een adres dat alleen achter een andere NAT bestaat.
| 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 |
Wie de audio draagt is een configuratiekeuze
Signalering en media zijn gescheiden rollen. Een proxy kan een heel gesprek op het signaleringspad blijven en nooit één RTP-pakket aanraken. Of de PBX een mediarelay wordt, hangt van de configuratie af, niet van de aanwezigheid van een tunnel.
Bij directe media wisselen de eindpunten zelf RTP uit, wat goed werkt op één LAN en slecht wanneer één kant achter een smal poortbereik zit.
direct_media=no instellen dwingt de PBX in het mediapad zodat beide benen eindigen op een adres dat hij beheert, wat bandbreedte en CPU inruilt voor voorspelbare adressering. Tijdens het relayen moet de PBX nog steeds een bereikbaar adres aankondigen. Op een multi-homed host bepalen external_media_address en external_signaling_address in pjsip.conf wat in de SDP en in Via-headers verschijnt. Laat je ze oningesteld, dan kan de PBX zijn LAN-adres aanbieden aan een beller wiens enige route de verre kant van de tunnel is.
Volg elke richting voordat je instellingen aanraakt
Begin met de sockettabel op de PBX terwijl een gesprek actief is: ss -uanp | grep -E '5060|10000' laat zien of RTP-poorten gebonden zijn en welk lokaal adres ze gebruiken. Als er niets in het mediagebied is gebonden, is de relay niet actief en praten de eindpunten rechtstreeks. Leg daarna vast aan de softphone-kant met tcpdump -ni any -s0 udp portrange 10000-20000 -w rtp.pcap. Uitgaande pakketten zonder inkomende pakketten vernauwen het probleem tot het retourpad of tot het adres dat de verre kant te horen kreeg te gebruiken, en een lege opname betekent dat media het tunnelinterface nooit hebben bereikt. Een signaleringsopname met sngrep beantwoordt de andere helft door de SDP-verbindingsregel te tonen zoals hij verzonden is.
Vergelijk het adres in die verbindingsregel met het adres waar de verre kant echt naartoe kan routeren. Die ene vergelijking lost de meeste eenrichtingsaudio meldingen sneller op dan welke configuratiereview dan ook.
Versleuteling stopt bij de rand van de tunnel
SIP over TLS beschermt de signaleringssprong waarvoor het is geconfigureerd, SRTP beschermt media wanneer beide kanten het onderhandelen, en de tunnel beschermt verkeer tussen zijn eigen eindpunten. Geen van die geeft de andere. Een gesprek dat in de tunnel versleuteld is, kan de gateway in platte tekst richting PBX verlaten, en dat is een ontwerpkeuze, geen defect.
Voordat je het ticket sluit, bevestig je drie dingen in volgorde: de registratie is vers, de SDP draagt een adres dat de verre kant kan bereiken, en pakketten stromen beide kanten op over de mediapoorten. Als een daarvan onjuist is, zit het probleem niet in de tunnel. Repareer het pad dat faalde en voer daarna dezelfde opname opnieuw uit om de wijziging te bevestigen. De opnames van voor en na bewaren maakt van de volgende eenrichtingsmelding een controle van vijf minuten in plaats van een hele middag.