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

[John Lange]

Since 1.0?

Something definitely changed in 1.4. When I migrated our dialplans to
1.4 the started working differently. At first I thought it was a bug
since more exact patterns were not matching in favor of less exact
patterns.

With further research I determined that this had been changed in 1.4
though off the top of my head I don't recall where I found that info.

In any case, your example makes sense based on my current understanding
of how it works but the question remains, why would anyone want it to
work that way? What is the benefit in comparison to reading them all in
and then treating them with equal weight then matching on the most
precise pattern?

The point is, under the current scheme, more precise matches in lower
contexts NEVER match. In other words, patterns in lower contexts are
useless unless absolutely nothing else matches.

It just doesn't seem to make sense to do it this way.

John

On Thu, 2008-02-21 at 13:40 -0500, Jared Smith wrote:
> 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?