Wednesday, August 21, 2013

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


Thursday, August 1, 2013

Forwarding Calls Using Inter-Trunk Routing

A question came up on the Lync Technet forums about how to make Lync 2013 take an inbound PSTN call to a specific Lync number and turn around and send it back out to the PSTN to another number.  Previous to Lync 2013, this wasn't possible unless you setup a response group to take the inbound call and forward it to a different number.

Lync 2013 introduced inter-trunk routing, which allows administrators to route incoming calls to another phone system. While its main intent is to facilitate connections between dissimilar phone systems, it can also be used to forward inbound calls to another external phone number using the same trunk.

Let's assume you have a SIP trunk connected to Lync Server 2013.  You have a phone number associated with Lync and your SIP trunk (+15554447777) that you want to forward to a completely different number not hosted on your SIP trunk/Lync (say +15558880001).  Also, assume that you've already setup dialing rules to normalize everything to E.164 standards.

First, go to your global voice policy and create a PSTN usage.

Create a new route that contains only +15554447777, and assign the route to your SIP trunk.

Now, go over to the Trunk Configuration page and edit your SIP trunk. Add the PSTN usage you created above to the Associated PSTN Usages dialog box:

Scroll further down and create a new Called Number Translation Rule. Create a rule that will translate +15554447777 to +15558880001, as shown below:

Commit your changes, and voila! You have now configured administrator controlled call forwarding in Lync 2013.

A few notes:

  • Make sure the number you want to forward is not already assigned to a user, response group or other feature. If it is, this will not work because Lync will check to see if any Lync resource has the number assigned before attempting any other routing.
  • In most cases, SIP trunks don't support REFER, so any calls routed using this manner will use two channels, one for the inbound leg, and one for the outbound leg. The call will be hairpinned through your Lync servers. Be careful before doing this to a lot of phone numbers.
I'm not sure how often this sort of thing would come up, but its nice to know it will work.