Summary:	ASTERISK-11726: digit extension pattern matches also dialed string, that looks like pattern itself
Reporter:	pj (pj)	Labels:
Date Opened:	2008-03-26 07:59:38	Date Closed:	2011-06-07 14:08:14
Priority:	Minor	Regression?	No
Status:	Closed/Complete	Components:	PBX/pbx_ael
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:
Description:	when reporting another bug in ael ASTERISK-1223302, 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;  } ****** ADDITIONAL INFORMATION ******    -- Executing [_ZXX@from-ipbx:2] Dial("SIP/bill-gw-082441c8", "H323/_ZXX@ccm-gw") in new stack    -- Requested transfer capability: 0x00 - SPEECH    -- Called _ZXX@ccm-gw  == Everyone is busy/congested at this time (1:0/0/1)    -- Executing [_ZXX@from-ipbx:3] Congestion("SIP/bill-gw-082441c8", "") in new stack  == Spawn extension (from-ipbx, _ZXX, 3) exited non-zero on 'SIP/bill-gw-082441c8'
Comments:	By: Steve Murphy (murf) 2008-03-26 09:03:54 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.