[Frage] Bristuffed Asterisk legt nicht auf...

[mhamann]

Hallo Allerseits,

habe bei einer Asterisk Installation (1.2.14-BRIstuffed-0.3.0-PRE-1y) zusammen mit einer Junghanns OctoBRI Karte ein merkwürdiges Problem.

Asterisk scheint in seltenen Fällen nicht aufzulegen. Heisst konkret ein Anwender telefoniert per SIP Endgerät via ZAP zum Amt und legt nach Beendigung des Gespräches auf. An seinem Endgerät sieht alles korrekt aus. Das Telefon legt auf und alles wie gewohnt.

Auf Asterisk Seite ist es aber so, dass die Verbindung weiter bestehen bliebt. Heisst die ISDN Verbindung wie auch die SIP Verbindung bleiben bestehen. (show channels zeigt es auch entsprechend an). Auch eine BLF Taste an z.B. eine SNOM Taste zeigt den Status nach wie vor als InUse an und leuchtet.

Auflegen ist dann nur noch durch einen soft hangup von der Asterisk Console aus möglich.

Das Problem scheint wohl in Fällen aufzutreten, wo die Gegenstelle nicht auflegt. Leider kann ich das Ganze nicht genau reproduzieren, aber bei einer Konferenznummer hatte ich das Problem. Hier legt die Gegenstelle nicht auf und die Verbindung bliebt bestehen, obwohl am SIP Endgerät alles normal aussah.

Ist jemand diese Thematik schon einmal untergekommen? Oder mache ich hier was falsch?

Bin dankbar für jeden Hinweis, da mich die Sache so etwas beunruhigt.

Hier noch ein paar Konfigurationsauszüge:

zapata.conf:

[channels]

switchtype = euroisdn

pridialplan = unknown
prilocaldialplan = unknown
priindication = passthrough

localprefix = 0761
nationalprefix = 00
internationalprefix = 000
privateprefix = 0
unknownprefix = 0

language=de
rxgain=0.0
txgain=0.0
echocancel = yes
echocancelwhenbridged = yes
echotraining = 100

;-------------------------------------------------------------------
; p2p TE mode (for connecting ISDN lines in point-to-point mode)
signalling = bri_cpe

context=isdn-incoming
group = 1
overlapdial=yes
immediate=no

; S/T port 1-3 (octoBRI)
channel => 1-2
channel => 19-20
channel => 22-23

zaptel.conf:

defaultzone=de


span=1,1,3,ccs,ami
span=2,2,3,ccs,ami
span=3,3,3,ccs,ami
span=4,4,3,ccs,ami
span=5,5,3,ccs,ami
span=6,6,3,ccs,ami
span=7,7,3,ccs,ami
span=8,8,3,ccs,ami

bchan=1,2
dchan=3
bchan=4,5
dchan=6
bchan=7,8
dchan=9
bchan=10,11
dchan=12
bchan=13,14
dchan=15
bchan=16,17
dchan=18
bchan=19,20
dchan=21
bchan=22,23
dchan=24

extensions.conf:

exten => _0Z.,1,Set(GROUP(${CALLERIDNUM})=${CALLERIDNUM})
exten => _0Z.,n,Dial(${AMT}/${EXTEN:1},60,r)
exten => _0Z.,n,Goto(00-${DIALSTATUS},1)

exten => 00-NOANSWER,1,Busy(60)
exten => 00-NOANSWER,2,Hangup()

exten => 00-CHANUNAVAIL,1,Busy(60)
exten => 00-CHANUNAVAIL,2,Hangup()

exten => 00-BUSY,1,Busy(60)
exten => 00-BUSY,2,Hangup()

exten => 00-CONGESTION,1,Busy(60)
exten => 00-CONGESTION,2,Hangup()

 

[clan]

1. Ohne die Ausgaben auf der Asterisk-Konsole oder den Logs zu sehen, ist es schiweirig, dir weiterzuhelfen.

2. Wie lange hast du denn auf das Auflegen gewartet, bis du entschieden hast, daß es nichts mehr wird?

3. Warum Busy(60)?

 

[mhamann]

1. Ohne die Ausgaben auf der Asterisk-Konsole oder den Logs zu sehen, ist es schiweirig, dir weiterzuhelfen.

2. Wie lange hast du denn auf das Auflegen gewartet, bis du entschieden hast, daß es nichts mehr wird?

3. Warum Busy(60)?

Problem ist, dass sich das Verhalten so nicht reproduzieren lässt. Somit kann ich leider keine Konsolenausgaben liefern.

In besagtem Falle stand die Verbindung mehrere Stunden bevor es bemerkt wurde.

Busy(60) um möglich Fehlbedienungen der Benutzer abzufangen. In der Regel legt der Benutzer vorher auf und damit wird der Call beendet.

Finde die Sache sehr mysteriös und etwas unebruhigend, da ich nicht immer schauen kann, ob irgendwo Verbinden "hängen geblieben" sind.

Hatte das Verhalten auch schon mal bei einer Faxnummer, die auf der Gegenseite nicht auflegt, sondern ein Auflegen des Anrufers erwartet.

Habe mir jetzt mit einem AbsoluteTimeout geholfen, aber auch hier habe ich meine Zweifel, ob die Verbindung damit beendet wird, wenn es mit normalem Hangup nicht funktioniert.

Leider lässt sich das ganze bisher leider nicht reproduzieren, weshalb ich Probleme habe das ganze genauer zu untersuchen.

Mich würde vor allem interessieren, ob schon einmal jemand anders vergleichbares Verhalten bemerkt hat oder ob an meiner Konfig evtl. was faul ist.

Grüße aus Freiburg
Michael

 

[Jogi76]

Hallo Michael,

also mich quälen seit ein paar Tagen die gleich Probleme. Konntest du das Problem schon beheben?

Ausgehenden Gespräche wie zb. Anpingen des Handys die laut Asterisk log -> Hungup 'Zap/2-1' Terminiert werden klingeln am anderen Ende einfach weiter.

Hier mal meine zapata.conf, vielleicht hab ich ja was übersehn

[channels]
switchtype=euroisdn
pridialplan=local
prilocaldialplan=local
priindication=passthrough
internationalprefix=00
nationalprefix=0
usecallingpres=yes
busydetect=no
callwaitingcallerid=yes
callprogress=no
echotraining=no
echocancel=yes
echocancelwhenbridged=yes
overlapdial=yes
immediate=no
callerid=asreceived
language=de
musiconhold=default
faxdetect=both

group=1
signalling=pri_cpe
context=from-trunk
channel=>1-15,17-31

group=2
signalling=bri_cpe_ptmp
context=from-trunk
channel=>32-33

Mir sind die möglichen Values der Option "priindication" auch nocht net so ganz klar. Ich hab einfach mal "inband", "outofband" und "passthrough" getestet, ohne veränderung.

Wenn jemand ne Idee hat woran es liegen könnte.

EDIT: Oh man, hab den Fehler gefunden. Es lag an

CALLERID(rdnis)=${CALLERIDNUM}

vorm rauswählen - Ich weiss zwar nicht wie das in den Dialplan gekonnen ist, aber na gut - da kommen nicht viele Personen in Frage.

Gruss Jogi