ZAP Cause 34 und andere Merkwürdigkeiten

[sisko-m]

Hallo Leute,

ich wollte mal hören, nachdem ich hier schon einige Tage über dem Problem brüte, ob noch jemand ähnlich (schlechte) Erfahrung gemacht hat mit der bristuffed asterisk-1.4.21-2.

Folgende Ausgangssituation:
- Ubuntu 8.04 LTS
- Asterisk 1.4.21-2 aus dem Debian VOIP tree angereichert mit eigenen patches und den RC3C kernel Treibern aus dem Junghanns Paket.
- Junghanns Octobri Karte mit 4*TE und 4*NT Ports.
- freepbx 2.5.1

Es gehen 3 Anschlüsse als Anlagenanschlüsse Richtung Amt.
An 2 NT Ports hängen intern Faxgeräte.

Das Problem ist sehr schlecht nachvollziehbar, aber es scheint immer dann aufzutreten wenn ein ZAP bridging Zustande kommt. Heisst von Aussen ruft jemand unser Fax an bzw. ein Faxgerät ruft nach Aussen.

Dann sind im LOG ab und an (nicht immer das macht es so gemein) folgende Meldungen zu sehen:
[Nov 17 10:26:52] WARNING[7490] app_dial.c: Unable to create channel of type 'ZAP' (cause 34 - Circuit/channel congestion)
Und es geht natürlich kein Fax durch, obwohl nachweisslich nichts belegt ist.

Das schlimme daran ist das der Zap Channel eine Weile lang in diesem Status verweilt und z.B. auch keine Anrufe von einem internen SIP Telefon nach Aussen mehr gehen.

Interessanterweise ist aber der Patch von Faidon Liambotis:
fix "cause34" with BRI: reset 'call' when no call
Reset the 'call' of a zaptel channel if failing to make a call.

(commit 232eb51c7572d8f4d73649103d51d70643bd4ad9 on Xorcom's tree)

-- Faidon Liambotis <[email protected]>

--- a/channels/chan_zap.c
+++ b/channels/chan_zap.c
@@ -2735,11 +2735,12 @@ static int zt_hangup(struct ast_channel
/* if we send a rel9999ease complete we wont ge no hangup event, so clear the call here */
if (icause == 34 || icause == 44 || icause == 82 || icause == 1 || icause == 81 || icause == 17) {
if ((ast->_state == AST_STATE_RING) || (ast->_state == AST_STATE_RINGING) || (ast->_state == AST_STATE_DIALING) || (ast->_state == AST_STATE_RESERVED)) {
- p->call = NULL;
+ /* no-op */
} else {
ast_log(LOG_ERROR, "What is wrong with you? You cannot use cause %d number when in state %d!\n", icause, ast->_state);
icause = 16; /* Note, in pri_hangup() libpri will already override the cause */
}
+ p->call = NULL;
}

if (p->pri->nodetype == BRI_NETWORK_PTMP) {

bereits drin.

Das nächste Problem betrifft auch wieder ZAP. Ich hab 2 Gruppen für die Faxgeräte. g2 und g3.. Wähle ich nun die Nummer für das Faxgerät das der g3 zugeordnet ist wird jedesmal ein channel verwendet ( 7-8 ) der eigentlich g2 zugeordnet ist obwohl ich in der Console genau sehe das er g3 versucht anzuwählen.

Jetzt ist meine Frage: Bin ich der einzige der solche Probleme mit dem aktuellen bristuff hat?? Oder traut sich sonst keiner was zu ssagen

Freue mich auf Antworten, denn ich bin etwas ratlos mittlerweile.
gruss
sisko-m

 

[Blubbmon]

Ich vermute, dass ich hier ein ähnliches Problem habe. Ich habe hier ebenfalls ein Ubuntu 8.04 LTS mit dem Asterisk aus dem Ubuntu-Repository (und auch 3 Anlagenanschlüsse mit OctoBRI-Karte). Kein Witz!

Bei mir tritt das Problem auch beim Telefonieren auf (aber ansich das selbe Szenario). Ich habe testweise nur zwei B-Kanäle an die OctoBRI angeschlossen und versuche mit einem SIP-Telefon ein anderes SIP-Telefon über eine externe Anlagen-Nummer zu erreichen. Der Ruf geht also erstmal über einen Kanal raus und kommt sofort wieder über den zweiten B-Kanal rein. Es klingelt auch, aber sobald ich am angerufenen SIP-Telefon den Anruf abweise, ist die OctoBRI komplett blockiert.

Dann folgen bei abgehenden Rufen die Meldungen:

[Nov 20 22:25:39] WARNING[8525]: app_dial.c:1210 dial_exec_full: Unable to create channel of type 'ZAP' (cause 34 - Circuit/channel congestion)

und ich erreiche keine Nebenstellen mehr von Außen.

 

[sisko-m]

Hallo Blubbmon,

also bei Dir könnte es aber auch sein das die packages aus dem Ubuntu tree nicht aktuell sind und der "zap-fix-cause34" patch noch nicht dabei ist.

Welche Version der Asterisk hast Du denn am Start?

Wie gesagt bei mir kommt es auch nach dem Patch noch vor, aber eben aufälligerweise beim ZAP<->ZAP Bridging. Mir scheint es so zu sein das der Channel nach einem Hangup nicht richtig gecleart wird. Ich häng mich ja auch gerne dahinter und nehm den Code auseinander, aber nur wenn eben noch andere das Problem haben, sonst geh ich im ersten Step erstmal von einem Konfigurationsproblem aus

Gruss
sisko-m

 

[Blubbmon]

Danke für den Hinweis. Ich habe nun das bei Ubuntu "mitgelieferte" Asterisk nun komplett deinstalliert und die Quellen von Junghanns runtergeladen, gepatcht bzgl. des "cause 34" Problems und installiert. Das Problem, dass Asterisk dachte, ein Kanal sei noch belegt, ist nun verschwunden. Der Patch ist beschrieben unter:

http://lists.three-dimensional.net/pipermail/bristuff-users/2008-September/000111.html

Zusätzlich musste ich noch das Makefile von qozap so verändern, dass das make zusätzlich noch den richtigen Include-Pfad zu den im bristuff enthaltenen zaptel-Quellen bekommt (-I/usr/src/bristuff-..../zaptel/include oder so ähnlich). Das funktionierte bei mir nicht automatisch

Auf dein Problem werde ich ja dann wahrscheinlich stoßen, sobald ich mich an die Konfiguration und das Testen der NT-Ports mache. Das wird noch dieses Wochenende sein. Notfalls würde ich mich dann also auch mit dem Asterisk-Code beschäftigen ...


Viele Grüße soweit,
Blubbmon

 

[sisko-m]

Prima Dann halt mich mal auf dem Laufenden. So wie ich das sehe ist das Problem eben noch nicht final gefixed. So aussagen wie:

Tzafrir Cohen:
Unfurtunetly I haven't had the time to test this, so I put the change as
I understand it in a side branch:

Machen mich auch als Informatiker irgendwie nervös muss ich zugeben.

Gruss
sisko-m

 

[speedy1980]

Zuerst einmal: Der cause-34 Fehler wurde durch mich gefunden und der minimale Patch entwickelt. Letzlich wird das Call-Flag in bestimmten Situationen nicht zurück gesetzt. Und zwar wenn ein einkommender Zap-Anruf wieder nach extern per Zap gehen soll, aber dafür kein B-Kanal mehr frei ist. Link zur Mailing-Liste dazu hat Blubbmon ja bereits gepostet. Ich hab es mit Asterisk 1.2 und Asterisk 1.4 (bzw. dem jeweiligen Bristuff-Paket) getestet. Definitiv bringt der Patch hier Verbesserungen. Ich kann aber nicht sagen, ob es irgendwelche Nebenwirkungen gibt. Ich konnte auf mehreren Asterisk 1.2 Installationen bisher keine Probleme feststellen.
Bei Euch gehe ich erst einmal von einem Konfigurationsproblem aus.

 

[sisko-m]

Hallo Speedy,

sorry wollte hier niemand an den Karren fahren und das geistige Eigentum eines patches absprechen Habe die Info nur von Debian changelog rausgelesen.

Was den bug angeht wüsste ich momentan nicht mehr an welcher Konfiguration das noch liegen könnte (kann ja heute Abend mal meine Konfigs posten). Fakt ist allerdings das freepbx allerhand wilder Dinge mit dem Dialplan treibt. In der Vergangenheit gab es aber eigentlich nie solche Probleme.
Generell hab ich solche Probleme auch erst mit Einführung der asterisk 1.4.

Gruss
sisko-m

 

[speedy1980]

zapata.conf und zaptel.conf interessieren eigentlich nur. Beim Dialplan wird niemand so schnell durchsteigen. Besser wären die CLI Ausgaben wenn der Fehler produziert wird. So wie ich es hier verstehe ist es ja reproduzierbar.