*1.4.x+bristuff-0.4.0-test4 hangup cause 18

[Netview]

Hi!

Ich bin diese Woche von Asterisk 1.2.23-BRIstuffed-0.3.0-PRE-1y-j (+florz-patch) auf 1.4.9+bristuff-0.4.0-test4 umgestiegen und habe das Problem, dass bei einem Ruf auf eine interne Nummer z.B.: 'Dial(Zap/g2/7053,120,)' die hfc-Karte (NT-Mode) bzw. das daran angeschlossene Endgeräte 'Siemens Gigaset 4170' nach ca. 3 Sekunden ein:

-- Channel 0/1, span 2 got hangup request, cause 18

signalisiert und anschliessend der channel beendet wird (hangup).

Ist dies ein bekannter Fehler im bristuff für * 1.4?

Gruss
Netview

PS: abgehende Gespräche via zap-channel auf SIP oder IAX2 sind problemlos möglich!

 

[pms.blade]

Hallo Netview,

ich habe das selbe Problem... allerdings bei der 0.3.0pre... wie in dem http://www.ip-phone-forum.de/showthread.php?t=144109
post beschrieben...
deshalb denke ich es ist ein Konfigurationssache

Grüße

 

[Netview]

Es kann imho keine Konfigurationssache sein da die zapata.conf, zaptel.conf sowie extensions.conf von *-1.2.23 zu 1.4.9 (jeweils bristuffed) identisch sind und in der alten Version laufen und in der Neuen nicht :-(

 

[vWalter]

Habe dasselbe Problem - Calls via IP-Phone sind ok, am ISDN-Bus geht nix.

Bin deshalb bei 0.3... geblieben.

 

[Netview]

Hallo vWalter!

Danke für deinen Hinweis (ich fühle mich dann wenigstens nicht so alleine auf der Welt) :mrgreen:

 

[pms.blade]

also ich hab das problem weiterhin bei der 0.3 und der 0.4...

hat denn niemand ne idee?

wäre für jede hilfe dankbar

 

[britzelfix]

Falls es interessiert...

Die Ausgabe wird in der chan_zap.c:10415 erzeugt und
"cause 18" bedeutet PRI_CAUSE_NO_USER_RESPONSE

Wenn es nur bei test4 passiert, dann kann man gegen
test3,2,1 Diffs erzeugen und so dem Bug auf die
Spur kommen.

Gruß
britzelfix

 

[britzelfix]

Als Workaround kann ich noch folgendes anbieten:

exten => s,2,Dial(ZAP/whatever,,)
exten => s,3,GotoIf($[${HANGUPCAUSE} = 18]?2)
exten => s,4,Hangup()

Gruß
britzelfix

 

[martink2]

Hallo,
ich hatte das selbe Problem und nach ein bischen rumprobieren
konnte ich den verantwortlichen (die libpri) ausmachen.
Den genauen Fehler konnte ich noch nicht ausmachen von
daher kann ich leider noch kein Patch anhängen. Als workaround
benutze ich gerade einfach die alte libpri (1.2.4) und compile den
bristuff und asterisk dagegen. Funktioniert bis jetzt super.

grüße

martin

 

[britzelfix]

@martink2

Wenn das klappt, dann ... :bier:

Der Bug ist vermutlich hier:

--- q921.c      2007-08-07 11:12:47.234985610 +0200
+++ q921.c.new  2007-08-07 11:15:17.652038546 +0200
@@ -690,4 +690,8 @@
        if (pri->txqueue[teio]) {
                /* Something left to transmit, Start the T200 counter again if we stopped it */
+               if (pri->t200_timer[teio]) {
+                       pri_schedule_del(pri, pri->t200_timer[teio]);
+                       pri->t200_timer[teio] = 0;
+               }
                if (pri->debug & PRI_DEBUG_Q921_DUMP)
                        pri_message(pri, "-- Something left to transmit (%d), restarting T200 counter\n", pri->txqueue[teio]->h.n_s);

(Dieses diff gegen das schon gepatchte libpri/q921.c des
bristuff-0.4.0-test4 anwenden.)

Ich kann es leider jetzt nicht testen und würde mich
freuen wenn das mal jemand macht und berichtet.

Gruß
britzelfix

 

[Netview]

@britzelfix:

Ich habe es ausprobiert - allerdings kommt weiterhin der cause 18 :-(

 

[britzelfix]

@Netview

Ok, danke. Vielleicht dringt der Bug irgendwann zu junghanns durch.
Es bleibt aber noch die Lösung von martink2. :freu:

Gruß
britzelfix

 

[Netview]

@martink2

Wieso eigentlich die 1.2.4 und nicht die 1.4.0 - wir sprechen doch von * 1.4 ?!

 

[britzelfix]

@Netview

Hab jetzt die test4 "from scratch" installiert
und ohne florz - works like charm.

So schließe ich mich mal jetzt pms.blade an.

Gruß
britzelfix

 

[easimon]

ich hatte auch das problem und ich denke, ich habe die zeilen gefunden, die das verhalten bewirken. nur bin ich mir nicht sicher, ob das wirklich "das richtige ist". jedenfalls funktioniert asterisk 1.4 seitdem endlich bei mir.

--- q931.c~     2007-08-08 23:58:52.000000000 +0200
+++ q931.c      2007-08-08 23:58:52.000000000 +0200
@@ -3634,8 +3634,8 @@
                c->sendhangupack = 1;
                UPDATE_OURCALLSTATE(pri, c, Q931_CALL_STATE_CALL_INITIATED);
                c->peercallstate = Q931_CALL_STATE_OVERLAP_SENDING;
-               c->t303timer = pri_schedule_event(pri, pri->timers[PRI_TIMER_T303], pri_setup_response_timeout, c);
-               c->t303running = 1;
+//             c->t303timer = pri_schedule_event(pri, pri->timers[PRI_TIMER_T303], pri_setup_response_timeout, c);
+//             c->t303running = 1;
        }
        return res;

 

[Netview]

--- q931.c~     2007-08-08 23:58:52.000000000 +0200
+++ q931.c      2007-08-08 23:58:52.000000000 +0200
@@ -3634,8 +3634,8 @@
                c->sendhangupack = 1;
                UPDATE_OURCALLSTATE(pri, c, Q931_CALL_STATE_CALL_INITIATED);
                c->peercallstate = Q931_CALL_STATE_OVERLAP_SENDING;
-               c->t303timer = pri_schedule_event(pri, pri->timers[PRI_TIMER_T303], pri_setup_response_timeout, c);
-               c->t303running = 1;
+//             c->t303timer = pri_schedule_event(pri, pri->timers[PRI_TIMER_T303], pri_setup_response_timeout, c);
+//             c->t303running = 1;
        }
        return res;

Prima - bei mir funktioniert der patch!

Es reicht die libpri.so.1.0 neu zu erstellen - asterisk muss nicht neu compiled und gelinked werden

 

[easimon]

Prima - bei mir funktioniert der patch!

Es reicht die libpri.so.1.0 neu zu erstellen - asterisk muss nicht neu compiled und gelinked werden

Die auskommentierten Zeilen waren bei 1.2 noch nicht da, daher gehts nun wieder
Ganz richtig ist das so aber IMHO nicht, die "Cause 18"-Meldung kommt mit pri debug immernoch, sie wird quasi nur ignoriert.

Gruss, Markus

 

[britzelfix]

@easimon

Seltsam.

Die auskommentierten Zeilen waren bei 1.2 noch nicht da, daher gehts nun wieder

Schau mal noch mal hin. In der 1.2.23-BRIstuffed-0.3.0-PRE-1y-j,
die Netview anfangs erwähnt hat, waren diese Zeilen schon da.

Gruß
britzelfix

 

[easimon]

@easimon

Seltsam.

Schau mal noch mal hin. In der 1.2.23-BRIstuffed-0.3.0-PRE-1y-j,
die Netview anfangs erwähnt hat, waren diese Zeilen schon da.

Gruß
britzelfix

Du hast recht, ich habe die 1.4.4 bristuffed mit 1.2.5 "plain" verglichen. Die Zeilen (bzw. der T303-Timer im allgemeinen) stammen aus dem bristuff-patch. Wäre offensichtlich einen Bugreport an kapejod oder florz wert.

Zumindest letzterer hat mir auf meine Mail bzgl. des Fehlers jedoch nicht geantwortet.

Gruss, Markus

 

[Netview]

Und - was hat Junghanns geantwortet?