Home » Skype for Business » Skype for Business–Understanding Location Based Routing

Skype for Business–Understanding Location Based Routing

First I should note to you that this post will probably contain nothing new and fancy that cannot be found on other blogs historically regarding location based routing. The purpose of this is to summarise Location based routing (LBR) in my own words to remind me. If it helps you too, all the better! When researching this function Microsoft’s documentation on how to implement it is pretty procedural. By this I mean, it shows you how to enable it, but doesn’t really explain the implications or dependencies for it. Thank you to Ken Lasko’s (http://ucken.blogspot.co.uk/2013/06/location-based-routing-without-inbound.html) and Rich Brynteson’s (http://masteringlync.com/2013/02/21/location-based-routing-with-lync-server-2013-cu1/) blogs on filling in the blanks!

So with these in mind, I wanted to get to grips with LBR and understand when and where to use it.


Location Based Routing is the ability to route calls to specific voice gateways and ultimately specific PSTN connections based on the user’s physical location.

Why is this needed?

The use case for LBR has predominantly been marketed as a regulatory compliance feature. In some countries, such as India & UAE, bypassing the local PSTN providers in order make cheaper long distance calls is illegal. This specific scenario has a few names to describe it, Tail End Hop Off (TEHO) and Toll Bypass to name a couple. You may be thinking that perhaps this is the only reason why LBR is required and if you don’t have PSTN ingress/egress points in these countries then you don’t need to worry? However, there is a far wider use for LBR that is suprisingly overlooked as a use case.

What if you have your Skype for Business front end pool located in your HQ and you have a bunch of users in a branch office connected by a WAN link? This is a common scenario that doesn’t cause over concern beyond what is normal. However, for poorly connected branch sites where WAN bandwidth is at a premium, sending PSTN calls over the WAN link can have a serious impact on ultilisation. In these scenarios usually a Survivable Branch Appliance is deployed to mitigate this impact. When deploying an SBA, you home users located at the branch site to this registar and create voice policies that force these users to use the SBC on the SBA for PSTN ingress/egress which is fine. But what about those users who are based in the HQ and travel to the branch site regularly? These users would still register to the Skype for Business front end pool at HQ and also make/receive voice calls to the PSTN via the HQ gateways thus traversing the WAN. By implementing LBR you can accommodate these users by enforcing PSTN egress out of the branch SBC when these users are visiting the branch office to help manage the bandwidth utilisation over the company WAN.

How does LBR work?

Location Based Routing works by identifying the local subnet the Skype for Business client is using. This relies on Network Configuration settings in Skype for Business (Regions, Sites, Subnets). In order to support LBR the client must report a specific attribute within the SIP Invite Message that identifies the subnet it is calling from. The attribute is called ms-subnet and is reported like: ms-subnet=


If the client cannot send this attribute, the location cannot be determined and therefore LBR will not take effect. Similarly the subnet can only be identified of clients located in corpnet. Remote clients (signed in from mobile or via the Edge Server) cannot be identified and therefore LBR also cannot take effect.

Once the subnet has been reported, the network location, or network site is determined. This network site is assigned a specific PSTN usage(s) which overrides the usage priorities set on the user’s voice policy and enforces calls to egress out of the local voice gateway instead.

The end result is that when a user registered to the HQ Skype for Business front end pool logs in from a client within the HQ office, the call will egress out the HQ PSTN gateways using the normal PSTN usages configured in the user’s voice policy. However, when they travel to the branch site, when they make a call, LBR determines their location and forces the call to egress via the branch voice gateway.

Capabilities of LBR

Location Based Routing allows outgoing calls to a PSTN gateway that is local to the caller’s location. It also prevent incoming calls to the Skype for Business user if they are not physically at the PSTN gateway’s location. Remember, regulatory compliance is enforced for both incoming and outgoing PSTN calls. So a user from India with an Indian DDI for instance who travels to USA branch is not allowed to receive incoming calls to their Indian DDI while visiting the USA office. Similarly, while in the USA if the Indian user wanted to call a local number in Mumbai they would have to use the PSTN gateways in the USA and make a call that can be charged at international rate, rather than breaking out locally in India which charges local rate.

Single Call Behaviour under LBR

A user who has a DDI assigned and is enforced with Location Based Routing can expect the following behaviour to be normal. Their DDI will be routed by the ITSP to terminate at the local PSTN gateway at the user’s local office. When in the office the user can expect to make / receive calls via the local PSTN gateway in the same manner as a normal user.

When the user attends another company site, they will be able to make a call to the PSTN using the pool or another site’s local PSTN gateway, but may not use their home site gateway to make this call. When a PSTN users attempts to call the user whilst at another site, the incoming call will be refused as that would attribute to toll bypass.

Caller ID

One thing to be aware of when a user enforced with LBR visits a remote site, their caller ID (Calling Number) will be that of their DDI. Normally this is not a problem when the user is at their normal office. But when they are at another site this can pose a problem for call back. Remember if the PSTN user tries to call back the Skype user, the call will fail because of strict location policy enforcement. While there is not much we can do about this, we can work around the problem by providing the PSTN caller a method of call back. By using a dedicated trunk for LBR calls we can apply a unique set of translation rules to the trunk. Using the calling number translation rules to replace the Caller ID of the LBR user with the main office number of the site in which he is located at currently (e.g. HQ) This would allow the operator to transfer the call to the LBR user while at the HQ site.

Another reason Caller ID transformation is required is while at the remote site, the user would call with an ID from the branch site (e.g. Delhi number out of USA Gateway). In most cases the ITSP provider would reject the call because the Caller ID is not a DDI that the provider owns. (credit: ucwire)

In the below example I am translating any UK worker’s Caller ID (DDI) to a Delhi local number owned by the service provider in India


Conferencing with LBR

Regulatory compliance also effects PSTN conferencing. This restriction means that under LBR some conference configurations may be disallowed. This is usually when a conference contains mixed set of VoIP users from different sites and PSTN dial-out. For instance it is not acceptable to have PSTN dial out users when a conference contains VoIP users from any site. But if the VoIP users are all from the same site (where the LBR site has been defined) it is acceptable to have PSTN dial out endpoints. The following table outlines the possibilities when conferencing LBR is enabled

Users in Conference Users allowed to join Users not allowed to join
Skype for Business VoIP client users in single network site
  • Skype for Business VoIP Client user from same network site
  • Skype for Business VoIP Client user from different / unknown network site
  • User joining from a PSTN endpoint
  • None
Skype for Business VoIP client users from unknown or different network sites
  • Skype for Business VoIP Client user from same network site
  • Skype for Business VoIP Client user from different / unknown network site
  • User joining via a PSTN endpoint
Skype for Business VoIP client users from a single network site and users joining from a PSTN endpoint
  • Skype for Business VoIP Client user from same network site
  • Skype for Business VoIP Client user from different / unknown network site
  • User joining from a PSTN endpoint

Conferencing restrictions are only enforced if the meeting organiser has LBR enforced on their voice policy

Conferencing LBR must be enabled manually using the following PowerShell command

New-CsServerApplication -Identity Service:Registrar:<Pool FQDN>/LBRouting -Priority 3 -Enabled $true -Critical $true -Uri http://www.microsoft.com/LCS/LBRouting

Simultaneous Ring, Transfer and Boss/Admin behaviour with LBR

Conferencing LBR also handles restrictions on consultative transfer. This is where a PSTN user calls user A with LBR enforced and user A puts the caller on hold, calls User B in a different site and then attempts to transfer the PSTN caller to User B. In this instance the transfer would fail because it breaches toll bypass laws. However, if the SIP trunk routing the PSTN call is authorised to re-route to the gateway at User B site the call can be transferred.

The same behaviour can be expected for delegate ringing (Boss/Admin). Consider a scenario where a manager has delegated rights to a deputy manager and both are homed in the HQ site. The deputy manager then visits the branch site in Delhi. When the manager’s phone rings, the deputy manager would not receive the call. However, if the manager visited the Delhi branch, when call from th PSTN comes in to their DDI, the boss will not see the call, but the deputy manager who is at HQ site would. If the deputy manager then tried to transfer the call to the manager, then this would fail unless the call can be re-routed over the PSTN (credit: Richard Brynteson).

Response Groups

Agents who are bound by Location Based Routing could violate regulatory compliance in hunt groups / IVR workflows of response groups if the telephone URI for the response group is not routed by the PSTN gateway at the same site as the agent. If this is required, the site may need a local Front End Server pool in order to reduce WAN bandwidth.

LBR When Compliance Not A Concern

Even without compliance reasons, implementing LBR can reduce WAN ultisation and improve call quality. For calls with no gateway local to the called party, select a gateway local to the calling party. You can still configure Least Cost Routing (LCR) in this manner by assigning least cost PSTN usages a higher priority in the site’s voice routing policy. When using LBR for PSTN optimisation it is important to “turn off” the strict compliance for inbound calls. By turning this feature off allows the user to receive calls to their DDI from the PSTN regardless of which site they are currently located. This can be done by disabling LBR on the PSTN trunks using the following PowerShell command (credit: Ken Lasko).

Set-CsTrunkConfiguration –Identity:”Service:PSTNGateway:<trunk>” –EnableLocationRestriction:$FALSE

What about LBR when Remote

When a user who is enabled for LBR is external (i.e. connected from home) the user’s location cannot be determined and therefore LBR cannot be enforced. In this scenario the calls will be controlled by the user’s voice policy and PSTN usages rather than by the network site. Therefore, a user in Delhi, who works from home would need a voice policy that forces them to use the Delhi PSTN gateway for all calls. This has the disadvantage if this user travels a lot because they would not be able to benefit from Least Cost Routing as they would alway attempt to use the Delhi gateway. In this case it is better to configure these users with a datacenter gateway (HQ) rather than over-burden a WAN link.

What about Emergency Calling

Location Based Routing does not apply to Enhanced 911. If a user dials an emergency number the call will route according to the PSTN usage assigned to E-911 location policy, LBR is ignored. If you attempt to use LBR instead of Enhanced 911, then the Presence Information Data Format Location Object (PIDF-LO) used for civic location is not used / does not exist! Instead use Enhanced 911 for real emergency calls to service provider / ELIN gateway and LBR for all other internal desks (e.g. security desk).

Key Points to Remember

When using LBR the site routing policy must include a route for all possible calls. If there is no route defined for a particular dial string normally allowed in the user’s voice policy in the network site routing policy, the call will be blocked.

To implement LBR, trunks have a 1:1 with a network site relationship so they are represented as one campus site.

Design your usages and routes to exclude any trunks to legacy PBX systems you may inter-operate with internally

Calculate your SBC licences to take into account LBR routing. Remember you may have 20 concurrent calls normally in a particular location under normal conditions, but 5 people travel to that site, could increase the concurrency to 21-25 meaning you don’t have the capacity to support travelling workers (credit: ucwire).

Testing LBR (Strict)

My test user is located in subnet which is assigned to a network site called Delhi. Delhi has a voice routing policy assigned to it called IN-DEL-LBR. image

The routing policy allows a single PSTN usage called IN-DEL-PSTN


The IN-DEL-PSTN usage is assigned to the IN-DEL-PRI voice route. This route stipulates that all calls regardless of destination can route out of the following gateway: IN-DEL-P1


For inbound call enforcement the trunk IN-DEL-P1 trunk is configured to enforce Location Restrictions and assigned to the Delhi Network Site


Looking at my user’s voice policy PSTN usages I can see that I have multiple uses, with the IN-DEL-PSTN usage being the last in priority I should use for making calls


Checking the voice route priority I can see that IN-DEL-PRI is the least preferred route. So when outside of an LBR enforced location I should be able to use the UK-CRE-Primary or UK-CRE-Secondary route in order to make a UK call


When making a test call I am using a fake UK PSTN number to simulate e.g. +441270826610 which routes via my SBC to a Internal SIP phone directly registered to my SBC. But the principal is the same.

Here we can see the initial SIP INVITE message. We can identify the subnet the user is calling from using the ms-subnet attribute


In the progress report we can see that the local mediation server the user is assigned to identifies that the call should be routed by the IN-DEL-PSTN usage and via the IN-DEL-P1 gateway, but for this to occur, the mediation must negotiate with the mediation server at the branch


Once negotiated the branch mediation server sends an invite out to the local SBC over the LBR trunk defined in the Network site voice routing policy rather than using the user’s PSTN usage policies or priorities


Now lets make the same call with the same user, this time from a location not defined in LBR. Here we can see that the ms-subnet has been identified as which is assigned to a site that has no voice routing policy


Here we can see that the same call is now routed via the UK-CRE-P1 trunk attached to the Pool-A-Default-PSTN usage


Testing Emergency number. In Delhi the Police number is 100 and we have declared this in the Location Policy


Here we can see the PSTN usage for the emergency number is INDIA-ELIN-PSTN usage. This will route emergency calls out to the ELIN gateway (in my lab Gateway:labsbc.hostedhouse.local) rather than the LBR route IN-DEL-PRI


Configuring LBR

Lastly to configure Location Based Routing you can follow these steps

  1. Define a network region
  2. Define a Network site that you want LBR enabled for
  3. Define a subnet and assign it to a network site
  4. Create a new trunk configuration for your location specific PSTN Gateway
    New-CsTrunkConfiguration –Identity “Service:PSTNGateway:<TrunkName>”
  5. Enforce trunk location restrictions and assign to Network site
    Set-CsTrunkConfiguration –Identity “Service:PSTNGateway:TrunkName” –EnableLocationRestriction $True –NetworkSiteID “SiteName”
  6. Create a user voice policy that contains all the required PSTN usages and routes the user can use. Include the PSTN usage you are going to enforce on the location policy
  7. Create a new Voice Routing Policy for the LBR location
    New-CsVoiceRoutingPolicy –Identity “SiteRoutingPolicyName” –PSTNUsages @{add=SitePSTNUsage}
  8. Now apply this routing policy to the network site
    Set-CsNetworkSite –Identity “NetworkSiteName” –VoiceRoutingPolicy “SiteRoutingPolicyName” –EnableLocationBasedRouting $true
  9. Now we need to prevent toll bypass on the user voice policy
    Set-CsVoicePolicy –Identity “UserPolicyName” –PreventPSTNTollBypass $true
  10.   Lastly, we need to enable LBR globally
    Set-CsRoutingConfiguration –EnableLocationBasedRouting $true


  1. Hello Mark. Thank you for the article. I’m quite new to setting up regions and Bandwidth Policies so I’m wondering if you would be able to answer probably this simple question. We still use Lync 2013 Enterprise Edition.

    You article mention only about PSTN and Voice features.
    My question is if the Bandwidth Policies also apply to Standard Lync Client Conferences.

  2. Hi Mark

    Step 6 you mentioned: “Include the PSTN usage you are going to enforce on the location policy”
    If the VoiceRoutingPolicy is overriding the UserVoicePolicy, then this seems redundant to me.
    If the user is in any non-LBR location, then surely they would only require the non-LBR PSTN usages. Any LBR site PSTN usage would not be allowed. When this same user “visits” the LBR site, then the user will make calls using the VoiceRoutingPolicy (which will include the LBR site PSTN usage with local routes and local gateways.

    Am I missing something here?

    Great article BTW!

    • Thanks Jason

      I understand where you are coming from. However, with my testing and implementations if users do not have the PSTN usage assigned to them for a LBR site, the call will fail. By assigning PSTN usages to the site, in effect just enforces those ones in the users PSTN usage list. Perhaps bad wording on my part.

  3. Hi

    Firstly great post, really useful info.

    I’m currently deploying location based routing in Bangalore, India and have a question about the following scenario.

    Each user has voice policy assigned with LBR enabled. All the subnets are defined and confirmed that LBR is working.

    I’m confused about the following:

    User in Bangalore office places a PSTN call > call connects via Bangalore SBC > all good.

    User then decides he needs to add in a 2nd PSTN call > user clicks invite more people and tries to add 2nd PSTN number to the call but gets “Cannot be reached” error

    Should this scenario work or is it restricted?

    Many thanks

    • Hi


      When the user adds a 2nd caller into the mix, it becomes a conference, then if you have enforced conferencing LBR then it adheres to the scenarios in the conference table. The 2nd PSTN caller – is that an external contact? i.e. someone not in another site? If they are really a user within your site, then i would expect the scenario to fail. The reason because you would have effectively patched a bangalore caller through to a sfb user in say USA, which in effect is toll bypass, even if you are the one hosting the conference.

      • Thanks for the swift reply.

        The 2nd PSTN caller is an external contact.

        So 1 internal user in Bangalore and 2 PSTN numbers.

        If a PSTN number dials IN to the meeting it works but if the user in Bangalore tries to dial OUT to a telephone number they get cannot be reached.

        By design do you think or should this work?

        Thanks again

      • Good question, I am not sure if toll bypass is that intelligent to figure out that both pstn numbers maybe from different regions? therefore, prevented in the same way as the patching call through scenario. Maybe.. What does snooper say?

        Also can you dial out to PSTN caller 1 in a conference / meet now?

        Can pstn caller 2 dial in, the same as pstn caller 1 at the same time?

  4. If we do a meet now and dial out to a PSTN caller we get the same error, “cannot be reached”

    In snooper I’m seeing:
    “The user is not authorized to call the specified number or none of the routes have a valid gateway configured”

    It would seem logical to me that this should be allowed as the call is still using the gateway in the same location as the user and the MCU so would be good to get your thoughts.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.

%d bloggers like this: