Summary:	ASTERISK-03118: hangup while in AGI and manager Redirect event
Reporter:	Petr Vodicka (soptidlo)	Labels:
Date Opened:	2004-12-28 17:44:01.000-0600	Date Closed:	2011-06-07 14:10:33
Priority:	Minor	Regression?	No
Status:	Closed/Complete	Components:	Core/General
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:	( 0) asterisk.patch
Description:	Hi, i have simple extension: exten => s,1,AGI(my-script.agi) I'm using phpagi interface in my-script.agi and i'm calling simple command: Wait 50. Until the asterisk recieves WAIT command and it's waiting i'm calling scrip, which connect to asterisk via manager interface and execute Redirect command with channel, it's being proceeded with AGI at same time. ****** ADDITIONAL INFORMATION ****** Normally, i think, asterisk should end agi session and getting channel into new extension defined in redirect command. But asterisk will do something like a hangup, nothing is written to log, but it's calling "h" extension and saying something about hangup. I think, it's only my opinion it's bug in ast_async_goto. I'm not C programmer, I'm only tried to lookup in sources and find reason for hangup in this case. This is DEBUG log: -- Executing AGI("OH323/R18112", "oh323.agi") in new stack    -- Launched AGI Script /var/lib/asterisk/agi-bin/oh323.agi  oh323.agi: set error handler  oh323.agi: >> EXEC Wait 50    -- AGI Script Executing Application: (Wait) Options: (50) Dec 29 00:41:03 DEBUG[36892]: manager.c:1030 process_message: Manager received command 'Login'  == Parsing '/etc/asterisk/manager.conf': Found  == Manager 'fop' logged on from 127.0.0.1 Dec 29 00:41:03 DEBUG[36892]: manager.c:1030 process_message: Manager received command 'Redirect'    -- AGI Script oh323.agi completed, returning 0 Dec 29 00:41:03 DEBUG[35866]: pbx.c:1852 ast_pbx_run: Extension 9101, priority 2 returned normally even though call was hung up ... and proceeding "h" extension in current context.
Comments:	By: Clod Patry (junky) 2004-12-28 19:50:27.000-0600 have you tried with latest CVS? Your version is more then 4 months old. By: twisted (twisted) 2004-12-29 20:25:35.000-0600 This does not qualify as a block.  Also, you absolutely need to try latest cvs, seeing the date on yours. By: Brian West (bkw918) 2004-12-30 10:06:23.000-0600 Also he's using chan_oh323 By: Clod Patry (junky) 2005-01-03 12:16:56.000-0600 soptidlo: have you tried with new CVS-HEAD? Please answer or we'll close this bug, cause we don't have any news from you. By: Petr Vodicka (soptidlo) 2005-01-03 12:39:19.000-0600 I'll compile last CVS tonight and i'll send result here.. Thanks By: Petr Vodicka (soptidlo) 2005-01-04 19:54:36.000-0600 I'm having same problem with Asterisk 1.0.3-BRIstuffed-0.2.0-RC3. I also tried latest CVS with only SIP channels, getting same errors. I also disabled chan_oh323, but nothing happen. It seems that there is problem in ast_softhangup_nolock procedure, which do something like hard hangup on channel is there is AGI running on channel. Debug from asterisk:    -- Started music on hold, class 'default', on SIP/478019306-09c2 Jan  5 02:47:52 DEBUG[2914]: channel.c:1158 ast_settimeout: Scheduling timer at 160 sample intervals Jan  5 02:47:52 DEBUG[2914]: channel.c:1409 ast_read: Generator got voice, switching to phase locked mode Jan  5 02:47:52 DEBUG[2914]: channel.c:1158 ast_settimeout: Scheduling timer at 0 sample intervals Urgent handler Jan  5 02:48:02 DEBUG[2925]: manager.c:1225 process_message: Manager received command 'Login' Jan  5 02:48:02 DEBUG[2925]: config.c:787 __ast_load: Parsing /etc/asterisk/manager.conf  == Manager 'fop' logged on from 127.0.0.1 Urgent handler Jan  5 02:48:02 DEBUG[2925]: manager.c:1225 process_message: Manager received command 'Redirect' Jan  5 02:48:02 DEBUG[2925]: channel.c:688 ast_softhangup_nolock: Soft-Hanging up channel 'SIP/478019306-09c2' Jan  5 02:48:02 DEBUG[2914]: channel.c:1737 ast_set_write_format: Set channel SIP/478019306-09c2 to write format ulaw    -- Stopped music on hold on SIP/478019306-09c2 Jan  5 02:48:02 DEBUG[2914]: channel.c:1158 ast_settimeout: Scheduling timer at 0 sample intervals Urgent handler    -- AGI Script ivr/incoming-call.php completed, returning 0 Jan  5 02:48:02 DEBUG[2914]: pbx.c:1866 ast_pbx_run: Extension 9101, priority 2 returned normally even though call was hung up By: Petr Vodicka (soptidlo) 2005-01-17 16:55:36.000-0600 Solution ? Possible.. I'm trying EAGI instead of AGI and what happens ? Problem is out. Redirect works correctly with EAGI and using classic AGI script. Also, in latest CVS problem isn't in Redirect while running AGI script on ZAP channes (on bri-stuff), problem still remains on combination last CVS & AGI command & SIP channels (may be other, but I have no way how to check other channels). By: cbachman (cbachman) 2005-01-18 20:27:21.000-0600 I ran into this today, I tried both CVS (Stable and Head) from today and both exhibit the same problem.  I invoke an AGI script that simply outputs a EXEC DIAL to a SIP extension, which completes.  I then use the manager interface to issue a redirect on both SIP channels to an extension leading to a MeetMe.  The "caller" is hungup, and the "callee" ends up correctly in the MeetMe.  Running AGI, DeadAGI, or EAGI has no effect on the results. If instead of invoking the AGI script, I have the extension itself issue a Dial, I can correctly Redirect both legs of the call into the MeetMe. I have no patches installed on my copy of asterisk, it's compiled straight from the CVS source. By: Mark Spencer (markster) 2005-01-19 00:00:45.000-0600 You can't transfer the two parties seperately because as soon as you transfer the first, it will hangup the second.  Instead you must transfer the two simultaneously with the Channel and ExtraChannel arguments both filled. By: Petr Vodicka (soptidlo) 2005-01-19 03:06:16.000-0600 Another solution. I'm seeing that the problem is really in ast_softhangup_nolock. It seems that if redirect is called, ast_async_goto makes channel redirect to new cont/ext/pri and softhangup is being called after this. If AGI exits due to hangup sooner then ast_channel, it's known asi AGI end and res_agi is closing channel, making it to hungup. This happen's time to time, one call good, one call bad. I change res_agi.c to lookup cause of softhangup. If it found cause of softhangup as result of softhangup called by asyncgoto (chan->_softhangup == AST_SOFTHANGUP_ASYNCGOTO), AGI is being ended with returnstatus -1, which cause, that the channel is still exist and no hungup is being proceeded on it. It works for me, but it's dirty change. I'm not C programmer and my knowledge of asterisk is based on user experience. My last bugnote with EAGI replacement was out too, with EAGI, it was more success to made Redirect work with AGI, but sometimes, same error has occured. With my change, on my * it works with all three variants, agi, eagi and deadagi too. See attached file, it's replacement of res/res_agi.c in last CVS (lines 1694-1699) By: cbachman (cbachman) 2005-01-19 10:55:14.000-0600 Mark, I'm definitely using the ExtraChannel option to the Redirect as it works perfectly when a straight Dial is used. I'm trying to use an agi script that invokes Dial and then at some later point direct both participants into a MeetMe conference.  I'm not sure what the proper procedure for asterisk should be in this situation.  The "ideal" would be that the channel is placed into the meetme and when it ends, the script receives the results of the Dial and then continues on (to perform cleanup/billing/etc.)  In the dialplan scenario (without AGI) it would continue on after the original Dial. By: Clod Patry (junky) 2005-01-23 14:50:32.000-0600 soptidlo: can you add just the patch (in a diff -u format) instead of the all res_agi.c? By: Petr Vodicka (soptidlo) 2005-01-24 02:09:10.000-0600 junky: Added. I hope it will be ok, I'm not guru. Copy to asterisk source directory and apply by command "patch -p1 < asterisk.patch". It's diff from latest CVS. By: Mark Spencer (markster) 2005-02-10 17:52:04.000-0600 Isn't it sufficient to do a do the asyncgoto and then do a WAIT FOR DIGIT? By: Mark Spencer (markster) 2005-03-01 23:46:13.000-0600 User seems to have lost interest.