[asterisk-dev] extensions.conf included contexts priorities

[Leif Madsen]

On Tuesday 24 April 2007 20:26:25 Jared Smith wrote:
> On 4/24/07, Steve Murphy <murf at parsetree.com> wrote:
> > Trouble is, is this desired behavior? Or is having the contexts checked
> > level by level until a match of any kind is found, the better procedure?
>
> Well, I for one desire the current behavior.  Everyone else can speak
> for themselves, but it makes it easy to override an extension included
> in a more-deeply-nested extension by putting its replacement in a
> less-deeply-nested context.  If they were all pulled together into one
> big ball of wax, we'd lose a lot of functionality.

I also agree here. If you change this functionality, people who depend upon it 
might come find you and do not such nice things to you :)

> Here's just one example of the many ways I use the current behavior.
>
> [long-distance]
> exten => _1NXXNXXXXXX,1,Dial(IAX2/${UPSTREAM}/${EXTEN})
> include => local
>
> [local]
> exten => _NXXXXXX,1,Dial(IAX2/${LOCALPROVIDER}/${EXTEN})
> exten => _1NXXNXXXXXX,1,Dial(no-permissions-to-make-this-type-of-call)

Or this:

[long_distance]
exten => _1NXXNXXXXXX,1,Dial(IAX2/${UPSTEAM}/${EXTEN})

exten => h,1,Verbose(1|This would actually get hit, and not the _. pattern)
include => match_all

[match_all]
exten => _.,1,NoOp()
exten => _.,n,Playback(cant-let-you-do-that)

Only the order of includes should matter, and not where they are placed in the 
dialplan in relation to extensions in the same context.

Leif.