[asterisk-users] Can't HANGUP call or channel on 1.4.9

[anarkhos at vfemail.net]

I've isolated this problem the furthest that I can, and I'm now convinced this is a bug in asterisk.

I have a context in extensions.conf like so:

[my_context]
	exten => _X.,1,AGI(my_agi|${EXTEN}|${CHANNEL})
	exten => _X.,2,GOTO(my_other_context|${EXTEN}|1)
	exten => h,1,DeadAGI(my_agi_cleanup)

For the purposes of this scenario, my_agi simply will try to HANGUP the channel to avoid the call going to priority 2 and instead go to my_agi_cleanup. Try as I might, I cannot hang up the channel from within the agi!

I originate the channel thusly:

CLI> originate SIP/50 extension 46 at my_context

I have agi debug turned on etc. 

I pick up the call, my_agi is called with the correct parameters. 

my_agi writes EXEC HANGUP and sleeps for 10 seconds. Asterisk responds 200 result=-1. The phone is still on the line.

my_agi writes EXEC HANGUP SIP/50-12345 (whatever channel it's given) and sleeps for 10 seconds. Asterisk responds 200 result=-1. The phone is still on the line.

When the script exits, asterisk goes to the second priority which goes to my_other_context. This shouldn't happen!

I try writing a GOTO h|1 in my_agi after my two HANGUP commands. Asterisk responds 200 result=0. This does go to h|1, but the channel doesn't hang up until my_agi_cleanup exits. This is a possible ugly work-around if no other solution can be found.

I try putting a HANGUP() as the second priority and moving the GOTO to the third. This does hangup the channel and goes to the 'h' priority, but defeats the whole purpose of priorities. 

If I do a soft hangup SIP/50-12345 in the console while my_agi sleeping (copying the channel from the HANGUP command feedback from agi debug), the correct thing happens. The channel is hung up and it avoids priority 2. Why soft hangup works, HANGUP() as a priotity works, and HANGUP or HANGUP <chan> within the AGI doesn't work is beyond me. Asterisk reports the correct arguments are passed and so on.

I also tried dialing into the context via a GOTO from a DID extension. The same problem manifests itself with the only change being the channel is a IAX2 trunk instead of a SIP phone.