[asterisk-dev] extensions.conf included contexts priorities

[Andrew Kohlsmith]

On Wednesday 25 April 2007 10:04 am, Steve Murphy wrote:
> Well, I guess the magic of putting the _1NXXNXXXXXX exten in the local
> context wouldn't be useful until you define an "untrusted" context:

I generally build my contexts as small and modular blocks, and then 
build "grouping" contexts which assemble them into various classes (trusted, 
untrusted, internal, etc.)

> [untrusted]
> include => local

Pretty much, yes...  

> And, maybe, it'd be better to define the local this way instead:
>
> [local]
> exten => _NXXNXXXXXX,1,Playback(gojumpinthelake)
> exten => _011.,1,Playback(gojumpinthelake)
> exten => _NXXXXXX,1,Dial(...)
>
>
> so, sip.conf might have
> [lobbyphone]
> context = untrusted
>
> (all you want folks using the phone in the lobby for is dialing local
> numbers)

Very close.  sip.conf is pretty much identical to how I'd do it, but untrusted 
would look like this:

[untrusted]
include => nine11
include => local
exten => _X.,1,Playback(invalid)

which, of course, doesn't work under this system, since _X. will match before 
anything that is included.  I'd have to have this:

[untrusted]
include => nine11
include => local
exten => i,1,System(/usr/local/scripts/detonate_handset ${CID(num)})

> So, now, a single local context can serve both trusted and untrusted
> situations.
> The gojumpinthelake message will only get played when not overridden by
> higher contexts.

Yes, but a hell of a lot messier, no?

> It's backwards to what you are accustomed to, but still useful.

I don't doubt that the system works, I'm just trying to understand the 
reasonings behind it and suggest better ways of doing things.  Having 
wildcard matches in [local], [longdistance], etc. to handle this seems like a 
hell of a way to do it.

-A.