Dadhi Trunk Not Correctly Hung Up

[andy18]

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=35

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!

[david55]

There is no indication in the trace that you are trying to hangup the call. If you are trying to the hangup the call, you will need to take up the problem with the FreePBX people, as we don’t support their dialplans.

Note that many, if not most, network operators implement calling party clearing, so you may have to wait up to three minutes after you hangup, if the caller fails to hangup.

If the hangup is supposed to be incoming, you need to find out from your network operator, if and how they signal disconnect supervision Polarity switch is relatively unusual for disconnect supervision, but it is possible that there is no disconnect supervision at all.

You can listen to see if they send a busy tone. Detecting line changes requires low level debugging, with which I’m not familiar.

Serious IVR work really needs ISDN or an ITSP (who in turn uses ISDN).