Two features that have been noticeably missing from Microsoft Teams are LBR (Location Based Routing) and dynamic location support for e911. Both have been available for on-prem deployments since the days of Lync. With this announcement https://techcommunity.microsoft.com/t5/Microsoft-Teams-Blog/Additional-Voice-Features-for-the-New-Year/ba-p/295062 LBR is now in preview and is expected to be generally available by the end of Q1.

What is LBR
In Skype for Business, users are assigned a voice policy. That policy links usages and routes. Together, these determine whether the user is permitted to call a number, and what path through the system the call will take. If William from New York is in his office and calls a customer down the street, that call will travel through the SfB system and exit to the PSTN in New York. If William travels to Los Angeles and calls that same customer, the call will flow back to the New York office (via the WAN if William is on the corporate network, otherwise via the Internet and Edge server) and will exit to the PSTN in New York.

In some countries, this type of routing isn’t permitted. When William is in Los Angeles, the call to his customer in New York must flow via the PSTN. There may also be restrictions on when you can blend PSTN and SIP calls in a conference. For example, you may be able to have PSTN callers join a SfB meeting, but only from one location. Thus, instead of call routing being done via the policies assigned to the user, we have Location Based Routing – the call routing is determined by the location of the caller.

In SfB, configuring LBR meant entering your IP subnets and assigning them to sites. Each site would then be configured to route PSTN calls via a particular gateway. Further policies within SfB would do things like block two PSTN sites from joining a conference.

The challenge in trying to build something like LBR in Teams versus in SfB comes down to the uniqueness of the IP address, which is used to establish the users location. In SfB, your office and favorite coffee shop might share the same IP subnet, however SfB knew if you were on the corporate network or not based on whether your client was connected directly to your Front-End pool, or was connecting via the Edge pool.

With Teams, the Edge and Front-End infrastructure isn’t there to help disambiguate the subnet that a user is on. Reading through the LBR documentation https://docs.microsoft.com/en-us/microsoftteams/location-based-routing-configure-network-settings we can see a new cmdlet

New-CsTenantTrustedIPAddress

This cmdlet lets you define your external IP address and assign them to your tenant. For example

New-CsTenantTrustedIPAddress -IPAddress 198.51.100.0 -MaskBits 30 -Description “HQ Internet”

When your Teams client or device traverses a NAT firewall and has a matching public IP, the tenant now knows that this Teams client/device is on an internal network, and it can apply LBR according to the internal subnets and sites that you’ve defined.

What about e911?

Emergency calling (e911) and LBR both require the same underlying technology to be able to identify a user’s location. With this basic foundation in place, we can likely expect to see subnet-based location policies for e911 soon. There’s still some additional work to be done, as at a minimum Teams will need to provide for masking/translating a user’s DID and replacing it with a number that’s unique to the location of the user when 911 is called.Subnets may not meet legal requirements for the granularity of the location that’s reported. In Skype for Business Server, there’s the LIS (Location Information Service) database and the ability to embed PIDF-LO (
Presence Information Data Format Location Object) – aka your location – into SIP packets. These allows a client to be located by the access point, switch port, or switch that they’re connected to. SfB Server talks to external LIS databases that may be provided by vendors like West or Redsky, who take on the task of determining the users location and providing it to SfB.

None of this functionality exists in Teams yet, and it’s all required to do proper granular, dynamic location determination for emergency calling, natively in Teams.