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

[Tilghman Lesher]

On Wed, Feb 29, 2012 at 4:21 AM, Johan Wilfer <lists at jttech.se> wrote:
> 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.
>>>
>> 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's definitely the issue:  is this a bug or a new feature?

>>> 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.

This is going to be the easiest, but not automatically inserting the code
makes this not a bugfix, and thus STACK_PEEK cannot go into 1.8.  When
the bugfix exception is triggered in the policy, it has to be the whole bugfix
or nothing.

> 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

This is going to be very difficult, because you're dealing with the AEL
compilation code.  You could lessen the pain considerably if you create
a common include'd context (with this logic) and added the include to
each context created by AEL.  Thus, the "h" extension would bubble up
until it found a "real" h extension.  If you went with this option, you could
remove the for loop, because each context would do the iteration for you.
This works correctly, as long as this include is the last include in each
context, because we search depth-first.

> 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

This is a non-starter, because it considerably changes how the "h"
extension works.  It's only supposed to execute the found "h" extension
which is closest to where the hangup occurred, not every "h" extension
in the stack.  I would consider any implementation which did this by
default to be a bug.

-Tilghman