'cause 34' nach Ausfall der ISDN-Leitung

miwag · 21 Jun 2007

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

PHP:

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

PHP:

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 · 23 Jun 2007

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 · 23 Jun 2007

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 · 24 Jun 2007

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

PHP:

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...

PHP:

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 · 24 Jun 2007

Gut dann würde ich sagen Bugmeldung an Junghanns!

miwag · 24 Jun 2007

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 · 24 Jun 2007

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 · 9 Jul 2007

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 · 4 Apr 2008

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 · 7 Apr 2008

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 · 8 Apr 2008

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 · 8 Apr 2008

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

fsiggi · 9 Apr 2008

Was soll das mit dem Provider zu tun haben??

speedy1980 · 9 Apr 2008

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 · 9 Apr 2008

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

MicroPhone · 9 Apr 2008

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

Thomas007 · 9 Apr 2008

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 · 9 Apr 2008

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 · 14 Apr 2008

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 · 6 Mai 2008

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!

'cause 34' nach Ausfall der ISDN-Leitung

Neuer User

Neuer User

Mitglied

Neuer User

Mitglied

Neuer User

Mitglied

Mitglied

Neuer User

Neuer User

Neuer User

Aktives Mitglied

Neuer User

Mitglied

Aktives Mitglied

Neuer User

Aktives Mitglied

Neuer User

Mitglied

Neuer User

Statistik des Forums