'cause 34' nach Ausfall der ISDN-Leitung

[miwag]

Ich habe hier schon seit Monaten einen Asterisk (Asterisk 1.2.17-BRIstuffed-0.3.0-PRE-1y-d) mit 2 ISDN-Karten stabil laufen.

Heute jedoch mußte ich kurz den RJ45-Stecker von der Karte, welche die Verbindung zum PSTN herstellt trennen. Der *-PC lief aber weiter.
Nach kurzer Zeit hatte ich den Stecker wieder eingesteckt und ich konnte über Asterisk keine Verbindung nach extern mehr aufbauen.
Im CLI bekomme ich bei jedem Versuch die Meldung

app_dial.c:1079 dial_exec_full: Unable to create channel of type 'Zap' (cause 34 - Circuit/channel congestion)

Ein Neustart des Asterisk (Dienst) brachte keinen Erfolg.
Erst ein Neuladen des zaphfc-Moduls mit

invoke-rc.d asterisk stop
rmmod zaphfc
modprobe zaphfc
invoke-rc.d asterisk start

brachte den gewünschten Erfolg.

Leider habe ich diesbezüglich nichts im Forum finden können und daher meine Frage an euch ob dieses Phänomen/Verhalten bei euch auch auftritt.

Muß es wirklich so sein, daß das zaphfc-Module neu geladen werden muß?
Weiß von euch vielleicht jemand eine elegantere Lösung, die evtl. auch selbstständig erkennt daß es ein Problem mit dem zaphfc-Modul bzw. dem Trunk zum PSTN gibt?

Gruß miwag

 

[jam4ever]

Ne, so in der Form ist das bei mir bis jetzt noch nicht aufgetreten..
Gib mal ein paar Details zu deinem System...
Plattform, Distribution, sonstige Dinge die auf dem System laufen.

Den Fehler 34 hatte ich bei mir glaub ich auch schonmal, aber der ging weg ohne den zaphfc neu laden zu müssen.

 

[speedy1980]

Versuch mal
zap restart span x
Das x durch die entsprechende Zahl ersetzen, bei zwei einfachen HFC Karten wirst Du span 1 und 2 haben. Ich hab den Befehl zumindest so im Kopf ... könnte auch leicht anders sein. Auf jeden Fall sollte danach kein Reload vom Modul nötig sein.

 

[miwag]

Ich habe gerade mal Deinen Vorschlag durchexerziert. Leider ohne Erfolg.
Hier mal meine Vorgehensweise.

ISDN-Verbindung zur Außenwelt gekappt. (RJ45 am NTBA abgezogen)
--> keine Meldung im CLI

Am ISDN-Telefon welches an der internen ISDN-Karte des * hängt eine Nummer zur Außenwelt gewählt.
Mit der Meldung

Jun 24 14:41:49 NOTICE[31578]: app_dial.c:1079 dial_exec_full: Unable to create channel of type 'Zap' (cause 34 - Circuit/channel congestion)

Verbindung zum NTBA wieder hergestellt und erneuter Wählversuch.
--> Die Meldung bleibt die gleiche
Deinem Vorschlag gefolgt...

zap reset span 1
  == Shutting down span 1. Please wait...
  == Starting up span 1. Please wait...
  == Reset of span 1 completed.

... und Alles bleibt wie gehabt. Es bleibt mir nur die oben beschriebene Möglichkeit Asterisk zu stoppen, zaphfc neu zu laden und Asterisk wieder zu starten. :noidea:

Gruß Miwag

 

[speedy1980]

Gut dann würde ich sagen Bugmeldung an Junghanns!

 

[miwag]

Was mich von einem Bugreport an Junghanns abhält ist, daß ich hier der Einzige bin, der mit dem Problem zu kämpfen hat. Daher denke ich es liegt wohl eher nicht an Junghanns als vielmehr an.... :noidea:

 

[speedy1980]

Trotzdem einfach mal eine E-Mail hinschreiben mit der Frage nach einem Bug, hat ja keine negativen Folgen. Die Leute ziehen nun mal nicht ständig ihr ISDN Kabel ab und stecken es wieder dran

 

[speedy1980]

Ich hatte jetzt das gleiche Problem mit einer 4-Port Karte, Bristuff 0.3.0-PRE-1y-g. Allerdings hat da keiner das ISDN Kabel abgezogen gehabt oder so... Gibt es bei Dir Neuigkeiten zu dem Thema?

 

[MicroPhone]

Moechte mich anschliessen - mit einer OctoBri auf nem bristuff-0.4.0-test6 asterisk 1.4.17. - Eingehende Gespraeche funktionieren - bei ausgehenden kommt o.g. Fehlermeldung.

Gruss Micro

 

[fsiggi]

Schliesse mich auch an - mit einer Beronet BN4S0 auf bristuff 0.4.0-test6 asterisk 1.4.17.
Eingehende Gespräche gehen, bei ausgehenden kommt der cause 34 Fehler.

Abhilfe schafft, die ISDN-Kabel für einige Sekunden abzuziehen. Asterisk startet dann mit etwas Glück den span neu.

Den Befehl "zap reset span" gibt es leider gar nicht (mehr?).

Gruss
fsiggi

 

[DomRoc]

Hallo,

kann ich bestätigen. Manchmal melden meine ZAP-Channel Congestion (cause 34) obwohl Sie nachweislich frei sind.
Hat jemand schon eine Lösung?

Meine Lösung war das Beenden und Neustarten der Asterisk-Software...

Grüße,
DomRoc

 

[Thomas007]

Habe das gleiche Problem.
Welcher Provider, evtl. Alice?

 

[fsiggi]

Was soll das mit dem Provider zu tun haben??

 

[speedy1980]

Es wird nichts mit dem Provider zu tun haben ... Ich hab das Problem an mehreren Schweizer ISDN Anschlüssen gesehen.
Vielleicht sollten wir uns mal an Junghanns wenden. Wer hatte schon mal (positiven) Kontakt?

 

[Thomas007]

Tritt bei mir nur da auf und auch erst seit Alice Provider ist.
ansonsten keine Probleme dieser Art

 

[MicroPhone]

Trat bei uns mit T-Com auf. Von den Channels war max 1 von 4 ISDN-CHAN (PTP) belegt.

 

[Thomas007]

LBO bei dem Alice Anschluss auf 0 gesetzt und span ist up.

Zur allg. Info auch mal diesen Thread lesen:
http://www.ip-phone-forum.de/showthread.php?t=125837

 

[fsiggi]

Bei uns ist das Problem an Colt-Anschlüssen zu finden, T-CoMs haben es bisher nicht gehabt, aber darüber wird auch kaum nach außen telefoniert.

Ich werde das mit dem LBO mal testen, danke!

 

[speedy1980]

Irgendwie erschließt sich mir da kein Zusammenhang. Warum soll lbo=0 den Fehler beheben? Ich hab jetzt seit 2 oder 3 Wochen bristuff-0.3.0-PRE-1y-p am laufen. Damit ist der "cause 34" Fehler bisher nicht mehr aufgetreten (trotz lbo=3). Kann das jemand bestätigen?

 

[DomRoc]

ALso bei mir habe ich den schuldigen gefunden:

Der intern S0-Bus der AGFEO fährt sich manchmal komplett runter und dann gleich wieder hoch:

== Primary D-Channel on span 4 down
== Primary D-Channel on span 4 up

Da kann ich auch kein Muster erkennen. Manchmal passiert's halt einfach, und dann sind die Gespräche eben weg!
Wenn es bei "echten" externen Anschlüssen auftritt kann man wohl nur die Telefongesellschaft dafür verantwortlich machen!