BIG ISSUE - After hanging up, dahdi channels remain open

A new system that I have just put together is having some major issues that I cannot identify cause of. Essentially, the user hangs up, the dahdi channels seem to remain open. It results in a busy signal and calls cannot be made in or out of the system. What’s going on?

Simple, you don’t know what you are doing, didn’t read the manual and didn’t search for a solution prior to posting.

You also provided no information on what software you are running, how it was installed and Asterisk/FreePBX versioning, the type of DAHDI card you have and how it is configured.

You didn’t ask what was wrong, you asked what was going on. Since I have answered that I will suggest you focus your studies on disconnect supervision.

Sorry. I was panicking. But, you just about hit the nail on the head. I did look for something, but I was not certain as to what I was looking for. All I knew were the symptoms. Thanks for the suggestion, though.

I knew you were panicking, that’s why I busted your chops. If you lighted up you would have a better perspective, or toss something at me!

Glad you got it resolved.

Well, I haven’t necessarily resolved it yet. What’s really funny is that this new system (FreePBX 1.812.210.57/Sangoma A200) is a replacement for an old one that had PBX in a Flash v1.2/Asterisk v1.4/Sangoma A200 installed. I suspect that the problem had existed before, but I do not know what they did. I have been through the configuration files, comparing the old zapata.conf settings to the chan_dahdi.conf settings to see what was done. I ended up using busydetect=yes and busycount=3, but those settings were not in zapata.conf. I also checked out wanpipe1.conf on both systems, but I don’t think I found anything out of the ordinary. If I am right about the issue being corrected on the previous system, then (considering what I have found) I would have figured that the changes would have been made here somewhere.

Here are the respective config files:

New Machine

chan_dahdi.conf

[trunkgroups]

[channels]
context=default
usecallerid=yes
hidecallerid=no
callwaiting=yes
usecallingpres=yes
callwaitingcallerid=yes
threewaycalling=yes
transfer=yes
canpark=yes
cancallforward=yes
callreturn=yes
echocancel=yes
echocancelwhenbridged=yes
relaxdtmf=yes
rxgain=8.0
txgain=0.0
group=1
callgroup=1
pickupgroup=1
immediate=no
busydetect=yes
busycount=3

;Sangoma AFT-A200 [slot:4 bus:2 span:1]
context=from-zaptel
group=0
echocancel=yes
signalling = fxs_ks
channel => 1

context=from-zaptel
group=1
echocancel=yes
signalling = fxs_ks
channel => 2

context=from-zaptel
group=2
echocancel=yes
signalling = fxs_ks
channel => 3

context=from-zaptel
group=3
echocancel=yes
signalling = fxs_ks
channel => 4


wanpipe1.conf (new machine)

[devices]
wanpipe1 = WAN_AFT_ANALOG, Comment

[interfaces]
w1g1 = wanpipe1, , TDM_VOICE, Comment

[wanpipe1]
CARD_TYPE = AFT
S514CPU = A
CommPort = PRI
AUTO_PCISLOT = NO
PCISLOT = 4
PCIBUS = 2
FE_MEDIA = FXO/FXS
TDMV_LAW = MULAW
TDMV_OPERMODE = FCC
RM_BATTTHRESH = 3
RM_BATTDEBOUNCE = 16
FE_NETWORK_SYNC = NO
MTU = 1500
UDPPORT = 9000
TTL = 255
IGNORE_FRONT_END = NO
TDMV_SPAN = 1
TE_AIS_MAINTENANCE = NO #NO: defualt YES: Start port in AIS Blue Alarm and keep line down
#wanpipemon -i w1g1 -c Ttx_ais_off to disable AIS maintenance mode
#wanpipemon -i w1g1 -c Ttx_ais_on to enable AIS maintenance mode
TDMV_HW_DTMF = NO # YES: receive dtmf events from hardware
TDMV_HW_FAX_DETECT = NO # YES: receive fax 1100hz events from hardware
HWEC_OPERATION_MODE = OCT_NORMAL # OCT_NORMAL: echo cancelation enabled with nlp (default)
# OCT_SPEECH: improves software tone detection by disabling NLP (echo possible)
# OCT_NO_ECHO:disables echo cancelation but allows VQE/tone functions.
HWEC_DTMF_REMOVAL = NO # NO: default YES: remove dtmf out of incoming media (must have hwdtmf enabled)
HWEC_NOISE_REDUCTION = NO # NO: default YES: reduces noise on the line - could break fax
HWEC_ACUSTIC_ECHO = NO # NO: default YES: enables acustic echo cancelation
HWEC_NLP_DISABLE = NO # NO: default YES: guarantees software tone detection (possible echo)
HWEC_TX_AUTO_GAIN = 0 # 0: disable -40-0: default tx audio level to be maintained (-20 default)
HWEC_RX_AUTO_GAIN = 0 # 0: disable -40-0: default tx audio level to be maintained (-20 default)
HWEC_TX_GAIN = 0 # 0: disable -24-24: db values to be applied to tx signal
HWEC_RX_GAIN = 0 # 0: disable -24-24: db values to be applied to tx signal

[w1g1]
ACTIVE_CH = ALL
MTU = 8
TDMV_HWEC = YES


Old Machine

zapata.conf

[trunkgroups]

[channels]

language=en
context=from-zaptel
signalling=fxs_ks
rxwink=300 ; Atlas seems to use long (250ms) winks
;
; Whether or not to do distinctive ring detection on FXO lines
;
;usedistinctiveringdetection=yes

usecallerid=yes
hidecallerid=no
callwaiting=yes
usecallingpres=yes
callwaitingcallerid=yes
threewaycalling=yes
transfer=yes
cancallforward=yes
callreturn=yes
echocancel=yes
echocancelwhenbridged=no
echotraining=800
rxgain=8.0
txgain=0.0
group=0
callgroup=1
pickupgroup=1
immediate=no

;faxdetect=both
faxdetect=incoming
;faxdetect=outgoing
;faxdetect=no

;Include genzaptelconf configs
#include zapata-auto.conf

;Include AMP configs
#include zapata_additional.conf


wanpipe1.conf (old machine)

[devices]
wanpipe1 = WAN_AFT_ANALOG, Comment

[interfaces]
w1g1 = wanpipe1, , TDM_VOICE, Comment

[wanpipe1]
CARD_TYPE = AFT
S514CPU = A
CommPort = PRI
AUTO_PCISLOT = NO
PCISLOT = 13
PCIBUS = 0
FE_MEDIA = FXO/FXS
TDMV_LAW = MULAW
TDMV_OPERMODE = FCC
RM_NETWORK_SYNC = NO
RM_BATTTHRESH = 3
RM_BATTDEBOUNCE = 16
MTU = 1500
UDPPORT = 9000
TTL = 255
IGNORE_FRONT_END = NO
TDMV_SPAN = 1
TDMV_HW_DTMF = NO

[w1g1]
ACTIVE_CH = ALL
TDMV_ECHO_OFF = NO
TDMV_HWEC = YES

Here is what I have come to recognize. The channels seem to close almost immediately after hangup in the case that a call is answered. However, when an external, inbound call is answered by the IVR and the caller hangs up, the system (for whatever reason) does not recognize it and continues to repeat until the timeout retry limit has been reached, and hangs up. A similar issue occurs with voicemail, but is less likely to hang up and the recipient gets an extra long VM in their box. Hopefully, the maxmessage setting will correct this.

I will reiterate SkyKing’s suggestion, that apparently you missed.

. . . I will suggest you focus your studies on disconnect supervision.

It is locale specific if available, check with your vendor for options. The fall back is “busy detect”, use a butt set (Plain old telephone will work) on the line, that might give you some insight.