VoIP mittels SIP ist ein komplexes Thema. Die Vielzahl von Parametern, die für eine funktionierende Kommunikation korrekt eingestellt werden müssen, sowie die Vielzahl der Beteiligten, ist erheblich. Man bedenke, welche Geräte „mitspielen“ müssen:
- der Router und die Firewall auf der Seite des Telefonanbieters,
- der eigene Router und die Firewall auf der Seite des Telefonierenden,
- evtl. die Telefonanlage auf des Seite des Telefonierenden und letztendlich
- das VoIP-Telefon auf der Seite des Telefonierenden.
Ggf. kommen noch weitere Geräte, z. B. SIP-Proxys, hinzu. Auch SIP ging bei der Entwicklung von einer „heilen Welt“ aus, in der die Geräte normalerweise alle erreichbar sind und nicht hinter NAT (Network Address Translation, der Router verbirgt das lokale Netzwerk hinter sich) verborgen sind und zusätzlich zu SIP selbst andere Ports im Verbindungsaufbau hinzu kommen: SIP ist das Session Initiating Protokoll, dient also zum Verbindungsaufbau. Die Verbindung selbst, also die Sprache, läuft getrennt ab, gleich zweimal einmal für die „eingehende Sprache“ und einmal für die „ausgehende Sprache“.
So kommt es in der Praxis häufig vor, dass man bei SIP nichts hört, der Gesprächspartner schon. Oder dass, umgekehrt, man selbst den Gesprächspartner hört, aber dieser einen nicht.
In den „Internetnormen“, den RFC (Request For Comments), sind die verschiedenen Konfigurationsmöglichkeiten aufgeführt. Wenn man nun weiß, wie die Gegenstelle konfiguriert ist, kann man die eigene Infrastruktur kompatibel einstellen und alles funktioniert, man kann miteinander sprechen.
Sehr ärgerlich ist es, wenn ein Provider seine Einstellungen ändert und den Kunden nicht informiert. Noch ärgerlicher ist es, wenn der Provider seine eigenen Einstellungen nicht veröffentlicht und die Techniker des Providers, die es wissen könnten, hermetisch von der Außenwelt abgeschnitten werden, also nicht zu erreichen sein. Dann hilft nur ausprobieren. Nach unserer Erfahrung gilt: je größer ein Anbieter, desto problematischer wird es.
Genug der Vorrede und Einführung, das konkrete Problem, das bei einem Kunden aufgetreten ist. Vielleicht hilft die Schilderung anderen ITlern, die plötzlich vor einem ähnlichen Verhalten stehen:
Von einem Tag auf den anderen Tag konnte der Kunde noch angerufen werden, aber nicht mehr raus telefonieren.
Was war geschehen? In der Telefonanlage des Kunden, eine FreePBX, also eine Asterisk-Telefonanlage, war keine Konfigurationsänderung und auch kein Update gemacht worden. Eine Übertragung der Einstellungen in eine baugleiche Anlage, ebenfalls an einem gleichen Telekom-Anschluss ergab: dort funktioniert es. Können dann die Einstellungen falsch sein? Nun betreibt die Telekom als sehr großer VoIP-Provider viele SIP-Server und verbirgt diese Server hinter Proxies. Nach welchen Kriterien den Kunden welche Proxies und welche SIP-Server zugeteilt werden, ist nach außen nicht bekannt. Unsere Vermutungen daher:
- Kunden werden relativ statisch zumindest einer identisch konfigurierten Proxygruppe zugeordnet und wir mit unserem Anschluss landen bei einer anderen Proxygruppe als der Kunde.
- Die Telekom hat die Konfiguration im Proxy oder in der dahinter liegenden Infrastruktur geändert.
Ein Anruf bei der Hotline führte, wie leider erwartet, nicht weiter. Der Tipp „starten sie das Gerät neu“ und der Hinweis „wenn sie kein Gerät von uns nutzen, können wir ihnen nicht helfen“ waren nicht förderlich.
Also die Analyse der Log-Dateien. Zusammengefasst: keine auf die Fehlerursache hindeutende Information.
Problemanalyse
Folglich: Wie fließen die Daten beim Verbindungsaufbau, was könnte sich geändert haben und wo ist der Unterschied bei eingehenden Gesprächen, die funktionierten, zu ausgehenden Gesprächen, die nicht funktionierten?
Die Überlegungen führten zu einem Routing-Problem der SIP-Meldungen. Auch bei VoIP-Telefonaten gibt es ein Routing. Die Endstelle spricht mit einem SIP-Server, der wiederum kommuniziert mit der nächsten Endstelle, ggf. aber auch mit einem weiteren SIP-Server, usw. Üblicherweise konfiguriert man in einem VoIP-Telefon (oder der eigenen VoIP-Telefonanlage) den SIP-Server, zu dem ausgehenden Gespräche geleitet werden sollen, und ggf. einen SIP-Proxy, der diesem Server vorgeschaltet ist und z. B. eine Lastverteilung macht. Die Telekom hat, in diesem Zusammenhang geschildert, vor einiger Zeit zur Lastverteilung auf DNS-SRV-Records umgestellt und die Kunden hierüber auch informiert. Im Gegensatz zur Ansprache eines SIP-Servers mittels DNS-A-Record ermöglicht der SRV-Record eine schnellere und feinere Lastverteilung.
Für das SIP-Routing gibt es zwei Prinzipien „strict“ und loose Routing. Strict Routing ist das ursprüngliche Verfahren. Die Route wird beim Gesprächsaufbau angegeben, d. h. im Endgerät ist eingetragen: Spreche eigentlich mit dem SIP-Server sip.xyz.de und nutze den Proxy sipproxy.xyz.de als Tor zum SIP-Server, der sich hinter dem sipproxy verbirgt.
Beim loose Routing wird das weitere Routing der Infrastruktur hinter dem ersten Proxy überlassen. Also im Endgerät ist eingetragen Spreche eigentlich mit dem SIP-Server sip.xyz.de und nutze den Proxy sipproxy.xyz.de als Tor zum SIP-Server, aber da könnte noch mehr hinter stecken, der sipproxy soll sich um den Folgeweg kümmern, den gebe ich als Endgerät nicht vor.
Leider muss die Routing-Methode im Endgerät eingestellt werden.
Das Fehlerverhalten deutete auch auf ein solches Problem im Routing hin: Bei eingehenden Gesprächen muss nicht mehr geroutet werden, das eigene Gerät ist das Ende, daher funktionieren diese. Bei ausgehenden Gesprächen wird jedoch auf jeden Fall geroutet. Wenn sich also im Protokoll etwas geändert hat, werden diese nicht mehr funktionieren.
Die Lösung: SIP-Routing-Methode umstellen
Also haben wir bei dem PJSIP-Channel, der in der Asterisk-Anlage für die SIP-Telefonie genutzt wird, das Routing-Protokoll von strict auf loose geändert. Hierzu wird hinter der URL des Proxy in der Bedienoberfläche die Zeichenkette „\;lr“ angehängt (ohne Anführungszeichen). Der Parameter selbst ist das „lr“ (für loose routing). Das Semikolon trennt den Parameter von der Proxy-Adresse und der Backslash „\“ ist notwendig, da das Semikolon in der Konfiguration eigentlich als Kommentareinleitung dient. Der Backslash teilt also mit, dass kein Kommentar folgt sondern das Semikolon als Semikolon betrachtet werden soll.
Und tatsächlich, nach der Aktivierung dieser Anpassung funktionierte die Telefonie wieder in beiden Richtungen.