I have struggled with this issue for a while on a large deployment (6 servers hosting ~175 extensions). An extension would complete a call, and the SIP channel on the extension side would fail to release when the call terminated, resulting in the extension appearing to be busy to the server. All calls go straight to voicemail. Calls can be initiated just fine, but I could not find a resolution for releasing the channel short of restarting the server, which is obviously not the desired method of resolution. This issues is addressed in the Asterisk ticket here: https://issues.asterisk.org/jira/browse/ASTERISK-19455, but no short-term resolution to the immediate problem of the channel that won’t die.
SO… Today when this issue happened, I stuck with it longer that I had in the past, experimenting with trying to stop the channel. Here’s how I was able to release the extension without a complete reboot of the server.
You can see your active channels from the asterisk CLI command ‘core show channels’:
root@asteriskserver:~ $ asterisk -rvvvvv
Asterisk 188.8.131.52, Copyright (C) 1999 - 2011 Digium, Inc. and others.
Created by Mark Spencer <email@example.com>
Asterisk comes with ABSOLUTELY NO WARRANTY; type 'core show warranty' for details.
This is free software, with components licensed under the GNU General Public
License version 2 and other licenses; you are welcome to redistribute it under
certain conditions. Type 'core show license' for details.
== Parsing '/etc/asterisk/asterisk.conf': == Found
== Parsing '/etc/asterisk/extconfig.conf': == Found
Connected to Asterisk 184.108.40.206 currently running on asteriskserver (pid = 3184)
Verbosity was 3 and is now 5
asterisk*CLI> core show channels
Channel Location State Application(Data)
SIP/2215-000002ed 600@from-internal:1 Up AppDial((Outgoing Line))
15 active channels
7 active calls
954 calls processed
I have obviously sanitized the output and removed all of the channels except the problem child. You’ll be able to identify if this is the same, or at least a similar, issue by the count at the bottom of the core show channels output. You’ll notice above that the number of active calls and the number of active channels does not match. This is not necessarily indicative of a problem, but you should generally see a 2:1 ratio in active channels and active calls. Legitimate exceptions would be conference calls and call queues, but in our system, it’s generally one channel for each end of the call.
Once you have identified the hung channel, you can get more information about the channel with the command ‘core show channel <channel>’:
asterisk*CLI> core show channel SIP/2215-000002ed
-- General --
Caller ID: 2215
Caller ID Name: Unhappy Extension User
Connected Line ID: 1573280XXXX
Connected Line ID Name: APLACEIN, MO
DNID Digits: *8
State: Up (6)
NativeFormats: 0x4 (ulaw)
WriteFormat: 0x4 (ulaw)
ReadFormat: 0x4 (ulaw)
1st File Descriptor: 230
Frames in: 3
Frames out: 0
Time to Hangup: 0
Elapsed Time: 70h14m21s
-- PBX --
Call Group: 2
Pickup Group: 2
Data: (Outgoing Line)
Blocking in: (Not Blocking)
level 1: dnid=
level 1: clid="Unhappy Extension User"
level 1: src=2215
level 1: dst=*8
level 1: dcontext=from-internal
level 1: channel=SIP/2215-000002ed
level 1: start=2013-01-04 12:32:30
level 1: answer=2013-01-04 12:32:30
level 1: duration=252860
level 1: billsec=252860
level 1: disposition=ANSWERED
level 1: amaflags=DOCUMENTATION
level 1: uniqueid=1357324350.2043
level 1: linkedid=1357324350.2043
level 1: sequence=2619
As you can see from the sanitized output above, this channel was stuck all weekend. So then looking over the help, I discovered the command “channel request hangup <channel>’:
asterisk*CLI> channel request hangup SIP/2215-000002ed
Requested Hangup on channel 'SIP/2215-000002ed'
Yay, right? Wrong. Didn’t touch the hung channel. No dice. Until I tried ‘channel redirect <channel> <exten>’:
asterisk*CLI> channel redirect SIP/2215-000002ed 2304
Channel 'SIP/2215-000002ed' successfully redirected to 2304
== Starting SIP/2215-000002ed at from-internal,600,2304 failed so falling back to exten 's'
-- Executing [s@from-internal:1] Macro("SIP/2215-000002ed", "hangupcall") in new stack
-- Executing [s@macro-hangupcall:1] GotoIf("SIP/2215-000002ed", "1?theend") in new stack
-- Goto (macro-hangupcall,s,3)
-- Executing [s@macro-hangupcall:3] ExecIf("SIP/2215-000002ed", "0?Set(CDR(recordingfile)=)") in new stack
-- Executing [s@macro-hangupcall:4] Hangup("SIP/2215-000002ed", "") in new stack
== Spawn extension (macro-hangupcall, s, 4) exited non-zero on 'SIP/2215-000002ed' in macro 'hangupcall'
== Spawn extension (from-internal, s, 1) exited non-zero on 'SIP/2215-000002ed'
-- Executing [h@from-internal:1] Hangup("SIP/2215-000002ed", "") in new stack
== Spawn extension (from-internal, h, 1) exited non-zero on 'SIP/2215-000002ed'
I redirected the channel from the original extension to my own. The original extension is released, my extension is unaffected, and there was much rejoicing. (yay.)
So, the end result is that I still have a hung channel in the system, which I’m sure will remain until I reboot the server. But, the extension is returned to normal, use of the system seems unaffected, and now I have a quick solution to the problem for the next time it occurs. Hope this is useful to someone.