[asterisk-users] Matching *, + and # in the dialplan

[Steve Murphy]

On Sat, 2008-10-11 at 10:09 +0200, Benny Amorsen wrote:
> Tilghman Lesher <tilghman at mail.jeffandtilghman.com> writes:
> 
> > exten => [0-9*#+].,...
> >
> > If that does not work, that is a bug and needs to be reported as such.
> 
> Sadly that matches *james and 9foo...
> 
> It would be nice if you could use normal regexes (e.g. with the pcre
> library) in extensions.conf.
> 

Full RE's are not really a good choice for extension pattern 
matching in the asterisk environment.

People have voiced this before; but the cut-down version of RE's that
the matching algorithms allow are fairly fast, both in the new and
the old pattern matching algorithms.

Using pcre would not be good in the dialplan. It would cut the
speed of matching an extension to a fraction of what is now.
It would be incompatible with the current dialplan algorithms,
so you'd have to use some sort of alternate syntax.
I've written at length why we use the algorithm we use now, and
why pcre type implementations might seem nice, but they preclude 
using the current matching algorithms. Look around in the dev list
archives
over the last 2 years from me...

Other than the above, we could invent a slightly different syntax for
pcre type expressions; and you'd have to invent some sort of
disambiguation
for when multiple extensions might be matched, to choose the 'best' one.

You'd have to forever stick with the 'check against every extension in
the
context for the best one' sort of algorithm, which is OK when the 
extension list is fairly short, but if you end up with more than 100 or
so
extensions in a context, you'd best go with the fast pattern matcher if
you
have to/want to deal with heavy call loads.

I've previously offered to expand the current pattern matchers to
include
some useful notation available in RE's. Some constructs could be done
in the current regime, but depending on which ones, will complicate the
current algorithms, but are possible. Some RE features are simply 
incompatible with the current algorithms.

murf


> 
> /Benny
> 

-- 
Steve Murphy
Software Developer
Digium
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3227 bytes
Desc: not available
Url : http://lists.digium.com/pipermail/asterisk-users/attachments/20081013/ff47cf5b/attachment.bin