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

pms.blade · 10 Aug 2007

schön das es eine lösung zu geben scheint!

nur irgendwie steh ich aufm schlauch... kann mir mal bitte jemand kurz erklären wo und wie das diff einzusetzen ist?

hab mit solchen patches noch nicht viel zu tun gehabt...

danke

pms.blade · 13 Aug 2007

Hallo

hab das jetzt mit dem Patch hinbekommen... hab die zwei Zeilen auskommentiert und libpri neu kompiliert (make && make install). Hat alles soweit funktioniert und der cause 18 kommt auch nicht mehr... nur das an der ISDN Anlage angeschlossene Telefon klingelt nicht und bekommt auch kein Freizeichen.

hat da vielleicht noch jemand eine Idee?

britzelfix · 13 Aug 2007

Hier kann nur noch ein Theologe helfen.

Gruß
britzelfix

pms.blade · 13 Aug 2007

hmm... nur ob der theologe sich mit asterisk und isdn auskennt is die frage... wäre für jede nicht theologische hilfe auch dankbar!

grüße

dtinnovations · 16 Aug 2007

ich bin über das selbe Problem gestoßen.
Habe mir den 1.4 er Asterisk mit Bristuff unter FreeBSD zusammengebastelt(gibt es noch nicht über ports) und dachte auch zunächst es würde an meiner Prutscherei liegen, bis ich auf diesen Beitrag gestoßen bin.

Interessant an britzelfix' Workaround ist, dass das "GoTo" nur genau einmal ausgeführt wird.

das hier bewirkt also das gleiche:

exten => 6012595,1,Dial(Zap/g2/5,60,tr)
exten => 6012595,2,Dial(Zap/g2/5,60,tr)
exten => 6012595,3,Hangup

Die spannende Frage hieran ist doch eigentlich: "Warum funktioniert das Weiterleiten des Rufes beim zweiten Mal, obwohl ich beim ersten mal exact dasselbe tue."
Ich habe auch ein wenig in den Sourcen gewühlt, habe aber auf die Schnell die stelle nicht gefunden. Wäre um Hinweise dankbar.

Gruß

Dirk

dtinnovations · 17 Aug 2007

Da ist mir noch was aufgefallen.
ich habe mal ganz billo 'core set verbose 10' eingeschaltet:

folgenen output habe ich wenn ich von einem belibigen festnetzanschluss eine meiner internen durchwahlen direkt anwähle:

-- Accepting voice call from '2855xxxxx' to '601xxxx' on channel 0/1, span 1
-- Executing [601xxxx@isdn-incoming:1] Dial("Zap/1-1", "Zap/g2/0|200|tr") in new stack
-- Requested transfer capability: 0x00 - SPEECH
-- Called g2/0
== Primary D-Channel on span 2 up for TEI 64
== Primary D-Channel on span 2 up for TEI 65
-- Zap/4-1 is ringing
-- Channel 0/1, span 2 got hangup, cause 18
-- Hungup 'Zap/4-1'
== Everyone is busy/congested at this time (1:0/0/1)
-- Executing [601xxxx@isdn-incoming:2] Hangup("Zap/1-1", "") in new stack
== Spawn extension (isdn-incoming, 601xxxx, 2) exited non-zero on 'Zap/1-1'
-- Hungup 'Zap/1-1'
== Primary D-Channel on span 2 down for TEI 64
== Primary D-Channel on span 2 down for TEI 65

Was ich hier merkwürdig finde sind die meldungen über den TEI:
== Primary D-Channel on span 2 up for TEI 64
== Primary D-Channel on span 2 up for TEI 65

ist das richtig so, dass der D-Channel hier zweimal auf dem selben span up geht? oder kann hier die wurzel allen übels liegen. sprich der macht zwo channels auf, wobei einer der echte ist und der andere ins "nirvana" läuft und cause 18 bringt?

ist nur mal ein gedanke

gruß

dirk

pms.blade · 23 Aug 2007

Hallo an alle,

sämtliche Ansätze haben bei mir nix geholfen... irgendwo is da der Wurm drin... Wenn ich einen Anruf auf einem Telefon an der ISDN Anlage schalten will, klickt diese ganz kurz, so wie wenn sie annimmt, beended dies aber sofort... Das passiert sonst bei Besetzt...

Ich wäre echt dankbar wenn mir mal jemand helfen könnte... vielleicht liegt es ja auch an meinen configs?

sagt was ihr braucht und ich stell es zur verfügung

grüße

pms.blade · 6 Sep 2007

Hallo,

mal eine ganz doofe frage... wenn ich den verbose level auf 1o setze seh ich weder die meldung das der D-Kanal Up oder Down geht... kann da das Problem liegen?

Grüße

Starwing · 8 Sep 2007

Hat jemand schon mal ne idee woran des liegt weil dies ist echt mürpe ..
ich habs entweder bei libpri1.2.5 od. libpri1.4.2 egal bei beiden tauch der gleiche fehler auf.

anruf klingel 1 sec später hangup.

wenn ich den context zweil anwende klingelt er durchgängig.

fluse · 13 Sep 2007

Hallo,

ich hatte mit der test4 das Problem, dass ISDN-Telefone am NT nicht wählen konnten. Ankommend klappte, abgehend erkannte Asterisk keine gewählten Nummern.

Nach Herumprobieren habe ich den Tipp befolgt und die libpri.* in /usr/lib gelöscht. Anschließend den libpri-1.2.4 aus der bristuff-0.3.0-PRE-1y neu kompiliert - Voila.. Bei mir sind die Fehler am NT nun behoben.

Gruß
Fluse

Starwing · 14 Sep 2007

also hast du nun libpri1.2.4 im einsatz und nicht libpri 1.4.2 für die test4 ?
seh ich des richtig ?

fluse · 14 Sep 2007

@Starwing
Ja. Genau. Mit der libpri-1.4.1 aus bristuff-0.40.test4 kann ich an der als NT konfigurierten hfc-Karte nicht wählen. Nach dem Löschen der libs und Kompilieren der libpri-1.2.4 aus bristuff-0.30 geht es.

Gruß
Fluse

Netview · 14 Sep 2007

fluse schrieb:
@Starwing
Ja. Genau. Mit der libpri-1.4.1 aus bristuff-0.40.test4 kann ich an der als NT konfigurierten hfc-Karte nicht wählen. Nach dem Löschen der libs und Kompilieren der libpri-1.2.4 aus bristuff-0.30 geht es.

Gruß
Fluse

Diese Lösung funktionert am allerbesten!

Es reicht aus die libpri.so.1.0 auszutauschen - eine Neukompilierung von * ist nicht notwendig, daher braucht man nur die libpri-1.2.4 downzuladen und den libpri-patch aus dem bristuff-0.3.0-PRE-1y-j/k einzuspielen.
Danach lediglich ein 'make' (kein 'make install' da sonst eine 'libpri.a' erstellt und beim Kompilieren von * eingebunden wird!) und die 'libpri.so.1.0' in die 'usr/lib' kopieren (die alte 'libpri.so.1.0' kann man ja unter einem anderen Namen sichern).

Starwing · 14 Sep 2007

des ist doch schon mal was

mal guggern obs funkelt.

Netview · 22 Nov 2007

Lösung auch für den cause 18 durch libpri 1.4.2 siehe:

http://www.ip-phone-forum.de/showpost.php?p=980794&postcount=20

comvid · 8 Dez 2007

Vielen, vielen Dank! Ich liebe euch.
Mein cause 18 Problem ist jetzt auch gelöst.

Mg
Leo

heimi666 · 26 Feb 2008

Hi,
Ich habe das Cause 18 auch mit den Versionen: bristuff-0.4.0-test6, libpri-1.4.3

Ein Test mit anderen libpri Versionen konnte das Problem dann intern beseitigen mit der Konsequenz, dass ich extern kein Freizeichen mehr bekommen habe

Der Workaround mit dem zweimaligen Dial oder dem einfachem GotoIf bei Hangupcause = 18 haben den Nachteil, das das Dialtimeout nicht funtioniert, da nach dem Timeout eben genau cause 18 kommt.
U.a. Workaround klappt, da der erste Hangup mit "CHANUNAVAIL" scheitert, der zweite jedoch mit "NOANSWER". Wenn man das in einem Macro verbaut, kann man damit leben.

Code:

exten => s,n(dial),Dial(${ARG2},15,t)
exten => s,n,GotoIf($[$[${HANGUPCAUSE} = 18] & $["${DIALSTATUS}" = "CHANUNAVAIL"]]?dial)

Netview · 27 Feb 2008

Wer sucht der findet auch den libpri patch um den cause 18 zu beseitigen:

http://www.ip-phone-forum.de/showpost.php?p=1012958&postcount=5

pette · 6 Mrz 2008

Hallo,

Ich habe leider auch das "cause 18" Problem hier mit Asterisk 1.2.13-BRIstuffed-0.3.0-PRE-1v von Debian (Etch). Ich habe den cause-18 Patch erfolgreich auf das Debian libpri1.2 Paket angewendet und installiert, bekomme aber trotzdem noch den gleichen Fehler wie vorher.
Im PRI debug modus sieht das dann so aus:

Code:

  == Primary D-Channel on span 1 up for TEI 65
  == Primary D-Channel on span 1 up for TEI 66
1 < Protocol Discriminator: Q.931 (8)  len=4
1 < Call Ref: len= 1 (reference 136/0x88) (Terminator)
1 < Message type: ALERTING (1)
    -- Zap/1-1 is ringing
2 > Protocol Discriminator: Q.931 (8)  len=4
2 > Call Ref: len= 1 (reference 193/0xC1) (Terminator)
2 > Message type: ALERTING (1)
1 < Protocol Discriminator: Q.931 (8)  len=4
1 < Call Ref: len= 1 (reference 136/0x88) (Terminator)
1 < Message type: CALL PROCEEDING (2)
    -- Zap/1-1 is proceeding passing it to Zap/4-1
  == Primary D-Channel on span 1 up for TEI 64
1 < Protocol Discriminator: Q.931 (8)  len=4
1 < Call Ref: len= 1 (reference 137/0x89) (Terminator)
1 < Message type: ALERTING (1)
    -- Zap/2-1 is ringing
1 < Protocol Discriminator: Q.931 (8)  len=4
1 < Call Ref: len= 1 (reference 137/0x89) (Terminator)
1 < Message type: CALL PROCEEDING (2)
    -- Zap/2-1 is proceeding passing it to Zap/4-1
  == Primary D-Channel on span 1 up for TEI 67
1 < Protocol Discriminator: Q.931 (8)  len=4
1 < Call Ref: len= 1 (reference 136/0x88) (Terminator)
1 < Message type: CALL PROCEEDING (2)
1 < Protocol Discriminator: Q.931 (8)  len=4
1 < Call Ref: len= 1 (reference 137/0x89) (Terminator)
1 < Message type: CALL PROCEEDING (2)
1 < Protocol Discriminator: Q.931 (8)  len=8
1 < Call Ref: len= 1 (reference 136/0x88) (Terminator)
1 < Message type: DISCONNECT (69)
1 < [08 02 85 92]
1 < Cause (len= 4) [ Ext: 1  Coding: CCITT (ITU) standard (0) 0: 0   Location: Private network serving the remote user (5)
1 <                  Ext: 1  Cause: No user responding (18), class = Normal Event (1) ]
1 -- Processing IE 8 (cs0, Cause)
    -- Channel 0/1, span 1 got hangup request
    -- Channel 0/1, span 1 received AOC-E charging 0 units
1 > Protocol Discriminator: Q.931 (8)  len=8
1 > Call Ref: len= 1 (reference 8/0x8) (Originator)
1 > Message type: RELEASE (77)
1 > [08 02 85 90]
1 > Cause (len= 4) [ Ext: 1  Coding: CCITT (ITU) standard (0) 0: 0   Location: Private network serving the remote user (5)
1 >                  Ext: 1  Cause: Normal Clearing (16), class = Normal Event (1) ]
1 > Protocol Discriminator: Q.931 (8)  len=8
1 > Call Ref: len= 1 (reference 8/0x8) (Originator)
1 > Message type: RELEASE (77)
1 > [08 02 85 90]
1 > Cause (len= 4) [ Ext: 1  Coding: CCITT (ITU) standard (0) 0: 0   Location: Private network serving the remote user (5)
1 >                  Ext: 1  Cause: Normal Clearing (16), class = Normal Event (1) ]
1 > Protocol Discriminator: Q.931 (8)  len=8
1 > Call Ref: len= 1 (reference 8/0x8) (Originator)
1 > Message type: RELEASE (77)
1 > [08 02 85 90]
1 > Cause (len= 4) [ Ext: 1  Coding: CCITT (ITU) standard (0) 0: 0   Location: Private network serving the remote user (5)
1 >                  Ext: 1  Cause: Normal Clearing (16), class = Normal Event (1) ]
1 NEW_HANGUP DEBUG: Destroying the call, ourstate Disconnect Indication, peerstate Disconnect Request
1 NEW_HANGUP DEBUG: Calling q931_hangup, ourstate Disconnect Indication, peerstate Disconnect Request
    -- Hungup 'Zap/1-1'
1 < Protocol Discriminator: Q.931 (8)  len=4
1 < Call Ref: len= 1 (reference 136/0x88) (Terminator)
1 < Message type: RELEASE COMPLETE (90)

Was kann ich tun, damit das Problem endlich verschwindet?

--- [EDIT] ---
Hat sich erledigt. Der Patch wirkt nun doch, nachdem ich den externen Anrufbeantworter ausgestöpselt habe.
--- [/EDIT] ---

Gruss,
Pette

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

Neuer User

Neuer User

Gesperrt

Neuer User

Neuer User

Neuer User

Neuer User

Neuer User

Neuer User

Neuer User

Neuer User

Neuer User

IPPF-Promi

Neuer User

IPPF-Promi

Neuer User

Neuer User

IPPF-Promi

Neuer User

Statistik des Forums