I did some testing of my own, and found out that the first part of the 7-digit rules were causing the Lync client to ignore the entire rule. The first part of each 7-digit normalization rule is this cryptic piece of regex:
(?=^\d{7}$)This bit of regex says that whatever number is entered has to be a total of 7 digits long. The rest of the regular expression dictates the allowable first 2 or 3 digits for that particular area code. At the time, this was the only way I could think of to ensure the total number of digits entered was exactly 7.
I put the question to Microsoft, who acknowledged that the server and the client can use different criteria for evaluating the validity of regular expressions. It may be fixed in a future patch, but rather than waiting, I went about figuring out how to ensure 7-digit numbers without that bit of cryptic regex at the beginning.
After a good amount of research, work, and testing, I was able to figure out a way to ensure 7 digits in a much simpler way. At the same time, I got a bit of regex schooling by Dan Berry of Acrodex. He told me I had way too many brackets in my regular expressions, so with his prompting, I was able to reduce the number of brackets by quite a bit. He also gave me some other ideas for reducing the length and complexity of my regular expressions.
The end result is a much shorter and more robust set of regular expressions for all the North American local dialing rules. For example, one ruleset for Toronto, ON used to be 820 characters long. With the new optimizations, the character count is down to 621. This reduction can result in fewer rules, especially in larger cities.
If you've previously used the Optimizer to create your rulesets for 7-digit dialing, I recommend you apply the updated rules. If you subscribe to the monthly email rule update, then you'll get the updated ruleset starting next month. If you come across any issues with the new rules, please let me know.
Thanks for the update Ken. Anyone whom hasn't used this tool should really try it!
ReplyDeleteHi Ken,
ReplyDeleteI see some issues with the optimized output. I do see where you have 2 opening and 2 closing parentheses in some cases, but a bigger issue is when the digits in the bracket are preceded by a carat. An example NPA is 208642 with 7-digit. The normalization rule and route as depicted in this excerpt of the rule:
|33[^579]|34[^679]|35[035]|36[^0]|37[^024]
I am trying to analyze the results a bit more for any other items.
Thanks for the efforts and for sharing.
Hey Jeff,
DeleteYes, I know about the double brackets around some rules. As for the rules with the preceding carat, what's the problem? In all my tests, it works as expected as a NOT operator.
Ken
Hi Ken,
DeleteA new one on me as a NOT character. I will have to research better before publishing. I was trying the digit ranges which did not match, so I guess that is my error. Sorry.
>> |33[^579]|34[^679]|35[035]|36[^0]|37[^024]
DeleteCan I ask why negative matches are used?
The above is the same as
|33[0-468]|34[0-58]|35[035]|36[1-9]|37[135-9]
and I find it a bit easier to read.
Additionally [^0] doesn't just allow 1-9 but also allows characters and punctuation, whereas [1-9] allows only those digits.
Hi Ken,
ReplyDeleteI'm looking at the rules for 604-990. That should match for 604-909 and 604-910 according to the raw data, but the rule looks like it's not matching. If I remove the last |9 then the rule match for those, but obviously also matches for some others.
Any thoughts?
Hi Torren,
DeleteIt looks like there was a bug introduced with the latest changes that incorrectly stripped the last few digits from the rule. In your case, |9 should have been |989. I've corrected the problem, so give it a go again.
Ken
That's done the trick!
Deletecheers,
Torren
Hi ken,
ReplyDeletethe lync optimizer tool is not for middle east. is there a possiblity that i can add qatar and pakistan in the rule from my side, and then together we can update the tool.
If yes then can you please email me at khatri_shehzad@hotmail.com
Thanks
Salahuddin
Hi Ken,
ReplyDeleteI am using this tool for Virgin Iceland (North America 1). But when i am running this ps1 script in My Lync Server then getting this Massage.
PS C:\> .\dp.ps1
SiteId Identity
------ --------
1 Site:ICMC
Enter the Site ID to apply the dialing rules for Charlotte Amalie (St Thomas), V
I: 1
Creating premium number blocking rules
Creating call park orbits
Finished!
PS C:\>
I am selecting all the options in http://www.lyncoptimizer.com/.
Please suggest me how i can fix it.
Thanks:
AMit Sharma
Hi Amit,
DeleteI ran the ruleset you generated against my testbed and it worked as expected. Can you reach out to me via Lync or email at klasko AT buchanan.com?
Ken
Would it be possible to look at adding New Zealand to the Optimizer? Happy to help where I can. Thanks,
ReplyDeleteKeith
Hey Keith,
DeleteI've looked at doing New Zealand in the past, but from what I understand, its as messed up as North America. No clear way to tell if a number is local or long distance. Is that true?
Ken
Hi Ken,
DeleteI to would love you to add New Zealand to your Optimizer (with audiocodes would be wonderful as well!)
The main differance is New Zealand has a special case of an open dialing plan. While most nations require the area code to be dialed only if it is different, in New Zealand, one needs to dial the area code if the phone is outside the local calling area. For example, the town of Waikouaiti is in the Dunedin City Council jurisdiction, and has phone numbers (03) 465 7xxx. To call the city council in central Dunedin (03) 477 4000, residents must dial the number in full including the area code even though the area code is the same, as Waikouaiti and Dunedin lie in different local calling areas (Palmerston and Dunedin respectively)[5]
full set of numbers used in New Zealand can be found here:
http://en.wikipedia.org/wiki/Telephone_numbers_in_Oceania#New_Zealand
Regards John
I am looking for Dial Plan and Normalization Rules for Pakistan?
ReplyDeleteHi Ken,
ReplyDeleteWould it be possible to create dialing plan for Sofia, Bulgaria? I can assist you with information regarding mobile numbers, free numbers, etc.
Thank you!