More Control Options in Lync Optimizer

Introduction

A few long-asked for features in the Lync Dialing Rule Optimizer are the ability to modify the rule naming convention used for dialplans, usages, routes etc and simplified routing.  I haven't done so in the past because I thought that allowing users full control over the naming convention would cause all kinds of issues with the Optimizer code.  A fair amount of the code assumes all the rules follow a certain naming convention for things like least-cost routing to work. For non-North American countries, I've long allowed for the addition of a rule suffix, but the main rule format stayed the same.

The "typical" Lync Dialing Rule Optimizer naming convention starts with a 2-character country code, followed by a 2-character state or province code (North America only), then the city/area name, the numeric area code of the city/area, and finally a suffix denoting the call type (local, mobile, premium, national etc).  So, for Toronto, Ontario, we would have NA-ON-Toronto-416-222-Local (or -National, -Premium etc).  London, UK would be UK-London-20-Local.

I've recently realized that the code only relies on the country name prefix and the call-type suffix for all the code to work properly (a rare bit of foresight coming from this non-programmer).  So, I've made some changes to the Optimizer UI to allow for some new user-controllable settings.

Changing Rule Names

First off, I've extended the Rule example preview that's been available for non-North America countries for some time.  Now for any country, you will see a live preview of what a rule will look like after you've selected any of the options above the example.

If you don't like the default rule naming convention as displayed in the Rule example, you can change it by clicking the checkbox beside Change Rulename Base, and entering your own rule format, as in the below examples:

You'll get real-time feedback on how your rules will look without having to actually generate the ruleset and look through the Powershell output. The Optimizer will still control the country prefix and the -Local, -National etc suffixes as per usual to ensure least-cost routing and other options will still work.

Force English Rulenames

If you're working with a ruleset for a country that doesn't use English for rulenames, you can now click the Force English Rulenames checkbox. This box only appears when you select a country that doesn't already use English for its rulenames. When selected, all rules and descriptions will use English instead of the local language. This replaces the feature that was previously available using a separate (seemingly hard to find) webpage.

Simple Rulesets

I've also added an option to create a simple ruleset that handles all calls instead of the default that breaks up local, national, international, mobile and service numbers into groups so administrators can easily assign different voice policies that limit the types of calls users can make.

For example, a "traditional" Optimizer ruleset for London, UK will create the following usages and routes:

UK-London-20-Local

UK-London-20-Mobile

UK-London-20-National

UK-London-20-International

UK-London-20-Premium

UK-London-20-Service

If a company has a lot of sites, the number of usages and routes grows quite quickly.  Selecting the "Simple Ruleset" option will create the following usage/route:

UK-London-20-AllCalls

The AllCalls rule simply hands every single call off to the next hop. Much less complicated, but there are trade-offs. Least-cost routing between sites is not possible since any call will match the AllCalls usage. Administrators can't limit the types of numbers users can auto-forward calls to (see http://ramblingsofker.blogspot.com /2013/01/Lync-Call-Forwarding-SimulRing.html" target="_blank">this post for more information on the topic).

Also, don't attempt to add an AllCalls usage to a "traditional" Optimizer-generated voice policy that prevents certain classes of calls (ie international etc).  For example, assume a user is assigned to the voice policy NA-ON-Toronto-416555-Local, with usages formatted as below:

NA-ON-Toronto-416555-Local

NA-ON-Toronto-416555-Service

When a user dials a number, Lync will check for a match against all the routes in the usages assigned to the voice policy. So, if a user assigned to the Local policy tries to dial a long-distance or international number, Lync will check against the Local then Service usages for a match.  It won't find one, and the user will be denied the call.

The Lync administrator decides to add the UK-London-20-AllCalls usage to the bottom of the NA-ON-Toronto-416555-Local voice policy.

NA-ON-Toronto-416555-Local

NA-ON-Toronto-416555-Service

UK-London-20-AllCalls

Now when the user tries to dial a previously denied North American long-distance number,  the call will match against the UK-London-20-AllCalls usage and allow the call.  To add insult to injury, the call will route via London as an international call, and incur higher toll charges. 

So, the general rule is not to add AllCalls usages with voice policies that intend to limit calls to certain classes of numbers.  The Optimizer won't include AllCalls usages in least-cost routing calculations on "traditional" rulesets.  However, failover routing calculating and application is still available between rulesets that use the AllCalls option.

Conclusion

You can combine all these new features to create a truly customized ruleset for your deployment. So, you're able to create an English language simplified ruleset for Budapest, Hungary using a customized naming convention with just a few clicks.

These most recent UI and functionality changes should go a long way towards helping Lync administrators create rulesets that most benefit their deployment requirements.  Check out version 10.0 of the Lync Dialing Rule Optimizer at www.lyncoptimizer.com.

As usual, feedback is always appreciated. If there's anything else you'd like to see in the Optimizer, let me know in the comments.