Thursday, May 31, 2012

Lync Dialing Rule Optimizer Gets Optimized

It was recently brought to my attention that some of the normalization rules created by the Lync Dialing Rule Optimizer in certain cases were not being used by the Lync client.  Specifically, the issue only arises if you select the option for the Optimizer to create 7-digit local dialing rules (only available for North America dialing rules).  The 7-digit rules are simply never used.  If you enter a 7-digit number that should be normalized to a 11-digit E.164 North American phone number, it doesn't happen.  Interestingly, if you use the Lync Voice Routing Test Case applet in the Lync Control Panel, you'll see that it normalizes just fine.

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.

16 comments:

  1. Thanks for the update Ken. Anyone whom hasn't used this tool should really try it!

    ReplyDelete
  2. Hi Ken,

    I 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.

    ReplyDelete
    Replies
    1. Hey Jeff,
      Yes, 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

      Delete
    2. Hi Ken,

      A 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.

      Delete
    3. >> |33[^579]|34[^679]|35[035]|36[^0]|37[^024]

      Can 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.

      Delete
  3. Hi Ken,

    I'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?

    ReplyDelete
    Replies
    1. Hi Torren,
      It 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

      Delete
    2. That's done the trick!

      cheers,
      Torren

      Delete
  4. Hi ken,
    the 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

    ReplyDelete
  5. Hi Ken,

    I 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

    ReplyDelete
    Replies
    1. Hi Amit,
      I 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

      Delete
  6. Would it be possible to look at adding New Zealand to the Optimizer? Happy to help where I can. Thanks,
    Keith

    ReplyDelete
    Replies
    1. Hey Keith,
      I'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

      Delete
    2. Hi Ken,

      I 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

      Delete
  7. I am looking for Dial Plan and Normalization Rules for Pakistan?

    ReplyDelete
  8. Hi Ken,

    Would it be possible to create dialing plan for Sofia, Bulgaria? I can assist you with information regarding mobile numbers, free numbers, etc.

    Thank you!

    ReplyDelete