Hallo zusammen,
vor wenigen Tagen hat mich der Kollege cpuprofi aus dem Urlaub um Rat gefragt, weil es bei einem seiner Telekom-Kunden ein Problem mit der Telefonie gibt, jetzt habe ich das gleiche Problem bei etlichen Kunden auch (es dauert bei diesem Problem etwas, ehe das als (dauerhafte) Störung wahrgenommen wird, weil es zwischenzeitlich immer wieder funktioniert und auch der LANCOM-Router keinen Fehler anzeigt, z. B. eine nichtregistrierte SIP-Leitung, wo ich ja schon längst eine E-Mail bekommen hätte vom Router).
Problembeschreibung:
Der LANCOM-Router gibt bei seinem REGISTER bei der Telekom eine (Wunsch-)Expires-Time von 1620 s an, das sind 27 Minuten. Der SIP-Server der Telekom gibt im OK-Paket eine Expires-Time von 660 s an, das sind 11 Minuten. Diese Expires-Time wird wohl an einer anderen Stelle im SIP-Packet angegeben, als früher/bisher. Es erfolgt im Contact-Parameter, die entsprechende Zeile sieht so aus (XXX=Datenschutz):
Contact: <sip:+497251300XXX@91.5.XXX.XXX:14420;transport=UDP>;expires=660;+sip.instance="<urn:uuid:3c574daf-8aa5-82c7-a71f-f0d54f4315fc>"\r\n
Der LANCOM-Router ignoriert diese Expires-Time offenbar, weil er sie nicht erkennt. Er registriert sich erst wieder kurz nach Ablauf seiner Expires-Time von 1620 s (27 Min.), also genau genommen nach 90 % dieser Zeit, also nach 1458 s (24 Min. u. 18 s).
Im Endeffekt führt das dazu, dass die Telefonie für 11 Minuten funktioniert und dann für 13 Minuten und 18 s nicht. (In der Zeit des Nichtfunktionierens kann man weder rausrufen (Forbidden ohne weitere Angabe von Gründen), noch ist man von außen erreichbar.)
Das Problem ist in neueren Firmwares gefixt bzw. nicht existent. Aufgetreten ist das Problem z. B. in den Versionen 10.50.0423 und 10.34.0458 (ich aktualisiere diese Liste hier die folgenden Tage).
Das Problem tritt seit mind. 23.01.2025 auf. Davor funktionierte alles fehlerfrei.
Fragen:
Kann mir jemand sagen, ab welchen Firmwareständen (Mehrzahl, also für jede Major-Version) das Problem gefixt bzw. nicht existent ist?
Und weiß jemand genau, was die Telekom geändert hat? (Ich müsste mal einen alten Trace raussuchen, was früher anders war.)
Vielen Dank und viele Grüße
Jirka
Was hat die Telekom schon wieder am VoIP geändert? (...womit ein LANCOM-Router mit älterer Firmware nicht klar kommt?)
Moderator: Lancom-Systems Moderatoren
Re: Was hat die Telekom schon wieder am VoIP geändert? (...womit ein LANCOM-Router mit älterer Firmware nicht klar kommt
Haben sich die LANCOMs überhaupt an den EXPIRES-Wert angepasst?
Ich hatte das Problem sehr lange an einer Unify OpenScape Business. Die hat 180 Sekunden gemeldet, der Router stand auf 30 Minuten.
Mir wurde das Problem bestimmt fünf Jahre lang gemeldet, bis ich es dann irgendwann vor kurzem gefunden habe.
Ich hatte das Problem sehr lange an einer Unify OpenScape Business. Die hat 180 Sekunden gemeldet, der Router stand auf 30 Minuten.
Mir wurde das Problem bestimmt fünf Jahre lang gemeldet, bis ich es dann irgendwann vor kurzem gefunden habe.
LCS NC/WLAN
Re: Was hat die Telekom schon wieder am VoIP geändert? (...womit ein LANCOM-Router mit älterer Firmware nicht klar kommt
Na offenbar nicht, das ist ja das Problem.5624 hat geschrieben: Gestern, 17:03 Haben sich die LANCOMs überhaupt an den EXPIRES-Wert angepasst?
Wobei ich im Augenblick gar nichts mehr verstehe. Ich habe eine leicht neuere Firmware installiert (also auch als "alt" zu bezeichnen, 10.34.0469), jetzt geht wieder alles. Der LANCOM schlägt plötzlich 480 s als Expires-Time vor. Offenbar hat nicht das Update das Problem verschwinden lassen, sondern der Neustart.
Der Neustart mit dem Firmware-Update hat eine Änderung der WAN-IP zur Folge. Nun steht 45 Minuten später doch tatsächlich doch die alte Registrierung, also mit der alten WAN-IP im OK-Paket unten mit drin mit 3600 s?! Wo kommen denn jetzt die 3600 her? Und die zählen auch gar nicht runter?!
Contact: <sip:+497251300XXX@91.5.XXX.XXX:14420;transport=UDP>;expires=3600;+sip.instance="<urn:uuid:3c574daf-8aa5-82c7-a71f-f0d54f4315fc>"\r\n
Und die zweite Zeile (also die mit der aktuellen WAN-IP) steht jetzt auf 480 s?
Contact: <sip:+497251300XXX@91.5.YYY.YYY:9506;transport=UDP>;expires=480;+sip.instance="<urn:uuid:d716b79c-dce3-dcbe-93e0-68978c59b16b>"\r\n
Man, man, man, ich dachte die VoIP-Probleme gehören langsam der Vergangenheit an.
-
Dr.Einstein
- Beiträge: 3467
- Registriert: 12 Jan 2010, 14:10
Re: Was hat die Telekom schon wieder am VoIP geändert? (...womit ein LANCOM-Router mit älterer Firmware nicht klar kommt
Das war aber eine SIP-PBX Verbindung, kein SIP-Trunk oder SIP-Provider-Verbindung, oder? Zumindest kann ich mich an einen Bug diesbezüglich in der 10.20 oder so erinnern.5624 hat geschrieben: Gestern, 17:03 Ich hatte das Problem sehr lange an einer Unify OpenScape Business. Die hat 180 Sekunden gemeldet, der Router stand auf 30 Minuten.
Bei SIP-Leitungen wurde der Expire Timer meines Wissens nach immer beachtet. Außer vielleicht in einzelnen fehlerhaften Rel/RU-Versionen.
Re: Was hat die Telekom schon wieder am VoIP geändert? (...womit ein LANCOM-Router mit älterer Firmware nicht klar kommt
Es sind SIP-Provider-Verbindungen. Jeder Standort hat eine Einzelrufnummer an der OSBiz.
Wie gesagt, das Problem bestand mindestens fünf Jahre lang und definitiv über viele Versionen hinweg. Selbst bei der 10.42 wars noch da (manche unserer Router haben noch diesen Stand und gelöst hab ich das Problem erst 2024 oder 2025).
Rein theoretisch müsste ich es, durch Änderung des REGISTER-Intervalls auf fünf unserer Router noch provozieren können. Für die 10.80 und 10.9x kann ich keine Aussage treffen, da hier im Template von Anfang an der Wert geändert wurde.
Wie gesagt, das Problem bestand mindestens fünf Jahre lang und definitiv über viele Versionen hinweg. Selbst bei der 10.42 wars noch da (manche unserer Router haben noch diesen Stand und gelöst hab ich das Problem erst 2024 oder 2025).
Rein theoretisch müsste ich es, durch Änderung des REGISTER-Intervalls auf fünf unserer Router noch provozieren können. Für die 10.80 und 10.9x kann ich keine Aussage treffen, da hier im Template von Anfang an der Wert geändert wurde.
LCS NC/WLAN
Re: Was hat die Telekom schon wieder am VoIP geändert? (...womit ein LANCOM-Router mit älterer Firmware nicht klar kommt
So, also es sind irgendwie mehrere Probleme, die hier zusammenkommen. In der großen Hoffnung, dass das hier jemand liest (awi, Dr. Einstein), werde ich hier jetzt noch mal einiges beschreiben und versuchen, die Probleme zu trennen.
Das Kernproblem habe ich oben beschrieben, allerdings nicht, wie es dazu kommt. Weil ich es ja auch nicht genau weiß oder nachvollziehen kann. Dr. Einstein hat heute Abend herausgefunden, dass es wohl SIP-Server seitens der Telekom gibt, die mit 1.620 s Expire-Time arbeiten. Deswegen fange ich jetzt ganz am Anfang an.
Also es gibt ja diese DNS-SRV-Auflösung für die SIP-Server. SRV sind Service Records. Über einen Service Record können mehrere Server angegeben werden mit entsprechendem Port und Priorität. Das sieht dann so aus:
Nun gab es also einen Schwenk des SIP-Servers (der SIP-Leitung) aufgrund geänderter SIP-SRV-Priorität. (Dr. Einstein hat es nachvollzogen, danke!)
Dieser Schwenk führte irgendwann zu einem SIP-Server mit der Expire-Time von 1.620 s. Und vor kurzem (im nachvollzogenen Beispiel von Dr. Einstein am 27.01. um 00:34 Uhr) wieder zurück zu einem SIP-Server mit Expire-Time von 660 s.
Davon abgesehen, dass es sicher nicht schön ist, dass die SIP-Server mit unterschiedlichen Expires-Zeiten arbeiten, tritt nun das erste Problem auf: Der LANCOM fordert in neuen REGISTER-Paketen immer wieder die 1.620 s als Expires an, obwohl es echt sinnfrei ist. Für diesen Schönheitsfehler wird Dr. Einstein morgen einen Low-Prio-Case bei Lancom einreichen.
Ältere Firmwares leiden jedoch, und nun kommen wir zum zweiten Problem, dem eigentlichen Kernproblem, was die Ausfälle verursacht, darunter, dass sie die vom SIP-Server vorgegebene Expires-Zeit nicht einhalten bzw. schlicht nicht verarbeiten. Der SIP-Server gibt also die 660 s an und der LANCOM IGNORIERT das und zieht seine angeforderten 1.620 s durch. In der Folge kommt es, wie oben in meinem Eingangsposting ausführlich beschrieben, zu massiven Störungen. Im konkreten Fall ist die Telefonie 55 % der Zeit gestört. Weder rein noch raus geht es in der Zeitspanne der Störung. Meine Frage: Mit welchen Firmware-Versionen wurde das Problem gefixt? Mit einer 10.80-RU13 tritt es jedenfalls nicht auf. In den Release-Notes habe ich nach nunmehr ausführlicher Suche Folgendes gefunden:
Demnach gilt offenbar: Alles vor 10.50.0530-RU4 ist von dem Kernproblem betroffen, alles danach nicht mehr. Router mit All-IP-Option die nicht mindestens die 10.50 bekommen, kann man also verschrotten oder man muss sich von der Telekom trennen und zu einem der Billig-SIP-Anbieter gehen, am besten mit nur einem einzigen SIP-Server. Mir stößt es, wie man sieht, sauer auf, wenn ich überlege, dass man so einen fatalen Fehler nicht wenigstens noch auf Firmwares rückportiert, die noch RUs oder SUs bekommen.
So, nun geht es aber weiter. Allerdings eher mit einem komischen Problem auf Telekom-Seite, das wäre das dritte Problem:
Startet man den LANCOM neu, passiert Folgendes:
Der LANCOM schickt ein REGISTER mit Expires 0 an den SIP-Server. [Anmerkung: Das Verhalten wurde offenbar mit der Firmware 10.50 geändert. Es gibt kein REGISTER mit Expires 0 nach Neustart des LANCOM-Routers mehr. Das wusste ich auch noch nicht. Unglaublich, was sich immer alles von Version zu Version ändert. Man kommt irgendwie nicht mehr hinterher, insbesondere, weil man einen nicht einheitlichen Firmwarestand hat. Was waren das doch früher schöne Zeiten, als man alle LANCOM-Router auf einer Firmware hatte. Leider alles vorbei.] Das Expires 0 ist eine Eigenart des LANCOM-Routers, die damals so implementiert wurde, um einen definierten Start zu haben. Das Expires 0 soll nämlich alle Registrierungen zu der SIP-Leitung löschen. Was grundsätzlich gut gedacht ist, kann natürlich bei Mehrfachregistrierungen zu blöden Situationen führen, die bisher sauber registrierte andere Seite fliegt in dem Moment raus. Nun gut, das ist nun seit Jahren so, wenn man es weiß, dann meldet man sich lieber über VPN am LANCOM mit der Mehrfachregistrierung, als direkt beim Provider. Man muss es also wissen und dann passt das schon.
Aber was macht die Telekom daraus?!
Der LANCOM-Router registriert sich dann ordnungsgemäß - übrigens mit der Default-Expire-Time von 480 s. Im untersten OK-Paket sieht man dann aber, dass die Telekom die alte SIP-Registrierung (WAN-IP des LANCOMs vor Neustart) nicht nur sogar noch drin hat, nein, sie ist sogar auf expires=3600 gesetzt. Und dieser Expires-Wert zählt auch nicht runter, wie man es früher kannte, also beim nächsten OK-Paket hat man dann schön gesehen, dass die Zeit der Registrierung ablief. Aber hier bleibt es anderthalb Stunden (ja, anderthalb, ich verstehe es auch nicht, denn 3600 Sekunden sind ja eigentlich eine Stunde) so drin stehen. Das ist mir völlig unverständlich, was die Telekom da macht. Erstens, wo kommen die 3.600 s her? Zweitens wieso ist der Eintrag überhaupt noch da? (Hier könnte man erklären, dass das REGISTER mit Expire 0 von einer anderen IP kam und die Telekom keine fremden Registrierungen von einem UA löschen lassen will. Ohne das REGISTER mit Expire 0 (also ab Firmware 10.50) ist das hier übrigens unverändert, die Zeile steht auch dann mit 3.600 s dadrin.) Und drittens, wieso geht der Eintrag erst nach anderthalb Stunden raus?! Während ein REGISTER mit 1.260 s, was von der Telekom auf 660 s runtergedrückt wird, auch nach 660 s verschwindet. Das ist doch alles sehr komisch und nicht erklärbar. Auch nicht, wozu das gut sein soll.
Fakt ist aber auch, dass das Problem, dass es plötzlich einen SIP-Server mit 1.620 s gibt, während andere SIP-Server sagen nicht mehr als 660 s, der Auslöser des Problems ist, schließlich hat die SIP-Telefonie jahrelang funktioniert.
Fildercom hatte ja neulich auch ein Problem, was in die Richtung ging. Hoffentlich ist bald mal ein Punkt erreicht nach nunmehr 20 Jahren SIP-Telefonie (Ich hatte 2006 meinen 1722 gekauft, und damit meinen ersten VoIP-Router.), bzw. 10 Jahren SIP-Telefonie bei der Telekom, wo man an die Zuverlässigkeit vom alten ISDN heran kommt. Manchmal habe ich den Eindruck, die Festnetztelefonie ist regelrecht kaputt gemacht worden durch die ganzen SIP-Probleme. Hat schon mal jemand bei WhatsApp einen Gesprächsabbruch gehabt? Im SIP habe ich das regelmäßig und zu definierten Zeiten, je nachdem, wer gerade anruft. Es wundert also nicht, wenn die Leute immer mehr zum reinen Handy übergehen als Telefoniegerät. Die ganze SIP-Telefonie ist zu fehleranfällig und im Betrieb zu teuer.
Für mich bleibt die Erkenntnis, dass man mit All-IP-Option dringend auf die Firmware 10.50 oder höher setzen sollte. Darunter erlebt man ansonsten derartige Überraschungen.
Vielen Dank und viele Grüße
Jirka
Das Kernproblem habe ich oben beschrieben, allerdings nicht, wie es dazu kommt. Weil ich es ja auch nicht genau weiß oder nachvollziehen kann. Dr. Einstein hat heute Abend herausgefunden, dass es wohl SIP-Server seitens der Telekom gibt, die mit 1.620 s Expire-Time arbeiten. Deswegen fange ich jetzt ganz am Anfang an.
Also es gibt ja diese DNS-SRV-Auflösung für die SIP-Server. SRV sind Service Records. Über einen Service Record können mehrere Server angegeben werden mit entsprechendem Port und Priorität. Das sieht dann so aus:
Code: Alles auswählen
root@LN_Router-DSL:/
> show vcm dns
DNS Cache:
1. Cache Entry:
SRV string: _sip._udp.tel.t-online.de
Routing Tag: 0
Use Count: 1 SIP registrar line depends on this cache entry
Pending DNS queries:
None.
Cached SRV records for this key (sorted by preference):
Priority | Weight | TTL | Port | Target
10 | 0 | 971 | 5060 | stg010-l01-mav-pc-rt-001.edns.t-ipnet.de
20 | 0 | 971 | 5060 | nes008-f01-mav-pc-rt-001.edns.t-ipnet.de
30 | 0 | 971 | 5060 | hno002-l01-mav-pc-rt-001.edns.t-ipnet.de
No CNAME records cached for this key.
Cached address records for this key (sorted by DNS name, then IPv6 first):
Address | TTL | DNS name
217.0.147.197 | 548 | hno002-l01-mav-pc-rt-001.edns.t-ipnet.de
217.0.147.5 | 854 | nes008-f01-mav-pc-rt-001.edns.t-ipnet.de
217.0.146.197 | 459 | stg010-l01-mav-pc-rt-001.edns.t-ipnet.de
Dieser Schwenk führte irgendwann zu einem SIP-Server mit der Expire-Time von 1.620 s. Und vor kurzem (im nachvollzogenen Beispiel von Dr. Einstein am 27.01. um 00:34 Uhr) wieder zurück zu einem SIP-Server mit Expire-Time von 660 s.
Davon abgesehen, dass es sicher nicht schön ist, dass die SIP-Server mit unterschiedlichen Expires-Zeiten arbeiten, tritt nun das erste Problem auf: Der LANCOM fordert in neuen REGISTER-Paketen immer wieder die 1.620 s als Expires an, obwohl es echt sinnfrei ist. Für diesen Schönheitsfehler wird Dr. Einstein morgen einen Low-Prio-Case bei Lancom einreichen.
Ältere Firmwares leiden jedoch, und nun kommen wir zum zweiten Problem, dem eigentlichen Kernproblem, was die Ausfälle verursacht, darunter, dass sie die vom SIP-Server vorgegebene Expires-Zeit nicht einhalten bzw. schlicht nicht verarbeiten. Der SIP-Server gibt also die 660 s an und der LANCOM IGNORIERT das und zieht seine angeforderten 1.620 s durch. In der Folge kommt es, wie oben in meinem Eingangsposting ausführlich beschrieben, zu massiven Störungen. Im konkreten Fall ist die Telefonie 55 % der Zeit gestört. Weder rein noch raus geht es in der Zeitspanne der Störung. Meine Frage: Mit welchen Firmware-Versionen wurde das Problem gefixt? Mit einer 10.80-RU13 tritt es jedenfalls nicht auf. In den Release-Notes habe ich nach nunmehr ausführlicher Suche Folgendes gefunden:
Wieso gab es dafür keinen Bugfix in der 10.42? Verstehe ich nicht. Ehrlich nicht. Der letzte RU der 10.42 kam im Dezember 2022, es war also ein Jahr Zeit, das zu implementieren, aber es wurde offenbar unterlassen. Jedenfalls finde ich nichts dazu in den Release Notes. Der LANCOM 1781VA-4G hatte bis Februar 2022 normale Updates.LCOS-Änderungen 10.50.0530 RU4 (12.01.2022)
Der Voice Call Manager handelt mit dem SIP-Provider einen Wert für die Aktualisierung der Registrierung (Min-Expires) aus und verwendet diesen. In Szenarien, in denen der SIP-Provider im „200 OK“ nach dem REGISTER im Contact Feld einen kleineren ‚Expires‘-Wert vorgab, wurde dieser vom Voice Call Manager nicht berücksichtigt. Dies führte dazu, dass die Registrierung nach Ablauf des ‚Expires‘-Wertes abbrach.
Demnach gilt offenbar: Alles vor 10.50.0530-RU4 ist von dem Kernproblem betroffen, alles danach nicht mehr. Router mit All-IP-Option die nicht mindestens die 10.50 bekommen, kann man also verschrotten oder man muss sich von der Telekom trennen und zu einem der Billig-SIP-Anbieter gehen, am besten mit nur einem einzigen SIP-Server. Mir stößt es, wie man sieht, sauer auf, wenn ich überlege, dass man so einen fatalen Fehler nicht wenigstens noch auf Firmwares rückportiert, die noch RUs oder SUs bekommen.
So, nun geht es aber weiter. Allerdings eher mit einem komischen Problem auf Telekom-Seite, das wäre das dritte Problem:
Startet man den LANCOM neu, passiert Folgendes:
Code: Alles auswählen
[SIP-Packet] 2026/01/30 00:17:44,127 [Packet]:
Sending datagram (544 Bytes) from 91.5.25.241:11076 to 217.0.147.5:5060 using UDP (RtgTag 0):
REGISTER sip:tel.t-online.de SIP/2.0\r\n
Via: SIP/2.0/UDP 91.5.25.241:11076;branch=z9hG4bK-f5cb8c46-ac351eee;rport\r\n
From: "+497251300XXX"<sip:+497251300XXX@tel.t-online.de>;tag=232687746-1582034971\r\n
To: "+497251300XXX"<sip:+497251300XXX@tel.t-online.de>\r\n
Call-ID: +497251300XXX-tel.t-online.de-18d88bb5@00a0574b9a64\r\n
CSeq: 1 REGISTER\r\n
Allow: REGISTER, INVITE, ACK, CANCEL, BYE, REFER, NOTIFY, OPTIONS, PRACK, UPDATE, SUBSCRIBE, INFO\r\n
Max-Forwards: 70\r\n
Contact: *\r\n
Expires: 0\r\n
User-Agent: LANCOM 1784VA (over ISDN) 10.34.0442\r\n
Content-Length: 0\r\n
\r\n
[SIP-Packet] 2026/01/30 00:17:44,160 [Packet]:
Receiving datagram (424 Bytes) at 91.5.25.241:11076 from 217.0.147.5:5060 using UDP (RtgTag 0):
SIP/2.0 200 OK\r\n
Via: SIP/2.0/UDP 91.5.25.241:11076;received=91.5.25.241;branch=z9hG4bK-f5cb8c46-ac351eee;rport=11076;dt-wcdereg\r\n
From: "+497251300XXX" <sip:+497251300XXX@tel.t-online.de>;tag=232687746-1582034971\r\n
To: "+497251300XXX" <sip:+497251300XXX@tel.t-online.de>;tag=02E4606C1405-14b7-4e8c5700-317597-697bea99-b99a1\r\n
CSeq: 1 REGISTER\r\n
Call-ID: +497251300XXX-tel.t-online.de-18d88bb5@00a0574b9a64\r\n
Content-Length: 0\r\n
\r\nAber was macht die Telekom daraus?!
Code: Alles auswählen
[SIP-Packet] 2026/01/30 00:17:44,661 [Packet]:
Sending datagram (596 Bytes) from 91.5.25.241:11076 to 217.0.147.5:5060 using UDP (RtgTag 0):
REGISTER sip:tel.t-online.de SIP/2.0\r\n
Via: SIP/2.0/UDP 91.5.25.241:11076;branch=z9hG4bK-5bda6038-9fae48e5;rport\r\n
From: "+497251300XXX"<sip:+497251300XXX@tel.t-online.de>;tag=1565799286-914737755\r\n
To: "+497251300XXX"<sip:+497251300XXX@tel.t-online.de>\r\n
Call-ID: +497251300XXX-tel.t-online.de-18d88bb5@00a0574b9a64\r\n
CSeq: 2 REGISTER\r\n
Allow: REGISTER, INVITE, ACK, CANCEL, BYE, REFER, NOTIFY, OPTIONS, PRACK, UPDATE, SUBSCRIBE, INFO\r\n
Max-Forwards: 70\r\n
Contact: <sip:+497251300XXX@91.5.25.241:11076;transport=UDP>\r\n
Expires: 480\r\n
User-Agent: LANCOM 1784VA (over ISDN) 10.34.0442\r\n
Content-Length: 0\r\n
\r\n
[SIP-Packet] 2026/01/30 00:17:44,800 [Packet]:
Receiving datagram (759 Bytes) at 91.5.25.241:11076 from 217.0.147.5:5060 using UDP (RtgTag 0):
SIP/2.0 401 Unauthorized\r\n
Via: SIP/2.0/UDP 91.5.25.241:11076;received=91.5.25.241;branch=z9hG4bK-5bda6038-9fae48e5;rport=11076\r\n
WWW-Authenticate: Digest algorithm=MD5,realm="tel.t-online.de",nonce="4e42414e4241294bed0ff8998e2fa560cf0403d561eb",qop="auth"\r\n
From: "+497251300XXX" <sip:+497251300XXX@tel.t-online.de>;tag=1565799286-914737755\r\n
To: "+497251300XXX" <sip:+497251300XXX@tel.t-online.de>;tag=mavodi-0-4b-b5-5-ffffffc7-975-ffffffffffffffff-76df0000-6939f6e2-_028A41DE0554-1645-a2bdb700-3278f1c-697bea9a-5f338\r\n
Call-ID: +497251300XXX-tel.t-online.de-18d88bb5@00a0574b9a64\r\n
CSeq: 2 REGISTER\r\n
Reason: SIP;cause=401;text="CC_SIP_UNAUTHORIZED_401"\r\n
Session-ID: 00000000000000000000000000000000; remote=854ce779fa114f7650257b9f9cde075f\r\n
Content-Length: 0\r\n
\r\n
[SIP-Packet] 2026/01/30 00:17:44,801 [Packet]:
Sending datagram (867 Bytes) from 91.5.25.241:11076 to 217.0.147.5:5060 using UDP (RtgTag 0):
REGISTER sip:tel.t-online.de SIP/2.0\r\n
Via: SIP/2.0/UDP 91.5.25.241:11076;branch=z9hG4bK-92f29454-1b691903;rport\r\n
From: "+497251300XXX"<sip:+497251300XXX@tel.t-online.de>;tag=1565799286-914737755\r\n
To: "+497251300XXX"<sip:+497251300XXX@tel.t-online.de>\r\n
Call-ID: +497251300XXX-tel.t-online.de-18d88bb5@00a0574b9a64\r\n
CSeq: 3 REGISTER\r\n
Allow: REGISTER, INVITE, ACK, CANCEL, BYE, REFER, NOTIFY, OPTIONS, PRACK, UPDATE, SUBSCRIBE, INFO\r\n
Max-Forwards: 70\r\n
Contact: <sip:+497251300XXX@91.5.25.241:11076;transport=UDP>\r\n
Expires: 480\r\n
User-Agent: LANCOM 1784VA (over ISDN) 10.34.0442\r\n
Authorization: Digest username="anonymous@t-online.de", realm="tel.t-online.de", algorithm=MD5, uri="sip:tel.t-online.de", nonce="4e42414e4241294bed0ff8998e2fa560cf0403d561eb",qop=auth, cnonce="6f5c7c0fda16bd27", nc=00000001, response="d788db6fb8962800e370503bc454d0ff"\r\n
Content-Length: 0\r\n
\r\n
[SIP-Packet] 2026/01/30 00:17:44,896 [Packet]:
Receiving datagram (1255 Bytes) at 91.5.25.241:11076 from 217.0.147.5:5060 using UDP (RtgTag 0):
SIP/2.0 200 OK\r\n
Via: SIP/2.0/UDP 91.5.25.241:11076;received=91.5.25.241;branch=z9hG4bK-92f29454-1b691903;rport=11076\r\n
From: "+497251300XXX" <sip:+497251300XXX@tel.t-online.de>;tag=1565799286-914737755\r\n
To: "+497251300XXX" <sip:+497251300XXX@tel.t-online.de>;tag=mavodi-0-4b-b5-5-ffffffc7-975-ffffffffffffffff-76df0000-6939f6e2-_028A41DE0554-1645-a2bdb700-3278f1d-697bea9a-76622\r\n
Call-ID: +497251300XXX-tel.t-online.de-18d88bb5@00a0574b9a64\r\n
CSeq: 3 REGISTER\r\n
Contact: <sip:+497251300XXX@91.5.12.152:9506;transport=UDP>;expires=3600;+sip.instance="<urn:uuid:d716b79c-dce3-dcbe-93e0-68978c59b16b>"\r\n
Contact: <sip:+497251300XXX@91.5.25.241:11076;transport=UDP>;expires=480;+sip.instance="<urn:uuid:133f86da-c745-9bfa-1651-8fd38f2b42ca>"\r\n
P-Associated-URI: <sip:+497251300XXX@tel.t-online.de>\r\n
P-Associated-URI: <tel:+497251300XXX>\r\n
Authentication-Info: nc=00000001,cnonce="6f5c7c0fda16bd27",rspauth="d788db6fb8962800e370503bc454d0ff",qop=auth\r\n
Reason: SIP;cause=200;text="CC_NO_ERROR"\r\n
Session-ID: 00000000000000000000000000000000; remote=854ce779fa114f7650257b9f9cde075f\r\n
Service-Route: <sip:mavodi-0-272-3fffffff-4-0-510b2014-647ea7361a2c3-975@217.0.147.5:5060;transport=UDP;lr;mpcftk=0-269-da3-4-ffffffff-510b2014-647ea7361a2c3-975>\r\n
Content-Length: 0\r\n
\r\nFakt ist aber auch, dass das Problem, dass es plötzlich einen SIP-Server mit 1.620 s gibt, während andere SIP-Server sagen nicht mehr als 660 s, der Auslöser des Problems ist, schließlich hat die SIP-Telefonie jahrelang funktioniert.
Fildercom hatte ja neulich auch ein Problem, was in die Richtung ging. Hoffentlich ist bald mal ein Punkt erreicht nach nunmehr 20 Jahren SIP-Telefonie (Ich hatte 2006 meinen 1722 gekauft, und damit meinen ersten VoIP-Router.), bzw. 10 Jahren SIP-Telefonie bei der Telekom, wo man an die Zuverlässigkeit vom alten ISDN heran kommt. Manchmal habe ich den Eindruck, die Festnetztelefonie ist regelrecht kaputt gemacht worden durch die ganzen SIP-Probleme. Hat schon mal jemand bei WhatsApp einen Gesprächsabbruch gehabt? Im SIP habe ich das regelmäßig und zu definierten Zeiten, je nachdem, wer gerade anruft. Es wundert also nicht, wenn die Leute immer mehr zum reinen Handy übergehen als Telefoniegerät. Die ganze SIP-Telefonie ist zu fehleranfällig und im Betrieb zu teuer.
Für mich bleibt die Erkenntnis, dass man mit All-IP-Option dringend auf die Firmware 10.50 oder höher setzen sollte. Darunter erlebt man ansonsten derartige Überraschungen.
Vielen Dank und viele Grüße
Jirka
-
Frühstücksdirektor
- Beiträge: 253
- Registriert: 08 Jul 2022, 12:53
- Wohnort: Aachen
Re: Was hat die Telekom schon wieder am VoIP geändert? (...womit ein LANCOM-Router mit älterer Firmware nicht klar kommt
Hallo Jirka,
vielen Dank für die sehr informative Darstellung des Problems.
Bist Du wirklich sicher, dass das Problem in der letzten 10.42 Build nicht gefixt ist? Ich habe den Verdacht, dass der Fix drin ist, aber aus irgendeinem Grund nicht in die Rel-Notes der 10.42 gekommen ist.
Ein Gegentest mit 10.42 SU14 würde mich interessieren....
Viele Grüße,
Frühstücksdirektor
vielen Dank für die sehr informative Darstellung des Problems.
Bist Du wirklich sicher, dass das Problem in der letzten 10.42 Build nicht gefixt ist? Ich habe den Verdacht, dass der Fix drin ist, aber aus irgendeinem Grund nicht in die Rel-Notes der 10.42 gekommen ist.
Ein Gegentest mit 10.42 SU14 würde mich interessieren....
Viele Grüße,
Frühstücksdirektor
Re: Was hat die Telekom schon wieder am VoIP geändert? (...womit ein LANCOM-Router mit älterer Firmware nicht klar kommt
Was die Telekom geändert hat kann ich Dir nicht sagen, nur daß die Änderung so gravierend war, daß einer der Mitbewerber auch für seine 13 Jahre alte Hardware eine geänderte Firmware zur Verfügung stellt: https://www.heise.de/news/13-Jahre-alte ... 34909.html
- Änderung: Anpassungen an den Telefoniedienst des Anbieters Deutsche Telekom
-
Dr.Einstein
- Beiträge: 3467
- Registriert: 12 Jan 2010, 14:10
Re: Was hat die Telekom schon wieder am VoIP geändert? (...womit ein LANCOM-Router mit älterer Firmware nicht klar kommt
Jein. AVM hat Firmwareversionen bzw. Konfigurationspunkte (anderer Provider statt T-Online), wo einfach der Wert 1620s kombiniert mit SIP 423 ignoriert wird und weiterhin fest 4 Minuten verwendet werden für ein REGISTER. Das fand die Telekom gar nicht lustig und hat alle Registrierungsversuche abgelehnt. Aktuell ist die Ablehnung seitens Telekom deaktiviert da zu viele Fritzboxen sich falsch verhalten...sixty hat geschrieben: Heute, 08:55 Was die Telekom geändert hat kann ich Dir nicht sagen, nur daß die Änderung so gravierend war, daß einer der Mitbewerber auch für seine 13 Jahre alte Hardware eine geänderte Firmware zur Verfügung stellt: https://www.heise.de/news/13-Jahre-alte ... 34909.html- Änderung: Anpassungen an den Telefoniedienst des Anbieters Deutsche Telekom
-
Dr.Einstein
- Beiträge: 3467
- Registriert: 12 Jan 2010, 14:10
Re: Was hat die Telekom schon wieder am VoIP geändert? (...womit ein LANCOM-Router mit älterer Firmware nicht klar kommt
Ggf. sollte man bei EoL-Geräten überlegen, einen CRON-Job auf 4 Uhr nachts zu legen, der den Callmanager ausschalten, und mit Sleep 60s später wieder einschaltet. Damit sind alle gespeicherten Werte, besonders die DNS Themen, zurückgesetzt. Ich denke, dadurch bekommt man viele Fehlerfälle weg. Hilft natürlich nicht, wenn im Tagesbetrieb ein Telekom Server (oder anderer Provider) ausfällt und ein Schwenk mittels Priorität erfolgen muss.Jirka hat geschrieben: Heute, 04:21 Für mich bleibt die Erkenntnis, dass man mit All-IP-Option dringend auf die Firmware 10.50 oder höher setzen sollte. Darunter erlebt man ansonsten derartige Überraschungen.