Summary:	ASTERISK-07532: Post hangup macro calls only execute partially if called from within another macro
Reporter:	Sherwood McGowan (rushowr)	Labels:
Date Opened:	2006-08-14 15:00:16	Date Closed:	2006-08-29 08:33:14
Priority:	Major	Regression?	No
Status:	Closed/Complete	Components:	Applications/app_macro
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:	( 0) 7731.ext.conf-format.txt ( 1) testcase.ael ( 2) testcase.log
Description:	Steven Murphy and I recently worked on and confirmed this bug: If a macro calls another macro (tested up to 3 or 4 calls deep), the macros execute normally. But ONLY if the calls are performed before a hangup. If a macro is called after the hangup (example, from the 'h' extension, being used to postcall billing cleanup, etc...) the macro calls do not properly execute anything other than the first macro. If macro1 calls macro2 pre-dial, they execute just fine, up to 3 or 4 levels deep, but if macro1 is called from 'h', it executes all commands in macro1, but the call to macro2 results in the first priority being executed and then execution returns to macro1 instead of full execution. I'm including a quickie output (using the Verbose command and verbosity level 1) in the Additional information box. Additionally, testcase.log and testcase.ael are being uploaded after the submission to further present as much data as possible. Pardon the dialplan example being in AEL2, but it's now my primary method of dialplan coding. Last note, I have experienced this with the SVN trunk 39752, and with the 1.2 branch ****** ADDITIONAL INFORMATION ****** Output from Verbose Level 1 (the level specified in my verbose commands) Start Test Call In workext Entering macro-level1 with ARG1 = precall Entering macro-level2 with ARG1 = precall Entering macro-level3 with ARG1 = "This should be output ONLY during PRECALL" This should be output ONLY during PRECALL Exiting macro-level3 Exiting macro-level2 Exiting macro-level1 Far side hung up| manually hanging up local side and continuing to h exten Entering h extension in workext Entering macro-level1 with ARG1 = postcall Exiting macro-level1 ALL 3 macros should have been run| check your output Finishing post call processing
Comments:	By: Steve Murphy (murf) 2006-08-14 18:43:49 For those of you allergic to AEL, I have attached the equivalent dialplan code in extensions.conf format. It's mostly the output of aelparse with the -w option. The way the test works, is you put the 772 extension in a context you can test from. Set the number to dial to something like a 'time&temp' number. Dial 772. Watch the messages on the asterisk console.  You will see a call to the level1 macro before the dial command is called.  Let dial command do its thing and return after the remote party hangs up. Because the Dial command has the 'g' option, it will return, and there is a goto, to the 'h' extension, where you have a call to macro level1 again. Note that the first call goes 3 levels deep. The post-dial call will execute the Set in the level2 macro, and then silently return before the goto to the 'postcall' part of the switch. By: Michael Neuhauser (mneuhauser) 2006-08-27 11:27:45 The fix for this bug (i.e., r39931, the one present in 1.2.11) breaks execution of GotoIf() in macros called from the 'h' extension (in my dialplan, 3010 executes a macro that does a Dial()):      pbx.c:01680: Launching 'GotoIf' app_macro.c:00251: Extension s, macroexten 3010, priority 25 returned normally even though call was hung up I suspect that instead of  if (chan->_softhangup && strcasecmp(chan->macroexten,"h")) the following is needed in macro_exec()  if (chan->_softhangup && strcasecmp(oldexten,"h") && strcasecmp(chan->macroexten,"h")) With this change, my h-handler works as expected (all tests done with 1.2.11). By: Serge Vecher (serge-v) 2006-08-28 15:00:42 mnehauser: your change has been commited to 1.2 branch in r41239. By: Steve Murphy (murf) 2006-08-28 19:18:25 The change looked appropriate. By: Steve Murphy (murf) 2006-08-28 19:20:08 As noted by serge-v, the change has been folded into the release. By: Steve Murphy (murf) 2006-08-29 08:30:40 Thought the automerge stuff would push the 1.2 patch to the trunk, but it's the next day, and nothing so far, so I applied the change by hand to trunk, and committed it, version 41268. By: Steve Murphy (murf) 2006-08-29 08:33:14 Until another problem is found, I'm closing this...