[asterisk-dev] Behaviour in trunk's pbx_config.c, app_stack.c and users.conf

[Octavio Ruiz]

Hi!,

I would like to know how to proceed on this in order to generarte a proper
patch.

While testing trunk, found that the new way that pbx/pbx_config.c uses the
new Asterisk 11 'missing context feature' from apps/app_stack.c behaves in
a mode that you can only create a stdexten context in extensions.conf syntax
and not in AEL2 or LUA being both not able to arbitrarily set priorities.

This is because pbx_config.c when using users.conf and hasvoicemail,
instead of create an extension with all the proper and old fashion Gosub
set of options context,extension,priority(args), it uses the shorter
priority(args) syntax which leads you to necessarily add an include =>
stdexten to whatever it is 'usercontext', following the missing context
feature in app_stack.cs that asumes that

context=ast_channel_context(chan).

Therefore the new [stdexten] examples in extensions.conf adds a (stdexten)
label inside [stdexten] context but also sets the priority to some high
and arbitrary number, 50000 for [stdexten] and 60000 for
[stdPrivacyexten]in order to isolate the merge between [default] (or
'usercontext') and the included stdexten.

If you rewrite stdexten in LUA or AEL2, whenever you use a Return(), it
will reach the 2nd priority of the LUA/AEL2 stdexten which is not desired
(endless loop or at least until the stack empties).

To workaround this, you must have to write stdexten in extensions.conf
syntax starting with a priority non reachable  by the Gosub()/Return()
stack (as the extensions.conf.sample does) assuming that the only way that
it can be called using users.conf / pbx_config.c is doing an include to the
stdexten context in the 'usercontext'.

I think a best approach would be to return to the old behavior when
pbx_config.c generated the full set of options to GoSub
context,extension,priority(args)
(stdexten,${EXTEN},1(${HINT}) based on the idea that is desirable to be
able to write stdexten in any of the provided languages to code dialplans
in Asterisk.

Any opinion?

Best.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20120831/e5f3a26d/attachment.htm>