Dahdi Channel Is Not Hanging Up

[andy18 (Andy Saw)]

Hi Guys,

Running FreePBX on a Centos environment and noticed lately some of the calls was not properly hung up which cause the Dahdi trunk to be open that stop any further incoming/outgoing calls from being able to make.

On the asterisk full log, I am seeing this :

– Executing [s@ivr-5:11] ExecIf(“DAHDI/2-1”, “1?Background(custom/Close_for_day)”) in new stack
– <DAHDI/2-1> Playing ‘custom/Close_for_day.slin’ (language ‘en’)
– Timeout on DAHDI/4-1, going to ‘t’
– Executing [t@ivr-5:1] Set(“DAHDI/4-1”, “TIMEOUT_LOOPCOUNT=1”) in new stack
– Executing [t@ivr-5:2] GotoIf(“DAHDI/4-1”, “0?final”) in new stack
– Executing [t@ivr-5:3] Set(“DAHDI/4-1”, “IVR_MSG=no-valid-responce-pls-try-again”) in new stack
– Executing [t@ivr-5:4] Goto(“DAHDI/4-1”, “s,start”) in new stack
– Goto (ivr-5,s,10)
– Executing [s@ivr-5:10] Set(“DAHDI/4-1”, “TIMEOUT(digit)=3”) in new stack
– Digit timeout set to 3.000
– Executing [s@ivr-5:11] ExecIf(“DAHDI/4-1”, “1?Background(no-valid-responce-pls-try-again)”) in new stack
– <DAHDI/4-1> Playing ‘no-valid-responce-pls-try-again.slin’ (language ‘en’)
– Executing [s@ivr-5:12] WaitExten(“DAHDI/4-1”, “10,”) in new stack
– Timeout on DAHDI/4-1, going to ‘t’
– Executing [t@ivr-5:1] Set(“DAHDI/4-1”, “TIMEOUT_LOOPCOUNT=2”) in new stack
– Executing [t@ivr-5:2] GotoIf(“DAHDI/4-1”, “0?final”) in new stack
– Executing [t@ivr-5:3] Set(“DAHDI/4-1”, “IVR_MSG=no-valid-responce-pls-try-again”) in new stack
– Executing [t@ivr-5:4] Goto(“DAHDI/4-1”, “s,start”) in new stack
– Goto (ivr-5,s,10)
– Executing [s@ivr-5:10] Set(“DAHDI/4-1”, “TIMEOUT(digit)=3”) in new stack
– Digit timeout set to 3.000
– Executing [s@ivr-5:11] ExecIf(“DAHDI/4-1”, “1?Background(no-valid-responce-pls-try-again)”) in new stack
– <DAHDI/4-1> Playing ‘no-valid-responce-pls-try-again.slin’ (language ‘en’)
– Executing [s@ivr-5:12] WaitExten(“DAHDI/4-1”, “10,”) in new stack
– Timeout on DAHDI/4-1, going to ‘t’
– Executing [t@ivr-5:1] Set(“DAHDI/4-1”, “TIMEOUT_LOOPCOUNT=3”) in new stack
– Executing [t@ivr-5:2] GotoIf(“DAHDI/4-1”, “0?final”) in new stack
– Executing [t@ivr-5:3] Set(“DAHDI/4-1”, “IVR_MSG=no-valid-responce-pls-try-again”) in new stack
– Executing [t@ivr-5:4] Goto(“DAHDI/4-1”, “s,start”) in new stack
– Goto (ivr-5,s,10)
– Executing [s@ivr-5:10] Set(“DAHDI/4-1”, “TIMEOUT(digit)=3”) in new stack
– Digit timeout set to 3.000
– Executing [s@ivr-5:11] ExecIf(“DAHDI/4-1”, “1?Background(no-valid-responce-pls-try-again)”) in new stack
– <DAHDI/4-1> Playing ‘no-valid-responce-pls-try-again.slin’ (language ‘en’)
– Executing [s@ivr-5:12] WaitExten(“DAHDI/4-1”, “10,”) in new stack
– Executing [s@ivr-5:12] WaitExten(“DAHDI/2-1”, “10,”) in new stack
– Timeout on DAHDI/4-1, going to ‘t’
– Executing [t@ivr-5:1] Set(“DAHDI/4-1”, “TIMEOUT_LOOPCOUNT=4”) in new stack
– Executing [t@ivr-5:2] GotoIf(“DAHDI/4-1”, “1?final”) in new stack
– Goto (ivr-5,t,5)
– Executing [t@ivr-5:5] Playback(“DAHDI/4-1”, “no-valid-responce-transfering”) in new stack
– <DAHDI/4-1> Playing ‘no-valid-responce-transfering.slin’ (language ‘en’)
– Timeout on DAHDI/2-1, going to ‘t’
– Executing [t@ivr-5:1] Set(“DAHDI/2-1”, “TIMEOUT_LOOPCOUNT=1”) in new stack
– Executing [t@ivr-5:2] GotoIf(“DAHDI/2-1”, “0?final”) in new stack
– Executing [t@ivr-5:3] Set(“DAHDI/2-1”, “IVR_MSG=no-valid-responce-pls-try-again”) in new stack
– Executing [t@ivr-5:4] Goto(“DAHDI/2-1”, “s,start”) in new stack
– Goto (ivr-5,s,10)
– Executing [s@ivr-5:10] Set(“DAHDI/2-1”, “TIMEOUT(digit)=3”) in new stack
– Digit timeout set to 3.000
– Executing [s@ivr-5:11] ExecIf(“DAHDI/2-1”, “1?Background(no-valid-responce-pls-try-again)”) in new stack
– <DAHDI/2-1> Playing ‘no-valid-responce-pls-try-again.slin’ (language ‘en’)
– Executing [s@ivr-5:12] WaitExten(“DAHDI/2-1”, “10,”) in new stack
– Executing [t@ivr-5:6] Goto(“DAHDI/4-1”, “ivr-5,s,1”) in new stack
– Goto (ivr-5,s,1)
– Executing [s@ivr-5:1] Set(“DAHDI/4-1”, “TIMEOUT_LOOPCOUNT=0”) in new stack
– Executing [s@ivr-5:2] Set(“DAHDI/4-1”, “INVALID_LOOPCOUNT=0”) in new stack
– Executing [s@ivr-5:3] Set(“DAHDI/4-1”, “_IVR_CONTEXT_ivr-5=ivr-5”) in new stack
– Executing [s@ivr-5:4] Set(“DAHDI/4-1”, “_IVR_CONTEXT=ivr-5”) in new stack
– Executing [s@ivr-5:5] Set(“DAHDI/4-1”, “__IVR_RETVM=”) in new stack
– Executing [s@ivr-5:6] GotoIf(“DAHDI/4-1”, “1?skip”) in new stack
– Goto (ivr-5,s,9)
– Executing [s@ivr-5:9] Set(“DAHDI/4-1”, “IVR_MSG=custom/Close_for_day”) in new stack
– Executing [s@ivr-5:10] Set(“DAHDI/4-1”, “TIMEOUT(digit)=3”) in new stack
– Digit timeout set to 3.000
– Executing [s@ivr-5:11] ExecIf(“DAHDI/4-1”, “1?Background(custom/Close_for_day)”) in new stack
– <DAHDI/4-1> Playing ‘custom/Close_for_day.slin’ (language ‘en’)
– Timeout on DAHDI/2-1, going to ‘t’

Here’s output of the dadhi and core show channels :

pbx*CLI> core show channels
Channel Location State Application(Data)
0 active channels
0 active calls
374 calls processed

pbx*CLI> dahdi show channels
Chan Extension Context Language MOH Interpret Blocked State
pseudo default default In Service
1 from-zaptel default In Service
2 from-zaptel default In Service
3 from-zaptel default In Service
4 from-zaptel default In Service
5 from-zaptel default In Service
6 from-zaptel default In Service
7 from-zaptel default In Service
8 from-zaptel default In Service

Here’s the output for chan_dahdi.conf

;include dahdi extensions defined in FreePBX
#include chan_dahdi_astribank.conf
#include chan_dahdi_additional.conf
#include chan_dahdi_trunk.conf

[trunkgroups]

[channels]
context=from-zaptel
signalling=fxs_ks
;rxwink=300 ; Atlas seems to use long (250ms) winks
usecallerid=yes
hidecallerid=no
callwaiting=yes
usecallingpres=yes
callwaitingcallerid=yes
threewaycalling=yes
transfer=yes
canpark=yes
cancallforward=yes
callreturn=yes
;echocancel=yes
;echocancelwhenbridged=no
;faxdetect=incoming
;echotraining=800
rxgain=7.0
txgain=7.0
callgroup=1
pickupgroup=1

;Uncomment these lines if you have problems with the disconection of your analog lines
busydetect=yes
busycount=3
immediate=no

immediate=no

progzone=sg
tonezone=18

callprogress=no

hanguponpolarityswitch=yes

The hanguponpolarityswitch was not turn on previously and even I have that configured, it’s also not addressing the issues.

One thing I have also tested is I make a call to the system, immediately upon the IVR kicks in in 3 seconds time, I closed the call, and the system will still like processing the request and the channel will like stuck there until I manually force the channel to close through CLI.

I make some reading but I still can’t figure out what would be the problems on this. Anyone who is able to give me a shed of hand will be great. Thanks!

[dicko]

There is no one size fits all answer for your problem, there are many ways (and even none) that your provider will (or won’t) supervise far end disconnects. Start with:-

http://www.asteriskdocs.org/en/3rd_Edition/asterisk-book-html-chunk/OutsideConnectivity_id271202.html

and

http://www.voip-info.org/wiki/view/Asterisk+Disconnect+Supervision

safest way is to check with your peers that use the same provider that you are using for what works for them.