[Asterisk-Dev] Re: [Core Asterisk 0001760]: Macros do not clear argument variables when calling other macros

[Eric Wieling]

I guess I didn't specify enough of a real world example.  This example
uses the macro dial-result to try dialing the number via an alternate
method if the original Dial() fails.  Then if the alternate method fails
it gives up.  If you don't call dial-result with any parameters it justs
pages me and gives up, but if you call it with a parameter then page me
and try dialing whatever was in the argument.

Here is one:

[default]
exten => 91NXXNXXXXXX,1,Dial(${PSTN}/${EXTEN:1}
exten => 91NXXNXXXXXX,2,Macro(dial-result,${NUFONE}/${EXTEN:1})

[macro-dial-result]
;
; Handle Disconnect Cause Codes
;
exten => s,1,NoOp(HANGUPCAUSE is ${HANGUPCAUSE})
exten => s,2,AbsoluteTimeout(120)
exten => s,3,Goto(${HANGUPCAUSE},1)
                                                                                                                                                                                                                  
exten => 0,1,NoOp(AST_CAUSE_NOTDEFINED)
exten => 0,2,GoToIf($["${SAVED_EXTEN}" != ""]?0,4)
exten => 0,3,SetVar(SAVED_EXTEN=${MACRO_EXTEN})
exten => 0,4,GoToIf($["${SAVED_ARG1}" != ""]?0,6)
exten => 0,5,SetVar(SAVED_ARG1=${ARG1})
exten => 0,6,GoToIf($["${ARG1}" = ""]?0,11)
exten => 0,7,System(/bin/echo AST_CAUSE_NOTDEFINED received when dialing ${SAVED_EXTEN}.  Trying again using ${SAVED_ARG1}.  | /usr/bin/mutt -s "COLISEUM PBX ERROR" pbxadmin-pager@)
exten => 0,8,SetVar(ARG1=)
exten => 0,9,Dial(${SAVED_ARG1})
exten => 0,10,Macro(dial-result)
exten => 0,11,System(/bin/echo AST_CAUSE_NOTDEFINED received when dialing ${SAVED_ARG1}.  Giving up. | /usr/bin/mutt -s "COLISEUM PBX ERROR" pbxadmin-pager)
exten => 0,12,Zapateller(answer)
exten => 0,13,Playback(an-error-has-occured)
exten => 0,14,Playback(pls-try-call-later)
exten => 0,15,Wait(3)
exten => 0,16,Zapateller(answer)
exten => 0,17,Playback(an-error-has-occured)
exten => 0,18,Playback(pls-try-call-later)
exten => 0,19,Wait(3)
exten => 0,20,Congestion

[handling of other cause codes removed for brevity]

On Tue, 2004-06-01 at 13:39, bugs at digium.com wrote:
> The following bug has been RESOLVED.
> ======================================================================
> http://bugs.digium.com/bug_view_page.php?bug_id=0001760
> ======================================================================
> Reporter:                   ewieling
> Handler:                    markster
> ======================================================================
> Project:                    Core Asterisk
> Bug ID:                     1760
> Category:                   General
> Reproducibility:            always
> Severity:                   minor
> Priority:                   normal
> Status:                     resolved
> Resolution:                 not a bug
> ======================================================================
> Date Submitted:             06-01-2004 09:17 CDT
> Last Modified:              06-01-2004 14:41 CDT
> ======================================================================
> Summary:                    Macros do not clear argument variables when calling other macros
> Description: 
> You can call a macro from within a macro, however when you do this the ARG*
> variables are not cleared.
> ======================================================================
> 
> ----------------------------------------------------------------------
>  markster - 06-01-2004 14:41 CDT 
> ----------------------------------------------------------------------
> The behavior is correct.  Only arguments that are specified are backed up
> and
> restored.  I see no reason whatsoever to clear the other arguments:
> 
> [macro-bar]
> exten => s,1,Noop(${ARG1}/${ARG2})
> 
> [macro-foo]
> exten => s,1,Noop(${ARG1}/${ARG2})
> exten => s,2,Macro(bar,bar1);
> exten => s,3,Noop(${ARG1}/${ARG2})
> 
> [default]
> exten => 102,1,Macro(foo,foo1,foo2)
> 
> 
> produces the correct output:
> 
>     -- Executing Macro("Zap/1-1", "foo|foo1|foo2") in new stack
>     -- Executing NoOp("Zap/1-1", "foo1/foo2") in new stack
>     -- Executing Macro("Zap/1-1", "bar|bar1") in new stack
>     -- Executing NoOp("Zap/1-1", "bar1/foo2") in new stack
>     -- Executing NoOp("Zap/1-1", "foo1/foo2") in new stack
> 
> Bug History
> Date Modified       Username            Field               Change              
> ======================================================================
> 06-01-04 09:17      ewieling            New Bug                                 
> 06-01-04 09:17      ewieling            Bug Monitored: ewieling                    
> 06-01-04 14:41      markster            Bugnote Added: 0010146                    
> 06-01-04 14:41      markster            Assigned To          => markster        
> 06-01-04 14:41      markster            Resolution          open => not a bug   
> 06-01-04 14:41      markster            Status              new => resolved     
> ======================================================================
-- 
          Eric Wieling * BTEL Consulting * 504-899-1387 x2111
"In a related story, the IRS has recently ruled that the cost of Windows
upgrades can NOT be deducted as a gambling loss."