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

[Johan Wilfer]

2012-02-29 21:47, Tilghman Lesher skrev:
> 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?

I've spent some more time thinking about this. My opinion is that it's a
bug, and we should fix it in 1.8 and 10.
Can someone open ASTERISK-19336 so I can upload a patch for the ael
parser later?

Or speak out if this is not a bug, so I can drop this...

I've a lot to to the next weeks but I should find some time at the end
of the month.

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

Okay, you are right, this is the solution.

I'll try to persuade Steve, or look at it myself at the end of the month.

Thanks for the input!

-- 
Med vänlig hälsning

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