SIP-Registrierung mit FW 10.00.0165RU1 nicht mehr möglich

[fildercom]

Hallo zusammen,

ich habe von der 9.24 auf die 10.0 RU2 aktualisiert und an zwei Telekom All-IP-Anschlüssen jetzt folgendes Problem:
Die SIP-Leitungen können teilweise nicht registriert werden. Wenn ich den VCM aus- und wieder einschalte, funktioniert es bei manchen Rufnummern, aber auch nur kurzzeitig.

Ich habe im VCM den Port jetzt von 5060 auf 0 geändert und jetzt scheint es zu funktionieren.

Früher hatte es bei LANCOM mit Port 5060 eigentlich kaum Probleme gegeben, während bintec elmeg schon immer empfohlen hat, Port 0 einzutragen, da die Telekom ein Load Balancing durchführt und deshalb DNS SRV Lookup durchgeführt werden soll.

Kann das jemand bestätigen, dass man bei LANCOM ab sofort Port 5060 ebenfalls nicht mehr eintragen soll?

Viele Grüße und vielen Dank
fildercom.

[fildercom]

Hallo zusammen,

ich habe von der 9.24 auf die 10.0 RU2 aktualisiert und an zwei Telekom All-IP-Anschlüssen jetzt folgendes Problem:
Die SIP-Leitungen können teilweise nicht registriert werden. Wenn ich den VCM aus- und wieder einschalte, funktioniert es bei manchen Rufnummern, aber auch nur kurzzeitig.

Ich habe im VCM den Port jetzt von 5060 auf 0 geändert und jetzt scheint es zu funktionieren.

Früher hatte es bei LANCOM mit Port 5060 eigentlich kaum Probleme gegeben, während bintec elmeg schon immer empfohlen hat, Port 0 einzutragen, da die Telekom ein Load Balancing durchführt und deshalb DNS SRV Lookup durchgeführt werden soll.

Kann das jemand bestätigen, dass man bei LANCOM ab sofort Port 5060 ebenfalls nicht mehr eintragen soll?

Viele Grüße und vielen Dank
fildercom.

Kann hier wirklich niemand etwas zu diesem geänderten Verhalten sagen?

[beki]

Traces vom Fehlerfall?

Seit der 10.00 ist es so, dass der Port abhängig vom Transport (UDP/TCP => 5060 vs. TLS => 5061) automatisch gewählt wird, wenn dieser gleich 0 eingestellt ist. Ein Port im SRV Record zur SIP-Domäne wird aber vor der automatischen Wahl der Standardport bevorzugt, hat aber Nachrang wenn ein Port ungleich 0 eingestellt ist.

[fildercom]

Traces vom Fehlerfall?

Seit der 10.00 ist es so, dass der Port abhängig vom Transport (UDP/TCP => 5060 vs. TLS => 5061) automatisch gewählt wird, wenn dieser gleich 0 eingestellt ist. Ein Port im SRV Record zur SIP-Domäne wird aber vor der automatischen Wahl der Standardport bevorzugt, hat aber Nachrang wenn ein Port ungleich 0 eingestellt ist.

Hallo beki,
danke für die Rückmeldung. Ich hatte mir gar nicht die Mühe gemacht, Traces zu erstellen, da die Lösung mit Port 0 ja auf Anhieb dauerhaft funktioniert. Eigentlich bin ich davon ausgegangen, dass dies auch Absicht war (siehe bintec elmeg), aber dann sollte man es eben in den Release Notes erwähnen und am besten den Assistenten auch anpassen, damit darüber angelegte Telekom VoIP-Accounts sonst auf dieselben Probleme laufen wie es bei mir war.

Kann auch sein, dass das Problem nicht generell besteht: Möglicherweise ist es an der BNG-Plattform nicht da, sondern nur an der alten AGS/BRAS-Plattform der Telekom, die aber eigentlich ohnehin schon längst durch BNG abgelöst werden sollte (aber in den THS-Städten geht es momentan einfach nicht vorwärts... aber das ist ein anderes Thema).

Gruß und danke
fildercom.

[Jirka]

Hallo fildercom,

aber in den THS-Städten geht es momentan einfach nicht vorwärts...

was ist das für eine verrückte Abkürzung?! T-Home-Speed-Städte? Habe ich noch nie von gehört... Also Sachen gibt es, das hält man nicht für möglich.

Viele Grüße,
Jirka

[Dr.Einstein]

Hallo,

THS, ja T-Home Speed, hat damals zur WM 2006 in den großen deutschen Städten mit VDSL angefangen (=Entertain). Dort ist aus jetziger Sicht ziemlich ältere Technik im Einsatz. Aber das sich da gar nix tut, kann ich nicht bestätigen. Meine Eltern z.B. paar Straßenzüge weiter sind schon auf VDSL-BNG umgestellt, Einzugsgebiet von meinem Bruder ist sogar schon auf VDSL Vectoring trotz WM Stadt hochgerüstet (und natürlich dadurch BNG).

Aber fildercom, du könntest natürlich mit deiner Vermutung Recht haben. Alt- und Neuplattform verhalten sich um 179 Grad unterschiedlich.

Gruß Dr.Einstein

[fildercom]

Hallo,

THS, ja T-Home Speed, hat damals zur WM 2006 in den großen deutschen Städten mit VDSL angefangen (=Entertain).

Korrekt. Manchmal wird als Synonym auch THE verwendet (= T-Home Entertain). Aber THS ist die gängigere Abkürzung.

Dort ist aus jetziger Sicht ziemlich ältere Technik im Einsatz.

Ja, wobei ich bereits im Juli 2016 vom alten Siemens hiX 5625 mit Infineon-Linecards (PSTN) auf einen neuen Adtran hiX 5630 mit Broadcom-Linecard umgeschaltet wurde (Vectoring-Ready). Aber seitdem tut sich nichts mehr, es sind weiterhin 2 DSLAMs im MFG und eine BNG-Umschaltung wird nicht gemacht, da sinnvollerweise auf dem neuen DSLAM (!) noch einige PSTN-Anschlüsse laufen, die wohl bisher noch nicht gekündigt wurden. Anstatt dass man diese auf den alten DSLAM umschaltet, damit man den neuen an den BNG anschalten kann, passiert aber leider nichts.

Aber das sich da gar nix tut, kann ich nicht bestätigen. Meine Eltern z.B. paar Straßenzüge weiter sind schon auf VDSL-BNG umgestellt, Einzugsgebiet von meinem Bruder ist sogar schon auf VDSL Vectoring trotz WM Stadt hochgerüstet (und natürlich dadurch BNG).

Wie oben geschrieben. Teilweise passiert schon was, aber eben nur stellenweise und in homöopathischen Dosen. Es wäre dringend nötig, die BNG-Migration und damit einhergehende Vectoring-Aktivierung in den THS-Städten zu beschleunigen, damit die Kunden nicht zu den KNBs mit ihren 400 Mbit/s-Tarifen abwandern (die Segmentüberlastung bei den KNBs ist ein anderes Thema, welches in der Wahrnehmung der wenigsten Kunden bei Abschluss eines solchen Vertrages bekannt ist). Die Hardware-Misere bei den KNBs wäre bei mir momentan aber immer noch der wichtigste Grund, der gegen einen DOCSIS-Internetanschluss spricht.

Gruß
fildercom.

[beki]

aber dann sollte man es eben in den Release Notes erwähnen

Es gibt nichts weiter zu erwähnen. Alles was sich geändert hat ist die Festlegung des Remoteports auf 5061 falls man "0" eingestellt hat, kein SRV den Port vorgibt und TCP oder TLS als Transport eingestellt ist. Und das wurde als "Support für TCP/TLS zu SIP-Providern" verkauft.

Wenn du vorher fest Port 5060 eingetragen hattest, dann muss das auch nach einem Update auf die 10.00 funktioniert haben. Wenn nicht, dann ist das ein Bug und keine Nachricht in den Release Notes dass es nicht mehr empfohlen sei einen festen Remote-Port einzustellen (Schwachsinn).

Hast du vielleicht an der Einstellung "Local-Port" gespielt? Wenn du dort bei allen Lines fest Port 5060 einträgst dann hat das bis zur 10.00 zufällig funktioniert und ab der 10.00 ist das ein Problem. Weil Konfigurationsfehler.

Ich bin übrigends recht genervt davon dass ich Zeit investiere dir zu antworten und auf deine Frage einzugehen, während aber auf mein Verlangen nach Traces im Fehlerfall, mit denen man deine Frage vermutlich ohne Glaskugel beantworten könnte, mit einem "Nö, hab ich nicht, tut ja jetzt" beantwortet wird. Warum diskutieren wir, wenn die Materie nicht wichtig genug ist einen Trace zu erstellen? Warum kopierst du deinen eigenen Beitrag und fragst extra nochmal nach ob wirklich niemand etwas zum Thema sagen kann wenn du noch nicht einmal bereit bist Traces zu liefern.

Versteh ich nicht. Aber gut, ich versteh so vieles nicht.

Traces or it didn't happen!

[fildercom]

Hallo beki,

sorry, ich wusste nicht, dass es dich gleich so nervt. Das war nicht meine Absicht. Wie gesagt, da es mit Port 0 funktionierte, habe ich keine Traces erstellt.

Ich habe gerade das Update auf die 10.0 RU4 aufgespielt und hatte anschließend mit einigen Rufnummern wieder Registrierungsprobleme. Der Port steht nach wie vor auf "0". Nach dem Ausschalten und Einschalten des VCM lief es dann.

Beim anderen Gerät habe ich etwas gewartet und nach ein paar Minuten klappte die Registrierung auch von alleine. Ich habe aber dieses Mal Traces erstellt.

Soll ich damit einen "normalen" Support-Fall aufmachen oder direkt zu dir?

Und noch was: Wo ist denn "Local Port" im VCM? Ich wüsste nicht, dass ich diesen Parameter schon einmal gesehen hätte und habe dort definitiv auch nichts verändert.

Gruß und danke
fildercom.

[fildercom]

Nochmal kurz @ beki:
Kann es sein, dass die IP-Adressen der Gegenstelle für die SIP-Registrierung irgendwo gecached werden und dies auch nach dem Reboot erhalten bleibt?

Als die Registrierung nicht geklappt hat, habe ich im LANmonitor eine IP gesehen, an der nicht registriert werden konnte. Da die Telekom aber Load Balancing nutzt, ändert sich die IP immer wieder.

Nachdem die Registrierung dann geklappt hatte, stand im LANmonitor eine andere IP.

Waren nur ein paar Gedanken meinerseits dazu...

[Jirka]

Ich habe gerade das Update auf die 10.0 RU4 aufgespielt und hatte anschließend mit einigen Rufnummern wieder Registrierungsprobleme. Der Port steht nach wie vor auf "0". Nach dem Ausschalten und Einschalten des VCM lief es dann.
Beim anderen Gerät habe ich etwas gewartet und nach ein paar Minuten klappte die Registrierung auch von alleine.

cpuprofi hat auch beobachtet, dass mit der Firmware 10.x gegenüber der 9.24 eine gewisse Verzögerung bis zur Registrierung der SIP-Leitungen bzw. einzelner SIP-Leitungen nach Neustart oder Verbindungsaufbau festzustellen ist.

Ich habe aber dieses Mal Traces erstellt.

Schön.

[cpuprofi]

Hallo fildercom,

...sorry, ich wusste nicht, dass es dich gleich so nervt. Das war nicht meine Absicht....da es ...funktionierte, habe ich keine Traces erstellt...

nicht nur Beki nervt dieses "Verhalten". Leider neigen immer mehr Leute hier im Forum dazu "Fragen zu stellen" aber dann keine "Lösung erarbeiten zu wollen". Ist aber kein an Deine Person gebundenen Problem

...Ich habe gerade das Update auf die 10.0 RU4 aufgespielt und hatte anschließend mit einigen Rufnummern wieder Registrierungsprobleme. Der Port steht nach wie vor auf "0". Nach dem Ausschalten und Einschalten des VCM lief es dann.

Beim anderen Gerät habe ich etwas gewartet und nach ein paar Minuten klappte die Registrierung auch von alleine...

Wie Jirka schon schrieb, mir sind die Änderungen im Verhalten des VCM bei der 10er FW auch schon aufgefallen...

...Ich habe aber dieses Mal Traces erstellt. Soll ich damit einen "normalen" Support-Fall aufmachen oder direkt zu dir?...

Da Beki nicht mehr bei Lancom arbeitet, wird er an dem "Verhalten" nichts ändern können. Er könnte Dir höchstens sagen, ob dieses der Programmierung "entspricht".

Grüße
Cpuprofi

[Dr.Einstein]

nicht nur Beki nervt dieses "Verhalten". Leider neigen immer mehr Leute hier im Forum dazu "Fragen zu stellen" aber dann keine "Lösung erarbeiten zu wollen". Ist aber kein an Deine Person gebundenen Problem :wink:

Wobei mich in letzter Zeit immer wieder nervt, dass der Support für jeden Scheiss gleich einen Trace haben will, obwohl viele Sachen direkt durch beschriebenes Reproduzieren / Beispielkonfig etc. direkt nachvollziehbar wäre (in dem konkreten Fall hier natürlich nicht ;)

Gruß Dr.Einstein

[fildercom]

Hallo cpuprofi,

danke für deine Antwort.

nicht nur Beki nervt dieses "Verhalten". Leider neigen immer mehr Leute hier im Forum dazu "Fragen zu stellen" aber dann keine "Lösung erarbeiten zu wollen". Ist aber kein an Deine Person gebundenen Problem

Ja, kann ich nachvollziehen. Allerdings habe ich in anderen Themen auch schon sehr oft mein Wissen an andere User weitergegeben und ihnen Lösungsmöglichkeiten aufgezeigt.
Im vorliegenden Fall empfand ich es als überflüssig, Traces zu erstellen, da es mit Port 0 ja auf Anhieb funktioniert hatte. Ein Tracen hätte ein erneutes Verändern der Konfiguration bedeutet, was ich im Telefon-Bereich nur äußerst ungern mache und auch nur dann, wenn es wirklich erforderlich ist. Die ISDN-Zeiten sind ja leider vorbei und im SIP können schon kleinste Veränderungen ein unerwünschtes Verhalten nach sich ziehen. Deshalb gilt da bei mir: "Never change a running system".

Wie Jirka schon schrieb, mir sind die Änderungen im Verhalten des VCM bei der 10er FW auch schon aufgefallen...

Das ist dann natürlich ein etwas unschönes Verhalten, da Telefonie eigentlich "sofort" funktionieren sollte (zumindest nach meinem Verständnis). Aber die schöne neue All-IP-Welt macht eben nicht alles besser (zumindest wollen uns das die TKs und die Hersteller immer erzählen).

Da Beki nicht mehr bei Lancom arbeitet, wird er an dem "Verhalten" nichts ändern können. Er könnte Dir höchstens sagen, ob dieses der Programmierung "entspricht".

Schade, aber vielleicht kommen wir einer Lösung oder Aufklärung des "Verhaltens" trotzdem noch etwas näher.

Viele Grüße und bis bald
fildercom.

[beki]

Ich habe gerade das Update auf die 10.0 RU4 aufgespielt und hatte anschließend mit einigen Rufnummern wieder Registrierungsprobleme.

RU4?! Meinst du RU3 vielleicht?

Unmittelbar nach einem Firmwareupdate sollte es keine derartigen Probleme geben. Da du davon schreibst es ginge nach aus- und wieder einschalten des VCMs wieder nehme ich an dass der Fehlerfall auch im Betrieb auftritt.

Wie ist denn da nun der Stand? Hast du den Fehlerfall noch ab und zu während des Betriebes? Gibt es einen Trace davon dass sich der VCM versucht zu registrieren während dies aber fehlschlägt? Falls ja, kann man sich den anschauen und nach Hinweisen suchen. Was steht in einem solchen Fall unter /status/voice/lines?