Some of you may have been unlucky / lucky enough to work on global voice deployments that have encountered telephone regulations restricting the use of a flexible Unified Communications telephony network that is designed for least possible cost. The term LBR, of Location Based Routing to give it’s full name is a technology baked into the majority of UC systems that help keep organizations compliant with these laws.

Traditional LBR Implementation

In this example, we see a traditional implementation of LBR in action. A user in the Dubai Office wants to make a phone call to a person in the UK. The organization the user works for has a telephony gateway in the UK. Under normal conditions where there are no regulations, the organization can configure all outbound UK numbers to route through their UK gateway and therefore pay local rate call charges, instead of international rate. However, the UAE, amongst other nations have regulations that stipulate all international (and sometimes even provincial) numbers must route out of a gateway connected to the local telephone company network. This means the organization must force calls through this gateway when a user is in the Dubai Office. This is where LBR comes in.

As we move towards a cloud first telephony model, and in particular Teams, it presents some challenges within organizations that have been using traditional PBXs installed at various locations. In the old model, we had a number of PBXs we could configure for its individual site’s needs. In Teams we have one “PBX” type replacement that is used across all sites. As a result, there are some limitations to this concept and design.

Let me give you an example. An organization has 10 sites in the UK of various sizes. At each site there is a PBX of some description. The sites a physically protected by the Organization’s security team who are responsible for building and campus security and emergencies. The Organization has a policy that any employee can dial 3333 from any phone and get through to the security office personnel responsible for the site in which they are calling from.

How can you achieve this same experience in Teams, from desktop clients, to mobile and desk phone?

The first solution may meet most of your requirements depending on how mobile your workforce is. The simple solution would be to create a dial plan for the site that transforms 3333 into the local DID of the security office Teams Object, whether that is a single endpoint, an endpoint with team call group or even a Call Queue.

However, if you have a mobile workforce that float between sites, then how do you maintain continuity for them? Using the 1st approach, if the mobile worker dialed 3333 at a site that is not “home” to them, they would be connected to the wrong security office which will waste valuable time and even compromise the emergency they are calling about. IT cannot change dial plans in line with each transient move.

Another solution could be to create different emergency numbers at each site. Site 1 is 3333, Site 2 is 4444 etc. But this relies on users remembering and knowing these. Probably not a feasible solution.

But wait, don’t people search by name in Teams? Can we not just rely on that? Well, you could, but the same problem arises in what do users have to type in to get the lookup record they want? Typing a name also takes up valuable time, more if you have to use a desk phone or mobile. It’s also probably not an ideal solution.

You could compensate for this by creating your own Teams Directory App that lists clearly all the important contacts in your Organization, therefore all the user has to do is visually find the contact that applies and click to dial. Again, you’re limited to desktop client for this functionality currently and in emergencies people are going to want to dial a number from a physical phone in most cases.

So where does this leave us?

It leaves us with two viable options. Option 1 is to deploy a contact center where the 3333 number routes to that has a voice IVR that is capable of routing based on voice answers, e.g. Please tell me the site you are calling from? Answer: Cardiff. Then routes to the Cardiff site security office.

Or use LBR to route these calls to the local security office. From the outset, you would need a local SBC at each site. Whether you choose to connect them to local PSTN services or centrally is your choice. Looking at the SIP message received from Direct Routing, all client IP information is abstracted and replaced by Microsoft SBC FQDNs, so we are unable to rely on a conditional route based on the Client IP in the FROM Header. Shame.

Using LBR in this way would enable you to route the call placed to 3333 to any desired endpoint, whether that is in Teams or another PBX.

LBR used for Internal Routing Of Calls

In this example we have two sites, Cardiff and London. London is the main office and has an SBC connected to the PSTN via a chosen ITSP. Cardiff is a satellite site with no direct local PSTN access. Deploying an SBC here and connecting it downstream to the London SBC will allow Cardiff users to share the PSTN access with London, but also be leveraged for this use case.

Simon is a mobile worker and splits his time between both sites. We cannot rely on Simon’s SIP message information from pstnhub to determine location. The only reliable information we have is the client IP address used by his device and that is held only between the client and Microsoft Teams Back-end. So we have to look inside what we can do with Microsoft.

By using LBR and taking his client workstation IP we can determine which gateway to use based on this information allows Simon to dial 3333 at both sites and get through to local building security personnel.

In Teams each building security object would have it’s own unique DDI and the SBCs would transform 3333 into that local number and route back into Teams for lookup and dial tone. Any other number would be routed back to the London SBC for PSTN dial tone.

At first it seems an over engineered solution to an internal problem, but when global numbers are used to route to local services it is often very hard to change this approach. In all likelihood any organization of this size and complexity probably have a valid use case for local PSTN access too making this more cost effective. Smaller organizations may want to consider the options suggested earlier in this article first as they carry less investment.

However, it seems that Location Based Routing for Microsoft Teams is going to play more of a part in modern cloud telephony than it previously did with On-Premises. For more information about how to set up LBR for Microsoft Teams:
https://docs.microsoft.com/en-us/microsoftteams/location-based-routing-plan

Advertisements

Leave a Reply

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