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

[Tilghman Lesher]

On Fri, Aug 31, 2012 at 4:48 PM, Octavio Ruiz <tacvbo at tacvbo.net> wrote:
>> The configuration parameter does open up a way to implement the
>> stdexten behavior differently if you still feel the need to do so.
>
> Being the configuration parameter named 'stdexten' sounds reasonable
> that, even if Gosub has always used the current context if a context
> is not provided, to explicitly call a context named 'stdexten' it in
> pbx_config.c?
>
> This is what I mean:
>
> -  snprintf(tmp, sizeof(tmp), "%s,stdexten(${HINT})", cat);
> + snprintf(tmp, sizeof(tmp), "stdexten,%s,1,(${HINT})", cat);
>
> Right now, due the nature of Gosub and more precisely the way is
> invoked in pbx_config.c  'stdexten' can be _any_ context with a
> priority label (stdexten) meanwhile is included in the context where
> it's called and its written in extensions.conf syntax.

Correct, and that's as designed.  It means you can have multiple
meanings of what stdexten is in different contexts.  With Macro, you
could only have one definition.

> I do agree that documentation at asterisk.conf is clear with "How to
> invoke the extensions.conf stdexten (...) using a gosub as documented
> in extensions.conf.sample"  but, does that implicitly means that
> stdexten can only be written in extensions.conf and not in AEL2 nor
> LUA? Does it have to invoke Gosub exactly as the examples instead of
> the full set of options to Gosub (extension,label(args) vs.
> context,extension,priority(args))?

That eliminates the flexibility of there being different definitions
depending upon the context in which a phone starts.  For example, you
might want a different stdexten for outside callers than you do for
internal callers.

> Why not make it in a way that stdexten subroutine can be coded in any
> Asterisk supported language using Gosub instead of Macro knowing that
> Gosub nest more efficiently? I'm sure that's the reason why the
> implementation changed to Gosub.

Because that's incredibly complicated and easily broken.  We do not
generally support switching between dialplan languages in the midst of
a dialplan.  Specifically, it means that we aren't free to change the
underlying implementation, because we could break somebody's dialplan,
if that were supported.  And sometimes, either because of a bug or
because of a security issue, we need to be free to change underlying
implementation details.  There is an exception to this, and that is,
if you need to call a subroutine written in AEL, you can use the
AELSub() application for a consistent entry point.

The reason why Gosub is preferred is that Macro is very fragile when
it comes to nesting; it may unceremoniously crash the server process
when only a few levels deep, because it consumes a significant amount
of thread stack upon each nested invocation.  Gosub has no such
limitation and has been tested to at least 100,000 levels deep with no
ill effects.  Internally, AEL2 uses Gosub for all of its subroutines
now, because it is far more robust than Macro.

> I can imagine two approaches to this, one is keep it as it does right
> now but be even more clear on documentation, not assuming that
> dialplan code in extensions.conf express the limitations of the
> feature.
>
> The suggestion would be to document the need to include the
> stdexten-or-whatever-name context with a stdexten label in order to
> make it work and also to declare that when using Macro you are calling
> a Macro as an small, limited context named with a macro- prefix and
> can be written in AEL, LUA or extensions.conf and when using Gosub you
> are actually calling a label within the same context where you are
> calling it, not a context even if it name is stdexten and for sanity
> it can only be written in extensions.conf being the only language able
> to define arbitrary priorities (like the 50000 or 60000 in the
> extensions.conf.sample).

The point of using an arbitrily high priority is to ensure that it
does not conflict with any sequentially numbered priorities in the
normal space.  Also, starting from a priority other than 1 ensures
that it can ONLY be reached through a Gosub, not through somebody
dialing an alphabetic string from their SIP phone.

-Tilghman