Line doesn't hangup - gets busy signal

[blanchae]

Line doesn't hangup - gets busy signal - Solved

I have a T1 line connecting to an Adtran TSU-600e channel bank. The channel bank is loaded with fxs ports. I can call from a SIP phone to a POTS phone connected to one of the channel bank ports with no problem. I can call from one of the channel bank's POTS phones to Asterisk SIP phone with no problem.. all with good voice quality.

Here's the issue: if I call from the SIP phone to the POTS phone then hang-up the SIP phone. The POTS phone doesn't hang up, it sits there and receives a busy signal.

Why does this matter? Normally, the pots line is connected to Cisco Call Manager Express's auto attendant and if the line doesn't hang up, the call remains in the auto attendant queue and continuously cycles through the sequential hunt group until someone answers and hear's the busy tone.

Not sure where to start checking on this one...

The T1 line is esf, b8zs. The signaling is loop_start. I don't believe I can use kewl_start because of the channel bank.

Solution - changed signaling to ground_start (explanation in last post).

 

[blanchae]

Found a google link that indicates I can use kewl_start. I'll try it tomorrow and see.

 

[dghundt]

can you use busydetect?

 

[blanchae]

I tried busydetect and it didn't make a difference. I think busydetect is for incoming calls. Asterisk is hanging up but the output at the channel bank doesn't detect it properly and gives a busy signal.

 

[blanchae]

Found a google link that indicates I can use kewl_start. I'll try it tomorrow and see.

Asterisk 1.6.0.6
Dahdi 2.1.0.4

Nope that didn't fix it. Here's my /etc/dahdi/system.conf:

#Adtran TSU-600e Channel Bank Config
#To simulate POTS CO
span=1,0,0,esf,b8zs
fxoks=1-16
unused=17-24
echocanceller=mg2,1-16

# Global data

loadzone = us
defaultzone = us

Here's /etc/asterisk/chan_dahdi.conf

[channels]
language=en

; include dahdi extensions defined in FreePBX
#include chan_dahdi_additional.conf
#include chan_dahdi_custom.conf


Here's a typical extension (all 16 are identical except for channel/extension numbers) from /etc/asterisk/chan_dahdi_additional.conf, I've tried all busydetect=no and yes.

;;;;;;[7804100001]
signalling=fxo_ks
pickupgroup=
mailbox=7804100001@device
immediate=no
echotraining=800
echocancelwhenbridged=no
echocancel=yes
context=from-internal
callprogress=no
callgroup=
callerid=device <7804100001>
busydetect=no
busycount=7
accountcode=
channel=>1

Here's the TSU chan 1.1 config:

 

[blanchae]

Tried

busydetect=yes
busycount=3

Didnt work, then tried

callprogress=yes

and it didn't work

Also tried "hanguponpolarityswitch=yes" in /etc/asterisk/chan_dahdi.conf and it didn't work either.

 

[blanchae]

Tried in /etc/asterisk/chan_dahdi.conf

inbanddisconnect=yes and then separately
priiindication=inband

Neither worked..

 

[blanchae]

Tried changing the signaling to sf_featd instead of fxo_ks, the sf series of signaling is inband signaling and sf_featd is specific to the Adtran fake signaling (not sure what it actually means) but it didn't work either and /etc/dahdi/system.conf plus dahdi drivers rejected it as an unknown keyword. Looks like the sf keywords got dropped when everything moved to dahdi from zaptel.

Isn't life fun?

 

[blanchae]

Tried relaxdtmf=yes in /etc/asterisk/chan_dahdi.conf and it didn't work.

 

[briankelly63]

Hi Eugene,

I talked to Adtran on your behalf... case# 1141651 (long ver. [FONT=&quot]RQST00001141651[/FONT]). This is fairly old technology (600e) but they said the issue may be related to signaling bits (check port status).

There may not be a fix for this but they would be happy to talk to you and they have a paste of the thread. They will try and troubleshoot it for you, their number is 888-423-8726
...

Please change the name and phone on case.

Brian

 

[blanchae]

Thanks I'll give them a ring. I have been tracing the signaling bits but don't have enough experience to figure out what is right or wrong. Yes it's old technology but it has allowed me to simulate the PSTN in the lab for the post-secondary institute that I work for. It actually worked pretty nice until I integrated Cisco Call Manager Express auto attendant feature then found out the pots line wasn't hanging up. There's always something..

 

[blanchae]

Came across this digium thread that has some more things to try

 

[blanchae]

NOT Solved - changed the signaling to ground start (gs) then everything works as it should. Originally, I had both ends as loop_start (ls) then tried kewl_start (ks), finally ground_start works. So after all this, the only thing that needed to be done was to change:

1. /etc/dahdi/system.conf

fxogs=1-16 (I'm only using 16 channels of the T1 line)

2. In FreePBX extensions, change the signaling to fxo_gs

Everything else attempted previously was not required.

NOT SOLVED - rebooted the server and I can't dial out. Freaking pain in the a$$.

 

[blanchae]

Went to a new server with Dahdi 2.2 and guess what, ground start doesn't work anymore, back to stage 1 again. Updated sources and loaded dahdi 2.3.0 because unless you have the latest version, you''re always asked "do you have the latest version?". Anyways dahdi 2.3.0 doesn't work either. I have a thread going in the digium forums to see if any solutions arrive...

 

[blanchae]

Finally gave up trying to get dahdi 2.3.0 to work with my oddball setup - NOTE: this is an unusual setup and doesn't reflect normal operation of dahdi. It is quite good unless you try to make it work with 20 year old equipment.

I tried to downgrade to dahdi 2.1.0.4+2.1.0.2 (which was the version that worked) and it just broke asterisk as it now complains that inappropriate ioctl occurs.

 

[blanchae]

Went back to the original server that worked 3 days ago. Nothing was changed. Powered it up and now I've run into a new problem. I can dial in, can disconnect but can't dial out - no dialtone. I give up. I'm purchasing a 16 port FXS Astribank and see how that works.

The adtrans are going in the junk pile.

 

[briankelly63]

I'm sure this is all very frustrating. When I spoke to them they were very helpful but they were clear that this old technology was probably going to have a lot of issues when connected to newer devices. As a practical matter they were not going to able to expend limited engineering dept. time (vs. support time) on such old technology... I guess its lessons learned. To bad there was no easy fix from them.

 

[blanchae]

It was so close and actually worked for a day. I must of messed up the Asterisk side because after I rebooted with the same config, it went away. Oh well, I thought that I could recycle some old equipment and make it useful.

 

[wardmundy]

And folks wonder why Tom has criticized DAHDI as Not Ready for Prime Time...