„Telefon geht nicht“ – warum die Störungssuche bei VoIP so knifflig ist

„Telefon geht nicht.“

Diesen Satz lese ich in meinem Berufsalltag ziemlich oft. Und so verständlich er ist: Für die Fehlersuche ist er ungefähr so hilfreich wie „Auto macht komisches Geräusch“ für die Werkstatt.

Ich arbeite im technischen Support für Telefonie über das Internet, also VoIP. In diesem Beitrag erzähle ich, warum die Auswertung einer Störung manchmal Minuten und manchmal Tage dauert. Was man dabei alles im Blick haben muss. Und warum wir Supporter so hartnäckig nach Callbeispielen fragen.

Ein Telefonat geht durch viele Hände

Früher war Telefonie eine Leitung: Kupfer rein, Kupfer raus. Heute ist ein Telefonat eine Kette aus vielen Gliedern, und jedes kann der Schuldige sein.

• Das Endgerät: Tischtelefon, Softclient am PC, DECT-Basis
• Die TK-Anlage: mit ihrer Konfiguration, ihrer Firmware, ihren Eigenheiten
• Der Router: NAT, Firewall und manchmal ein „hilfreicher“ SIP-ALG
• Der Anschluss: Bandbreite, Auslastung, Paketverlust
• Der Provider: Session Border Controller, Plattform, Routing
• Die Gegenstelle: ein anderes Netz, Mobilfunk, Ausland, eine Hotline mit eigener Anlage

Dazu kommt eine Eigenheit von VoIP, die viele überrascht: Signalisierung und Sprache sind zwei verschiedene Dinge. SIP baut das Gespräch auf, verhandelt und beendet es. Die eigentliche Sprache läuft getrennt davon über RTP, auf anderen Ports und manchmal sogar über andere Wege. Ein Gespräch kann also perfekt aufgebaut werden und trotzdem stumm bleiben.

Warum es ohne Callbeispiele kaum geht

Stellen wir uns vor, über eine Plattform laufen pro Tag sehr viele Gespräche. Darunter ist eines von dir, das schiefging. Mit „Telefon geht manchmal nicht“ suchen wir die sprichwörtliche Nadel im Heuhaufen.

Mit einem konkreten Beispiel sieht das ganz anders aus. Dann können wir genau dieses eine Gespräch in den Protokollen finden, uns die Signalisierung ansehen, im besten Fall einen Mitschnitt ziehen und sehen, an welcher Stelle es knirscht.

Ein gutes Callbeispiel enthält:

Und am besten nicht nur ein Beispiel, sondern zwei oder drei. Erst mehrere Fälle zeigen ein Muster: Betrifft es nur Mobilfunknummern? Nur Anrufe ins Ausland? Immer nach genau 30 Sekunden?

Noch ein wichtiger Punkt: Zeitnah melden. Protokolle und Verbindungsdaten werden aus Datenschutzgründen nur begrenzt aufbewahrt. Ein Beispiel von vor drei Wochen ist oft schlicht nicht mehr nachvollziehbar.

Schlechtes Beispiel: „Seit letzter Woche brechen manchmal Gespräche ab.“

Gutes Beispiel: „Heute, 10:42 Uhr, ausgehend von 0421 xxxx-100 nach 0170 xxxxxxx, Gespräch nach ca. 30 Sekunden getrennt. Gleiches um 11:15 Uhr nach 0151 xxxxxxx.“

Der Unterschied: Beim ersten fangen wir an zu raten. Beim zweiten fangen wir an zu messen.

Das Symptom verrät oft schon die Richtung

Mit der Zeit entwickelt man ein Gefühl dafür, welches Symptom typischerweise welche Ursache hat. Eine kleine Übersicht aus der Praxis:

Der Abbruch nach rund 30 Sekunden ist übrigens ein schöner Klassiker. Das ist kein Zufall: Wer ein Gespräch annimmt, schickt ein „200 OK“ und wartet auf die Bestätigung (ACK). Kommt die nicht, wird das 200 OK wiederholt, insgesamt etwa 32 Sekunden lang. Danach gibt die Gegenseite auf und legt auf. Wer „immer nach einer halben Minute weg“ meldet, hat damit schon die halbe Diagnose geliefert.

NAT: der Dauergast

Wenn ich eine Hitliste der Störungsursachen aufstellen müsste, stünde NAT ganz oben. Und das hat einen einfachen Grund.

Fast jede TK-Anlage steht in einem privaten Netz hinter einem Router. Der Router übersetzt die private Adresse in seine öffentliche Adresse, das ist NAT. Das funktioniert wunderbar für Webseiten. Bei SIP gibt es aber ein Problem: SIP schreibt IP-Adressen in den Inhalt seiner Nachrichten. Im SDP-Teil steht drin, wohin die Gegenseite die Sprache schicken soll.

Der Router übersetzt die Adresse im Kopf des Pakets, aber nicht die Adresse, die im Text der Nachricht steht. Steht dort die private Adresse der Anlage, schickt der Provider die Sprache an eine Adresse, die im Internet niemand zustellen kann. Das Gespräch wird aufgebaut, das Telefon klingelt, man nimmt ab – und einer hört nichts.

Was bei NAT richtig eingestellt sein muss

• Die öffentliche IP-Adresse in der Anlage. Die meisten Anlagen haben ein Feld für „externe IP“, „öffentliche Adresse“ oder „NAT-Adresse“. Ist das leer oder falsch, landet die private Adresse im SDP.
• Die lokalen Netze in der Anlage. Die Anlage muss wissen, welche Adressen „drinnen“ sind, damit sie intern nicht unnötig übersetzt.
• Keepalives kürzer als der NAT-Timeout. Router vergessen UDP-Verbindungen oft schon nach 30 bis 180 Sekunden. Wenn die Anlage sich nur alle 60 Minuten meldet, ist der Weg nach innen zwischendurch zu. Eingehende Anrufe kommen dann einfach nicht an. Abhilfe: kurze Registrierungsintervalle oder regelmäßige Keepalives (z. B. SIP OPTIONS).
• RTP-Ports. Je nach Aufbau müssen die RTP-Ports der Anlage freigegeben oder weitergeleitet werden. Bei vielen Anbietern reicht symmetrisches RTP, die Anlage sendet also zuerst, und der Rückweg öffnet sich von selbst.

SIP-ALG: gut gemeint, schlecht gemacht

Viele Router haben eine Funktion namens SIP-ALG (Application Layer Gateway). Die Idee: Der Router schaut in die SIP-Nachrichten hinein und korrigiert die Adressen gleich mit. In der Theorie genau die Lösung für das Problem oben.

In der Praxis macht der SIP-ALG leider oft mehr kaputt als heil: Er schreibt Adressen falsch um, verändert Ports, bricht Nachrichten oder kommt mit verschlüsselter Signalisierung nicht klar. Typische Folgen sind einseitige Sprache, Abbrüche nach 30 Sekunden oder Registrierungen, die mal klappen und mal nicht.

Meine Faustregel: Wenn die Anlage NAT selbst richtig beherrscht, SIP-ALG im Router ausschalten. Bei einigen Routern heißt die Option anders, versteckt sich in Expertenmenüs oder lässt sich nur per Kommandozeile deaktivieren. Es lohnt sich trotzdem, sie zu suchen.

Wie ich eine Störung auswerte

Wenn ein gutes Callbeispiel da ist, gehe ich ungefähr so vor:

1. Den Anruf finden. Anhand von Zeit, Nummern und Richtung den passenden Dialog heraussuchen.
2. Den Ablauf als Leiter betrachten. INVITE, 100 Trying, 183 oder 180, 200 OK, ACK, BYE. Fehlt etwas? Kommt etwas doppelt? Wer schickt was wann?
3. Den SDP vergleichen. Welche IP-Adressen und Ports werden angeboten, welche Codecs? Passt das zu dem, was im Netz tatsächlich ankommt?
4. Die Sprachströme ansehen. Gibt es RTP in beide Richtungen? Von welcher Adresse kommt es wirklich? Wie hoch sind Paketverlust und Jitter?
5. Das Ende ansehen. Wer hat aufgelegt, mit welchem SIP-Code und welchem Grund? Der Q.850-Code im Reason-Header verrät oft mehr als der SIP-Code selbst, zum Beispiel 16 für ein normales Auflegen, 17 für besetzt, 31 oder 41 für allgemeine Fehler.
6. Mit anderen Fällen vergleichen. Erst wenn sich ein Muster über mehrere Beispiele bestätigt, ist die Ursache wirklich gefunden.

Wer selbst mitschneiden möchte, kann das mit Wireshark oder auf der Kommandozeile mit tshark tun. Wichtig ist dabei, an der richtigen Stelle mitzuschneiden. Ein Mitschnitt auf der Anlage zeigt die private Seite, einer am Router die öffentliche. Manchmal braucht man beide, um den Übersetzungsfehler zu sehen.

# SIP und RTP auf dem Interface der Anlage mitschneiden
sudo tshark -i eth0 -f "udp port 5060 or udp portrange 10000-20000" -w stoerung.pcapng

Die Ports sind dabei nur Beispiele. Welche genau gebraucht werden, steht in der Konfiguration der Anlage.

Eine Bitte an alle, die eine Störung melden

Fehlersuche bei VoIP ist Teamarbeit. Der Satz „Das liegt am Provider“ ist genauso wenig hilfreich wie „Das liegt an Ihrer Anlage“. Beides kann stimmen, aber nur Belege entscheiden.

Was die Suche am meisten beschleunigt:

• Konkrete Callbeispiele, mehrere, zeitnah
• Eine kurze Beschreibung des Symptoms, möglichst genau: wer hört was nicht, nach wie vielen Sekunden bricht es ab
• Infos zur Umgebung: welche Anlage, welcher Router, was wurde zuletzt geändert?
• Wenn möglich einen Mitschnitt von der Anlage

Und wenn sich herausstellt, dass es doch die eigene Router-Einstellung war: kein Grund für Verlegenheit. Das passiert den Besten. Hauptsache, das Telefon klingelt wieder.

Ein Hinweis: Die IP-Adressen in diesem Beitrag stammen aus Bereichen, die extra für Dokumentationen reserviert sind. Rufnummern sind unkenntlich gemacht.

Passend dazu auf der Frickelfabrik:

• SIP-Spickzettel: Antwortcodes und Q.850-Causes zum Nachschlagen
• SIP-Traces lesen lernen: das Wireshark-Tutorial mit zwei Beispiel-Mitschnitten
• Fax über SIP: warum es hakt und was als Erste Hilfe hilft
• S2M vs. SIP-Trunk: was sich beim Umstieg wirklich ändert
• Warum die Rufnummer lügt: CLIP no screening, Spoofing und was die Anzeige bedeutet
• Voice-Diagnose: PCAP rein, Befund raus
• Mein Rasenmäher hat keine IP-Adresse: Fehlersuche nach der 2nd-Level-Methode

Trace lesen lassen statt selbst grübeln: Lade deinen SIP-/VoIP-Mitschnitt bei der Pcap-Diagnose hoch und bekomme eine klare technische Einschätzung zurück — wo es hakt, auf welcher Seite, was der nächste Schritt ist. Die erste Analyse pro E-Mail-Adresse ist kostenlos.