[asterisk-bugs] [Asterisk 0013363]: [patch] Device Side transfer of a call between 2 extensions leads to failure because MACRO_DEPTH is not reset

[Asterisk Bug Tracker]

A NOTE has been added to this issue. 
====================================================================== 
http://bugs.digium.com/view.php?id=13363 
====================================================================== 
Reported By:                p_lindheimer
Assigned To:                
====================================================================== 
Project:                    Asterisk
Issue ID:                   13363
Category:                   Applications/app_macro
Reproducibility:            always
Severity:                   major
Priority:                   normal
Status:                     new
Asterisk Version:           1.4.21.1 
SVN Branch (only for SVN checkouts, not tarball releases): N/A 
SVN Revision (number only!):  
Disclaimer on File?:        N/A 
Request Review:              
====================================================================== 
Date Submitted:             2008-08-22 13:24 CDT
Last Modified:              2008-08-23 02:10 CDT
====================================================================== 
Summary:                    [patch] Device Side transfer of a call between 2
extensions leads to failure because MACRO_DEPTH is not reset
Description: 
Here is the scenario. You have 2 levels of macro depth to make a call such
that upon successfully creating the call, the MACRO_DEPTH in the channel is
set to 2. You now use the SIP phone's 'transfer' key to transfer the call
to another extension and then begin repeating the transfers between the 2
extensions. The MACRO_DEPTH increments by 2 each transfer until Asterisk
eventually terminates the call with:

[Aug 22 09:57:51] ERROR[9446] app_macro.c: Macro():  possible infinite
loop detected.  Returning early.
[Aug 22 09:57:51] DEBUG[9446] app_macro.c: Executed application: Macro

The issue seems to be seen in the following trace. The following is a
snapshot of the log where the call being transfered exits back out of MoH
and seeks the new extension it was transfered to (which results to the
macro call to exten-vm,700,700):

[Aug 22 09:55:53] VERBOSE[9446] logger.c:     -- Stopped music on hold on
SIP/224-09850350
[Aug 22 09:55:53] VERBOSE[9446] logger.c:   == Spawn extension
(from-internal-xfer, 700, 0) exited non-zero on 'SIP/224-09850350' in macro
'dial'
[Aug 22 09:55:53] VERBOSE[9446] logger.c:   == Spawn extension
(from-internal-xfer, 700, 0) exited non-zero on 'SIP/224-09850350' in macro
'dial-confirm'
[Aug 22 09:55:53] VERBOSE[9446] logger.c:   == Spawn extension
(from-internal-xfer, 700, 0) exited non-zero on 'SIP/224-09850350'
[Aug 22 09:55:53] VERBOSE[9446] logger.c:     -- Executing
[700 at from-internal-xfer:1] Macro("SIP/224-09850350", "exten-vm|700|700") in
new stack

So as can be seen in that example, the macros are exited. The bug seems to
be that the channel is considered dead, so the MACRO_DEPTH is never
decremented. This is because of the following code segment in app_maro.c:

  if (!dead) {
    pbx_builtin_setvar_helper(chan, "MACRO_DEPTH", depthc);
    ast_set2_flag(chan, autoloopflag, AST_FLAG_IN_AUTOLOOP);
  }

Since the channel is marked as dead in the code above this, the
MACRO_DEPTH does not get decremented even though the trace shows that the
macros are exiting.

The patch below moves the call to pbx-builtin_settvar_helper above the if
so that it always gets called. Since I am not intimately familiar with this
code, I  don't know if this is safe or the right way to do it. I can say
that testing this code removes the issue and I can transfer back and forth
continually.

ANOTHER IMPORTANT COMMENT: If I run the same test, but instead of using
the device side transfer I use the Asterisk '#' transfer the issue goes
away.





====================================================================== 

---------------------------------------------------------------------- 
 (0091666) p_lindheimer (reporter) - 2008-08-23 02:10
 http://bugs.digium.com/view.php?id=13363#c91666 
---------------------------------------------------------------------- 
another issue related to this. Should we also be clearing all the old ARGn
macro arguments upon returning. If we don't, they end up getting left in
the channel for the transfered call which could create an issue in some
cases. Example:

Last macro to run had ARG1-ARG3 passed to it. The call is transfered and
because of this issue, ARG1 - ARG3 are left with stale values.

The new call hits a new macro to process it which takes ARG1, ARG2 and an
OPTIONAL ARG3. The specific extension has the optional ARG3 blank. But the
macro that is called has a construct that looks like:

if ("${ARG3}" != "") {do something}

If this channel were properly initiated, the ARG3 would be blank, instead,
it has a 'random' stale value in it and the macro does something that it
shouldn't...

This same issue may or may not be a problem with some of the other
leftover macro channel variables as well that I'm not thinking of. In any
event, a modified patch is being attached that also makes sure the ARGn
variables are processed normally whether the channel is marked as 'dead' or
not. 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2008-08-23 02:10 p_lindheimer   Note Added: 0091666                          
======================================================================