[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