[asterisk-dev] extensions.conf included contexts priorities

[Andrew Kohlsmith]

I've been using Asterisk for several years now, and I've run across something 
I am *positive* is unintended.  Testing against trunk and 1.4, the result is 
the same, so it's something which has been going on for a long long time 
now...  

When I design a dialplan, I list things in the priority I expect them to match 
in.  This includes 'include =>' statements, which (to me) should be included 
in the dialplan where they are written.  The current Asterisk dialplan 
implementation does not do this; it includes them at the end of the current 
dialplan context, in the order they were written.

I have two cases to present which I hope can convince everyone that this is 
the right way to do things.  I am a strong, strong believer in the path of 
least surprise, and Asterisk's dialplan does not currently follow this.

Case 1: included context has an extension which matches an extension defined 
later in the current context.

[bar]
exten => 789,1,NoOp(exten 789, bar context)

[foo]
exten => 123,1,NoOp(exten 123, foo context)
include => bar
exten => 789,1,NoOp(exten 789, foo context)

Now, following the path of least surprise, a call starting out in [foo] for 
extension '789' should match [bar]'s extension, since it is listed before 
[foo]'s extension of the same value.  This is not the case.  Includes are 
tacked on to the end of the dialplan they are mentioned in, not where they 
stand.

If I have a dialplan context (bar) which has a number of "overrides" for 
standard extensions in a master context (foo), I can't selectively override 
foo's extensions; I need to make the overrides part of foo's extensions.

Alternatively, I need to make a third context which I can then comment out 
the "include => bar" in order to switch the overrides in and out.  This is 
messy and counter-intuitive, at least to me, since it does not make sense to 
my pea-brain that contexts match in order, except for includes, which match 
in-order but at the end of the context they were included in.

Case 2: Wildcard matching for catchall extensions.

If I have a context which includes other contexts, and then also includes a 
wildcard afterward, the wildcard takes precedence over all the includes...  
Surely this is wrong, as the dialplan is to match wildcards last, with more 
precise matches taking priority.  It is not stated that wildcards take 
priority over includes, which adds to the surprise.

[bar]
exten => 555,1,NoOp(exten 555, bar context)
exten => _XXX,1,NoOp(wildcard match ${EXTEN}, bar context)

[foo]
exten => 123,1,NoOp(exten 123, foo context)
exten => 456,1,NoOp(exten 456, foo context)
include => bar
exten => 789,1,NoOp(exten 789, foo context)
exten => _XXX,1,NoOp(wildcard match ${EXTEN}, foo context)

If I dial '555' in the [foo] context, the _XXX matches.

The quick answer is to simply have your catchall as an included context, but 
that leads to a messy dialplan; if I have a dozen contexts with 
similar-but-different catchall actions, I have to create another dozen 
contexts just to handle the catchall rules.

Similarly, at least to me, the _XXX in [bar] should match before _XXX in [foo] 
because it is included BEFORE the _XXX in [foo].  Instead of all of these 
exception cases because of included contexts, why not simply state that 
extensions are matched in a top-down fashion as defined in their context, 
with more precise matches matching first?

Is this functionality intended, or am I just thinking stupidly?  I'd like to 
open a bug, but I want to make sure that this isn't intentional.

-A.