Unerreichbarkeit von 1&1-Rufnummern in Verb. mit All-IP-Opt.

[Jirka]

EDIT: Wie sich inzwischen rausgestellt hat, handelt es sich hierbei um ein neues, bisher nicht ersichtliches Feature und keinen Bug.

Hallo zusammen,

an mich wurden mehrere Problemfälle von 1&1-Kunden herangetragen:

Fehlerbild: Sämtliche im LANCOM hinterlegten 1&1-VoIP-Leitungen (Rufnummern) sind von außen nicht erreichbar oder nur in einem von 30 Fällen und dann oft auch nur nach ca. 30 bis 40 Sekunden (Zeit bis zum Freiton beim Anrufer). Ein Neustart des LANCOMs oder ein erneutes REGISTER der SIP-Leitungen (1&1 verwendet traditionell eine sehr lange Re-Registrierungszeit ("Expires") von derzeit 4 h (früher 8 h)) bringt keine Besserung. SIP-Leitungen von der Telekom oder sipgate funktionieren einwandfrei. Eine Ausnahme stellen Anrufer dar, die ebenfalls aus dem 1&1-Netz kommen. Hier kann es mit etwas glücklicher Fügung (also teilweise) sein, dass diese regelmäßig ein Freiton bekommen. Firmware-Version ist 9.10-RU5.

Troubleshooting/Fehleranalyse: Die SIP-Leitungen sind ordnungsgemäß registriert, es konnten keine Fehler bei der Registrierung festgestellt werden, auch die Re-Registrierung erfolgt korrekt. Beim Provider sind die Leitungen ebenfalls korrekt registriert. Ruft ein Anrufer an (bzw. versucht anzurufen), so ist im SIP-Packet-Trace KEIN eingehendes Paket zu sehen. An dieser Stelle unterlag ich - aufgrund meiner Kenntnis des bisherigen Verhaltens des VCMs - leider der fehlerhaften Annahme, dass der SIP-Server demnach kein INVITE an den LANCOM-Router sendet und ging nachfolgend allen möglichen anderen Fehlerquellen nach bis hin zu der Annahme, 1&1 würde LANCOM-Router extra blocken oder 1&1 kommt mit (gewissen) IP-Adressen aus dem Telekom-Netz nicht klar oder sperrt diese bzw. auch Probleme mit VLAN-7-Tag an Annex-J-Anschlüssen. Das kostete mich fast anderthalb Tage. Irgendwann musste ich verzweifelt erkennen, dass es das aber nicht sein kann und ich fing an, dem SIP-Packet-Trace zu misstrauen. Ich wollte also wissen, ob wirklich kein Paket kommt und schaute deshalb in den A/VDSL-Data-Trace - und siehe da, es kommt ein INVITE, sogar im Dauerbeschuss. Leider lehnt der LANCOM dies (jedes Mal) mit port unreachable ab, obwohl das Paket auf dem korrekten Port ankommt, nämlich genau auf dem, den der LANCOM vorher beim REGISTER auch verwendet/angegeben hat. Warum das port unreachable kommt, kann man auf Anhieb nicht erkennen, vermutlich passt dem LANCOM-Router die WAN-IP nicht, von der das INVITE kommt. Anscheinend wurde der VCM dahingehend modifiziert, dass INVITEs oder andere SIP-Pakete nur von IPs angenommen werden, die dem LANCOM-Router bekannt sind. Und anscheinend funktioniert dieser Ansatz bei 1&1 nicht (1&1 hat traditionell mehr als nur eine handvoll SIP-Server). Leider und das war ja auch eine weitere Katastrophe, der ich unterlag, kamen die Fehlermeldungen extrem zeitversetzt zu dem letzten Firmware-Update - das Raustelefonieren funktionierte ja noch und dass Weihnachten und Neujahr bei Privatkunden niemand anrief war zwar eigenartig, aber fiel auch nicht gleich auf, und bei den Geschäftskunden war es halt ab 4. Januar auch noch so ruhig wie zuvor bei den Feiertagen. Erst am 5. und 6. Januar manifestierten sich die ersten Probleme, d. h. 2,5 Wochen nach meinem letzten Firmware-Update auf eine Release-Update-5-Version, wo man ja nun eigentlich auch nicht mehr mit neuen Features im VCM rechnet und schon gar nicht mehr mit neuen Bugs. Dazu kam auch noch, dass sipgate auch am 4./5./6. Januar reihenweise sipgate-basic-Accounts umstellte, womit es teilweise bei einigen Anschlüssen auch zu Nichterreichbarkeit kam. Das lenkte auch wiederum vom LANCOM ab und deutete auf Providerprobleme hin - diese gab es tatsächlich, allerdings eben nur bei sipgate und nicht bei 1&1. Ach ja, der Workaround ist zurück zu gehen auf die Firmware 9.10.0521. Das Problem tritt mit der 9.10.0530RU5 auf, Zwischenversionen liegen mir nicht vor.

Traditionell stelle ich Bugs den Kunden nicht in Rechnung - die Kunden können ja nichts dafür. Allerdings war das diesmal echt hart und viele andere geplante Sachen mussten abgesagt werden. Irgendwie ein Bug, der einem zeigt, dass man wirklich alles im Fehlerfall in Frage stellen muss. So, nun reicht's, die nächsten anderthalb Stunden sind um.

Viele Grüße,
Jirka

[Rougu]

Hallo Jirka,

reines Bauchgefühl: ich könnte hier einen Zusammenhang mit meinem, leider bisher von berufener Stelle nicht kommentiertem Thread sehen:
http://www.lancom-forum.de/feedback-lco ... 14889.html
(Unter der Annahme, das LANCOM im VCM intern, und für uns User nicht sichtbar, UDP-Regeln verkettet.)

Die 9.10.0530 ist in meinen Augen an einigen Punkten massiv kaputt.

Gruß,
rougu

[cpuprofi]

Hallo Rougu,

hast Du denn mal Firmwaren vor der 9.10.0530 gegengetestet, so dass man sagen kann, ab wann dieses von Dir geschilderte "Verhalten" im LCOS erst auftritt?

Grüße
Cpuprofi

[Jirka]

Hallo Rougu,

das glaube ich eher nicht - hab mir Dein Problem aber trotzdem durchgelesen.

Hallo zusammen,

in der Nacht fiel mir noch ein, dass man ja mal in die Release-Notes schauen könnte - und siehe da:

Es kann nun konfiguriert werden, dass SIP-Nachrichten nur von IP-Adressen angenommen werden, bei denen die SIP-Leitung registriert ist.

Also doch ein neues Feature, sogar ein neuer Schalter mit einem RU. Das ist mir schon öfter aufgefallen, dass langsam niemand mehr durchsieht, neue Features und Konfigurationsparameter mit RUs eingeführt werden, die Build-Nummern eigenartig springen (und niemand außerhalb von LANCOM bekommt zu erfahren warum, ja wohl selbst bei LANCOM arbeitende Programmierer sagen, es sei verwirrend geworden mit den Versionen wegen der vielen parallel laufenden Freigaben und Projekte).

So, aber wo ist denn nun der neue Konfigurationsparameter?

Ah ja, Strict-Mode nennt er sich. Er hat es natürlich nicht in LANconfig geschafft, kann er ja auch nicht, schließlich kam der Parameter mit einem RU, LANconfig unterscheidet aber nur nach Vollversionen. Hilfe gibt es auch nicht zu dem Parameter - warum wird die nicht in dem Moment geschrieben, und erläutert, wenn der Konfigurationsparameter erstellt wird? Ein halbes Jahr später macht es sowieso keiner mehr. Ach ja, und per default ist er auf "ja".

Wie funktioniert der Strict-Mode genau? Warum knallt es da bei 1&1?

Immerhin - wir wollen ja nicht nur meckern, am meisten ärgere ich mich ja über mich selber, mittlerweile ist es eine Verkettung von unglücklichen Umständen, die mich in diese Situation gebracht hat, z. B. weil ich vor Weihnachten keine Zeit mehr hatte, die Release-Notes zu lesen, das hätte mir einiges erspart - also nochmal: Immerhin ist der Parameter ja pro SIP-Leitung und nicht global konfigurierbar, so kann man dem evt. tatsächlich noch was abgewinnen. Aber es bleibt wie gesagt die Frage, wie das Feature ganz genau funktioniert, basiert das auf DNS-Auflösungen oder wirklich nur auf der IP-Adresse, wo das REGISTER hin ging? Welche Provider sind ebenfalls nicht kompatibel mit diesem Feature?

Oh je, jetzt ist die Geschichte endlich aufgeklärt...

Viele Grüße,
Jirka

[Jirka]

Hallo,

also mir wurde zugetragen, dass der Parameter Strict-Mode diesbezüglich demnächst in LANconfig "SIP-Nachrichten nur vom Registrar erlauben" lauten wird und somit dann in LANconfig konfigurierbar sein wird.
Die Hilfe zu dem Parameter lautet:

Wird dieser Modus aktiviert, werden eingehende SIP-Nachrichten nur von der IP-Adresse akzeptiert, bei der die Leitung registriert wurde.

Hinweis: Beachten Sie, dass nur die Einstellung "Nein" eine hohe Kompatibilität sicherstellt. Sollte der VoIP-Provider Rufe von Servern/IP-Adressen signalisieren, die nicht dem Registrar entsprechen, werden eingehende Rufe nicht an den internen Teilnehmer signalisiert.

Vielen Dank und viele Grüße,
Jirka

[hubiuwe]

Hallo,
Ich habe das gleiche Problem. Das Phänomen kenne ich aus der Zeit wo ich mit Asterisk rumexperimentiert habe.

Ich war Jahrelanger Fritzbox Fan und habe jetz auf eine L1781aw migriert und mir die AllIP Option gegönnt. Und musste mit Schrecken feststellen daß ich nicht angerufen werden könnte. Ein Mitschnitt der ADSL-Schnittstelle bestätigte mir auch den Verdacht.
Es ist wie Lotto, das bei einem Anruf zufällig ein SIP-Invite vom aktuell registrierten 1und1 Proxy vorbei kommt.

Allerdings kommen bei einem Anruf im Sekundentakt Invite Packete von immer verschiedenen Proxys damit hatt man eine geringe Chance auch nach 15 sek. Ein Klingeln zu hören :
Das blöde ist nur, daß der Anrufer keinen Ton hört un schon vorher auflegt.

Jetz habe ich die Fritzbox als Proxy doch wieder vorne dran
Ich hoffe daß der og. Haken bald kommt

Gruß Uwe

[Dr.Einstein]

Geht doch jetzt schon:

set /Setup/Voice-Call-Manager/Lines/SIP-Provider/Line/NameSIPVerbindung/Strict-Mode 0

Gruß Dr.Einstein

[hubiuwe]

Danke
Habe es auch eben entdeckt.
Gruß Uwe

[fhebel]

Grazie mille.

Ich war schon ziemlich verzweifelt. Der Lancom-Support hatte mir, nachdem ich Traces von Callmanager, SIP-Packet & VDSL-DATA geschickt hatte, empfohlen ein Config-Ticket zu kaufen und mir die Telefonie von einem Profi einrichten zu lassen ...

[garfield0815]

Grazie mille.

Ich war schon ziemlich verzweifelt. Der Lancom-Support hatte mir, nachdem ich Traces von Callmanager, SIP-Packet & VDSL-DATA geschickt hatte, empfohlen ein Config-Ticket zu kaufen und mir die Telefonie von einem Profi einrichten zu lassen ...

nuja die müssen doch auch irgendwie geld verdienen

[Christoph_vW]

Ahja - ich hatte es damals auch gleich wieder aufgegeben und eine FritzBox 7490 hinter den LANCOM gehängt. Hatte aber auch keine Möglichkeit lange genug nach dem Fehler zu suchen.

[passi]

Hi!

Ich hatte gestern das Vergnügen zur Telekom VDSL100/IP zu wechseln.

Alle drei Rufnummern liessen sich am Lancom nicht registrieren, blieb im LanMonitor bei Registrierungsversuch stehen. LanTrace immer nur "isNotAvailible:0...." nach Aktivierung des VCM.

Einrichtung erfolgte per Wizard, LCOS 9.10.0629RU6 / 1781VAW

Abhilfe: /Setup/Voice-Call-Manager/Lines/SIP-Provider/Line/WIZ_T-xxxxxx/Strict-Mode no

Der Telekom-Hotline fällt natürlich nur ein "Lancom 1781 ist nicht kompatibel..."

Interessanterweise hat ein Gigaset C475IP das gleiche Problem an diesem Anschluss, eingerichtet per Assistent --> "Anmeldung fehlgeschlagen".