Bobby B wrote:
I you wanted to go further, supporting a subset of standard regular expressions, with only digits for text, may be beneficial.
A regular expression engine is more computationally expensive and may "clog the pipe". When the server is trying to match the number against one or more blacklist entries, this matching process needs to be as fast as possible, especially when there's many other calls waiting to be processed.
I was wondering about bandwidth needed in wildcard blacklist processing at first....I think the way you guys implemented it is pretty smart allowing only trailing wildcards. That way, you can just check "exists" condition vs having to check match with every single wildcard entry.
In my simple mind, I imagine you having range-low and range-high created behind the scenes when blacklist entries are created. Range-low being a 10 digit number filled with 0's outside of user specified leading numbers and range-high filled with 9's (explicit blacklist entries would have identical range-low and range-high). This way, you just check for incoming callerid falling within any ranges in the blacklist.
Now, for entry level treatment option to happen, the extra work involved would be....of the "existing" blacklist rows the incoming callerid hit, you'd have to select the entry with the smallest range (most explicit blacklist specification) and decipher the treament option specified before the call gets routed. After the call get routed, you can also increment the hit counter for that entry