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

[John Lange]

I know this has been raised as a thread before but the more I experience
it the more confused and frustrated I become. I must be missing
something...

In 1.4 the priority of matching dial strings changed from "best match"
to "best local match -> best included-match".

In other words, in 1.2, all patterns were given equal weight regardless
if they were part of an include or not, and then the closest exact match
was used.

In 1.4, only non-included patterns are evaluated and if, and only if
there is absolutely no match found, then included patterns are
evaluated.

Can someone please explain what purpose this serves or why this is an
improvement? I can't think of a single example of how this could be used
in practice.

Far from being an improvement this change has caused our dialplans to be
much messier and inefficient. I'll try and give a brief example and
maybe someone can explain how this can be done with 1.4.

In a situation where you have many classes of users, many sections of
the dialplans for these users will be identical with only minor
differences (perhaps for different outbound trunking).

e.g.

; Class 1 users uses 2 cheap SIP and IAX proviers for
; long distance but uses the PRI for local calls.
[class1]
include => local_calls
exten => _1555NXXXXXX,1,Dial(SIP/${EXTEN}@provider1)
exten => _1NXXNXXXXXX,1,Dial(iax2/2195 at provider2/${EXTEN})
exten => _011.,2,Dial(iax2/1234 at provider2/${EXTEN})
include => toll_free

; Class 2 uses cheap provider for international but use PRI for
; all other calls.
[class2]
include => local_calls
exten => _1555NXXXXXX,1,Dial(${PRITRUNK}/${EXTEN})
exten => _1NXXNXXXXXX,1,Dial(${PRITRUNK}/${EXTEN})
exten => _011.,2,Dial(iax2/1234 at provider2/${EXTEN})
include => toll_free

; in all cases we want to send toll free through the PRI
[toll_free]
exten => _1800NXXXXXX,1,Dial(${PRITRUNK}/${EXTEN})
exten => _1888NXXXXXX,1,Dial(${PRITRUNK}/${EXTEN})
exten => _1877NXXXXXX,1,Dial(${PRITRUNK}/${EXTEN})
exten => _1866NXXXXXX,1,Dial(${PRITRUNK}/${EXTEN})
exten => _1855NXXXXXX,1,Dial(${PRITRUNK}/${EXTEN})

; In all cases we want to send local calls to the PRI so just in case
; the user accidentally dialed a local call as a long distance call,
; we try and match all local area codes and exchanges
[local_calls]
exten => _1555940XXXX,1,Dial(${PRITRUNK}/${EXTEN:4})
exten => _1555941XXXX,1,Dial(${PRITRUNK}/${EXTEN:4})
exten => _1555942XXXX,1,Dial(${PRITRUNK}/${EXTEN:4})
exten => _1555943XXXX,1,Dial(${PRITRUNK}/${EXTEN:4})
.
.
.
.
.
.. insert 190 other local exchanges here ...

------

In the above example, the "toll_free" and "local_calls" contexts NEVER
match anything because the less precise "_1NXXNXXXXXX" pattern is in a
higher context and therefore matches everything.

The only way to make this work is to duplicate the entire "toll_free"
and "local_calls" context (which is nearly 200 lines long) for every
class of user or put the "toll_free" and "local_calls" into separate
files (without the context identifiers) and then "#include" them.

What am I missing here? How can this less-precise, prioritized pattern
matching ever be used?

John Lange