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

Klaus Darilion klaus.mailinglists at pernau.at
Tue Mar 17 04:25:10 CDT 2009



Tilghman Lesher schrieb:
> On Monday 16 March 2009 12:31:10 pm Steve Davies wrote:
>> 2009/3/16 Alex Hermann <alex at speakup.nl>:
>>> On Monday 16 March 2009 17:57:20 Klaus Darilion wrote:
>>>> Hi!
>>>>
>>>> I tried the CID match feature of Asterisk (1.4.23) but found a strange
>>>> behavior: it matches on shortest prefix, e.g:
>>>>
>>>>    s/_+436991116! => &Macro1();
>>>>    s/_+4369911!   => &Macro2();
>>>>
>>>> if CALLERID(num) is +43699111600 I would think that Macro1 is executed,
>>>> but instead Macro2 is executed. Regardless of the order in the config
>>>> file.
>>>>
>>>> Debugging is very difficult, as the CID match is not shown in "dialplan
>>>> show" and also the logging does not reveal any CID matching.
>>>>
>>>> I think this is a bug - or is there a reason why shortest prefix match?
>>> That is the function of the !: match as soon as possible. Try a . (dot)
>>> instead and it will match the loger pattern.
> 
> This is incorrect; see below.
> 
>> Has this changed then?
>>
>> I was always under the impression that if there were 2 possible
>> exten=> matches in a single context, then which one was chosen was
>> "undefined", but include=> directives were still considered in order,
>> so to specify which order the above patterns are tried would require:
>>
>> [context1]
>> include => context2    # <- Consider this first
>> include => context3    # <- Consider this second
>>
>> [context2]
>> exten => s/_+436991116! => &Macro1();
>> [context3]
>> exten => s/_+4369911!   => &Macro2();
>>
>> TBH I am not sure of the use of the ! on the CID match. On the
>> extension matching I am under the impression that it signifies a
>> last-ditch match that only occurs if nothing more specific is
>> available.
> 
> When it comes to the short-circuit operators "." and "!", the first matches,
> based upon an alphanumeric search of the entire extension string.

Yes. But also relevant is the order in which Asterisk tries to match the 
extension - and this order is usually (regardless of the order in 
extensions.*) longest prefix first.

regards
klaus

>  As Steve
> Davies correctly pointed out, the order in which matching is done is better
> managed by using ordered includes (depth-first search).  Also note that the
> short-circuit operators may only be the final character within an extension,
> by definition:  the short-circuit nature of the character means that no
> further matching will be done.
> 



More information about the asterisk-dev mailing list