Force Hangup Not Working On Stuck Channel
I am unable to force a hangup on a channel that has been stuck for over two days:
IAX2/from-CD-11006 oficina 2770 1 Up
Dial IAX2/to-CD/2883 3467130007 46:24:59 Sotelo
Sotelo IAX2/to-CD-20713
I have tried “hangup request IAX2/from-CD-11006” several times but no joy. I also see the following in the CLI:
[Nov 3 10:05:54] WARNING[2879]: chan_iax2.c:4936 handle_call_token: Too much delay in IAX2 calltoken timestamp from address X.X.X.X
This is an IAX2 trunk between two Asterisk 1.8 servers (I know it is old but new client so haven’t had time yet to upgrade to 13). Because this channels is stuck
all other calls between servers are not working. The only way I have found to resolve the problem is to stop and restart Asterisk. This is obviously a great inconvinience so is there a way for force iax to unload even if there are channels in use? Or any other way to kill these stubborn channels?
—
Telecomunicaciones Abiertas de México S.A. de C.V. Carlos Chávez dCAP #1349
+52 (55)9116-91161
—
4 thoughts on - Force Hangup Not Working On Stuck Channel
Hi Carlos,
Did you try with the following CLI command:
CLI> channel request hangup CHANNEL_NAME
???
El nov. 3, 2016 1:16 PM, “Carlos Chavez” escribió:
I always set a TIMEOUT(absolute) on calls across trunks to something reasonable like 10 hours, that way calls should end in a sane amount of time even if something weird happens.
Otherwise I’ve always had to do a reload when I couldn’t hang up from the CLI.
If doing a soft hangup on them doesn’t work, the only other way I know to do it is to restart Asterisk. Sorry about the bad news 🙁
There’s a part of me that’s curious as to why the channel is stuck, but there’s another part of me that says “1.8… run away quickly”.
You could try to replicate it with a modern branch (i.e. 13/14) and see if it still exists. At the very least that’d leave you the option of posting a bug on the issue tracker about it. Also, a lot of bugs have been fixed since 1.8, so it’s quite possible that this issue is resolved as well.
Also, it looks like in https://issues.asterisk.org/jira/browse/ASTERISK-21762 there might be a workaround (see the last comment at the bottom).
Matthew Fredrickson