Re: new priority of pattern matching in 1.4. Does it makes sense?

On Mon, 2008-02-25 at 16:40 -0500, Jarenessto wrote:

> > 3) Only if no pattern could possibly match in the
first included
> > context, then Asterisk will search the second,
then third included
> > context, and so on until a match is found or all
patterns have been
> > tested.
> 
> I'd rewrite this as "Only if no patter could
possibly matchin in the
> first included context *or any contexts included in the
first included
> context*,

I'd forgotten about nested includes. So the nested includes
are searched
all the way down the tree before the next included context.
Correct?

And I second that question about how the special extensions
play into
this, especially "a" and "o".

If a call is sent into voicemail via an include or a nested
include and
the caller subsequently exits the voicemail system with
"*" or "0", do
they exit in the starting context, or into the context that
voicemail
was called? Or are all included contexts searched from the
start down
for the first match of 'a' or an 'o' ?

John



_______________________________________________
--Bandwidth and Colocation Provided by http://www.api-digital.c
om--

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

On Tue, 2008-02-26 at 12:00 -0600, John Lange wrote:
> I'd forgotten about nested includes. So the nested
includes are searched
> all the way down the tree before the next included
context. Correct?

Yes.  It's a depth-first search.

> And I second that question about how the special
extensions play into
> this, especially "a" and "o".
> 
> If a call is sent into voicemail via an include or a
nested include and
> the caller subsequently exits the voicemail system with
"*" or "0", do
> they exit in the starting context, or into the context
that voicemail
> was called? Or are all included contexts searched from
the start down
> for the first match of 'a' or an 'o' ?

An include acts as if the included extension was actually a
part of the
context that contains the include statement.

Again, this is easy enough to test with a quick dialplan
example:

[original]
exten => a,1,NoOp(We matched in the original context)
include => first-include

[first-include]
exten => 500,1,Voicemail(1234default)
exten => a,1,NoOp(We matched in the first included
context)
include => second-include

[second-include]
exten => a,1,NoOp(We matched in the second included
context)

If you were to point your phone at the [original] context
and dialed
extension 500 and then pressed the * key (to get to the 'a'
extension),
you'd see that we'd match on the 'a' extension in the
[original]
context.  This is because extension 500 was called as if it
had been in
the [original] context.  Make sense?

-- 
Jarenessto
Community Relations Manager
Digium, Inc.


_______________________________________________
--Bandwidth and Colocation Provided by http://www.api-digital.c
om--

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

John Lange wrote:

> I'd forgotten about nested includes. So the nested
includes are searched
> all the way down the tree before the next included
context. Correct?

Yes, this is why Matt Nicholson referred to it as a
'depth-first'
search. A width-first search would check all the included
contexts at
the top level first before descending.

> And I second that question about how the special
extensions play into
> this, especially "a" and "o".
> 
> If a call is sent into voicemail via an include or a
nested include and
> the caller subsequently exits the voicemail system with
"*" or "0", do
> they exit in the starting context, or into the context
that voicemail
> was called? Or are all included contexts searched from
the start down
> for the first match of 'a' or an 'o' ?

Extensions are searched for in the 'current context' of the
channel, but
matches found via switches, includes and other means do
*not* change the
current context of the channel. Because of this, no matter
how the
extension was found that is running VoiceMail() (for
example), exiting
via the 'a' or 'o' paths will search for those extensions in
the
channel's current context, which will be the one it was sent
into
originally.

-- 
Kevin P. Fleming
Director of Software Technologies
Digium, Inc. - "The Genuine Asterisk Experience"
(TM)

_______________________________________________
--Bandwidth and Colocation Provided by http://www.api-digital.c
om--

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev