Asterisk / Telekom MagentaZuhause / VoIP/TLS - seltsames Verhalten beim Deregistrieren einer Rufnummer / Mediasec-Problem?

gehtdoch

Mitglied
Mitglied seit
3 Feb 2019
Beiträge
210
Punkte für Reaktionen
14
Punkte
18
Hallo zusammen!
Ich registriere via Asterisk (Asterisk 18.x - ist aber auch bei 16.x z.B. zu beobachten) / pjsip 3 Rufnummern bei der Telekom / AllIP oder MagentaZuhause. Rein IP-technisch erfolgt die Anbindung der drei Rufnummern über ein und dieselbe Verbindung (Bsp.):
Code:
# netstat -n | grep 5061
tcp        0      0 a.b.c.d:58093       217.0.20.195:5061       VERBUNDEN

Soweit, so gut.

Wenn man Asterisk nun startet, werden alle drei Nummern in der Regel quasi parallel registriert (nur wenige Millisekunden liegen dazwischen) - manchmal läuft die 3. Nummer auch in einen Timeout und wird dann 1 Minute später registriert.

Auch bis hierher so weit so gut.

Jetzt tauchen aber ab und zu Probleme auf beim reRegister (da werden dann ja auch alle drei Nummern wieder quasi parallel angefahren) - der scheint (zumindest aus der Sicht von Asterisk) manchmal nicht schnell genug zu gehen, sprich, aus Sicht von Asterisk reagiert die Telekom zu langsam (ok, wenn 0,04s langsam sind ...) und meldet dann sofort einen Retry nach 60s im Log - der natürlich nicht benötigt wird, weil ja nach 0,04s doch eine Reaktion eintrifft.

Ich vermute da seitens der Telekom irgendwelche Restriktionen, die vorsehen, dass nicht zu viele Registers von einem Client quasi gleichzeitig eingehen.

Daher habe ich mir folgendes überlegt (Entzerrung der reRegistrierung der drei Nummern):
Nach dem Start von Asterisk entzerre ich die drei Rufnummern, indem ich zwei von ihnen hintereinander erst deregistriere und dann wieder registriere (die Deregistrierung wird auch seitens der Telekom jeweils mit einem 200 ok bestätigt).
Ziel ist, dass die Nummern zukünftig zeitlich weit auseinander liegen und damit quasi gut getrennt voneinander die reRegistrierungen vorgenommen werden können. Ich habe über Wochen nun beobachtet, dass dann keine false positive retries mehr auftreten und die Reaktion seitens des Telekomservers auch fast immer schneller ist bzw. auch Asterisk nicht mehr verwirrt wird (ich vermute da auf Asterisk-Seite auch noch ein Problem).

Soweit auch so gut.

Jetzt kommt das Spannende - das ist der Hauptgrund, warum ich hier poste:
Nach jedem unregister einer Nummer (obwohl noch z.B. 2 Nummern registiert sind und diese auch nicht angefasst wurden), kommt grundsätzlich reproduzierbar immer nach 10s der Abbruch der TCP/TLS(!) Session vom Telekomserver!

Dabei tritt am Ende der TCP/TLS-Session immer eindeutig reproduzierbar folgendes Problem auf:
  1. Letztes ACK-Paket vom Client zur Telekom
  2. 10 s Pause / irgendein Timeout?
  3. FIN ACK von der Telekom - das Wireshark unter "TCP previous segment not captured" einstuft (nein, es geht beim capture kein Paket verloren und das ist auch jedesmal reproduzierbar)
  4. Wiederholung des letzten ACK-Pakets vom Client zum Server (also 1. Paket hier) - Dieses Paket wird von Wireshark als "DUP ACK" eingestuft
  5. Jetzt kommt ein PSH ACK-Paket vom Telekomserver - welches Wireshark als "TCP out of order" einstuft und das auch noch 31 bytes Daten enthält
  6. Der Client schickt darauf ein ACK und ein FIN ACK Paket
  7. welches die Telekom mit ACK quittiert - damit ist die Verbindung final beendet.
Die Verbindung wurde, wohlgemerkt, ohne ein vorheriges Unregister auf Anwendungsebene seitens der Telekom beendet. D.h., die eigentlich noch bestehenden Registers sollten, trotz gekappter TCP/TLS-Verbindung noch bestehen - oder doch nicht?

Wie auch immer - Asterisk reagiert auf den Verbindungsabbruch derart, dass logischerweise ein Neuaufbau stattfindet - und ein neuer Register für alle nicht deregistrierten Nummern wieder durchgeführt wird. Alle bisher noch nicht deaktivierten Nummern werden dann wieder parallel registriert. Ok, man deregistriert dann eben auch noch die zweite Nummer und wartet die 10 Sekunden ab, bis die Verbindung wieder neu aufgebaut wird. Danach können dann sequentiell die beiden noch ausstehenden Nummern wieder registriert werden. Uff.

Hat zufällig irgendwer eine Idee, was den Telekomservern da nicht passt - warum die nach 10 Sekunden einfach die Verbindung abbrechen? Bei Easybell verhält sich ein unregister ganz anders: der wird durchgeführt, wie man es erwartet - danach wird die TCP/TLS-Verbindung seitens Asterisk jedoch nicht getrennt (auch nicht seitens Easybell). Die wird solange gehalten, bis Asterisk beendet wird (da gibt es TCP/TLS keep alives) bzw. sie wird weitergenutzt, sobald eine neue Registrierung durchgeführt wird.

Edit 09.01.21:
Mediasec ist nicht das Problem - selbes Verhalten tritt auch ohne Mediasec auf.


Oder gibt es in Sachen Mediasec etwas zusätzlich beim deRegister zu beachten? Ich mache den gleich wie einen Register - außer dass eben der Expire auf 0 gesetzt ist: Die drei zusätzlichen Header sind gesetzt im REGISTER:
Code:
Security-Client: sdes-srtp;mediasec
Proxy-Require: mediasec
Require: mediasec

Läuft ja dann auch scheinbar problemlos durch (wird durch den 200 OK seitens Telekom nach Authentication bestätigt).


Edit 14.01.2021: Lösung siehe hier.
 
Zuletzt bearbeitet:

Erhalten Sie 3CX für 1 Jahr kostenlos!

Gehostet, in Ihrer privaten Cloud oder on-Premise! Ganz ohne Haken. Geben Sie Ihren Namen und Ihre E-Mail an und los geht´s:

3CX
Für diese E-Mail-Adresse besteht bereits ein 3CX-Konto. Sie werden zum Kundenportal weitergeleitet, wo Sie sich anmelden oder Ihr Passwort zurücksetzen können, falls Sie dieses vergessen haben.
oder via