Warum ein SIP-Anruf über ein VPN registriert wird, aber kein Audio sendet

Eine erfolgreiche Registrierung verrät fast nichts über Audio. Ein Softphone kann stundenlang eine gültige Bindung an die Büro-PBX halten und trotzdem Stille liefern. Der Tunnel trägt nur die Pakete, die jemand bewusst hineinschickt, und ein Anruf nutzt drei getrennte Wege: Bindung, Dialogaufbau und den RTP-Stream. Sobald man diese trennt, landet der Fehler auf einem Weg statt auf dem Wort VPN.

Stellen Sie sich einen Laptop im Heim-WLAN vor, der über einen genehmigten Tunnel eine Bürodurchwahl wählt. Die PBX authentifiziert den Benutzer, akzeptiert das REGISTER, und die Durchwahl erscheint als verfügbar, doch der Anruf kommt mit Totenstille in einer Richtung zustande.

Registrierung bindet einen Kontakt, keinen Medienpfad

Eine REGISTER-Anfrage bittet den Registrar, eine Zuordnung zwischen einer Adresse-of-Record und einem oder mehreren Kontakt-URIs zu speichern. Diese Zuordnung beantwortet eine enge Frage: wohin ein neuer Dialog gerade jetzt gesendet werden soll. Sie sagt nichts darüber, wohin Medien gehören, und eine akzeptierte Registrierung beweist nicht, dass ein späteres INVITE eine erreichbare Medienadresse trägt. Registrierungen laufen zudem per Timer ab, sodass ein Telefon, das das Auffrischen einstellt, eingehende Anrufe verliert, während sein Tunnel noch gesund aussieht. Beobachten Sie den Ablauf des Kontakts statt den Tunnelstatus.

Wenn das Softphone hinter dem Tunnel sitzt, kann der Kontakt-Header eine private Adresse tragen. Eine PBX, die ihn an einen anderen Endpunkt weiterleitet, erzeugt einen Dialog, der auf ein Netz zeigt, das der Angerufene nicht erreichen kann. rewrite_contact=yes am PJSIP-Endpunkt setzt die beobachtete Quelladresse ein, und das ist oft der Unterschied zwischen einem Klingeln und einem Timeout.

Was das INVITE anbietet und wer es nutzen kann

Ein INVITE mit SDP-Body schlägt vor, wo der Anrufer Medien empfangen möchte: eine Adresse, einen Port und eine Codec-Liste. Der Angerufene antwortet mit eigener Adresse und eigenem Port, und danach sendet jede Seite RTP an das, was die andere vorgeschlagen hat. Hat der Anrufer eine 192.168.x.x-Adresse vorgeschlagen, die nur im eigenen Heimnetz existiert, hat der Angerufene keinen Ort, an den er Audio senden kann, so sauber die Signalisierung auch war. Maskerading schreibt IP-Header um, wenn Pakete einen Router verlassen, aber es schreibt nie den Text innerhalb eines SDP-Bodys um.

Diese Lücke erklärt den klassischen Einweg-Anruf: Die Signalisierung funktioniert, weil beide Endpunkte die PBX erreichen, und Audio scheitert, weil einem Endpunkt gesagt wurde, er solle an eine Adresse senden, die nur hinter einem anderen NAT existiert.

Wer das Audio trägt, ist eine Konfigurationsentscheidung

Signalisierung und Medien sind getrennte Rollen. Ein Proxy kann einen ganzen Anruf lang auf dem Signalisierungspfad bleiben und nie ein einziges RTP-Paket berühren. Ob die PBX zum Medienrelay wird, hängt von der Konfiguration ab, nicht von der Existenz eines Tunnels.

Bei direkten Medien tauschen die Endpunkte RTP selbst aus, was in einem LAN gut und schlecht funktioniert, wenn eine Seite hinter einem engen Portbereich sitzt.

direct_media=no zwingt die PBX in den Medienpfad, sodass beide Beine auf einer von ihr kontrollierten Adresse enden, was Bandbreite und CPU gegen vorhersagbare Adressierung tauscht. Wenn sie weiterleitet, muss die PBX dennoch eine erreichbare Adresse ankündigen. Auf einem Multi-Homed-Host entscheiden external_media_address und external_signaling_address in pjsip.conf, was in SDP und in Via-Headern erscheint. Bleiben sie ungesetzt, kann die PBX ihre LAN-Adresse einem Anrufer anbieten, dessen einziger Weg die fernere Seite des Tunnels ist.

Verfolgen Sie jede Richtung, bevor Sie Einstellungen anfassen

Beginnen Sie mit der Socket-Tabelle auf der PBX, während ein Anruf aktiv ist: ss -uanp | grep -E '5060|10000' zeigt, ob RTP-Ports gebunden sind und welche lokale Adresse sie verwenden. Ist im Medienbereich nichts gebunden, ist das Relay nicht beteiligt und die Endpunkte sprechen direkt. Nehmen Sie dann auf der Softphone-Seite mit tcpdump -ni any -s0 udp portrange 10000-20000 -w rtp.pcap auf. Ausgehende Pakete ohne eingehende verengen das Problem auf den Rückweg oder auf die Adresse, die dem fernen Ende genannt wurde, und eine leere Aufnahme bedeutet, dass Medien die Tunnelschnittstelle nie erreicht haben. Eine Signalisierungsaufnahme mit sngrep beantwortet die andere Hälfte, indem sie die SDP-Verbindungszeile so zeigt, wie sie gesendet wurde.

Vergleichen Sie die Adresse in dieser Verbindungszeile mit der Adresse, zu der das ferne Ende tatsächlich routen kann. Dieser eine Vergleich löst die meisten Einweg-Audio-Berichte schneller als jede Konfigurationsprüfung.

Verschlüsselung endet am Tunnelrand

SIP über TLS schützt den Signalisierungssprung, für den es konfiguriert wurde, SRTP schützt Medien, wenn beide Seiten es aushandeln, und der Tunnel schützt den Verkehr zwischen seinen eigenen Endpunkten. Keines davon gewährt die anderen. Ein Anruf, der im Tunnel verschlüsselt ist, kann das Gateway im Klartext Richtung PBX verlassen, und das ist eine Designentscheidung, kein Defekt.

Bevor Sie das Ticket schließen, bestätigen Sie drei Dinge der Reihe nach: Die Registrierung ist frisch, der SDP-Body trägt eine Adresse, die das ferne Ende erreichen kann, und Pakete fließen in beide Richtungen über die Medienports. Ist eines davon falsch, liegt das Problem nicht im Tunnel. Beheben Sie den Weg, der versagt hat, und wiederholen Sie dann dieselbe Aufnahme, um die Änderung zu bestätigen. Behält man die Aufnahmen vorher und nachher, wird der nächste Einweg-Bericht zu einer Fünf-Minuten-Prüfung statt zu einem ganzen Nachmittag.