[asterisk-bugs] [Asterisk 0012303]: digit extension pattern matches also dialed string, that looks like pattern itself
noreply at bugs.digium.com
noreply at bugs.digium.com
Wed Mar 26 09:03:59 CDT 2008
The following issue has been CLOSED
======================================================================
http://bugs.digium.com/view.php?id=12303
======================================================================
Reported By: pj
Assigned To: murf
======================================================================
Project: Asterisk
Issue ID: 12303
Category: PBX/pbx_ael
Reproducibility: always
Severity: minor
Priority: normal
Status: closed
Asterisk Version: SVN
SVN Branch (only for SVN checkouts, not tarball releases): trunk
SVN Revision (number only!): 104031
Disclaimer on File?: N/A
Request Review:
Resolution: open
Fixed in Version:
======================================================================
Date Submitted: 03-26-2008 07:59 CDT
Last Modified: 03-26-2008 09:03 CDT
======================================================================
Summary: digit extension pattern matches also dialed string,
that looks like pattern itself
Description:
when reporting another bug in ael http://bugs.digium.com/view.php?id=0012302, I
accidentally found issue with
ael digit pattern matching,
simple dialplan below, doen't match only numbers with three digits like
[1-9][0-9][0-9] as expected, but also match dial string, that corresponding
with pattern itself,
I accidentally dial '_ZXX' and it match!
_ZXX => {
Dial(H323/${EXTEN}@ccm-gw);
Congestion;
}
======================================================================
----------------------------------------------------------------------
murf - 03-26-08 09:03
----------------------------------------------------------------------
I think I am responsible for this odd behavior. I made mods to the code way
back when to allow direct matches between patterns and the pattern itself,
because certain operations depend on finding a pattern not by some
dialstring, but by the pattern.
This is a subtle difference, but an important one. For instance, if you
wanted to Goto a priority in a patterned extension, how do you do that? If
instead of referring to the extension explicitly, you invent a string that
the pattern matches, and then count on the pattern matching, what if later
mods remove the extension you referenced, but some other pattern matched
instead?
I **could** re-engineer the interface to provide two different matching
algorithms: the pattern match as exists, and one to lookup by direct,
explicit, whatever match. The former would match "899" with "_X99"; the
latter would match only "_X99" with "_X99". But then all apps that would
require "either or" would have to be split, or accept another arg, to
differentiate which kind of match to make.
Such a change would require potentially big changes in the current
dialplans, extensions.conf, and extensions.ael, as well as the core
interface. Way back when, I decided the lowest impact approach was the one
currently in force.
But, if the community feels strongly about this, I could generate a new
set of Goto apps (along with potentially all other apps, and funcs, that
take an extension argument), and provide a new set that use a new explicit
matcher. I could go back into the bowels of the pattern matcher and reverse
the changes I made earlier, and make a new matcher that will make the
direct matches (as if the beginning '_' were not present. This kind of
approach would leave dialplans to use the current Goto, which in most cases
will work, but force users who were previously counting on the explicit
match behavior to change their dialplans accordingly. Since that would
really, really, be a messy thing to do, one other approach could be taken:
any dial string beginning with "_" will be considered a direct match
string, and match explicitly. Even this is not exactly what the current
matcher does. Right now, given pattern "_9XX", the pattern matcher will
match "988", "9XX", "99X", etc. It's more a char-by-char thing than a
entire string match.
Changing any aspect of this is a pretty nasty thing to do. People's
dialplans will fail in unexpected and unpredictable ways. I vote to leave
it the way it is, but again, if the community feels strongly that the
current solution is inadequate, then the reward will exceed the pain.
For those wishing to light up the torches, and pull out the pitchforks and
baseball bats, and make any of the above proposed changes, I suggest
re-opening this bug, and begin a campaign in the asterisk-dev mailing list
to drum up some support. When enough of the right folks are in agreement,
it will be done.
Issue History
Date Modified Username Field Change
======================================================================
03-26-08 09:03 murf Note Added: 0084575
======================================================================
More information about the asterisk-bugs
mailing list