[asterisk-dev] (ASTERISK-19336) h exten is not run in the context that calls a AEL macro

[Johan Wilfer]

2012-02-29 02:59, Tilghman Lesher skrev:
>> This change in >1.6 makes it hard to actually use macros for anything
>> complex as I have to duplicate hangup-code in every macro, and even
>> duplicate the same macro for different contexts calling the macro!
>>
>> To add to that, in 1.4 there was channel variables to know the context
>> invoking the macro. This is also less functionality in newer versions.
>> For the call above these variables are set in 1.4:
>>
>> MACRO_DEPTH=1
>> MACRO_PRIORITY=2
>> MACRO_CONTEXT=conference
>> MACRO_EXTEN=incoming
>>
>> None of these variables are present anymore.
> I have created a function called STACK_PEEK() which would provide the
> equivalent values.  It is on reviewboard here:
> https://reviewboard.asterisk.org/r/1776/
Wow! Thank you!
It looks very thought through.

This is a tool to create very powerful ael dialplans.

> (from [asterisk-dev] [Code Review] Create STACK_PEEK to view calling context, extension, and priority):
>
> Whether this goes into a version of Asterisk earlier than 11 is a case for the bug reporter to make.

I would really like to have this included in a release-branch so I can
upgrade from 1.4 to 1.8/10 without applying patches.
It's a matter of view if this lost functionality is a bug or a feature I
guess.

That said, I can live with patching until asterisk 11 is released and
begin migrating to 11 at the end of the year..


>> If these variables were present in 1.8 and forward you could make a work
>> around like this:
> catch h {
>   for (i=1;${STACK_PEEK(${i},p)};i=${i}+1) {
>     if (${DIALPLAN_EXISTS(${STACK_PEEK(${i},c)},h,1)}) {
>       goto ${STACK_PEEK(${i},c)},h,1;
>     }
>   }
> }
>
>> I would argue that this should be inserted by default by the ael-parser
>> to make asterisk behave like in 1.4.
>> This way macro's would be much more flexible and useful even in complex
>> dialplans.
> You are more than welcome to try to modify the AEL compile code
> in res/ael/pval.c to get that code inserted.  Or, alternatively, you're
> welcome to try to persuade Steve Murphy (the author) to insert it for
> you.  That code is deep juju, and I'm not going there if I don't have to.

Now with this new STACK_PEEK-funktion maybe we should consider how this
could be done first?

I can think of three variants:

1) No AEL compile code should be touched, you should use the work-around
above for this functionality
Con: Suprises when the h exten doesn't run if you are in a macro, but
you could work around.

2) If there isn't a catch h in the macro, insert one with the code above.
Pro: This will make all ael macros behave like in 1.4 again
Con: If you have a catch h you will have to implement code at the end
yourself to continue down the stack

3) Insert a catch h if there isn't one with the code above. And if there
is a catch h insert the code at the end of this catch.
Pro: Will behave like in 1.4, but expanded possibilities - run a stack
of h extens down to the original context calling the macros


I would prefer #3, This would combine the no-suprise logic (h exten
always run) in 1.4 and add more power to the mix if you would like to do
crazy things..

I can settle with #1, and only have more power, but I think we should
eliminate the surprises and go for #2 or #3.

Thoughts?


And thanks again Tilghman, for creating this function!

-- 
Johan Wilfer                 email: johan at jttech.se
JT Tech | Developer          webb: http://jttech.se