[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-25 11:45 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.





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

---------------------------------------------------------------------- 
 (0091705) p_lindheimer (reporter) - 2008-08-25 11:45
 http://bugs.digium.com/view.php?id=13363#c91705 
---------------------------------------------------------------------- 
Is there any other data to determine if it is specifically in this unique
dead state, vs. any dead state, and is it safe in this unique dead state
(since I realized my patch doesn't differentiate and that was my concern
with my patch, that it may not always be safe). The value of 'ret' is -1 so
that doesn't seem to differentiate it. 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2008-08-25 11:45 p_lindheimer   Note Added: 0091705                          
======================================================================