Analog line not being released when call disconnects

What you are describing sounds like a failure of hangup detection except for the high pitch screaming part. There are a number of settings that can help with this but no guaranteed cure all.

you should be able to hang up the offending channel from the asterisk cli
use "core show channels" to identify the offending channel and "soft hangup [channel]" to hangup the channel.

If it is hangup detection it only causes a problem when a call is not answered from a handset and nothing else in the dialplan explicitly hangs up the call.

Depending on where you are geographically you may need to change the default zone settings.

ironix,

You may want to take a look at your Zaptel/DAHDI signaling options.

---

From Digium's website [http://kb.digium.com/entry/44/30/]:

What is the difference between loopstart, groundstart, and kewlstart signalling?

Loopstart signalling is used by virtually all analog phone lines. It allows a phone to indicate on hook/offhook, and the switch to indicate ring/no ring.

Kewlstart is based on loopstart, but extends the protocol by allowing the switch to drop battery on the phone line to indicate to the phone that the other end of the party has disconnected the call. Most real phone switches, and almost no PBX's (except Asterisk, of course) support this feature. It is generally required for getting hangup notification.

Groundstart signalling is sometimes used by PBX's. If you don't know what it is, don't worry, you won't need it.

---

A friend of mine in another part of the city had to change from the default `kewlstart` signaling to `loopstart` because they're on a very old telco switch. I just spoke to him and he seems to remember having similar problems until they made the change to `loopstart`. You should be able regenerate your Zaptel/DAHDI configuration with the alternative signaling method. Look at the script `/usr/sbin/genzaptelconf` for some more information.

I don't have an analogue card handy to test with, so you'll have to do some homework on how to go about it. Good luck!

I seem to have found a way of replicating the problem.

Seems as though if the external caller disconnects / hangs up while listening to the voice mail (unavailable or busy) message nearing the end of the recorded message, but prior to playing the "standard greeting" the line does not disconnect.

(that's not particularly clear I know...)

basically - inbound route -> IVR -> t destination = operator : if no answer -> operator voicemail
the operator voicemail plays a recording (...not available...press 0 to return ... hold to leave a message - "wait for input" - if no input then play built in recording "please leave a message after the tone..." vm-intro)
If the caller hangs up approximately 0 - 2 seconds before the "wait for input" then the problem occurs. Any time before or after that (including during the timeout period) the problem does not occur.

It also seems only to occur on analog lines - dialing the extension / voicemail from another sip device I cannot re-create the problem (though that was expected).

So to me it appears that the hangup detection does not "have time" to detect the hangup if it occurs that close to the pause. I've tried increasing and decreasing my "busycount" to no avail.

If you barge the channel that's being affected, you can hear the remainder of the vm-intro message being played, the beep and then the high pitched "screaming" sound mentioned in the first post.

I'm afraid I'm not even sure where to look at this point so any advice would be greatly appreciated.
I'm happy to do the research if someone has any ideas and can point me in the right direction but I've exhausted my (limited) knowledge on this.
Many thanks.

Not on that install, but on an install that was done perhaps 6 months before the problematic one, kewlstart would not detect any hangup at all.
Changing to loopstart worked immediately. Also, as I write I realise that all other installs are happily running loopstart and don't experience this problem.

Not to sure how to progress, so if you have any further thoughts, please don't hold back. Willing to try anything at this point.

Appreciate all the input thus far.

Apologies for the delayed response.

I had come across both links however not related to this problem, but prior to config of my first couple of systems.
Useful and necessary information.

chan_dahdi.cfg looks like this...

-----------------------------------------
[trunkgroups]

[channels]

language=en
context=from-zaptel
signalling=fxs_ls

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=9
txgain=9
group=0
callgroup=1
pickupgroup=1
immediate=no
busydetect=yes
busycount=3 ------------ has been as high as 10 and as low as 2 - 3 seems to be the best thus far
callprogress=no
flash=250
rxflash=250

faxdetect=incoming

#include dahdi-channels.conf

group=1

#include chan_dahdi_additional.conf

---------------

dahdi-channels.conf

---------------
; Span 1: WCTDM/0 "Wildcard TDM2400P Board 1" (MASTER)
;;; line="1 WCTDM/0/0 FXSKS"
signalling=fxs_ls
callerid=asreceived
group=0
context=from-pstn
channel => 1
callerid=
group=
context=default
-----------------
(same for 12 channels)
- line 2 of each channel indicates FXSKS however since that is a comment and line 3 indicates the required fxs_ls I don't think that's the problem.

chan_dahdi_additional.conf - is empty

--------------

I don't seem any closer to solving this I'm afraid, so still looking for any advice available.
A second, far less frequent, but perhaps related, problem seems to be "random" premature termination of calls.
Seems that calls are being disconnect mid conversation and after various durations.
The log indicates nothing out of the ordinary that I can find, but seems consistent to specific destinations (or sources as the case may be) on a given day. i.e. the same person will call the pbx 3 times in a day and be disconnected mid conversation, but after very different durations.
Listening to the recording of the conversations in question there are no audible anomalies - just normal conversation and very abrupt termination. Recording does not record any hangup signal.

If not related, I'll troubleshoot separately and start a new thread if necessary (can one hijack their own thread?) but I think the hangup detection is probably the problem in both cases - inverse reaction though.

Thanks again to all those offering assistance.

I haven't had a look at firmware changes for the card itself, something Digium would be able to recommend.

The hanguponpolarityswitch was removed because our Telco doesn't support that. It's known to cause problems here so necessary to remove (or disable) it.

I wonder if the tx and rx gain might not cause some interference - change the expected busy signal somehow.
I needed to increase that immediately after installation because call volume was too low. That change corrected that instantly.
Unfortunately that was as I say, within a day of installation so I don't know if the problem started after that change.

Think I'll chat to the hardware vendor again, and drop Digium a mail.

Thank you again for all your help.