Location Based Routing with Lync Server 2013 CU1

As announced at the Lync Conference 2013 a new feature, Location Based Routing, will be coming to the product as part of the February 2013 (CU1) update.  This feature will allow administrators to configure enterprise voice routing rules that will control routing based on the physical location of the person.  This is a huge new feature to the product!

Here are the major items to be aware of:

  • Location Based Routing forces outbound calls to be routed to a specific PSTN gateway that the user is physical located at.  This is controlled based on the sites/subnets you have already defined for CAC.  This prevents toll-bypass for these users which in some cases can violate local laws.
  • Location Based Routing also prevents inbound PSTN calls to Lync endpoints if in other location.  Preventing the call to be routed over the WAN.  For example if a user in Minneapolis traveled to India, the inbound call to Minneapolis PSTN Gateway would be prevented from routing over the WAN to India and the call would be sent to Voice Mail instead, assuming it has been enabled for that user.
  • Location Based Routing will prevent PSTN toll bypass on both inbound and outbound calls to and from locations that are not defined or unknown.  So if a site is enabled for location based routing and the user lands on an undefined wireless network (as defined in Lync Server Network/Sites/Subnets) then the call would not be allowed to be routed to that user as the server would not know what site they are currently in.

Outgoing PSTN Calls

Calls will be authorized based on the users voice policy.  Therefore in our example of a Minneapolis user visiting the India office, if the user in Minneapolis’ voice policy does not allow the user to call numbers in India, simply because the user has visited the office will not allow them to dial those internationally numbers suddenly.  So it’s important to remember that the user must be authorized to dial the number based on their voice policy.

Inbound PSTN Calls

I just wanted to mention it again, calls will not route over the WAN to the user, is the site is enabled to prevent PSTN Toll Bypass.

Delegate Users/Sim Ring/Call Forwarding

It’s important to think about the implications of these scenarios when using Location Based Routing.  Because all calls could eventually be affected.  So let’s take this simple example: In the boss/admin scenario where the admin is a delegate of the boss.  If the admin travels to India, in our example above, and is a sim-ring target for PSTN calls to the boss, the admin would not get these calls as it would circumvent location based routing.

I should note that in the reverse where the boss has traveled to India and the admin is located in Minneapolis a inbound call to the boss would not ring her endpoint in India but the Sim Ring delegate in Minneapolis would ring.  If the admin took the call and attempted to transfer the call to the boss in India, the transfer would fail as that would allow the PSTN call to be routed over the WAN.

NOTE: These are on PSTN calls and nothing I have seen or tested would affect a Lync-to-Lync call within the enterprise.

DR/Pool Failover

During pool failover all Location Based Routing rules still apply and therefore you need to make sure you carefully understand what the implications are of the two.

Deployment and Configuration

Let’s use the following as an example of our deployments

  • Trunk1 – Minneapolis-Gateway
  • Trunk2 – India-Gateway

We have the following voice policies

  • MinneapolisVoicePolicy
    • PSTN Usage: MSP-Usage
  • IndiaVoicePolicy
    • PSTN Usage: India-Usage

And our voice routes would be something like:

  • Route 1 – MSP-Route is associated to MSP-Usage and Minneapolis-Gateway
  • Route 2 – India-Route is associated to India-Usage and India-Gateway

UPDATED: Somehow my copy/paste missed this section.  Thanks Elan for pointing this out!

Create a new voice routing policy:

New-CsVoiceRoutingPolicy -Identity “MSPvoiceroutingpolicy” -Name “Minneapolis voice routing policy” -PstnUsages @{add=”MSP-Usage”}

END UPDATE

So on the User Voice Policy you would need to enable this:

Set-CsVoicePolicy MinneapolisVoicePolicy -PreventPSTNTollBypass $True

On the Network Site that has been defined you would need to enable it:

Set-CsNetworkSite -Identity MinneapolisNetworkSite -EnableLocationBasedRouting $true -VoiceRoutingPolicy MSPvoiceroutingpolicy

Configuration of the Trunk also:

Set-CsTrunkConfiguration -Identity Trunk1 -EnableLocationRestriction $true -NetworkSiteID MinneapolisNetworkSite

Lastly, it must be configured globally as enabled as well:

Set-CsRoutingConfiguration -EnableLocationBasedRouting $true

Hopefully that sheds some light on the new Location Based Routing functionality.  I’ll follow up with a nice Visio format of the above so for anyone who is a visual learner it would make sense as well.

UPDATE: Speaking with Ken Lasko (Lync MVP – http://ucken.blogspot.com/) he will start looking into updating the Lync Optimizer to handle some of these new routing options.

Share

11 comments on “Location Based Routing with Lync Server 2013 CU1”

  1. Elan Shudnow Reply

    Missing New-CsVoiceroutingPolicy. This is the policy name that actually gets applied to the Network Site hence the switch called -voiceroutingpolicy. New-CsVoiceRoutingPolicy is where you assign the PSTN Usages.

  2. Damien Margaritis Reply

    Hi Richard,

    I haven’t had a chance to lab this yet, am I able to leverage location based routing without enforcing prevention of toll bypass? Or can they only be configured together?

  3. Pingback: Lync Server 2013 February 2013 Cumulative Update Released | Justin Morris on UC

  4. B. Zang Reply

    Hi Richard,
    I’ve not gone through a lab test on this yet, but was wondering how does Lync enforce this in global topology with a combination of 2010 and 2013 pools? For example, a 2010 pool is in Minneapolis and a 2013 pool in India?

  5. David Hughey Reply

    I have been working with this to try to merely cause users to use a route based on their subnet, so that the route can have a specific call-ID configuration, even though ultimately the same PSTN gateway will be used regardless of location over WAN. For example, users in Ft. Worth and in Dallas, but ultimately only 1 gateway/trunk at the datacenter. Configuring a Dallas and Ft. Worth usage each with a route that masks caller ID. The idea would be that they use a different route based on their location/subnet, so the caller ID would be different. In my testing this is not working as thought, should it?

    • David Hughey Reply

      Well, 5 minutes after posting this question I got it working. This will also work without using location restriction or associating a network site with the trunk (if you only have one trunk and you just want to modify call ID based on location of user). The reason it wasn’t working for me earlier is I didn’t have the voice policy assigned to my test user when I thought I did.

      • David Hughey Reply

        My last reply is incorrect, I guess it’s too early in the morning. I think I fooled myself because the usages on the policy were doing what they were supposed to, but I haven’t proven this would work for masking call ID based on user’s subnet.

  6. Dave Murphy Reply

    Hi Richard,

    I came across this post because I was looking at specifics for LBR. Do you know if or how LBR would or could work in a VDI scenario where the customer wasn’t using the VDI plug-in. I am specifically wondering about client IPs and subnets and if Lync can handle this, for example if the Lync endpoint is not actually on a physical machine in India at the site the roaming user has gone to, but is on a VDI Server in Minneapolis still.

    Regards,

    Dave

  7. anon Reply

    Just to clarify, so no one else is misinformed: The PowerShell examples above, mainly referring to the below:
    Set-CsNetworkSite -Identity MinneapolisNetworkSite -EnableLocationBasedRouting $true -VoiceRoutingPolicy MSPvoiceroutingpolicy

    This means we are saying any one on the Subnet associated with the US Region/Site will have routing enforced via LBR, but what happens when a US user travels to the India Site is it not the India Subnets we should be setting this against ?

Leave a Reply

Your email address will not be published. Required fields are marked *