[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]

The issue 0013962 has been removed as a DUPLICATE OF the following issue. 
====================================================================== 
http://bugs.digium.com/view.php?id=13363 
====================================================================== 
Reported By:                p_lindheimer
Assigned To:                Corydon76
====================================================================== 
Project:                    Asterisk
Issue ID:                   13363
Category:                   Applications/app_macro
Reproducibility:            always
Severity:                   major
Priority:                   normal
Status:                     ready for testing
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-12-16 14:46 CST
====================================================================== 
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.





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

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2008-12-16 14:46 putnopvut      Relationship deleted     has duplicate 0013962
======================================================================