{"id":1849,"date":"2022-04-07T15:47:55","date_gmt":"2022-04-07T14:47:55","guid":{"rendered":"https:\/\/blog.imagmbh.de\/?p=1849"},"modified":"2022-04-12T14:02:54","modified_gmt":"2022-04-12T13:02:54","slug":"semikolon-lr-telekom-sip-und-loose-routing","status":"publish","type":"post","link":"https:\/\/blog.imagmbh.de\/index.php\/semikolon-lr-telekom-sip-und-loose-routing\/","title":{"rendered":"Semikolon lr &#8211; Telekom, SIP und loose Routing"},"content":{"rendered":"\n<p>VoIP mittels SIP ist ein komplexes Thema. Die Vielzahl von Parametern, die f\u00fcr eine funktionierende Kommunikation korrekt eingestellt werden m\u00fcssen, sowie die Vielzahl der Beteiligten, ist erheblich. Man bedenke, welche Ger\u00e4te &#8222;mitspielen&#8220; m\u00fcssen:<\/p>\n\n\n\n<ul class=\"wp-block-list\"><li>der Router und die Firewall auf der Seite des Telefonanbieters,<\/li><li>der eigene Router und die Firewall auf der Seite des Telefonierenden,<\/li><li>evtl. die Telefonanlage auf des Seite des Telefonierenden und letztendlich<\/li><li>das VoIP-Telefon auf der Seite des Telefonierenden.<\/li><\/ul>\n\n\n\n<p>Ggf. kommen noch weitere Ger\u00e4te, z. B. SIP-Proxys, hinzu. Auch SIP ging bei der Entwicklung von einer &#8222;heilen Welt&#8220; aus, in der die Ger\u00e4te normalerweise alle erreichbar sind und nicht hinter NAT (Network Address Translation, der Router verbirgt das lokale Netzwerk hinter sich) verborgen sind und zus\u00e4tzlich 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\u00e4uft getrennt ab, gleich zweimal einmal f\u00fcr die &#8222;eingehende Sprache&#8220; und einmal f\u00fcr die &#8222;ausgehende Sprache&#8220;.<\/p>\n\n\n\n<p>So kommt es in der Praxis h\u00e4ufig vor, dass man bei SIP nichts h\u00f6rt, der Gespr\u00e4chspartner schon. Oder dass, umgekehrt, man selbst den Gespr\u00e4chspartner h\u00f6rt, aber dieser einen nicht.<\/p>\n\n\n\n<p>In den &#8222;Internetnormen&#8220;, den RFC (Request For Comments), sind die verschiedenen Konfigurationsm\u00f6glichkeiten aufgef\u00fchrt. Wenn man nun wei\u00df, wie die Gegenstelle konfiguriert ist, kann man die eigene Infrastruktur kompatibel einstellen und alles funktioniert, man kann miteinander sprechen.<\/p>\n\n\n\n<p>Sehr \u00e4rgerlich ist es, wenn ein Provider seine Einstellungen \u00e4ndert und den Kunden nicht informiert. Noch \u00e4rgerlicher ist es, wenn der Provider seine eigenen Einstellungen nicht ver\u00f6ffentlicht und die Techniker des Providers, die es wissen k\u00f6nnten, hermetisch von der Au\u00dfenwelt abgeschnitten werden, also nicht zu erreichen sein. Dann hilft nur ausprobieren. Nach unserer Erfahrung gilt: je gr\u00f6\u00dfer ein Anbieter, desto problematischer wird es.<\/p>\n\n\n\n<p>Genug der Vorrede und Einf\u00fchrung, das konkrete Problem, das bei einem Kunden aufgetreten ist. Vielleicht hilft die Schilderung anderen ITlern, die pl\u00f6tzlich vor einem \u00e4hnlichen Verhalten stehen:<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">Von einem Tag auf den anderen Tag konnte der Kunde noch angerufen werden, aber nicht mehr raus telefonieren.<\/h2>\n\n\n\n<p>Was war geschehen? In der Telefonanlage des Kunden, eine FreePBX, also eine Asterisk-Telefonanlage, war keine Konfigurations\u00e4nderung und auch kein Update gemacht worden. Eine \u00dcbertragung der Einstellungen in eine baugleiche Anlage, ebenfalls an einem gleichen Telekom-Anschluss ergab: dort funktioniert es. K\u00f6nnen dann die Einstellungen falsch sein? Nun betreibt die Telekom als sehr gro\u00dfer 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\u00dfen nicht bekannt. Unsere Vermutungen daher:<\/p>\n\n\n\n<ul class=\"wp-block-list\"><li>Kunden werden relativ statisch zumindest einer identisch konfigurierten Proxygruppe zugeordnet und wir mit unserem Anschluss landen bei einer anderen Proxygruppe als der Kunde.<\/li><li>Die Telekom hat die Konfiguration im Proxy oder in der dahinter liegenden Infrastruktur ge\u00e4ndert.<\/li><\/ul>\n\n\n\n<p>Ein Anruf bei der Hotline f\u00fchrte, wie leider erwartet, nicht weiter. Der Tipp &#8222;starten sie das Ger\u00e4t neu&#8220; und der Hinweis &#8222;wenn sie kein Ger\u00e4t von uns nutzen, k\u00f6nnen wir ihnen nicht helfen&#8220; waren nicht f\u00f6rderlich.<\/p>\n\n\n\n<p>Also die Analyse der Log-Dateien. Zusammengefasst: keine auf die Fehlerursache hindeutende Information.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">Problemanalyse<\/h2>\n\n\n\n<p>Folglich: Wie flie\u00dfen die Daten beim Verbindungsaufbau, was k\u00f6nnte sich ge\u00e4ndert haben und wo ist der Unterschied bei eingehenden Gespr\u00e4chen, die funktionierten, zu ausgehenden Gespr\u00e4chen, die nicht funktionierten?<\/p>\n\n\n\n<p>Die \u00dcberlegungen f\u00fchrten 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\u00e4chsten Endstelle, ggf. aber auch mit einem weiteren SIP-Server, usw. \u00dcblicherweise konfiguriert man in einem VoIP-Telefon (oder der eigenen VoIP-Telefonanlage) den SIP-Server, zu dem ausgehenden Gespr\u00e4che 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\u00fcber auch informiert. Im Gegensatz zur Ansprache eines SIP-Servers mittels DNS-A-Record erm\u00f6glicht der SRV-Record eine schnellere und feinere Lastverteilung.<\/p>\n\n\n\n<p>F\u00fcr das SIP-Routing gibt es zwei Prinzipien &#8222;strict&#8220; und loose Routing. Strict Routing ist das urspr\u00fcngliche Verfahren. Die Route wird beim Gespr\u00e4chsaufbau angegeben, d. h. im Endger\u00e4t 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.<\/p>\n\n\n\n<p>Beim loose Routing wird das weitere Routing der Infrastruktur hinter dem ersten Proxy \u00fcberlassen. Also im Endger\u00e4t 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\u00f6nnte noch mehr hinter stecken, der sipproxy soll sich um den Folgeweg k\u00fcmmern, den gebe ich als Endger\u00e4t nicht vor.<\/p>\n\n\n\n<p>Leider muss die Routing-Methode im Endger\u00e4t eingestellt werden.<\/p>\n\n\n\n<p>Das Fehlerverhalten deutete auch auf ein solches Problem im Routing hin: Bei eingehenden Gespr\u00e4chen muss nicht mehr geroutet werden, das eigene Ger\u00e4t ist das Ende, daher funktionieren diese. Bei ausgehenden Gespr\u00e4chen wird jedoch auf jeden Fall geroutet. Wenn sich also im Protokoll etwas ge\u00e4ndert hat, werden diese nicht mehr funktionieren.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">Die L\u00f6sung: SIP-Routing-Methode umstellen<\/h2>\n\n\n\n<p>Also haben wir bei dem PJSIP-Channel, der in der Asterisk-Anlage f\u00fcr die SIP-Telefonie genutzt wird, das Routing-Protokoll von strict auf loose ge\u00e4ndert. Hierzu wird hinter der URL des Proxy in der Bedienoberfl\u00e4che die Zeichenkette &#8222;\\;lr&#8220; angeh\u00e4ngt (ohne Anf\u00fchrungszeichen). Der Parameter selbst ist das &#8222;lr&#8220; (f\u00fcr loose routing). Das Semikolon trennt den Parameter von der Proxy-Adresse und der Backslash &#8222;\\&#8220; 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.<\/p>\n\n\n\n<p>Und tats\u00e4chlich, nach der Aktivierung dieser Anpassung funktionierte die Telefonie wieder in beiden Richtungen.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>VoIP mittels SIP ist ein komplexes Thema. Die Vielzahl von Parametern, die f\u00fcr eine funktionierende Kommunikation korrekt eingestellt werden m\u00fcssen, sowie die Vielzahl der Beteiligten, ist erheblich. Man bedenke, welche Ger\u00e4te &#8222;mitspielen&#8220; m\u00fcssen: der Router und die Firewall auf der Seite des Telefonanbieters, der eigene Router und die Firewall auf der Seite des Telefonierenden, evtl. [&hellip;]<\/p>\n","protected":false},"author":2,"featured_media":1855,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[5,1],"tags":[297,74,296],"class_list":["post-1849","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administration","category-allgemein","tag-sip","tag-telekom","tag-voip"],"_links":{"self":[{"href":"https:\/\/blog.imagmbh.de\/index.php\/wp-json\/wp\/v2\/posts\/1849","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/blog.imagmbh.de\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/blog.imagmbh.de\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/blog.imagmbh.de\/index.php\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/blog.imagmbh.de\/index.php\/wp-json\/wp\/v2\/comments?post=1849"}],"version-history":[{"count":3,"href":"https:\/\/blog.imagmbh.de\/index.php\/wp-json\/wp\/v2\/posts\/1849\/revisions"}],"predecessor-version":[{"id":1852,"href":"https:\/\/blog.imagmbh.de\/index.php\/wp-json\/wp\/v2\/posts\/1849\/revisions\/1852"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/blog.imagmbh.de\/index.php\/wp-json\/wp\/v2\/media\/1855"}],"wp:attachment":[{"href":"https:\/\/blog.imagmbh.de\/index.php\/wp-json\/wp\/v2\/media?parent=1849"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/blog.imagmbh.de\/index.php\/wp-json\/wp\/v2\/categories?post=1849"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/blog.imagmbh.de\/index.php\/wp-json\/wp\/v2\/tags?post=1849"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}