Probleme mit Gigaset 30/40/41xx und ISDN an Lancom 1722

[Hobbyfahrer]

Hallo,

nach meinem Umzug habe ich leider Probleme.

In der alte Wohnung waren am 1722 ein Gigaset ISDN System Modell 4170 und ein Ascom Eurit 4000 über dem 2-fach Adapter an dem 1722 angeschlossen.

Nach dem Umzug betreibe ich nur noch das Gigaset 4170 direkt an dem ISDN Anschluss an dem 1722.

Nun verlieren die Endgeräte ständig den Kontakt zur Basisstation.

Schliesse ich das Gigaset direkt an den NTBA an ist wieder alles ok!

Was ist da los oder muss ich an der ISDN Einstellung (Dip-Schalter) etwas verändern?

Im LAN Monitor habe ich folgende Fehlermeldung:

Fehler (ISDN 1): Verbindungsaufbau fehlgeschlagen (D-Kanal Layer 1) [0x0081]


Thorsten

[joeMJ]

Hallo,

lass Deinen LC so wie er ist - lies vlt. mal
http://www.ip-phone-forum.de/showthread ... aset+basis
Die Thematik kommt mir ziemlich bekannt vor.

[Hobbyfahrer]

Stand der Dinge ist nun wie folgt:

- Gigaset Anlage auf neuste Firmware gebracht
- NTBA getauscht
- Splitter getauscht
- Gigaset Anlage und Mobilteile auf Werkseinstellungen bebracht und neu eingerichtet


Die Gigasetanlage verliert immer noch den ISDN Kontakt zum 1722.

Lancom ist eingeschaltet weiss allerdings auch nicht so recht weiter.

[ML]

Hi Hobbyfahrer,

bis ich Deinen Thread gelesen hatte, war mir gar nicht bewußt, dass ich auch dieses Problem habe. Habe es bisher auf meinen Repeater geschoben und da es nur alle paar Stunden auftrat bisher nicht weiter beachtet.

Jetzt habe ich mal etwas in verschiedenen Foren gestöbert und bin der Meinung, dass es an der Synchronisation des ISDN-Taktes liegt. Offenbar reagiert das Gigaset bei Abweichungen des Taktes mit einem Verbindungsabbruch zu den DECT-Endstellen. Prinzipiell synchronisiert der LC zwar den Takt auf NT-Schnitstelle (TK-Anlage) mit dem Takt der Telekom auf der TE-Schnittstelle. Die Standardeinstellung unter "Interfaces-WAN" für den PCM Synchronisations-Bus ist "Automatisch", d.h. der LC sucht auf allen TE-Schnittstellen nach einem Takt. Ich vermute mal, dass diese Automatik mit timeouts verbunden ist, wenn er alle ISDN-Schnittstellen "abklappert". Nachdem ich nämlich dort explizit die Schnittstelle selektiert habe, die zum NTBA geht, scheint es jetzt keine Basisverluste mehr zu geben. Habe zwar noch keine Langzeiterfahrung, aber bis jetzt sieht es gut aus...

Vielleicht hilft Dir das weiter...

ML

[Hobbyfahrer]

Hallo ML,

ja das habe ich auch vermutet und der Lancom Service hatte mir auch den Tipp gegeben. Leider hat das Abschalten der Automatikfunktion keinen Erfolg gebracht.


Thorsten



P.S. Mit meiner AVM FBF 7050 hatte ich nie diese ISDN Probleme

[joeMJ]

Hi,

gleiches Problem hatte ich auch. Allerdings auch bei meiner Erzeugerfraktion an einer FBF. Mit einem SX353 war es allerdings nicht so extrem wie bei einer 3075.

Gehopst wie gesprungen - ich hatte es bei meiner Erzeugerfraktion zuletzt "gelöst" mit einer kleinen, überzogen teuren ISDN <-> SIP Box von Auerswald (meine ich), die zusätzlich den Takt am NTBA synchronisieren konnte - allerdings setzen wir die jetzt nicht mehr ein, sondern nur noch SPA941/ 942 und diverse F1000G - so hatte sich die Thematik von selbst erledigt.

[rubinho]

Dieses Problem gab es glaub ich auch schon bei der Fritzbox und hat was mit dem ISDN-Takt zutun (Das ist zumindest bei den Fritzboxen so gewesen)


Uuups ! Sorry für den unnötigen Beitrag
Ich hab nicht alles gelesen


Gruß
Rubinho

[Hobbyfahrer]

Hallo,

das Problem ist beseitigt.


Was ist noch alles passiert?


Beta 6.20 auf LC 1722 eingespielt
Alles neu konfiguriert

Dadurch wurde die Probleme nicht beseitigt.

Zusammen mit Lancom haben wir dann alles genauer betrachtet und festgestellt, dass Hansenet den ISDN Anschluss in einen Sleepmodus schaltet. Dadurch bekommt der LC 1722 keinen Sync mehr und die TEIs werden nicht mehr zugeordnet. Dieses hat die Auswirkung, dass die internen ISDN Geräte keinen Sync mehr bekommen und die Endgeräte in einen Störungsmodus laufen.

Störungsmeldung bei Hansenet abgesetzt. Anrufe von der Hansenet Technik. Die erste Frage war, ob ich ein Endgerät habe was für Telekom (T-ISDN) Anschlüsse optimiert sei. Lancom scheint sich wohl sehr an die Telekom zu halten.

Daraufhin wurde dann die ISDN Layer aktiviert und der Anschluss auf Telekomwerte eingestellt.

Seit dieser Änderung läuft der LC 1722 wieder ohne Störungen.


Rückschluss:

Der LC 1722 hat seinen Schwerpunkt auf T-ISDN Anschlüsse und entspricht nicht 100% dem Euro-ISDN. Hansenet hat aber Euro-ISDN, so wie in fast ganz Europa.

Hier sollte Lancom unbedingt die Kompatibilität verbessern!


Ich möchte hier ausdrücklich den Service von Lancom und Hansenet loben!


Thorsten

[rubinho]

Das ist ja gut und schön für Dich.

Aber ich glaube das es keine Lösung für Festnetzlose wie mich ist.

Ich hab nämlich keinen Taktgeber.

Oder gibt es im Lancom die Möglichkeit den Takt selbst zu erzeugen ?

Gruß
Rubinho

[joeMJ]

Hi,

die letzten Siemens Dect/ GAP (5 Stück) habe ich jetzt bei meiner Erzeugerfraktion mit der featurelosen Basisstation für das C450 IP angebunden (Kosten ca. 85 EUR,- bei amazon), damit funktioniert es tadellos. Manko für mich: Makeln/ Halten fehlt noch, liefert Siemens evtl. noch nach. Die Analoge Schnittstelle v. C450IP Basis brauchst Du nicht anzuschließen.

[LoUiS]

Hallo,

nur noch ein paar Infos zum Verstaendnis:

dass Hansenet den ISDN Anschluss in einen Sleepmodus schaltet.

Dieses hat die Auswirkung, dass die internen ISDN Geräte keinen Sync mehr bekommen und die Endgeräte in einen Störungsmodus laufen.

Störungsmeldung bei Hansenet abgesetzt. Anrufe von der Hansenet Technik. Die erste Frage war, ob ich ein Endgerät habe was für Telekom (T-ISDN) Anschlüsse optimiert sei. Lancom scheint sich wohl sehr an die Telekom zu halten.

es ist lt. Euro-ISDN normal und auch erlaubt, dass der ISDN Bus deaktiviert wird. Dies wird meist von den Vermittlungsstellen gemacht, um Strom zu sparen. Es ist auch bei der Telekom normalerweise so das der Bus bei einem Mehrgeraeteanschluss deaktiviert wird und nicht nur, wie von Dir angenommen, bei Hansenet. Bei der Telekom muss ebenfalls wie bei Hansenet explizit darum gebeten werden, den Anschluss daueraktiviert zu lassen. Bei der Telekom sind ausschliesslich Anlagenanschluesse von vornherein daueraktiviert.

Es macht dem LANCOM selbst auch nichts aus, wenn der Bus deaktiviert wird, jedoch bringt es aber das Siemens Telefon dahinter aus dem Tritt.

Dies passiert, weil das LANCOM den NT Bus ISDN-2, an dem das Siemens Telefon haengt, nicht deaktiviert und der Takt daher fuer die Zeit der Deaktivierung des ISDN-1 frei laeuft. Wenn nun der Bus wieder aktiviert wird, so wird der Takt wieder synchronisiert. Dieser Angleich des ISDN1 an ISDN2 kann aber nur in kleinen Schritten passieren und dauert dann entsprechend lange, wenn der Takt zu weit auseinander gelaufen ist. Ab einer gewissen Zeit interpretiert das Telefon dies dann als Fehler und muss sich selbst neu synchronisieren.

In der Spezifikation zum Euro-ISDN wird eine maximale Abweichung des Taktes, von +-100ppm fuer ISDN Endgeraete vorgeschrieben. Ein LANCOM 1722 hat max. +-30 ppm, ist in der Regel aber genauer. Ein Vermittlungsstelle wird von einer Atomuhr synchronisiert, die natuerlich um einiges genauer ist. Dies verhaelt sich bei jedem Endgeraet und auch bei jeder Telefonanlage so, also koennte ich mir vorstellen, das dies auch an einem internen ISDN Bus einer TK-Anlage so auftritt.


Ciao
LoUiS

[LoUiS]

Hi,

Das ist ja gut und schön für Dich.

Aber ich glaube das es keine Lösung für Festnetzlose wie mich ist.

Ich hab nämlich keinen Taktgeber.

Oder gibt es im Lancom die Möglichkeit den Takt selbst zu erzeugen ?

Gruß
Rubinho

das LANCOM ist selber der Taktgeber fuer Dein Telefon und deaktiviert den Bus nicht von selbst, ausser es wird gebooted durch einen Fehler (os_panic) oder ein Firmware Update. das _koennte_ evtl. zu Problemen in dieser Richtung fuehren.
Was Du testen koenntest, waere ein D-Kanal Trace auf Layer 1 Fehler, der uns weiter helfen koennte. Lass dazu mal eine Zeitlang den "trace # d- @ ISDN-2" laufen (wenn das Telefon an ISDN-2 angeschlossen ist) und schreib das LOG mit. Achte auf Fehler im Trace und auf Resynchronisierungen und Aktivierungen des Bus. Kannst das Log ja hier posten, oder mir per PM zusenden.


Ciao
LoUiS

[Hobbyfahrer]

Hallo LoUiS,

danke für Deine Hinweise. Allerdings teile ich nicht ganz Deine Meinung, das ein Sleepmodus dem LC 1722 nichts aus macht.

Meine Erfahrungen sind, dass beim Sleepmodus nicht nur der S0 Bus deaktiviert ist sondern die TEIs nicht mehr aktiv sind. Es war dann nicht mehr möglich den Anschluß anzurufen. Selbst ein Neustart brachte keine Besserung.

In dieser Situation verlor der LC 1722 dann auch die TEIs vom S0 2 Bus.

Bei Lancom wird ja auch ständig an der Verbesserung auch der ISDN Busse gearbeitet, was auch mit in die 6.20 mit einfließen soll.

Für mich ist wichtig, dass das Gerät nun wieder läuft.


Thorsten

[eddia]

Hallo LoUiS,

Dies passiert, weil das LANCOM den NT Bus ISDN-2, an dem das Siemens Telefon haengt, nicht deaktiviert und der Takt daher fuer die Zeit der Deaktivierung des ISDN-1 frei laeuft.

mal abgesehen davon, dass ich noch nie die oben beschriebenen Probleme mit ISDN-Telefonen am ISDN-2 hatte, kann ich Deine Äusserung nicht nachvollziehen. Bei mir wird auch der 'interne' S0 deaktiviert - falls man das Ausgehen der ISDN-2 LED als solches interpretieren kann.

Gruß

Mario

[LoUiS]

mal abgesehen davon, dass ich noch nie die oben beschriebenen Probleme mit ISDN-Telefonen am ISDN-2 hatte, kann ich Deine Äusserung nicht nachvollziehen. Bei mir wird auch der 'interne' S0 deaktiviert - falls man das Ausgehen der ISDN-2 LED als solches interpretieren kann.

Nein, kann man nicht so interpretieren, das LANCOM deaktiviert den ISDN-2 Bus nie. Das erwaehnte Verhalten tritt auch m.W. nur bei einigen dieser Siemens DECT Telefonen auf und selbst da nicht bei allen. Das ist auch unabhaengig vom LANCOM, wenn man mal im Netz sucht, wird man feststellen, dass diese Problem oefters auftreten, auch an ISDN TK-Anlagen. Scheinbar synct. Siemens den Takt des ISDN auf das DECT und hat dabei bei groesseren Differenzen nach einer neu Aktivierung des Bus Probleme wieder zeitnah auf den Ursprungstakt zu synchronisieren.


Ciao
LoUiS

P.S. Unser Siemens CX "irgendwas" DECT ISDN Telefon zeigt diesen Effekt auch nicht.