[Problem] Octopus F X 8 an Lancom 884: keine Umleitung an Mobilnummern möglich

[mettwurscht]

Hallo zusammen,

folgende Situation: Eine Octopus F X 8 (Software osbiz_v2_R6.2.0_029) hängt per ISDN an einem Lancom 884 (aktuelle Software). Der Lancom wiederum terminiert einen Company Flex SIP Trunk der Telekom.

Am SIP Trunk ist aktuell kein CLIP no screening aktiv. Im Lancom ist SIP302 aktiviert. In der Octopus wurde "partial rerouting" über die Option "Rerouting aktiv: Immer" aktiviert. "Richtungswechsel erlaubt" ist nicht aktiv.

Vorweg: Ich bin in der Konfiguration der Octopus nicht versiert.

Seit der Umstellung des SIP Trunks auf den Company Flex (in dessen Zuge ist CLIP no screening verloren gegangen), funktioniert eine an einer SIP-Nebenstelle eingerichtete Rufumleitung auf Mobilfunknummern nicht mehr. Ich habe das ganze mal an einer Systel-Nebenstelle versuchen lassen. Dort funktioniert es.

Hat jemand eine Idee, was ich noch schauen bzw. probieren könnte?

 

[sunnyman]

folgende Situation: Eine Octopus F X 8 (Software osbiz_v2_R6.2.0_029) hängt per ISDN an einem Lancom 884 (aktuelle Software). Der Lancom wiederum terminiert einen Company Flex SIP Trunk der Telekom.

Warum diese (HD-Telefonie tötende) Lösung? Die Octopus kann SIP auch selbst, hat sogar ihren eigenen SBC an Board.
Allerdings ist der Softwarestand nicht aktuell, V3 ist die aktuelle. Wie stehts um eure Software Assurance?

Ich würde die Umstellung auf "Direktanbindung" insbesondere deswegen erwägen, weil man genau aus dem vorliegenden Problem das was der Lancom tut als Fehlerquelle rauskürzen könnte.

Am SIP Trunk ist aktuell kein CLIP no screening aktiv. Im Lancom ist SIP302 aktiviert. In der Octopus wurde "partial rerouting" über die Option "Rerouting aktiv: Immer" aktiviert. "Richtungswechsel erlaubt" ist nicht aktiv.

Vorweg: Ich bin in der Konfiguration der Octopus nicht versiert.

Seit der Umstellung des SIP Trunks auf den Company Flex (in dessen Zuge ist CLIP no screening verloren gegangen),

Hat der Vertrieb da Mist gebaut? Also möglich wäre das ja nachwievor, sprich wenn der Bedarf noch da ist könnte man es auch wieder zubuchen.

funktioniert eine an einer SIP-Nebenstelle eingerichtete Rufumleitung auf Mobilfunknummern nicht mehr.

Da du es expliziert erwähnst: Tritt das Phänomen nur bei Mobilfunknummern auf und nicht, wenn auf Festznetznummern weitergeleitet wird?

Ich habe das ganze mal an einer Systel-Nebenstelle versuchen lassen. Dort funktioniert es.

Da wäre dann direkt die Frage, wie denn die Nebenstelle die Umleitung signalisiert. Die supplementary services die im ISDN alle fest standardisiert waren, gibt es bei SIP so ja alle nicht. Insbesondere bekommt die TK-Anlage nicht mit, wenn eine Rufumleitung gesetzt bzw. gelöscht wird. Das kann immer nur beim SIP INVITE passieren bzw. indem das Telefon darauf antwortet.
Bei einem Systel ist das vom Grundsatz her anders, und die sind ja eh nur dumme Terminals, der ganze Zustand des Endgeräts ist in der Anlage gespeichert.

Hat jemand eine Idee, was ich noch schauen bzw. probieren könnte?

Ich würde ad hoc erstmal im Lancom am D-Kanal tracen und beide Fälle vergleichen. Dann wüsstest du schon mal ob es entweder an der Octopus (bzw. dem SIP-Endgerät) liegt oder am Lancom bzw. dem SIP-Trunk

 

[mettwurscht]

Warum diese (HD-Telefonie tötende) Lösung? Die Octopus kann SIP auch selbst, hat sogar ihren eigenen SBC an Board.
Allerdings ist der Softwarestand nicht aktuell, V3 ist die aktuelle. Wie stehts um eure Software Assurance?

Du hast dir die Antwort auf die Frage schon gegeben. Wir hatten für eine andere Sache einen Telekomtechniker an der Anlage, der den SIP Trunk wegen der alten Software nicht auf der Anlage einrichten wollte. Da die Softwarewartung abgelaufen ist, konnte er das Update nicht direkt durchführen. Dazu brauchts wieder einen separaten Auftrag. Daher haben wir das nun erstmal so gelassen, wie es vorher war. Es ist kompliziert...

Hat der Vertrieb da Mist gebaut? Also möglich wäre das ja nachwievor, sprich wenn der Bedarf noch da ist könnte man es auch wieder zubuchen.

Ja, da hat der Vertrieb Mist gebaut und ich, weil ich den Auftrag nicht auf das Merkmal gecheckt habe. Aber wie du sagt, lässt sich das ja kurzerhand zubuchen. Wir hatten es bisher drin, weil partial rerouting in der Anlage nicht aktiv war und so die Nummer des A-Teilnehmers nicht ans Umleitungsziel übertragen wurde. Das hatte ich nun geändert. Ich vermute nicht, dass das fehlende CLIP no screening die Ursache ist für die fehlgeschlagene Rufumleitung.

Da du es expliziert erwähnst: Tritt das Phänomen nur bei Mobilfunknummern auf und nicht, wenn auf Festznetznummern weitergeleitet wird?

Richtig.

Ich würde ad hoc erstmal im Lancom am D-Kanal tracen und beide Fälle vergleichen. Dann wüsstest du schon mal ob es entweder an der Octopus (bzw. dem SIP-Endgerät) liegt oder am Lancom bzw. dem SIP-Trunk

Das werd ich tun. Bin die Tage vor Ort, dann gehe ich das mal durch. Das debugging ist immer etwas blöd, wenn man dazu auf Leute angewiesen ist und sie so von deren eigentlicher Arbeit abhält.

 

[mettwurscht]

Lösung:

Das Problem ist nun gelöst, nachdem in den SIP-Trunk-Einstellungen des Lancom-Gateways die Option "overlap dialling" aktiviert wurde.

 

[tango501]

Das Overlap-Dialing hat im LCOS ein paar Eigenheiten. Welches LCOS wurde denn ursprünglich genutzt und welches LCOS ist jetzt mittlerweile installiert?

 

[mettwurscht]

Die Option wurde erst auf der aktuellen LCOS 10.80.0448RU3 aktiviert.
Ich bekam jetzt auch die Rückmeldung, dass die Umleitung hin und wieder nicht funktioniere, dann am Ziel immerhin noch ein Anruf in Abwesenheit aufschlägt.

Die Octopus soll jetzt "irgendwann" ein Softwareupdate bekommen, so dass der CompanyFlex SIP-Trunk direkt darauf terminiert werden kann. Das übernimmt aber alles die Telekom und mit denen teste ich dann auch die verschiedenen Umleitungs-Szenarien.

 

[tango501]

auf der aktuellen LCOS 10.80.0448RU3

Das aktuelle LCOS wäre übrigens LCOS 10.80 BUILD 0560.

https://ftp.lancom.de/LANCOM-Beta/LCOS/LCOS%2010.80/BUIL0560/LC-884VoIP-10.80.0560.upx

BUILD 0560 ist vom 11.04.2024 und hat noch den Status "Beta". Bitte ggf. nur zum Testen und NICHT in Produktivumgebungen nutzen.

 

[mettwurscht]

Danke für den Hinweis. Ich schau mir das jetzt mit der RU3 mal an und teste ggf. die Betaversion.

 

[mettwurscht]

Es gibt ein SU vom 16.4., das teste ich heute Abend mal. Denn einen richtig dauerhaften Erfolg hatte die Option nicht.
Hat jemand vielleicht noch eine Idee, ob es eine Einstellung im Company Flex an sich sein könnte?

 

[tango501]

Es gibt ein SU vom 16.4.

https://ftp.lancom.de/LANCOM-Releases/LC-884-VoIP/LC-884-VoIP-10.80.0450-SU4.upx

Und das ist der Hintergrund für SU4:

Passwort des Administrators „root“ wird nach Schreiben einer vollständigen Konfiguration mit einem weiteren Administrator zurückgesetzt
April 15, 2024
Durch eine Kunden-Rückmeldung konnten wir eine Sicherheitslücke im LCOS beheben, durch die nach Schreiben einer vollständigen Konfiguration (z.B. eine *.lcf Datei) mit einem weiteren Administrator mit Supervisor-Berechtigung das Passwort des Administrators „root“ zurückgesetzt – und damit gelöscht - wurde. LCOS ist ab der Version 10.80 RU1 von dieser Sicherheitslücke betroffen. Niedrigere LCOS-Versionen bzw. andere LANCOM Betriebssysteme sind nicht betroffen. Das Verhalten ist in der LCOS-Version 10.80 SU4 behoben. Ein unautorisierter Zugriff auf den Router über das WAN (Internet) ist durch diese Sicherheitslücke nicht möglich. In Public Spot-Szenarien mit einem separaten Gastnetzwerk ist durch die Verwendung von VLAN oder einem WLC-Tunnel ein Management-Zugriff aus dem Gastnetzwerk auf die Access Points nicht möglich und damit eine Gefährdung ausgeschlossen. Sicherheitslücke in LCOS 10.80 SU4 behoben: LANCOM Systems empfiehlt dringend die fehlerbereinigte LCOS-Version 10.80 SU4 einzuspielen (download).

Quelle: https://www.lancom-systems.de/service-support/allgemeine-sicherheitshinweise