'cause 34' nach Ausfall der ISDN-Leitung

miwag

Neuer User
Mitglied seit
29 Mai 2006
Beiträge
17
Punkte für Reaktionen
0
Punkte
0
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
 
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.
 
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.
 
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
 
Gut dann würde ich sagen Bugmeldung an Junghanns!
 
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:
 
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 :)
 
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?
 
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
 
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
 
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
 
Habe das gleiche Problem.
Welcher Provider, evtl. Alice?
 
Was soll das mit dem Provider zu tun haben??
 
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?
 
Tritt bei mir nur da auf und auch erst seit Alice Provider ist.
ansonsten keine Probleme dieser Art
 
Trat bei uns mit T-Com auf. Von den Channels war max 1 von 4 ISDN-CHAN (PTP) belegt.
 
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!
 
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?
 
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!
 
Holen Sie sich 3CX - völlig kostenlos!
Verbinden Sie Ihr Team und Ihre Kunden Telefonie Livechat Videokonferenzen

Gehostet oder selbst-verwaltet. Für bis zu 10 Nutzer dauerhaft kostenlos. Keine Kreditkartendetails erforderlich. Ohne Risiko testen.

3CX
Für diese E-Mail-Adresse besteht bereits ein 3CX-Konto. Sie werden zum Kundenportal weitergeleitet, wo Sie sich anmelden oder Ihr Passwort zurücksetzen können, falls Sie dieses vergessen haben.