[gelöst] Verbindung via HFC klappt nur 1 mal

[Larry]

Moin zusammen,

habe Pfingsten dazu nutzen wollen, endlich mal Asterisk zur ISDN-"Hauptanlage" zu machen. Dazu habe ich alle möglichen Links, Vorschläge etc. abgegrast und befolgt; an dieser Stelle vielen Dank an alle Poster für die hilfreichen Tips und Links!

IST-Zustand: Amt<->P2MP-Anlage (tiptel 412usb)+Telefone<->Asterisk (AVM)
SOLL-Zustand: Amt<->Asterisk (HFC/AVM)<->P2MP-Anlage+Telefone
!!!EDIT!!! SOLL-Zustand: Amt<->Asterisk<->AVM-USB<->HFC-USB<->P2MP-Anlage+Telefone

Im großen und ganzen klappt alles wunderbar, bis auf die Tatsache, dass bei Verkabelung nach SOLL der Verbindungsaufbau per ISDN-Telefon (mit eigener Stromversorgung) genau 1mal funktioniert und das auch nur wenige Sekunden lang. Dann bricht die Verbindung ab und ist auch nicht mehr möglich, neu aufzubauen. Erst nach trennen der Stromversorgung der TK-Anlage klappt es wieder nur 1mal.

An Verkabelung und Tests habe ich bislang folgendes probiert, ausgehend von hfcusb im NT-Modus:
X-Kabel an Anlage: OK, klappt 1mal
X-Kabel mit Abschlußwiderständen an Anlage: dito
X-Kabel an NTBA o.Strom, dann normal an Anlage: dito
X-Kabel an NTBA mit Strom, dann normal an Anlage: dito

Nachdem ich das verdächtige X-Kabel nochmals durchgemessen habe:
X-Kabel an Telefon mit Strom: "Störung"
X-Kabel mit Abschlußwiderständen an Telefon mit Strom: "Störung"
X-Kabel an NTBA o.Strom, dann normal an Telefon mit Strom: "Störung"
X-Kabel an NTBA mit Strom, dann normal an Telefon mit Strom: "Störung"


Eigentlich sollte das Telefon ja zumindest mal ein Freizeichen bringen; andererseits macht es mich stutzig, dass die Anlage nur einmal für wenige Sekunden, dafür in guter Qualität meine Demo runterleiert und dann den weiteren Dienst verweigert.

Im TE-Modus lief das HFC-Modul bei vielen Tests bislang stabil; ich gehe also mal davon aus, dass es weder das Modul noch mISDN sein dürfte...

Irgendwie habe ich den Eindruck, ich habe bei der ganzen Aktion etwas übersehen...
Bin für jeden Hinweis dankbar!

 

[Larry]

Teilentwarnung

...interessanter Tag heute. Habe heute mit einem guten Bekannten beim rosa T gequatscht, um mich u.a. zu versichern, dass ich keinen Blödsinn gebaut habe. Man versicherte mir, dass das zuvor beschriebene schon in Ordnung wäre, soweit dort nachvollziehbar...

Zurück in meiner Bastelstube habe ich vorhin mal das ganze mISDN-Paket (mqueue mit chan_misdn 0.3.1-rc6) "geparkt" und frisch installiert, diesmal mit chan_misdn 0.3.1-rc9 (gabs heute morgen neu).

Siehe da: Teste jetzt schon eine ganze Weile hin und her und alles scheint bestens zu funktionieren. Werde das noch den Rest der Woche im Auge halten und ggf. das Subject auf [gelöst] setzen.


Soweit ich Euch jetzt schon den Rat geben darf:
Habt Ihr ein problem mit mISDN, nicht verzagen, andere/neuere Version nehmen und einige Probleme lösen sich von selbst (Korrigiert mich bitte, wenn ich damit falsch liege)

 

[UnimatrixZero]

Hallo,

habe hier fast dasselbe Problem. Es sollte alles richtig verkabelt sein, aber die TK-Anlage btw. die Telefone bekommen kein Freizeichen. Es steht immer nur "Störung" auf dem Display (ist eine Gigaset 1054isdn mit 1000C-Telefonen).
Es tut sich aber irgendwas, da mISDN Debug-Ausgaben ausspuckt.
Auch die aktuellen Versionen von * und mISDN bringen leider keine Besserung.

Wie sieht Deine misdn.conf und extensions.conf aus? Mir ist immer noch nicht klar, wer eigentlich für den Wählton direkt nach dem Abheben sorgen muß. Braucht es da ein spezielles Kommando in der extensions.conf? Wie ich die Anlagentelefone vom * aus anwählen muß, ist mir klar, aber wie bringt man dem * die umgekehrte Richtung bei?

 

[Larry]

Hallo UnimatrixZero,

wer genau für den "Amtston" zuständig ist, kann ich Dir nicht sagen, wohl aber, dass es weder an der misdn.conf, noch an der extensions.conf liegt, denn da Deine Telefone am internen S0 der TK-Anlage angeschlossen sind, sollten sie auch von dort den internen "Amtston" (z.B. *TUT*TUUT*) bekommen.

Bis hierhin brauchst Du keine korrekte misdn.conf noch extensions.conf, da sich ja noch alles innerhalb Deiner Telefone und TK-Anlage bewegt.

Wenn Du ab hier eine halbwegs korrekte misdn.conf hast, weiß die ISDN-Karte, bzw. * wohin die Reise geht, wenn ein interner Ruf die TK-Anlage verläßt, heißt, wenn Du an einem der Telefone die Amtsziffer - meist 0 - drückst; jetzt bekommst Du den "echten Amtston" (*TUUUUUT*) (ob * den auch erzeugt, weiß ich nicht, kann auch sein, daß das Telefon/TK-Anlage freie b/d-Kanäle sieht und selber den Amtston erzeugt; aber man hört den Amtston nur, wenn * läuft).

Bis hierhin brauchst Du immer noch keine extensions.conf; dort steht ja eigentlich nur drin, was mit den ab jetzt gewählten Ziffernfolgen passieren soll.

Meine misdn.conf ist default, in der ich nur den CONTEXT angepasst habe; in der extensions.conf habe ich als einzige Einträge

exten => _XXXXX.,1,answer
exten => _XXXXX.,2,playback(testmusik)
exten => _XXXXX.,3,answer

damit ich während der ersten Testphase jeden rausgehenden Ruf abfange und eine lange Musik abspiele.


Bekommen Deine Telefone GAR KEIN Freizeichen, oder nur keines, nachdem Du Dir das Amt holen wolltest?
Läuft die TK-Anlage auf P2MP? Das mISDN-Kernelmodul auch und zwar im NT-Modus?

 

[UnimatrixZero]

Hallo Larry,

erstmal Danke für Deine ausführliche Antwort.

wer genau für den "Amtston" zuständig ist, kann ich Dir nicht sagen, wohl aber, dass es weder an der misdn.conf, noch an der extensions.conf liegt, denn da Deine Telefone am internen S0 der TK-Anlage angeschlossen sind, sollten sie auch von dort den internen "Amtston" (z.B. *TUT*TUUT*) bekommen.

Bis hierhin brauchst Du keine korrekte misdn.conf noch extensions.conf, da sich ja noch alles innerhalb Deiner Telefone und TK-Anlage bewegt.

Die Anlage hat keinen internen S0-Bus. Ist aber in diesem Fall egal, da die Telefone per DECT angebunden sind und man anlagenintern auch telefonieren kann.

Wenn Du ab hier eine halbwegs korrekte misdn.conf hast, weiß die ISDN-Karte, bzw. * wohin die Reise geht, wenn ein interner Ruf die TK-Anlage verläßt, heißt, wenn Du an einem der Telefone die Amtsziffer - meist 0 - drückst; jetzt bekommst Du den "echten Amtston" (*TUUUUUT*) (ob * den auch erzeugt, weiß ich nicht, kann auch sein, daß das Telefon/TK-Anlage freie b/d-Kanäle sieht und selber den Amtston erzeugt; aber man hört den Amtston nur, wenn * läuft).

Genau um den geht's mir. Statt dem echten Amtston kommt sofort die Anzeige "Störung" und es ertönt der Fehlerton der Anlage. Wenn ich die Verbindung zwischen * und der Anlage trenne, erscheint die Störungsanzeige erst nach ein paar Sekunden.

Mir ist auch gerade eingefallen, daß der Amtston eigentlich von * oder mISDN kommen muß, da er bei Auslandstelefonaten ja auch anders klingt.

Bis hierhin brauchst Du immer noch keine extensions.conf; dort steht ja eigentlich nur drin, was mit den ab jetzt gewählten Ziffernfolgen passieren soll.

Meine misdn.conf ist default, in der ich nur den CONTEXT angepasst habe; in der extensions.conf habe ich als einzige Einträge

exten => _XXXXX.,1,answer
exten => _XXXXX.,2,playback(testmusik)
exten => _XXXXX.,3,answer

damit ich während der ersten Testphase jeden rausgehenden Ruf abfange und eine lange Musik abspiele.

Wenn ich das richtig verstehe, dann ist das die Richtung TK->Asterisk. Ich werde diese Zeilen mal testen.

Bekommen Deine Telefone GAR KEIN Freizeichen, oder nur keines, nachdem Du Dir das Amt holen wolltest?
Läuft die TK-Anlage auf P2MP? Das mISDN-Kernelmodul auch und zwar im NT-Modus?

So ist es. Wo eigentlich der Amtston kommen sollte, habe ich nur "Störung" auf dem Display stehen. Die HFC-Karte ist auf nt-ptmp eingestellt und die Anlage auf Mehrgeräteanschluß konfiguriert. Das X-Kabel habe ich auch schon mehrfach durchgemessen und sollte passen.
Ich vermute mal, daß irgendwas in der Kommunikation */mISDN <-> Anlage nicht geht, da ich auch keines der Anlagentelefone von * aus anwählen kann.

 

[Larry]

Die Anlage hat keinen internen S0-Bus. Ist aber in diesem Fall egal, da die Telefone per DECT angebunden sind und man anlagenintern auch telefonieren kann.

Ah jetzt ja. Also soll die Anlage über den externen S0 an * angeklemmt werden.

Statt dem echten Amtston kommt sofort die Anzeige "Störung" und es ertönt der Fehlerton der Anlage. Wenn ich die Verbindung zwischen * und der Anlage trenne, erscheint die Störungsanzeige erst nach ein paar Sekunden.

Das sieht mir aber echt nach 'nem Problem des X-Kabels aus. Hatte ich auch am Anfang, als ich wider besseren Wissens ein 1:1-Kabel verwendet habe, um zu sehen/hören/lernen, was überhaupt am S0 so passiert.
Ist Dein X-Kabel direkt (mit oder ohne 100-Ohm Widerstände?) oder über einen weiteren NTBA an der HFC-Karte angeklemmt? Im Zweifel mal jede Möglichkeit ausprobieren...

exten => _XXXXX.,1,answer
exten => _XXXXX.,2,playback(testmusik)
exten => _XXXXX.,3,answer

Wenn ich das richtig verstehe, dann ist das die Richtung TK->Asterisk. Ich werde diese Zeilen mal testen.

Stimmt, vergaß ich zu erwähnen. Im Testbetrieb habe ich noch keine Verbindung von * zum Amt.

Ich vermute mal, daß irgendwas in der Kommunikation */mISDN <-> Anlage nicht geht, da ich auch keines der Anlagentelefone von * aus anwählen kann.

Das sehe ich auch so.
Überprüfe aber mal, ob die HFC-Treiber auch WIRKLICH im NT-Mode geladen werden. Ich hatte mir Anfangs den Wolf gesucht, da meine Treiber partout im TE-Modus liefen, egal wie ich sie aufrief. Bei meinem Gentoo lags daran, dass es bereits /etc/modules.d/misdn gab, in der drinne stand, die Treiber mögen bitteschön im TE-Mode laden
Flux abgeändert auf

options hfcsusb  protocol=0x12 layermask=0x3

oder per

modprobe hfcsusb  protocol=0x12 layermask=0x3

aufrufen und schon war die *-Welt etwas bunter

 

[UnimatrixZero]

Das sieht mir aber echt nach 'nem Problem des X-Kabels aus. Hatte ich auch am Anfang, als ich wider besseren Wissens ein 1:1-Kabel verwendet habe, um zu sehen/hören/lernen, was überhaupt am S0 so passiert.
Ist Dein X-Kabel direkt (mit oder ohne 100-Ohm Widerstände?) oder über einen weiteren NTBA an der HFC-Karte angeklemmt? Im Zweifel mal jede Möglichkeit ausprobieren...

Es funktioniert
Meine alte HFC-Karte war kaputt. Mit der neuen hatte ich die Variante mit NTBA noch nicht getestet, sondern nur die Direktverbindung verwendet, da crich in einem anderen Thread gemeint hatte, es ginge auch so.
Wenn's nach dem nächsten Reboot immer noch geht, dann kann ich mich endlich an die eigentliche Konfiguration machen ;-)

Danke nochmal.

 

[Larry]

Na, das ist doch mal etwas! Schön, dass es bei Dir jetzt auch klappt!

Mit der neuen hatte ich die Variante mit NTBA noch nicht getestet, sondern nur die Direktverbindung verwendet, da crich in einem anderen Thread gemeint hatte, es ginge auch so.

Das kann ich nur bestätigen; es scheint so, dass der NTBA nur der Einfachheit halber verwendet werden kann, bzw. man MUSS ihn samt Stromversorgung verwenden, wenn man so über die HFC-Karte einen intern S0 aufbauen will, deren TE-Geräte keine eigene Stromversorgung haben (man möge mich hier ggf. korrigieren).

 

[Larry]

Ende gut, alles gut

Thread als gelöst markiert, da alles seit dem 06.06. stabil in der Weise wie beschrieben läuft.
Einzige Änderung ist die Verwendung von chan_misdn-0.4.0-rc2 seit dem 08.06., da es mit chan_misdn-0.3.1-rc9 einen nicht nachvollziehbaren Absturz seitens Asterisk gab...aber meine Frau konnte halt nicht mehr telefonieren...ganz schlecht

Aufgefallen ist mir nur noch, dass das holen eines Amts, also HFC/Asterisk, manchmal mehrere Sekunden dauert, ehe man den Amtston hört. Außerdem hört man manchmal bei diesem Amtston ein seltsames "knuspern" in der Leitung, was aber verschwindet, wenn erst mal eine Verbindung zum Gesprächspartner steht (beides Auffälligkeiten mit chan_misdn-0.3.1-rc9 und chan_misdn-0.4.0-rc2).

Ansonsten eine erfreulich stabile Lösung. Bin sind sehr zufrieden und gespannt, was noch alles kommt...

An dieser Stelle besten Dank für alle Tipps, Links und Vorschläge und ein noch größeres Lob an die mISDN-Entwickler!