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

umagaur

Neuer User
Mitglied seit
8 Jul 2019
Beiträge
20
Punkte für Reaktionen
0
Punkte
1
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 ?
 

Anhänge

Meester Proper

Neuer User
Mitglied seit
24 Mai 2014
Beiträge
162
Punkte für Reaktionen
10
Punkte
18
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

Neuer User
Mitglied seit
8 Jul 2019
Beiträge
20
Punkte für Reaktionen
0
Punkte
1
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

Neuer User
Mitglied seit
21 Mai 2019
Beiträge
53
Punkte für Reaktionen
1
Punkte
8
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

Neuer User
Mitglied seit
8 Jul 2019
Beiträge
20
Punkte für Reaktionen
0
Punkte
1
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

Neuer User
Mitglied seit
21 Mai 2019
Beiträge
53
Punkte für Reaktionen
1
Punkte
8
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

Neuer User
Mitglied seit
8 Jul 2019
Beiträge
20
Punkte für Reaktionen
0
Punkte
1
Wir haben einen SIP Trunk Pure der über unsere eigene Leitung läuft. Die hat 100mbit synchron. Das ist also kein Problem
 

umagaur

Neuer User
Mitglied seit
8 Jul 2019
Beiträge
20
Punkte für Reaktionen
0
Punkte
1
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

Neuer User
Mitglied seit
3 Feb 2019
Beiträge
73
Punkte für Reaktionen
3
Punkte
8
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

Neuer User
Mitglied seit
21 Mai 2019
Beiträge
53
Punkte für Reaktionen
1
Punkte
8
Nein, mittlerweile weiß ich, dass der SIP-Trunk im Grunde auch nicht anders tickt, aber die DNS Server verhalten sich anders...
 

3CX PBX - GRATIS
Linux / Win / Cloud

Statistik des Forums

Themen
232,863
Beiträge
2,027,497
Mitglieder
350,975
Neuestes Mitglied
user7008