Summary:	ASTERISK-06563: MacroIf causes blind transfer to fail
Reporter:	gkloepfer (gkloepfer)	Labels:
Date Opened:	2006-03-17 21:43:18.000-0600	Date Closed:	2006-05-11 09:51:06
Priority:	Major	Regression?	No
Status:	Closed/Complete	Components:	Applications/app_macro
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:	( 0) extensions.conf ( 1) fails-log ( 2) good-log
Description:	When a blind transfer is initiated (or a Redirect from the manager), if the Dial from the previous call is inside a MacroIf, the transfer will fail with the call being dropped. ****** ADDITIONAL INFORMATION ****** The problem is the way that app_macro determines how to deal with an async_goto. The ast_async_goto request generates a softhangup with a cause of AST_SOFTHANGUP_ASYNCGOTO.  This is supposed to indicate that the dialplan is being interrupted at this point, and is restarted at the target specified by ast_async_goto. Inside app_macro.c, there is a section of code that checks to see if the current context is equal to the macro name prior to processing an async goto.  This test works fine when the macro is executing normally.  However, when macroif_exec is invoked, it invokes macro_exec and chan->context is not the same as fullmacro, so the async goto is never handled correctly and the softhangup actually terminates the call. I do not know exactly why this is happening, so I'm not in the right place to fix the problem. Attached to this problem report is the dialplan being used to test the problem, and two debug outputs from the console (one is with the dialplan with the MacroIf, the other is without it). There are three extensions, 201-203.  201 calls 202.  202 is a Polycom IP501 doing a blind transfer to 203.  In the MacroIf case, the call disconnects as soon as the blind transfer is initiated.  Without MacroIf, the call completes successfully, I lift the receiver, and hang up. The output is from SVN 8969, but I have also tested it with the same results on SVN 13356.
Comments:	By: Serge Vecher (serge-v) 2006-05-03 10:54:14 gkloepfer: is this still an issue with latest 1.2 branch (I believe as per Olle, sip transfer in trunk are broken pending the completion of his work)? By: Serge Vecher (serge-v) 2006-05-11 09:51:06 if you can reproduce this in the latest 1.2 or trunk, please reopen the issue with some debugging information. thank you.