Microsoft Teams and Extension Dialing

Over the last few months, I’ve been working a few separate Direct Routing projects where customers have been moving away from Skype for Business and into Microsoft Teams.  Also, in their environments are 3rd party PBX systems like Cisco and Avaya where some users are still homed.  As we’ve seen over the years, those legacy systems have been configured in a way where everyone shares a main number with internal, private extensions.  As Skype for Business was introduced in those environments, that same numbering plan and dialing habits traditionally made its way into Skype as well so we had to use the format +1xxxxxxxxxx;ext=xxxxxx with the last six “x’s” as the extension.

When Skype Online CloudPBX with PSTN Calling Plans and then Teams Phone System with PSTN Calling Plans came along, that Main Number, Extension only method was quickly thrown out as the system does not support such methods.  Then came along Direct Routing, and the same situation applied, where extension only dialing did not work.  That presented challenges in trying to conform to E.164 Dial Plans, we had to stop using the format +1xxxxxxxxxx;ext=xxxxxx.   We as engineers had to resort to re-introducing bad habits where we had to assign short numbers to users and normalizing our calls to short extension only.  That goes against everything we’ve been taught by Microsoft over the last 8 years or so to normalize everything to unique E.164 phone numbers for users.  So, in summary, it was incredibly frustrating in those regards when deploying Microsoft Teams Enterprise Voice.

Fast forward to a few months ago when Microsoft quietly dropped in their Teams Version of “Skype for Business Trunk Translations”.  This allows Teams Voice Engineers to manipulate incoming and outgoing Phone Numbers at the integration point to the SBC.  This does a couple things of incredible value to Engineers and Support services when an organization does not have DIDs for all users and must integrate with a phone system where users use extension only.

1.) It allows most of the number manipulations to be completely owned in the Teams Ecosystem and allows SBCs to have minimal configurations.  So, essentially, a single point of voice administration for the most part

2.) It gives us the ability to use extension only dialing….  So we welcome back the +1xxxxxxxxxx;ext=xxxxxx phone number format in Teams.


So whoa, mind blowing, correct?  How does it work, you might ask?

We leverage “TeamsTranslationRules” and assign them to the SBC gateway in Teams.  Whats nice about how Microsoft designed this in Teams is they itemized the translations.  We clearly get to see and manipulate all 4 URIs in Teams.  Meaning we get to mess around with numbers in the following 4 scenarios;

  • Calling Number outbound to PSTN
  • Called Number outbound to PSTN
  • Calling Number inbound to Teams
  • Called Number inbound to Teams.

To read more about those rules, head over here to look them over

So, back to actually sending main number extensions only.  In summary, this is how it works

  • Assign users a LineURI with main number and extension only
    • +1xxxxxxxxxx;ext=xxxxxx
  • Create Dial Plans to normalize to to the main number, extension method.  Use the GUI or PowerShell

  • User TeamsTranslationRules to strip the +1xxxxxxxxxx;ext= and send only 6 digits when you need to send to a PBX with an extension only
    • New-csteamstranslationrule -id Location-RemoveExt -Pattern ‘^\+1xxxxxx\d{4};ext=(26\d{4})$’ -Translation ‘$1’       (***The numbers in this rule, is from another environment, so it doesn’t match the example, but you get the idea)
  • Do the same for any inbound manipulations to match an extension only Teams User sent from a PBX

How it looks in the client

There you have it, extension dialing back in Teams Direct Routing


A couple notes

  • This is not supported with calling plans.  You must assign DIDs
  • TeamsTranslationRules per Gateway in the tenant are limited to a total of 100 normalization rules across all 4 scenarios

Teams Emergency Calling – Demystified

As mentioned previously in my Location Based Routing blog, Teams is evolving quickly and has been “checking the boxes” to be a legitmate PBX contender.   When we left off with Skype for Business, most telephony requirements defined by organizations were being met with Skype for Business, but, just like that, as soon as we got to that point, Teams was the new “gotta have” shiny thing from Microsoft.  Since the inception of CloudPBX with Skype Online, the cloud voice system has been lacking in some of those “must have requirements”, but still I found myself involved in very large deployments moving organizations to CloudPBX.  With that said, however, I was constantly saying; “well, that feature isn’t available….yet”, mainly around Dynamic emergency calling (sorry Microsoft, but your first attempt with static locations, doesn’t count).

Now that Teams is ready for mainstream, I’d like to try and bring a little more clarity to the Dynamic Emergency Calling scenarios within Teams.  But first, there are few tidbits I’d like to point out from the Emergency Calling documentation that make me smile (I know most of my long tenured peers will agree)

  • The hated “+”

  • The triumphed return of “LIS”

As most are aware, Teams Voice capabilities can be configured in 2 different manners and depending on which you deploy in your environment, will affect how Emergency Calling is configured.  Those types shown here;

  1. Calling Plans using Microsoft PSTN Connectivity
  2. Direct Routing using your own SIP Trunks/PRI

These 2 options not only handle Dynamic emergency calling differently from one another, but also differently within each solution, depending on geographic location, especially within Calling Plans.  Confused yet?  Lets break down the madness

Reference material is here

In a subsequent blog, I’ll be detailing a more in-depth look at configurations.  However, to ensure this blog makes a little more sense when defining the differences between Calling Plans and Direct Routing Emergency Calling, the following items are things that need to be planned for and configured, which are subtly referenced through the blog.

Network Settings Containing…
    • Trusted Internet IPs
    • Network Regions containing network sites
    • Network Sites for each region
    • Network Subnets for each site
Location Information Services (LIS) network identifiers using…
    • LIS Ports
    • LIS Switch
    • LIS Subnets
    • LIST WAPs
Emergency Policies…
    • TeamsEmergencyCallRoutingPolicy
    • TeamsEmergencyCallingPolicy


With the parameters defined in the above table, we can now configure Microsoft Teams to define closer to where the user is located within a building.  Those terminologies are defined below:

Emergency Address A civic address–the physical or street address of a place of business for your organization.
A Place Typically a floor, building, wing, or office number. Place is associated with an emergency address to give a more exact location within a building. You can have an unlimited number of places associated with an emergency address. For example, if your organization has multiple buildings, you might want to include place information for each building and for every floor within each building.
Emergency Location A location is a civic address–with an optional place. If your business has more than one physical location, it’s likely that you’ll need more than one emergency location.
Registered Address (Legacy CloudPBX Solution) An emergency address that is assigned to each Calling Plan user; it is sometimes referred to as a static emergency address or address of record. (Registered addresses do not apply to Direct Routing users.)

Calling Plans Dynamic Emergency Calling Solution – Defined

So if you are deploying all Calling Plans, or some locations with Calling Plans, this section is for you.  All the summaries below are solutions that apply ONLY to Calling Plans.  Read carefully.

Emergency Call Enablement – When the emergency location is assigned to a phone number

Assign Emergency location… …To the phone number as soon as you assign it to a user in the… …United States
Assign Emergency location… …To the phone numbers as soon as you obtain numbers from Microsoft or port numbers to Microsof in… …Europe, The Middle East and Africa

Dynamic Emergency Calling – the routing of emergency calls based on current location of Teams Client

**At this time, only Calling Plans in the United States can leverage dynamic locations for routing emergency calls

If a Teams Client dynamically acquires an emergency location… …Route directly to PSAP in the… …United States Only
If a Teams Client does not dynamically acquire an emergency location… …Screen call before PSAP routing in the… …United States Only

Emergency Call Routing – How the call is routed to the PSAP

**If your country is not listed below, it is not documented on Docs

If a Teams Client is located in a tenant-defined dynamic emergency location… …Route directly to PSAP for users in the… …United States
If a Teams Client is NOT located in a tenant-defined dynamic emergency location… …Screen call before PSAP routing for users in the…. …United States
If an emergency caller is unable to update their emergency location to the screening center… …The call will be transferred to the users registered address for users  in the… …United States
Regardless of Teams Client location… ….Emergency calls are routed directly to the PSAP serving the emergency address associated with the number for users in… …Canada, Ireland and the UK
Regardless of Teams Client location… …Emergency calls are routed directly to the PSAP for the local area code of the number for users  in the… …France, German and Spain
Regardless of Teams Client location… …Emergency calls are routed directly to the PSAP for the local area code of the number for users  in the… …Netherlands
Regardless of Teams Client location… …Emergency addresses are configured and routed by the carrier partner for users in… …Australia
Regardless of Teams Client location… …Emergency calling is not supported for users in… …Japan


Security Desk Notification – The requirement to notify additional security of an emergency

Assign TeamsEmergencyCallingPolicy… …To a site.  The site policy is used to configure the security desk notification
Assign TeamsEmergencyCallingPolicy in addition… …To a user.  If a client is connected to an unidentified site, or not policy is assigned  to a site, the user account policy is used to configure the security desk notification
If the client is unable to obtain a TeamsEmergencyCallingPolicy… …The user is not enabled for security desk notifications

Direct Routing Dynamic Emergency Calling Solution – Defined

If you are moving forward with Direct Routing (I hope so!) All the summaries below are solutions that apply  ONLY to Direct Routing.  Read carefully.

Emergency Call Enablement – Requires the use of TeamsEmergencyCallRoutingPolicy to define emergency numbers and associated routing destinations

Assign TeamsEmergencyCallRoutingPolicy… …To a site.  This is the first lookup by a client to know where to route the call
Assign TeamsEmergencyCallRoutingPolicy in addition… …To a user.  This is the second lookup if a policy is not found for a site
If the client is unable to obtain a TeamsEmergencyCallRoutingPolicy… …The user is not enabled for emergency calling

Dynamic Emergency Calling Solutions- Requires a PSTN Usage within Direct Routing to the appropriate PSTN Gateway.  Routing to emergency services can be handled in 2 different manners

Emergency Routing Services Providers (ERSP) (US Only) A service provided by companies like “Redsky”
Emergency Location Identification Numbers (ELIN) An SBC configuration that is maintained by the organization requiring emergency services call routing

Emergency Call Routing – How the call is routed to the PSAP using Service Providers

If an ERSP is integrated into Direct Routing, a dynamicaly acquired location will be… …Routed directly to a PSAP serving that location for users in the… …United States Only
If an ERSP is integrated, but no dynamic location is acquired… …The call will be screened to determine the location prior to being sent to appropriate dispatch for users in the… …United States Only

Emergency Call Routing – How the call is routed to the PSAP using ELIN

**ELIN functionality is not limited to geographic locations

When an emergency call with a dynamically acquired location is routed to the appropriate SBC via PSTN Usages… …The ELIN Application does the following to appropriately route the call…
    • Parses the emergency location of the caller
    • Matches the location of the ELIN Record
    • Substitutes the emergency caller’s number with the ELIN Phone number
    • Routes the call to the PSAP serving the location and the dispatchers obtain the location from the uploaded ELIN record

Security Desk Notification – The requirement to notify additional security of an emergency

Assign TeamsEmergencyCallingPolicy… …To a site.  The site policy is used to configure the security desk notification
Assign TeamsEmergencyCallingPolicy in addition… …To a user.  If a client is connected to an unidentified site, or not policy is assigned  to a site, the user account policy is used to configure the security desk notification
If the client is unable to obtain a TeamsEmergencyCallingPolicy… …The user is not enabled for security desk notifications

In Summary

Emergency Calling scenarios are closely related to a.) Your PSTN Calling Solution of choice and b.) Your Geographic location.  I hope this adds a little more clarity to an already convoluted situation with Emergency Call Routing within Microsoft Teams.

Understanding Microsoft Teams Location Based Routing

Location Based Routing – Defined

Location Based Routing (‘LBR’), at its core, is the concept of ensuring long distance calls go in and out of the PSTN through a local carrier of a specific user that must adhere to regulations.  In some countries, this a telecommunication regulation which makes sure tolls are not bypassed so long-distance revenue is maximized.  The Location Based Routing feature from a Microsoft standpoint was first released with Lync Server 2013 and has now since been carried over to Microsoft Teams.  If you have experience deploying LBR in the Lync Server and Skype for Business days, you will likely see similarities with Microsoft Teams as the same “logic”, we’ll call it, is used with Teams.   That logic is nothing more than simply identifying users and SBCs locations via IP addressing and applying policies to such.

To learn more about LBR and calling scenarios that apply and don’t apply to LBR users, visit the following Microsoft docs site:

This article also assumes you understand Direct Routing .  If not, please review that as well:

Now, let’s get an understanding of LBR from the perspective of a few illustrations:

In the first illustration, we show that User 1 or User 2 is trying to call the US.  You can see the signaling of the user tells Teams “Try and use the SBC in the United States to make a call to Chicago”.  This would be against regulation as you tried to enter the PSTN local to Chicago, rather than out the local PSTN in New Dehli.   This is considered “Toll Bypass”.

This second illustration shows the appropriate path, in which is signaling tells Teams “if you want to call the US, you need to go out your local gateway, through the PSTN then into Chicago”.  This meets regulation and ensure tolls are going to be collected within India.

The third illustration simply shows how all calls should traverse the PSTN within the user’s respective locations.  Essentially, each location needs its own PSTN Gateway/SBC connected to the PSTN.


So now that we understand LBR, logically, the next question is;  How do we set it up?

Planning and Deployment

Out of the gates, It’s important to define the following requirements, which will then be configured within Teams in a table further down:

  • The Region
  • The Site within the Region
  • Network Subnet at each site
  • Trust external internet IP address for each site
  • The PSTN Gateways/SBCs in each site
  • *Any PBX’s that may be required to ensure Teams users can call PBX users, such as Cisco
  • Users in each site
  • PSTN Usage
  • Voice Routes
  • Voice Routing Policies

Now, let’s take a look at the fictitious scenario box detailing our setup in India, which is a heavily regulated country for LBR.    The scenario box ensures traffic flows how we expect in illustration 3 shown above.

**Image is clickable to expand

Once those requirements are gathered, you can begin configuring the sites and users for LBR.  Inside of the scenario box are associated commands that should be ran to setup LBR based on requirements.  To summarize, here are the steps

  • Gather all the requirements listed above
  • Configure PSTN Usages
  • Configure Online Voice Routing Policies for each site
  • Enable LBR for each network site
  • Enable LBR for each gateway/SBC
  • Grant the CsOnlineVoiceRoutingPolicy to users that must have LBR applied
    • Also, grant this to any user who roams to India or an LBR configured site
  • Enable the AllowCallingPreventTollBypass flag within the Teams Calling Policy for LBR Users
    • This also includes any roaming users

When users whom are enabled for LBR travel to sites enabled for LBR, the LBR enabled site takes precedents and forces calls through the local SBC

*If you have a required connection to a PBX for internal calling, you should have a separate Teams Registered FQDN/IP or separate SBC connecting to that PBX.  In this scenario, you DO NOT apply LBR to that registered SBC.  In the documented scenario above, represents this SBC connecting to a Cisco System in New Dehli as illustrated below:

I hope this helps and add’s a little more clarity to your understanding of LBR.

Comments and edit requests welcomed


Jason Sloan – Cyclotron Group

Do I need a functioning Skype Edge to move users to Online? No

Hello Readers.

Now that Microsoft Teams is full steam ahead, more and more organizations are moving away from Skype for Business On-Premises at a rapid pace.  With that, however, I’m seeing an abundance of companies that have broken Edge configurations where they are completely non-functional, or simply no Edge footprint at all.  The natural question is then “do I need an Edge to move users to the Skype Online or Teams”?  It really comes down to what your goals are, as an organization.  Let’s explore a few scenarios;


  • Scenario 1 – Is your organization considering different Interop modes?  Perhaps you want to move Skype/Teams Workloads to the cloud, rather than full migration.  Such as “Meetings First” where you keep Voice, essentially, tied to Skype for Business users on-prem.
    • Answer:  Yes, you need working Hybrid/Edge/Federation
  • Scenario 2 – Is your organization looking for a Greenfield Teams Deployment and have no desire to “migrate users”, so Buddy Lists and Meetings are not required to be migrated?
    • Answer:  No, you don’t need working Hybrid/Edge/Federation
    • Caveat:  Mass Migrations or Rapid migrations of users is recommended.  Users in Skype On-Prem will not be able to communicate with Teams Users
  • Scenario 3 – Is your organization looking to slowly migrate users and require back and forth communication between on-premises users and Teams Users?
    • Answer: Yes, you need working Hybrid/Edge/Federation
    • Caveat:  I don’t particularly recommend this approach as the hybrid communication between environments can be “buggy” and frustrating, for lack of better terminology
  • Scenario 4 – Is your organization looking to migrate all users rapidly or in mass but don’t want to fix or setup Hybrid/Edge/Federation?  And still need to migrate scheduled meetings and buddy lists?
    • Answer: No, you don’t need a true Edge, but you DO need to configure Hybrid/Federation.  I know, you are likely thinking… What??
    • Caveat:  You can’t move users back down or communicate with users on-prem from Skype Online or Teams – Plan to migrate everyone as quick as possible

To achieve the 4th Scenario, you still need to go through the Hybrid setup steps located here – Those steps are highlighted below

Configuration Steps

If you have an Edge and it’s broken, it’s likely broken due to firewall/ports or mis-configured certificates.  It can be a pain to get that remediated, both from a time standpoint and investment standpoint.  Simply skip fixing the Edge and walk through the Federation steps:

  • Set-CSAccessEdgeConfiguration -AllowOutsideUsers 1 -AllowFederatedUsers 1 -EnablePartnerDiscovery 1 -UseDnsSrvRouting
  • Get-CsHostingProvider | ?{ $_.ProxyFqdn -eq “” } | Remove-CsHostingProvider
  • New-CsHostingProvider -Identity Office365 -ProxyFqdn “” -Enabled $true -EnabledSharedAddressSpace $true -HostsOCSUsers $true -VerificationLevel UseSourceVerification -IsLocal $false -AutodiscoverUrl
  • Log into Skype Online and configure – Set-CsTenantFederationConfiguration -SharedSipAddressSpace $true
  • Once those are complete, move the users using the move-csuser command
    • Move-csuser -id -target -hostedmigrationoverrideurl
    • Just make sure whatever PC/Server you use to migrate users, that it has outbound connection to the hostedmigrationoverrideurl
  • The key here is that your Edge is found in the Topology

If you DO NOT have an Edge, follow the same steps, however, your very first step is to define a fake Edge Server in Topology.  It can have fake names and IPs, it doesn’t matter, just as long as it is defined.  If it is NOT defined, then entering the subsequent steps for setting up Hybrid will fail since the commands check for an Edge.

Once this is complete, you can safely move users, including their Buddy Lists and Skype for Business scheduled meetings.  Once the meetings make it to the cloud, they will be rewritten to a cloud conferencing meeting via Meeting Migration Service, as normal.

*Keep in mind – If you put a bogus Edge server in, make sure you don’t associate the Edge with a Front End pool for Media.

Special thanks to Trevor Miller (@TrevorAMiller) for talking this through with me

Jason Sloan – Senior Cloud Consultant

Leveraging Microsoft Edge Profiles

Hello Readers.  I hope you find this helpful!

As Microsoft continues to improve the new Edge browser, one of the newest features that I find the most helpful with the new Chromium based browsers, is the use of’ ‘Profiles’ within the browser.  It’s no secret that it can become incredibly problematic in the Microsoft ecosystem when trying to navigate through multiple tenants.  Either you have to use InPrivate browsing, you have to close browsers to end sessions (and pray that works), or you have to use different browsers;  all of these little nuances add up to a time suck.  As a consultant, i’m constantly in and out of customer browsers, in addition to demo tenants for testing purposes, so I’m always in a constant search to make this process easier.  Well no longer, since the Chromium based Edge browser has fixed it.

If you are using this for tenant management purposes, you simply start by adding adding a profile for each tenant and logging in accordingly from within the browser:

Once you add each profile, you will still need to set the homepage for each profile.  A common mistake is when you are adding a profile and doing it from the site, as an example, that first profile you signed in with may follow you to each profile you setup thereafter.  You may need to go into each profile after you set it up, sign into the portal then add that page to the “On Startup” browser setting:

Once it’s all complete, you’ll see multiple profiles in the window, and when you click on a profile to log in, it will open up a separate Edge window for each profile so you can work within multiple tenants at one time.

Who should use this feature:

  • Consultants who need to manage multiple tenants
  • Managed Service Providers who need to manage multiple tenants
  • Customers who may be leveraging demo tenants

This is not only a convenient feature to help manage multiple tenants, but I would consider it a safety feature as well.  It is very possible that if you are trying to work in multiple tenants the old way, that you could easily think you are in a test tenant and make a configuration change to a production tenant.  I recommend moving forward using the new Edge browser for this added benefit, alone.


Jason Sloan – Senior Cloud Consultant and Teams Voice Lead