[asterisk-dev] new priority of pattern matching in 1.4. Does it makes sense?

[Jared Smith]

On Thu, 2008-02-21 at 11:05 -0600, John Lange wrote:
> There is no practical application of it. Someone please cite an example
> of when you would EVER want pattern matching to work that way.

Well, before we go into *why* we do it the way we do it, let's just
clarify how Asterisk actually does its extension matching.  Since at
least Asterisk version 1.0, the system looks recursively for a matching
extension in the following order:

1) An exact match in the current context
2) A pattern match in the current context
3) A match on any switch statements 
4) A match in the first included context (which we'll call A in the
example below)
4a) A match in the first context included in A (which we'll call AA in
the example below), following this same set of rules.
5) A match in the second included context (B in the example below)
and so forth.

In Asterisk dialplan code, let's do the following example:

[matching-demo]
include => A
include => B
switch => IAX2/some_peer/remote_context
exten => 123,1,Verbose(0,Alice)

[A]
include => AA
exten => 123,1,Verbose(0,Charlie)

[AA]
exten => 123,1,Verbose(0,David)

[B]
exten => 123,1,Verbose(0,Edward)


If you were to dial "123" in the matching-demo context, you'd see that
it would first match extension 123 in the matching-demo context and
print "Alice" to the CLI.  If that didn't exist, it would match
extension 123 on the remote peer in its remote_context context (because
of the switch statement), assuming that extension exists there.  If
there was nothing there, it would then match in context A, printing
"Charlie".  If that extension didn't exist, it would match on the
extension printing "David", and finally on "Edward".

Does that make sense?

-- 
Jared Smith
Community Relations Manager
Digium, Inc.