[asterisk-dev] CID match uses "shortest prefix match"

Jared Smith jsmith at digium.com
Wed Mar 18 06:55:11 CDT 2009


----- "Klaus Darilion" <klaus.mailinglists at pernau.at> wrote:
> Thanks for helping in clarifying things.

No problem!  I'm always glad to help when and where I can.

> So what about dialing 123456 and having:
> exten => _12345.,NoOp(Option 1)
> exten => _123.,1,NoOp(Option 2)
> 
> Which one will be used? I do not found this scenario in your
> description.

Let's apply the four rules I mentioned in my previous post to these two patterns, and see what happens.  

Let's begin by going digit by digit, let to right, and applying rule number 2.  We see that the first digit is the same (and only has one possibly option, the digit "1"), so the patterns are tied.  We move on to the second digit, and the patterns are still at a tie.  Same for the third digit.  Now we evaluate the fourth digit.  Both "4" and "." match what the callered entered for the four digit, but the "4" only has one matching possibility, while the "." matches on a lot more than one possibility.  This causes the first pattern (Option 1) to be ranked higher than the second.  We then move on and evaluate the rest of the digits.  Assuming that they match what the caller entered (and they do!), we execute rule number four and take the highest ranked pattern, which is Option 1.

Make sense?  If not, let me know where you're having problems, and I'll try to explain it in another way.

> Or what will be used in this case (dialing 123456):
> exten => _X2345.,NoOp(Option 1)
> exten => _123.,1,NoOp(Option 2)

OK, this is almost the exact same case as above.  We start with the first digit.  Both "X" and "1" match the dialed number.  The "1" is a more precise match, as "X" can match 10 possible digits, but the "1" can match only one.  This gives the second pattern (Option 2) a higher rank.  We then move on and evaluate the remaining digits, and assuming both patterns match what the caller dialed (and they do!), the second pattern (Option 2) gets chosen.

One thing I emphasize in our Asterisk training classes is how to double-check my pattern mathing.  To to this, you can use the "dialplan show" command from the CLI to test your patterns.  For example, I have in my dialplan right now the following context:

[patterns]
exten => _NXX     ,1,NoOp(1)
exten => _[1­8]22  ,1,NoOp(2)
exten => _[a­h]1X  ,1,NoOp(3)
exten => _X.      ,1,NoOp(4)
exten => _X2.     ,1,NoOp(5)
exten => _[0­9*#]11,1,NoOp(6)

Can you tell just by looking what would be matched if you dialed "822" in that context?  A bit tricky, no?  Add that to your dialplan, reload the dialplan, and then type "dialplan show 822 at patterns" and you'll see the patterns listed in the order that Asterisk would have chosen them.  

Using this method, I've been able to better understand how Asterisk does its pattern matching, and even catch a few errors in the Asterisk pattern matching system.  Let me finish by mentioning two other important items:  

1) If you're still running Asterisk 1.2, the pattern matching engine isn't nearly as robust as what's in 1.4 and 1.6.x.  Some fairly serious flaws in its matching have been found, which is one reason I won't touch Asterisk 1.2 any more.

2) There was also a bug in earlier versions of Asterisk 1.6.0 (and probably the 1.4 series as well).  You can test your system by copying the [patterns] context above into your dialplan, and typing "dialplan show 822 at patterns".  If option 1 shows up at the top of the list, you should probably upgrade your system.  The second pattern should be the best match in that example.

As always, feel free to test on your own system and give me feedback.

---
Jared Smith
Training Manager
Digium, Inc.



More information about the asterisk-dev mailing list