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

Netview · 29 Jul 2007

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 · 1 Aug 2007

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 · 1 Aug 2007

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 · 2 Aug 2007

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

Bin deshalb bei 0.3... geblieben.

Netview · 2 Aug 2007

Hallo vWalter!

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

pms.blade · 3 Aug 2007

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 · 3 Aug 2007

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 · 3 Aug 2007

Als Workaround kann ich noch folgendes anbieten:

Code:

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

Gruß
britzelfix

martink2 · 7 Aug 2007

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 · 7 Aug 2007

@martink2

Wenn das klappt, dann ... :bier:

Der Bug ist vermutlich hier:

Code:

--- 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 · 7 Aug 2007

@britzelfix:

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

britzelfix · 8 Aug 2007

@Netview

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

Gruß
britzelfix

Netview · 8 Aug 2007

@martink2

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

britzelfix · 9 Aug 2007

@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 · 9 Aug 2007

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.

Code:

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

easimon schrieb:

Code:

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

Netview schrieb:
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 · 9 Aug 2007

@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 · 9 Aug 2007

britzelfix schrieb:
@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 · 9 Aug 2007

Und - was hat Junghanns geantwortet?

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

IPPF-Promi

Neuer User

IPPF-Promi

Neuer User

IPPF-Promi

Neuer User

Gesperrt

Gesperrt

Neuer User

Gesperrt

IPPF-Promi

Gesperrt

IPPF-Promi

Gesperrt

Neuer User

IPPF-Promi

Neuer User

Gesperrt

Neuer User

IPPF-Promi

Statistik des Forums