[asterisk-dev] Re: extensions.conf included contexts priorities

Steve Murphy murf at digium.com
Wed Apr 25 14:33:56 MST 2007


On Wed, 2007-04-25 at 17:17 +0000, Tony Mountifield wrote:
> In article <1177516020.4769.57.camel at digium2>,
> Steve Murphy <murf at parsetree.com> wrote:
> > +; The algorithm to find an extension is recursive, and works in this
> > +; fashion: 
> > +;    a) Try to find a matching extension in the current context
> > +;       and, if found, begin executing the priorities there in sequence.
> > +;    b) If not found, Search the switches, if any declared, in sequence.
> > +;    c) If still not found, for each include, make that context the current
> > +;       context, and recurse to a).
> 
> This is not an accurate description. The search for an extension in the
> current context and then any included contexts is performed afresh at
> every priority, and any extension found within an include is executed
> in the original context. The included "context" isn't really a context,
> even though it looks like one!
> 
> Here's an example:
> 
> [foo]
> exten => 22,1,NoOp(CONTEXT1=${CONTEXT})
> 
> include => bar
> include => baz
> 
> [bar]
> exten => 22,2,NoOp(CONTEXT2=${CONTEXT})
> exten => 22,4,Hangup
> 
> [baz]
> exten => 22,3,NoOp(CONTEXT3=${CONTEXT})
> 
> If the caller enters context "foo" at extension 22, the following dialplan
> applications will be invoked:
> 
> NoOp(CONTEXT1=foo)
> NoOp(CONTEXT2=foo) *** not bar ***
> NoOp(CONTEXT3=foo) *** not baz ***
> Hangup

Tony--

As far as I know, the algorithm to find a priority in an extension in a
context is slightly different than that of just finding a matching
extension. I hate to be "nit-picking" here, but the algorithm is
accurate for finding a matching extension. We might be able to add that
it had better have the "1" priority, or things won't look so good...

But your example is truly mind-expanding. Heaven help the dialplan
programmer who uses those kinds of tricks, even if they are possible.
Any examples of practical usage that would demand this?

Hmm, you are right about the "current context" notion here. The current
context I mention is NOT the pbx core's "current context", but an
ideological one purely for the sake of the algorithm itself. During the
search, the pbx engine's "context" setting doesn't change a bit. How
would I make this clear? .... hmmm!


murf




-- 
Steve Murphy
Software Developer
Digium



More information about the asterisk-dev mailing list