CyberSW

Du solltest mehr zum Aufbau deines Netzes posten - da wird der Fehler wohl zu finden sein.

Zur Verbindung der relevanten Komponenten:

VDSL <=> FritzBox <=> Asterisk (PJSIP)-basierende Telefonanlage <=> interner ISDN NT (mISDN) <=> Eumex <=> Analog-Telefone

Die im ursprünglichen Post besagte Untersuchung mit Wireshark wurde zwischen FritzBox und Asterisk vorgenommen.

Die FritzBox ist mit entsprechender Port-Freigabe in der IPv4 Firewall konfiguriert (SIP (1 port) und RTP (port range), beides UDP). Der verwendete SIP-Port ist selbstverständlich nicht 5060 (da von FritzBox selbst schon belegt). Asterisk verwendet selbstverständlich die externe/public IP in SIP Headern.

Wir möchten an dieser Stelle klarstellen, dass der Aufbau mit seiner Konfiguration seit der Umstellung auf IP-Telefonie durch die Telekom _ohne_ das geschilderte Problem lief -- bis eben vor einigen Wochen. Den genauen Zeitpunkt an dem das Problem erstmalig Auftrat kann nicht rekonstruiert werden.

Insofern, @CyberSW, ist uns momentan unklar, inwiefern das Problem lokal bei uns liegen könnte. Zumal es, wie geschildert so ist, dass der Telekom-Server das SIP BYE 404 sendet. Die "Aktion" geht also nicht von uns lokal aus. Uns ist durchaus klar, dass die "Aktion" durch eine lokale Gegebenheit bei uns hervorgerufen werden kann. Doch warum erst seit diesen letzten Wochen? Der grundsätzliche Aufbau mit Konfig bei uns lokal hat sich nicht geändert.

Wir halten das Versenden von SIP BYE + 404, für insbesondere eingehende Verbindungen, nach scheinbar zufällige Zeitspannung _nach_ erfolgreicher Verbindungenaufnahmen, grundsätzlich für einen Zustand, den es nicht geben darf.

Daher lautet unsere Vermutung, dass es sich zumindest um einen falsche Reason-Code handelt und uns der Telekom-Server den eigentlichen Grund (sprich ein anderer 4xx) für den Abbau der Verbindung eben nicht mitteilt.

Uns würde auch interessieren was der Zusatz "(1:27)" bedeutet. Ein zugegeben bislang nur minmal kurzer Blick in RFCs 3326 und 3261 gibt uns keinen Aufschluss über die Bedeutung dieser zusätzlichen Zeichen nach "Not Found".

Hallo @longshot006,

ich kann Ihre Erkenntnisse bezüglich der spezielle Art und Weise der Abbrüche bestätigen - sogar mit meinen Wireshark-Mitschnitten aus dem letzten Jahr im Sommer. Ich habe zwar nicht alle Mitschnitte durchgesehen, aber in 5 Stück davon zeigt sich exakt der von Ihnen beschriebene Effekt: Der Abbruch durch das SIP BYE (404, Zusatz "1:27") vom Telekom-Server passiert immer nach einem Wechsel der Registry Adresse.
Hinzu kommt, dass die Zeit zwischen Neu-Registrierung und Abbruch immer ziemlich genau 110 Sekunden beträgt - bei Ihnen auch?

Als Workaround geben Sie an, dass Sie die Asterisk Konfiguration einmal pro Tag dynamisch ergänzen. Reicht das wirklich aus?

Denn: Die Telekom hat ja aktuell 3 Adressen mit 3 verschiedenen Prioritäten in der SRV-Records hinterlegt. Davon scheint Asterisk, nachvollziehbarerweise, immer den mit höchste Priorität auszuwählen. Nun habe ich allerdings nach einem kleinen Test über ein paar Stunden heute festgestellt, dass sich die angegebenen SRV-Records schon nach kurzer Zeit ändern (f, h2, d vs. h, h2, d).

Wenn man die Asterisk Konfiguration einmal am Tag anpasst, dann wird es also vorkommen, dass der verwendete Registry Endpunkt zu bestimmten Zeiten während des Tages gar nicht in der Liste der SRV-Records vorkommt. Genau dieser Umstand macht bei Ihnen also nichts "kaputt"? (Man könnte sich ja vorstellen, dass ein nicht gelisteter Telekom-Server auch nicht erreichbar ist, zumindest nicht garantiert, wenn er eben nicht in der Liste der SRV-Records ist).

Ihren Aussage entnehme ich weiterhin, dass es sich bei "unserem" Problem hier im Thread, um ein Problem in Asterisk (PJSIP) handelt? Ich frage mich gerade was die Spec dazu sagt? Verlangt die Spec, dass sich ein Client, bei laufendem Call, trotzdem noch an einem "alten" Registry Endpunkt re-registriert - der evtl. gar nicht mehr gelistet ist? Das scheint doch auf den ersten Blick auch irgendwie seltsam zu sein, wenn dem so sein sollte?

Hallo @fttelfor,

"Hinzu kommt, dass die Zeit zwischen Neu-Registrierung und Abbruch immer ziemlich genau 110 Sekunden beträgt - bei Ihnen auch?" Ja, exakt 110 Sekunden.

Durch diese tägliche Anpassung von der config (/etc/asterisk/pjsip.conf) wird statt tel.t-online als Registrar und Endpoint die "Rückgabe" von nslookup verwendet, um beides an einen Host "festzupinnen". Beispielsweise an d-epp-100.edns.t-ipnet.de:

<Registration/ServerURI..............................> <Auth..........> <Status.......>
==========================================================================================

telekom_XXXXXXX_reg/sip:d-epp-100.edns.t-ipnet.de:5060 telekom_auth Registered
telekom_YYYYYYY_reg/sip:d-epp-100.edns.t-ipnet.de:5060 telekom_auth Registered
telekom_ZZZZZZ_reg/sip:d-epp-100.edns.t-ipnet.de:5060 telekom_auth Registered

Objects found: 3

die Tägliche Rotation soll nur dafür sorgen, dass nicht irgendwann mal ein zu dekommissionierender Host in der Config stehen bleibt.

Also bei mir läuft das ganze Konstrukt schon seit Wochen sehr stabil und ohne Probleme. Dass im nslookup Hosts auftauchen und wieder verschwinden liegt vermutlich am loadbalancing, hat aber keine Auswirkungen auf die erreichbarkeit respektive Funktionalität des Hosts.

Ich bin auch eher aus pragmatischen Gründen auf pjsip gewechselt, da mit chan_sip die Session-Timer nicht sauber funktioniert haben. chan_sip hat aber auch etwas anders gerade bei lookups gearbeitet als es pjsip tut. so kann man bei chan_sip diese srv-lookups komplett abstellen und verwendet damit immer direkt die IP von tel.t-online.de (217.0.128.133). Eigentlich sollte das pjsip mittels loose routing (;lr) auch können aber leider haperts da etwas an der Umsetzung.

Was interessant wäre: Wie verhält sich die original-Hardware der Telekom in dieser Thematik?

Ich habe das Script mal angehangen. ggf. sind auf nicht-englischen und/oder nicht-ubuntu-Installationen anpassungen nötig.

Es wird noch eine pjsip.conf als "Template" benötigt, da die ursprüngliche pjsip.conf mit Hilfe dieses "Templates" generiert wird. Klar kann man das auch anders machen aber ich hab mich halt für diesen Weg entschieden.

Hallo @xuser_gugs ,

bei uns ist jetzt leider das selbe herausgekommen. Auerswald und Telekom haben sich bei der Untersuchung immer wieder gegenseitig beschuldigt und es ging so lange ergebnislos hin und her, dass wir nun auch den Provider gewechselt haben (zu easybell). Hier tritt das Problem nicht mehr auf und wir können ohne Gesprächsabbrüche telefonieren. Man muss der Telekom (bzw. dem Telekomhilft-Team) allerdings zu Gute halten, dass sie sehr engagiert sind und auch die Portierung der wichtigsten Rufnummern während der Vertragslaufzeit ermöglicht haben.

Falls noch jemand das gleiche Problem haben sollte muss ich allerdings zum selben Schritt zu raten. Ich habe wirklich alles versucht um das Problem zu lösen, aber hier rennt man auf technischer Seite bei der Telekom gegen Windmühlen an. Die Technikabteilung der Telekom scheint hier nicht sehr viel Interesse zu haben das Problem zu untersuchen und auszuräumen.

Viele Grüße

Daniel