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

[gehtdoch]

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.):

# 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:

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.

 

[key.stroke]

Hallo.
Ich habe das Problem auch bei nur einer Nummer. Die Registrierung fällt in einer Stunde bis zu 3 Mal weg und dann nach 600 Sekunden ist sie wieder da.
Ich suche auch nach dem Problem. An einer Stelle habe ich festgestellt, das die Telekom nicht mehr den Server betreibt.
Zuständig ist Plusnet.de.
Die sind aber genau so stur, wie die Telekom und möchten keinen Support leisten.
Trotz mehrfacher Anfrage und einigen Telefonaten ist es nicht möglich, den Support dazu zu bewegen mal auf dem Server nachzusehen, warum dieser Effekt eintritt.
Die Telefone, die ich parallel auf den anderen Nummern in betrieb habe, nutzen STUN. Leider will Asterisk dieses nicht so benutzen, wie die Telefone.
Firewall und Portforwarding ist aber mehrfach geprüft und sollte nicht der Grund sein.
ICh würde mich aber freuen, wenn (sofern eine Lösung gefunde wurde), ich diese hier auch einsehen kann.
Mit freundlichem Gruß
Jens

 

[gehtdoch]

Leider fehlen sämtliche essentielle Informationen - auf dieser Basis ist keine sinnvolle Hilfe möglich. Nimm als SIP-Protokoll TLS wie hier beschrieben - alles andere ist Zeitverschwendung.

 

[key.stroke]

Hallo GehtDoch!
Ich bin neu in dem Thema. Ich habe schon seit Februar versucht eine Lösung zu finden. ICh habe erst zu Ostern eine Mischung aus Sipgate und FreePBX-Konfig gefunden, die geht. Verstanden habe ich die Technik noch nicht. Daher kann ich dir nur sagen, das ich einen LANCOM-Router 1790VA habe und einen Raspberry Pi 3B. Mein Netzwerk wurde im Februar von CAT.4 auf CAT.7 umgebaut und als Telefone benutze ich Grandstream GXP 1615, Gigaset Go-Box 100. Eine simple Konfig ist vorhanden, die aber nicht sauber funktioniert.
Im Endeffekt bin ich für jede Info dankbar, wenn jemand das Fehlerbild kennt.
ICh habe aber heute schon gelernt, das Verzögerungen in der Anwahl ein Problem mit dem DNS ist.
Auch hast du mir mitgeteil, das man TLS mit Mzregio machen kann. Das ist schon mal ein Anfang und ich forsche weiter.
Mit freundlichem Gruß
Jens

 

[gehtdoch]

Was mich irritiert, ist Deine Aussage, die Voice-Server der Telekom würden nicht mehr von der Telekom, sondern von plusnet.de betrieben. Reden wir hier tatsächlich von tel.t-online.de? Ansonsten, nimm für die Registrierung TLS. Du hast ja sicher schon genug von mir hier gelesen und weißt daher auch schon, dass ich von SIP in Verbindung mit NAT nichts halte. Weil es eben solche Probleme und weitere, wie Du (und viele andere auch) sie hier beschreiben, hervorrufen.

Ansonsten musst Du das Problem eben tracen. sngrep kannst Du dafür verwenden (bei nicht verschlüsseltem Verkehr). Ansonsten kannst Du auch in Asterisk pcap-Logs direkt mitschneiden:

asterisk -x "pjsip set logger on"
asterisk -x "pjsip set logger verbose off"
asterisk -x "pjsip set logger pcap trace.pcap"

Die Datei findest Du dann wahrscheinlich in /var/lib/asterisk/

Ein erfolgreicher Register endet mit dem 200 Ok-Paket. Das enthält u.a. folgenden Eintrag (so ähnlich)

Contact: <sip:[email protected]:52011;transport=tls;line=irgendwas>;expires=660

Der Expire gibt an, wann Asterisk einen ReRegister ausführen muss. In diesem Fall wird er es nach 650 s tun. Standard bei der Telekom. Das solltest Du auch finden. Wird der ReRegister ausgeführt? Wenn Du zwischendrin keine eingehenden Anrufe bekommst, liegt das daran, dass Deine NAT-Session austimed. Fehler kannst Du dann bei Deinem Router suchen.
Asterisk / pjsip kennt da eine Hilfe zum Offenhalten des Ports. Nennt sich

qualify_frequency

in der aor-Konfiguration. Unter 240 s akzeptiert die Telekom aber nicht, wenn ich mich noch recht erinnere (zumindest, als ich es zuletzt getestet habe).

Ach ja: Vergiss nicht, dass Du sicherstellen musst, dass alle Requests immer zum gleichen Server gehen.

Ein FreePBX / Asterisk direkt an der globalen IP hat Verbindungszeiten bei ca. 0,2 s bis zum Trying seitens der Telekom (ausgehend brauchst Du halt noch Zeit für die Authentifizierung - ca. 0,04 s ). Die genannten Zeiten gelten zu einem TN, der ebenfalls bei der Telekom ist. Zu Fremdanschlüssen dauert es in der Regel deutlich länger. Wenn man einen leistungsstärkeren Server hat, könnten die Zeiten auch noch kürzer sein.

Viel Erfolg Dir!

 

[KunterBunter]

Reden wir hier tatsächlich von tel.t-online.de?

Nein. @mcmodem hat einen Magenta Zuhause REGIO Tarif.

 

[key.stroke]

Welchen Tarif habt ihr denn, weil ihr noch mit "tel.t-online.de" habt? Die Telekom hat mir diese Informationen (tel.mzregio.plusnet.de) so gegeben, doch wurde dort nicht das erste mal gelogen. Ich habe aber gestern mit (tel.t-online.de) getestet und keine Verbindung bekommen.
Ich bin zwar VoIP-Einsteiger, doch arbeite ich mit IP-Netzwerken seit 20 Jahren und habe im Bereich Planung und Fehlersuche einige Erfahrungen (Windparks und Solarparks). Auch IP-Tables und VPN-Tunnel kenne ich von meiner Arbeit. Da wird aber mehr mit TCP gearbeitet und die Software wird von Experten geschrieben, die auch direkt Support geben.
Was ich so Grauenhaft finde, ist das UDP-Protokoll. Bei RTP kann ich es noch verstehen, doch beim SIP hätte man TCP als Standard benutzen können. Nicht nur, das man dann eine sichere Verbindung hat, die man über eine Firewall und ein NAT laufen lassen kann. Auch die Verbindung Dyn-IP -> Fest-IP-Server wäre einfacher und sicherer.
Die Funkamateuere haben ihr DMR-Netzwerk auch in die falsche Richtung aufgebaut. Der Server hat eine feste IP und ist permanent erreichbar - statt dessen soll jede Station jeweils eine eigene Dyn-DNS-Adresse eingerichten, die dann unsicher ist und telweise zusätzlich Geld kostet.
Die System-Admins von Netzwerken machen sich schon bei jeder TCP-Port-Öffnung "in die Hose" - jetzt verlangen die VoIP-Anbieter, das ich eine Firewallöffnung und Weiterleitung zwischen 10000 und 40000! UDP-Ports einrichte. Bei max. 65535 verfügbaren Port kann ich die Firewall doch gleich deaktvieren und die Haustür offen lassen. In meinem Augen ein digitaler Selbstmord.
Naja. Vielleicht erschliesst sich ja der Sinn der Technik nach meinem VoIP-Lehrgang in Oldenburg bei der BFE.

Ich habe mal über Nacht an 3 Stellen (Router, Asterisk-Anlage, Telefon mit Direktverbindung) Hubs in die Netzwerkleitung geklemmt und mit 3 Rechnern Wireshark-Mitschnitte gemacht. Ich werde diese heute mal analyseiren.

Viellen Dank für die Informationen. Ich werde sie heute Abend umsetzen.

Mit freundlichem Gruß
Jens

 

[chrsto]

tel.t-online.de -> Eigene Telekom Infrastruktur. Tarifwelt MagentaZuhause, DeutschlandLAN etc.

tel.mzregio.plusnet.de -> Telekom Anschlüsse, die die Telekom als Wholesale bei anderen Anbietern einkauft. Tarifwelt MagentaZuhause Regio. Dort hat dann der andere Anbieter den Zuschlag für den Vectoringausbau bekommen und die Telekom mietet sich ein.

Bei VoIP ist grundsätzlich KEINE Portweiterleitung ins Netzwerk nötig (Ausnahme 1&1, ggf. andere Anbieter).

 

[key.stroke]

Hallo Chrsto.
Ich habe bei anderen Asterisk-Foren / Webseiten erfahren, das das STUN bei Asterisk nicht geht. Auch ich habe die Erfahrung gemacht (ich werte gerade die Wireshark-Mitschnitte von dieser Nacht aus), das keine STUN-Pakte von Asterisk gesendet werden. Ich habe in der RTP.CONF "stunaddr=stun.mzregio.plusnet.de" eingetragen. Doch es kommen keine STUN-Pakete. In anderen Foren wird immer auf die Weiterleitung von 5060, 3489, und den entsprechnenden RTP-Ports (z.B. 30000 bis 39999) hingewiesen, wenn man Asterisk einsetzen möchte.

Interessant sind auch die Unterschiede im Verhalten der Telefone:
Beides Grandstream GXP 1615:

Das Telekom-Telefon hat immer STUN-Pakete auf 5060! (alle 20sek) und macht alle Stunde eine neue Registrierung.
Auch ist die erste Registrierung immer mit 401 (Unauthorisiert) beantwortet worden. Der zweite Versuch (30ms später) dann mit 200 (OK) - obwohl beide Pakete identisch sind (bis auf die Zähler).
Vor jedem Registrierungsversuch wird eine DNS SRV Abfrage gestartet.

Bei Sipgate wird alle 5 Minuten eine neue Reistrierung ausgelöst, die sofort mit 200 (OK) beantwortet wird. STUN-Pakete (egal ob 3478 oder 5060) gibt es überhaupt nicht.
Hier wird alle 30 Minuten eine DNS SRV Abfrage gestartet - ob nun eine Registrierung stattfindet oder nicht.
Auch benutzt das Telefon den SourcePort 5160, ohne, das ich etwas wissendlich geändert habe.

Beide Telefone sind jungfreulich bei mir angekommen und aus dem versiegelten Karton entnommen worden.

Mit freundlichem Gruß
Jens

 

[chrsto]

In anderen Foren wird immer auf die Weiterleitung von 5060, 3489, und den entsprechnenden RTP-Ports (z.B. 30000 bis 39999) hingewiesen, wenn man Asterisk einsetzen möchte.

Nur weil das Empfohlen wird, macht es das nicht richtiger.

Die Telefonie bei der Telekom funktioniert in der Form, dass sich deine Anlage beim Telekom SIP Server registriert. Diese Verbindung wird über "keepalives" gehalten. Kommt nun ein Anruf rein, benutzt der Telekom Server diese Verbindung um das INVITE deiner Anlage mitzuteilen. Daraufhin baut deine Anlage eine RTP Verbindung zum Telekom Server auf. Über diese Verbindung erfolgt dann der Austausch der Sprachpakete in beide Richtungen.

Ein Verbindungsaufbau findet also nur ausgehend statt. Die Weiterleitung von Ports bringt daher gar nichts, nur potentielle Sicherheitslücken.

Nachlesen kann man das in der technischen Unterlage der Telekom, oder wer es technischer mag in der TR 114(?). Zugegeben, die Unterlagen sind für die "eigenen" Anschlüsse der Telekom, für die Regio Tarife wird es aber analog funktionieren.

 

[key.stroke]

Hallo Chrsto.
Haben Sie eine Beispielvorlage ?
pjsip.conf, rtp.conf, extension.conf ?
VIelleicht löst das mein Problem?

Mit freundlichem Gruß
Jens

 

[chrsto]

Da muss jemand anderes ran. Meine Experimente mit Asterisk liegen Jahre zurück.