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

[Klaus Darilion]

Jared Smith schrieb:
> ----- "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.

Fine - so I will go on asking :-)
>> 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.

Ok. I see.

> 
>> 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.

Ok. This makes clear that Asterisk is not using "longest prefix match".

> 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.

So, I guess the sorting is not done when Asterisk tries to match an 
extension, but when parsing extensions.conf. Because when I execute 
"show dialplan test" I see the extensions are always in the order you 
have described (first: less possible solutions, second: ASCII sorting 
but . and ! are lees prior), e.g:

 > dialplan show test
[ Context 'test' created by 'pbx_config' ]
   '_12*' =>         1. NoOp()
   '_12+' =>         1. NoOp()
   '_1234.' =>       1. NoOp()
   '_123.' =>        1. NoOp()
   '_12:' =>         1. NoOp()
   '_12.' =>         1. NoOp()
   '_12!' =>         1. NoOp()
   '_[8]2345.' =>    1. NoOp()
   '_[1-2]2345.' =>  1. NoOp()
   '_[2-3]2345.' =>  1. NoOp()
   '_[3-4]2345.' =>  1. NoOp()
   '_[5-7]2345.' =>  1. NoOp()
   '_N2345.' =>      1. NoOp()
   '_X2345.' =>      1. NoOp()
   '_[+0-9]!' =>     1. DumpChan()


> 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.  


Ok. So now back to the original topic: The CID matching problem. When 
doing normmal matching and exten = +43699111600:
    _+436991116! => &Macro1();
    _+4369911!   => &Macro2();
Macro1 will be executed.

But when using CID matching (CID=+43699111600)
    s/_+436991116! => &Macro1();
    s/_+4369911!   => &Macro2();
Macro2 will be executed. Thus I think this is a bug as Macro1 should be 
executed too - shouldn't it?

I backported displaying CID in "dialplan show" from trunk to 1.4 to 
debug the problem (http://bugs.digium.com/view.php?id=14702):

[test]
exten => s/_+436991116!,1,NoOp();
exten => s/_+4369911!,1,NoOp();
exten => _+436991116!,1,NoOp();
exten => _+4369911!,1,NoOp();

will the translated into:

 > dialplan show test
[ Context 'test' created by 'pbx_config' ]
   's' (CID match '_+4369911!') =>  1. NoOp() 

   's' (CID match '_+436991116!') =>  1. NoOp() 

   '_+436991116!' => 1. NoOp()
   '_+4369911!' =>   1. NoOp()


Thus, as you see, CID matching use a different sorting approach. Bug?


regards
klaus