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

Tilghman Lesher tilghman at mail.jeffandtilghman.com
Mon Mar 16 14:33:52 CDT 2009


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

-- 
Tilghman



More information about the asterisk-dev mailing list