Gesprächsabbrüche mit Asterisk 16 und Telekom Sip Trunk Pure

[umagaur]

Guten Morgen,

wir haben vor 6 Wochen auf den SIP Trunk der Telekom umgestellt und bei unseren Start Schwierigkeiten hier im Forum wertvolle Hilfe bekommen.
Nach 6 Wochen Betrieb haben wir noch ein großes Problem: Gesprächsabbrüche zu unregelmäßigen Zeiten.

Was ich weiß:
Die Gespräche von verschiedenen Personen, zu verschiedenen Teilnehmern werden nach unterschiedlichen Verbindungszeiten unterbrochen.
Durch einige Recherche konnte ich herausfinden das die Gespräche zur selben Zeit unterbrochen werden. (also zB 15.10) Deshalb unterschiedliche Gesprächslängen.
Das Log des Lyncservers sagt es erfolgte ein normaler Hangup. Ich konnte mit einem befreundeten admin ein solches Gespräch auch auf seiner Seite auswerten und er bekam ebenfalls vom Provider ein Hangup.
Beide User schwören sie haben nicht aufgelegt. (ausnahmsweise glaube ich den Usern) Also bekamen beide Seiten ohne ihr Zutun ein Hangup signalisiert. Die selbe Meldung bekommt man auch wenn man tatsächlich auflegt.

Ich habe ein Bild vom Telekom SRV Record für reg.sip-trunk.telekom.de angehängt dort kann man sehen das anhand der Priorisierung die 217.0.15.67 eigentlich immer verwendet werden muss, außer sie ist nicht erreichbar, dann übernimmt die 217.0.15.69.

Wenn ich jetzt die Logs unserer Firewall auswerte sehe ich das immer wenn es zu einem Gesprächsabbruch kam es eine Verbindung zur 217.0.15.69 gab. Teilweise bis zu 10 mal am Tag (also 10 Gesprächsabbrüche).
Diese Verbindungen tauchen nur während der Arbeitszeit auf ca. zwischen 8 und 17 Uhr. Nicht Nachts und nicht am WE. Bild 2 zeigt die Verbindungen. diese dauern in der Regel nur weinige Mintuen oder sogar nur Sekunden dann "übernimmt" wieder die 217.0.15.67.

Wenn ich mir überlege das die Anlage den Server der Registrierung wechselt dann erscheint es mir logisch das zu dem Zeitpunkt des Wechsels die Gespräche abbrechen und beide Seiten das Hangup Signal bekommen.

Ein Ticket bei der Telekom ist offen aber ob es zu einem Ergebnis führt weiß ich nicht. Als Workaround habe ich heute Morgen in der Telefonanlage das Hostfile so angepasst das reg.sip-trunk.telekom.de mit der 217.0.15.67 aufgelöst wird. Sollten die Gesprächsabbrüche weg sein und die Verbindungen zur 69 ebenso, wäre das zumindest der Beweis für meine Theorie.

Hat jemand etwas ähnliches beobachtet oder kann mir erklären wieso die Anlage versucht sich bei der 217.0.15.69 zu registrieren bzw wie ich das abstellen kann. Vielleicht so etwas wie eine DNS Auflösungsverzögerung Als DNS ist unser interner DNS Server eingetragen (WIN 2012R2 mit forwarder zur 8.8.8.8)

Ich habe auf der Asterisk kein Log gefunden in dem die Registrierung das pjsip Trunks dokumentiert wird. Gibt es das nicht, oder muss man das einschalten, oder bin ich blind ?

 

[Meester Proper]

Wer unterbricht auf welche Art und Weise die Anrufe? Gibt es SIP-Fehlermeldungen (4xx/5xx/6xx)?

Hast du mal einen Paketmitschnitt (PCAP) angefertigt, wenn die Abbrüche auftreten?

 

[umagaur]

Habe ich mich so unverständlich ausgedrückt ?
Beide seiten bekommen ein hangupsignal. da gibt es keinen Fehler. Die Meldung ist exact die selbe wie wenn ein Gespräch durch auflegen beendet wird.
Woher das Signal kommt ist nicht feststellbar. Anhand des Firewalllogs vermute ich das es passiert weil der Telekomtrunk sich bei dem anderen Server registriert. Die Meldung auf dem Lync ist 10027 "Normal Termination Response from Gateway after the call was established"

Um zu prüfen ob die neuregistrierung bei dem nicht priorisierten Gateway das Problem ist habe ich in die Hostfile einen eintrag für reg.sip-trunk.telekom.de gemacht und in den SIP Einstellungen auf der Asterisk den srv lookup auf false gesetzt. Jetzt dürfte er sich nur noch mit der 217.0.15.67 verbinden.

 

[ubsyathEe]

Dass das Problem bei dem SIP-Trunk auftritt, ist neu für mich. Aber ich glaube, dass die Beschreibung prinzipiell richtig ist und damit handelt es sich um die gleiche Problematik wie bei dem ALL-IP Produkt.

Wenn es das hier schon beschriebene Registrierungsproblem ist, dann bricht die Telekom laufende Gespräche nach einer gewissen Zeit ab (wegen der dann fehlenden Registrierung). In einem PCAP Trace, oder anderen geeigneten Aufzeichnungen, finden man dann den Fehlercode [Not Found 1:27]. Es gibt aber noch andere negative Auswirkungen.

Aus meiner Sicht sieht es derzeit so aus, dass keine Version von Asterisk wirklich kompatibel mit den erwähnten Telekomprodukten ist. Wenn die Telekom nicht intern über die Registrierungen buchführt, dann muss es halt die Gegenstelle machen, d.h. Asterisk. Da ist erstens nichts dergleichen vorhanden und zweitens ist das tatsächlich etwas aufwendiger umzusetzen, da man nicht nur auf geänderte SRV Records, sondern auch auf noch etwaig bestehende Verbindungen Rücksicht nehmen muss. Derzeit schreibe ich für Asterisk ein entsprechendes "Modul", wobei ich momentan noch die meiste Zeit damit verbringe das derzeitige Verhalten von Asterisk für mich zu dokumentieren. Es wird noch einige Zeit dauern, bis ich den Code einreichen kann, und ob das akzeptiert ist, ist eine andere Frage.

Ich glaube auch, dass Joshua Colp (Asterisk Wiki) Recht hat, wenn er sagt, dass hier von Asterisk eine ungewöhnliche Kommunikation mit einem Server verlangt wird. Mir liegt eine Stellungnahme eines Mitarbeiters des Technischen Kundenservice/Operation Department 1.1 aus Hamburg vor, wo das Problem anscheinend mittlerweile nach einigem Hin und Her auch so gesehen wird, aber, dass keine Produktänderungen zu erwarten sind. Für Privatanschlüsse ist das meines Erachtens auch nicht nötig, aber bei Geschäften sieht das zumindest nicht gut aus. Die eigentlich Frage ist: was macht die Digibox hier besser als Asterisk? Ich habe bisher noch keinen Beitrag irgendwo gelesen, dass das Problem für eine Digibox beschrieben wird.

Nichtsdestotrotz, gibt es eine Reihe von Notlösungen, die etwas helfen.

 

[umagaur]

Nichtsdestotrotz, gibt es eine Reihe von Notlösungen, die etwas helfen.

Hi, sind die irgendwo dokumentiert ? Ich bin für jeden schubs in die richtige Richtung dankbar.
Als Info über die Digibox die haben wir in einer Niederlassung als VoIP GW eingesetzt mit dem selben SIP Produkt der Telekom und dort kommt es zu keinen Fehlern. Ich hätte die hier anstelle der Asterisk eingesetzt wenn die nicht laut Beschreibung auf 20 Kanäle limitiert wäre.

Die Änderung hostfile eintrag und SRV Lookup abschalten hat nichts gebracht. Heute abend werde ich die internen Server (Lync und Fax) in die Hostfile eintragen und in der reolv.conf die internen DNS herausnehmen und statt dessen den Telekom DNS eintragen. Mal sehen ob das etwas bringt.

 

[ubsyathEe]

Nicht, dass ich wüsste, aber die beiden Grundideen, die jeweils ihre eigenen Nachteile mit sich bringen, sind auch hier zu finden... Asterisk greift auch nicht zwingend auf die host Datei zu.

Das ist aber alles Murks, da eigentlich nichts gelöst wird. Als Anlage ist die Digibox Premium auf 15 Teilnehmer/20 Endgeräte beschränkt, im Gateway-Modus natürlich nicht. Ob man allerdings mehr als 20 gleichzeitige Gespräche sauber über eine DSL-Leitung kriegt, ist eine andere Frage.

 

[umagaur]

Wir haben einen SIP Trunk Pure der über unsere eigene Leitung läuft. Die hat 100mbit synchron. Das ist also kein Problem

 

[umagaur]

Die Asterisk hat immer eine Überraschung parat. Asterisk bringt seinen eigenen dnsmgr mit und lt. einem Blogeintrag macht der folgendes:
"Asterisk only reads the first SRV entry without bothering with priorities and weights."
Der ist die 217.0.15.69. Das würde das verhalten perfekt erklären.
Angeschaltet wird der in der dnsmgr.conf
Ich habe jetzt unsere internen Server in die Hosts file gepackt und als nameserver den telekom DNS eingetragen. In der dnsmgr.conf habe ich den refresh von 300 Sekunden auf 86400 gesetzt. Mal schauen ob die Gesprächsabbrüche weg sind also die Verbindungen zur 217.0.15.67 stabil bleibt wenn er nur noch einmal am tag refreshed..

 

[gehtdoch]

Deine Info passt nicht ganz. Relevant ist pjsip. Hier findest Du vom Entwickler diese Info. Siehe "Load balancing". Das ganze hat auch nichts mit dem dnsmgr zu tun. Der kümmert sich um das Handling dynamischer IP-Adressen (falls Du ab und zu wechselnde Internet-IPs hast).

Was die abbrechenden Calls angeht:
Es kann aber trotzdem sein, dass sich bei ändernden SRV-Einträgen bzw. bei plötzlich nicht mehr erreichbaren Einträgen Probleme ergeben (ist zumindest bei AllIP so, weil dort alle requests grundsätzlich zum Registrar gehen müssen - das kann Asterisk aber nicht, weil er nicht stateful ist).
IAW: automatische Hochverfügbarkeit via zumindest AllIP, ist nicht möglich. Ob der SIP-Trunk der Telekom an dieser Stelle gleich oder anders tickt, vermag ich nicht zu sagen.
Zumindest bei AllIP hilft Dir am Besten ein eigener Bind mit einer RPZ, die Du hinsichtlich der Voice-Server der Telekom selbst gezielt befüllst. So kannst Du wenigstens kontrollieren, was Asterisk präsentiert bekommt. Wenn Du Änderungen beim Befüllen entdeckst, kannst Du in einer ruhigen Minute den Update der RPZ durchführen und dann einen ReRegister auslösen. Damit hast Du aber immer noch keine Hochverfügbarkeit, weil Asterisk mit ausfallenden Servern in der Liste nicht korrekt umgehen kann (= wie es das Betriebskonzept der Telekom AllIP z.B. benötigt).

Bevor Du diesen Aufwand aber fährst, würde ich erst mal sicherstellen, dass das Ganze auch wirklich so abläuft, wie vermutet. pcapsipdump ist dafür ein geeignetes Tool. Aber Achtung: Du hast da schnell Probleme in Sachen Mitschneiden am Hals. Datenschutzbestimmungen beachten!

Es geht in der Auswertung darum zu prüfen, ob REGISTER und INVITE zum gleichen Server gehen bzw. ob während eines laufenden Calls der Registrar geändert wird (so dass der laufende Call beim alten registrar quasi austimed mangels vorhandenem ReRegister). Bei AllIP ist das so - beim SIP-Trunk weiß ich es nicht.

 

[ubsyathEe]

Nein, mittlerweile weiß ich, dass der SIP-Trunk im Grunde auch nicht anders tickt, aber die DNS Server verhalten sich anders...

 

[therrmann78]

Auch ich stehe mit dem Telekom Sip Trunk Pure ziemlich auf Kriegsfuß... Wir nutzen FreePBX, und nachdem ich die srvlookups mit CHAN_SIP irgendwann am laufen hatte, gab es immer mal wieder Gesprächsabbrüche. Mittlerweile reproduzierbar mit Vodafone Mobilfunk (VoLTE/VoWIFI), so dass ich den Trunk auf PJSIP umgestellt habe. Mit dem Ergebnis, dass die Gesprächsabbrüche noch mehr geworden sind. Gibt es irgendwo ein gesammeltes Wissen, wie man einen Telekom-SIP-Trunk einrichtet, so dass das ganze stabil funktioniert? Welche Asterisk-Version ist dafür die beste? Vermutet hätte ich natürlich 16, aber habe auch schon gelesen dass es mit 13 besser sein soll. Da findet man leider viel Halbwissen, Halbwahrheiten und veraltete Angaben.

 

[ubsyathEe]

Nein, das kann es nicht geben, weil es auch noch Abhängigkeiten vom verwendeten Router geben kann, es sei denn Asterisk ist auch Bestandteil des Routers bzw. Gateways. Ein schlecht konfiguriertes Hostsystem kann auch eine Rolle spielen.

Es gibt daher auch fast nie vollständige Problembeschreibungen, die eine vernünftige Analyse erlauben. Wenn man sich die OSI-Ebenen anschaut, dann ist es ja auch so, dass das Probleme auf den unteren Ebenen sich zwangsläufig auf der Applikationsebenen auch irgendwie bemerkbar machen. Das wird aber so gut wie nie diskutiert. Gerade wenn in kleineren Firmen ein LAN seit 20 Jahren oder länger "gepflegt" wurde, sehe ich sehr häufig Probleme in der Verkabelung. Ich messe aber mit relativ teurem Equipment, was kaum ein Kunde einsieht und eigentlich lieber darauf verzichten will. Erst dann schaue ich mir den Rest an, oder gar nicht.

Es gibt eine Reihe von Gründen für Gesprächsabbrüche bzw. Nichtzustandekommen von Gesprächen, wobei das ALLIP DNS Problem nur eines ist. Nach wie vor können beispielsweise die Session Timer und UPDATE Requests schon mal Probleme machen, aber ich schaue mir den Traffic hier bei neuen Anlagen immer erst über Stunden an und mach auch lange Testanrufe, die über mehr als 1 Stunde laufen sollten. Für Leute, die mal schnell ein Problem gelöst bekommen haben wollen ("Asterisk funktioniert nicht"), ist das natürlich nix. Daneben gibt es auch noch aus meiner Sicht haarsträubende Asterisk Installationen, zu denen man besser gar nichts sagen sollte. Derzeit gehört meiner Meinung nach grundsätzlich FreePBX dazu (am besten noch auf einem alten Raspberry), aber vielleicht verstehe ich davon ja nichts.

Ich selbst habe seit einiger Zeit keine Probleme mehr mit dem SIP Trunk Pure und dem ALLIP Anschluss, wobei ich stets die aktuelle 16er Version, bzw. auf Testmaschinen den Git Master Code verwende (weil ich da auch meinen Code reinschreibe). Das heißt aber nicht, dass meine Konfiguration auch so anderswo laufen muss wegen der oben geschilderten Abhängigkeiten. Vermutlich ist es so, dass, wenn man das Problem technisch exakt beschreiben kann, die Lösung auch normalerweise einfach ist. Diejenigen, die das können, werden vermutlich sehr selten andere fragen.

Unabhängig davon verwende ich auch die Digibox der Telekom und habe ich noch nie ein Problem mit der Telefonie gesehen. Mittlerweile ist die Digibox auch einfacher zu konfigurieren. An den Quellcode der Digibox kommt man eher nicht ran, aber man kann beispielsweise neben Asterisk auch Kamailio betreiben und dann sehen, wie dieses System reagiert. FreeSwitch wäre auch noch eine Möglichkeit, aber ich ziehe Kamailio für Verbindungstests vor. Das ist aber eher ein zeitraubendes Hobby als eine Möglichkeit billig an eine große Telefonanlage zu kommen.

 

[gehtdoch]

Gibt es irgendwo ein gesammeltes Wissen, wie man einen Telekom-SIP-Trunk einrichtet, so dass das ganze stabil funktioniert? Welche Asterisk-Version ist dafür die beste? Vermutet hätte ich natürlich 16, aber habe auch schon gelesen dass es mit 13 besser sein soll. Da findet man leider viel Halbwissen, Halbwahrheiten und veraltete Angaben.

Nun, Du hast es selbst schon ganz gut beschrieben. Was ubsyathEe geschrieben hat, kann ich im Großen und Ganzen auch nur unterstreichen (abgesehen von den Aussagen zu FreePBX).

Ein Kochbuch, wie es sich die meisten wünschen, gibt es nicht - man muss sich grundsätzlich das gesamte Konstrukt anschauen (Netze / Firewalls / Hardware / detaillierte Traces von Problemsituationen). Das Ganze verbunden mit KnowHow, um die Abweichungen / Ursachen überhaupt entdecken zu können. Einfach so geht leider nicht. Zielführende Detailanalysen der relevaten Infrastruktur sind aufwändig. Habe ich alles schon hinter mir (was nicht heißt, dass ab und an wieder was Neues hochkommt - deshalb sollte man so wenig wie möglich am relevanten Stack schrauben bzw. nur sehr gut dokumentiert, so dass man auch später noch weiß, wo man mal gedreht hat). Man kommt da schlussendlich absolut überall rum.

Zwingende Basis ist eine absolut stabile Netzwerkinfrastruktur (insbesondere für kleine(!) Pakete) für die relevanten Wege - gar nicht so selbstverständlich. NAT für SIP meide ich wie der Teufel das Weihwasser. Genauso beliebige SOHO-Router. Damit bekommt man wenigstens mal grundsätzlich die Chance, die Dinge ordentlich analysieren und durchgängig gemäß Anforderungen konfigurieren zu können. Bei Problemen: reproduzieren und tracen und analysieren - nichts anderes hilft final weiter.
Ich hatte hier z.B. u.a. das Problem, dass der im Kernel mitgelieferte HW-Treiber für die Ethernet-Devices schrottig ist. Erst der Austausch gegen den Herstellertreiber hat zu stabilem VoIP geführt. Das bekommst Du aber auch nur raus, wenn Du exzessive Traces an verschiedenen Stellen fährst, um so feststellen zu können, wo es de facto klemmt (man muss in diversen Traces auch immer Ursache und Wirkung auseinanderhalten).

 

[ubsyathEe]

Ja, ja, viel hilft viel... Entweder man benötigt die vielen Features von FreePBX nicht, oder die Wartung wird mit der Zeit immer komplizierter und fehleranfälliger.

 

[umagaur]

Nach einigen Wochen konnte ich das Thema bei uns lösen. Leider ist die Asterisk trotz verbesserter DNS Unterstützung wohl nicht in der Lage die Registrierung beim SIP Trunk aufrecht zu erhalten. Bei der reregistrierung wechselt Sie den Port und das führt zum Verbindungsabbruch. Das ist in den Firewalllogs eindeutig dokumentiert.

Wir haben eine Digibox Premium gekauft und ich habe diese als SBC konfiguriert. Seither gibt es keine Gesprächsabbrüche mehr.
Einfach den pjsip zur Telekom auf auf der Astrisk stillgelegt. Neuer Trunk zur Digibox und alle ausgehenden Gesräche an die Digibox weitergeleitet.
Auf der Digibox 2 Trunks, einen zur Telekom und einen zur Asterisk.
Man sieht auf der Firewall das die Verbindung zum SIP Trunk der Telekom (Digibox) über jetzt 7 Tage geöffnet ist. Vorher auf der Asterisk war die Verbindung unter Last, wir haben 9,5k Gespräche in der Woche, maximal 2 bis 4 Stunden offen. dann erfolgte eine reregistrierung.

Bevor jetzt jemand sagt ja aber vielleicht steht die Box günstiger im Netzwerk, bessere Latenz o.ä. die Digibox geht auf den selben Switch und ist im selben Netzwerksegment wie die Asterisk. Der weg über die FW ist für die Digibox exakt gleich wie bei der Asterisk.

Nettes Phänomen am Rande. Wir hatten bei unserem Lync immer schon (seit Einführung 2011) bei vielen Gesprächen in den ersten 2 Sekunden keine richtige Verbindung. Man fing an zu reden und merkte dann das der gegenüber noch nicht im Gespräch war. Das tritt seit dem Einsatz der Digibox ebenfalls nicht mehr auf.

 

[therrmann78]

Wir haben eine Digibox Premium gekauft und ich habe diese als SBC konfiguriert. Seither gibt es keine Gesprächsabbrüche mehr.

Diese Lösung wollte ich immer vermeiden, aber wenn sie funktioniert, dann investiere ich lieber 250 Euro und habe eine weitere Plastikkiste rumstehen als sporadische Telefonieprobleme.

Frage zum Setup: die Digitalisierungsbox hängt nicht selbst am DSL/WAN, sondern im LAN hinter einem NAT? Mit nicht-öffentlicher IP-Adresse?

 

[umagaur]

Die Digibox hängt im Lan hinter einem NAT mit nicht öffentlicher Adresse, nur ein einziger Port angeschlossen auf der LAN seite der Digibox. Alles andere habe ich abgeschaltet.
Wir haben 2 ausgehende Leitungen als Primärweg eine 100mbit synchron der Telekom und als Sekundärweg einen 50 mbit WLAN über einen lokalen Provider. das ganze geht über einen Fortigate FW Cluster.
Die Verbindung zur Digibox-Asterisk und Digibox->Telekom war schnell erledigt. Damit hat das Telefonieren nach 20 Minuten geklappt.
Die richtigen Einstellungen auf der Astrisk zu finden damit nach extern die Durchwahl und nicht die Kopfrufnummer übertragen wird hat mich einige Stunden gekostet.

 

[therrmann78]

Wir haben 2 ausgehende Leitungen

Telefonieren über nicht-Telekom-Leitung funktioniert problemos? Das geht ja nur mit Verschlüsselung. Wie lange dauert die Umschaltung, wenn die Telekom-Leitung mal tot ist, bis man wieder raustelefonieren kann und von außen wieder erreichbar ist?

Die richtigen Einstellungen auf der Astrisk zu finden damit nach extern die Durchwahl und nicht die Kopfrufnummer übertragen wird hat mich einige Stunden gekostet.

Verrätst Du mir auch, was die Lösung war? Möchte das Rad nicht neu erfinden...

 

[umagaur]

Zu 90% kann man das Video digibox zur unify nutzen

Session Border Controller mit Unify OSBiz - Telekom - Digitalisierungsbox

digitalisierungsbox.bintec-elmeg.com

Nur an der Stelle an der in der digibox im Trunk zur Telefonanlage Betzername und Auth ID eingetragen werden darfst du nicht die Kopfrufnummer nehmen. Was man nimmt ist egal ich habe da 3456 eingetragen.
Auf der Asterisk habe ich eine PJSIP Verbindung konfiguriert.
Unter general dann bei Benutzername 3456 und dein Passwort. Sip Server die Digibox und Context from-pstn-toheader (wichtig da sonst die Empfänger nicht ausgelesen werden)
Unter erweitert wichtig expiration auf 120 und der from user ist pflicht. Ohne den erkennt der interne Proxy der Digibox den User nicht und lehnt den Callaufbau ab. Und wenn da die Kopfrufnummer steht (wie im video) dann hat man das Problem das keine Durchwahlen übertragen werden sondern immer nur die Kopfrufnummer. Durch die Verwendung von 3456 als User umgeht man das. die 70.24 ist die Digibox

 

[ubsyathEe]

Leider ist die Asterisk trotz verbesserter DNS Unterstützung wohl nicht in der Lage die Registrierung beim SIP Trunk aufrecht zu erhalten. Bei der reregistrierung wechselt Sie den Port und das führt zum Verbindungsabbruch. Das ist in den Firewalllogs eindeutig dokumentiert.

Das spricht aber eher für eine ungeeignete Routerkonfiguration. Wer ändert denn die Ports, wobei ich vermute, dass es die rausgehenden Ports sind?