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

Wed Feb 11 14:55:49 CST 2009

A NOTE has been added to this 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:                     closed
Asterisk Version:           1.4.21.1 
Regression:                 No 
SVN Branch (only for SVN checkouts, not tarball releases): N/A 
SVN Revision (number only!):  
Request Review:              
Resolution:                 fixed
Fixed in Version:           
====================================================================== 
Date Submitted:             2008-08-22 13:24 CDT
Last Modified:              2009-02-11 14:55 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.

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

---------------------------------------------------------------------- 
 (0099936) svnbot (reporter) - 2009-02-11 14:55
 http://bugs.digium.com/view.php?id=13363#c99936 
---------------------------------------------------------------------- 
Repository: asterisk
Revision: 174886

_U  trunk/

------------------------------------------------------------------------
r174886 | tilghman | 2009-02-11 14:55:47 -0600 (Wed, 11 Feb 2009) | 19
lines

Blocked revisions 174885 via svnmerge

........
  r174885 | tilghman | 2009-02-11 14:54:18 -0600 (Wed, 11 Feb 2009) | 13
lines

  Restore a behavior that was recently changed, when we fixed issue
http://bugs.digium.com/view.php?id=13962
and
  issue http://bugs.digium.com/view.php?id=13363 (related to issue
http://bugs.digium.com/view.php?id=6176).  When a hangup occurs during a
Macro
  execution in earlier 1.4, the h extension would execute within the Macro
  context, whereas it was always supposed to execute only within the main
context
  (where Macro was called).  So this fix checks for an "h" extension in
the
  deepest macro context where a hangup occurred; if it exists, that "h"
extension
  executes, otherwise the main context "h" is executed.
  (closes issue http://bugs.digium.com/view.php?id=14122)
   Reported by: wetwired
   Patches: 
         20090210__bug14122.diff.txt uploaded by Corydon76 (license 14)
   Tested by: andrew
........

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=174886 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2009-02-11 14:55 svnbot         Checkin                                      
2009-02-11 14:55 svnbot         Note Added: 0099936                          
======================================================================