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:16Date Closed:2006-08-29 08:33:14
Versions:Frequency of
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


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...