IP Corp > News > news > Microsoft Teams Dial Plan
  • George Goglidze
  • 2 Comments

by George Goglidze, CCIE #19926

Microsoft Teams Dial Plan

This is another blog from the how-to series, and the idea came to me as a colleague was asking me a question about the French dial plan. He was interested in how to set it up, and what are all the components required for a functional dial plan to well… function.

Few days after this conversation with a colleague, I was on another call with a larger audience, and the conversation was revolving around telephony within Microsoft Teams, and how there are not so many Microsoft Teams engineers that know well how to configure a dial plan as well as other aspects of Microsoft Teams architecture.

Therefore, I thought I’ll do this blog, design a simple dial plan, that will encompass most of the necessary components required for designing a country dial plan primarily for Direct Routing.

Here are the components necessary for a good dial plan architecture.

  • Dial Plans
  • Normalization Rules
  • Usages
  • Voice Routes
  • Voice Routing Policies

Some of the more obscure Dial Plan items, that are configurable only via Powershell. But we will not cover everything in this document. I want to keep this entry simple and easy to follow. If you require more information please comment and I will be happy to provide it separately.

  • SBC specific normalization rules
  • User and Conferencing policies / Restrictions

It does not look like a lot, and I always thought it was all quite straightforward. There are things in Microsoft’s architecture that I am not particularly fond of, but nevertheless, it’s a great system and as I thought easy to configure. But from the conversations I have been having recently, it seems like it may not be the case, and what I thought was common sense to me, maybe just ingrained transferrable knowledge from over 10 years of implementing other vendors telephony solutions.

In this blog, we are going to create an architecture for the dial plan of the United Kingdom, including but not limited to emergency, local, national, international, toll-free and premium dialling.

I will not talk much about actually implementing the Direct Routing, as I have already covered that in the blog entry:

https://ipcorp.co.uk/microsoft-teams-direct-routing-cisco-cucm-integration/

High-level overview

So how does it all work together? How does one go from voice routes to user policies? How does one know when a user picks up the phone, which route will be used? All good questions! Let’s see if I can find a good way to explain this, as it can be a little complex.

We will be working on the following network topology in this case.

Ok, so we have SBC in the Direct Routing. I’m assuming this is already configured in your environment.

Here we have our SBC configured and showing Active. (Well only one showing active in my case, as I do not actually have the second gateway.)

The first gateway sbc1.ccie.club is a local gateway in the London office, and the second gateway sbc2.ccie.club is the local gateway in the Birmingham office.

Dial Plan Architecture

The start of any good dial plan is the destinations that can be dialled. And these destinations at Microsoft Teams are called Voice Routes.

For the purpose of this dial plan, we will use an example of a company with two offices. One office in London and another say in Birmingham.

PSTN Usages

PSTN Usages play an important role in the configuration. This is what ties together the Voice Routing policy to the voice routes.

The best explanation for this is to compare the PSTN Usage to the Key.

Each PSTN usage is a key, that can open a specific door (Voice Route in our case).

And the Voice Routing Policy is the Keyring that holds the keys necessary for the specific policy. Then you give this keyring with all necessary keys to the user that needs access to those specific doors that those keys can open.

We will configure the following PSTN usage records for this:

Voice Routes

The following Voice Routes must be created.

You will notice that I’ve put +44 everywhere, even on the emergency routes. This is because how Microsoft Teams works. They will not allow any number out to the SBC without converting it to the +e164 number. This is of course wrong on Microsoft’s side, cause there are numbers that do not have +e164 equivalent, like emergency numbers or service numbers (118118 e.g.)

But because Microsoft Teams will add the country code according to where the user’s location is. We have to accommodate that in the voice routes.

After we have two ways to deal with this. One way would be to apply a normalisation rule to the SBC, stripping the +44 off to the numbers that do not need it, and the other would be to actually send it as is to the SBC and do some transformations on the SBC itself.

In my case, I will do all modifications on the SBC, so that I do not need to worry about it on Microsoft’s side.

So how does Microsoft Teams know which country code to add? Easy. It takes it from user’s location. If we go to Microsoft 365 admin centre  admin.microsoft.com, go to Users > Active Users, find your user and click on it, then go to Licenses and Apps and the location will be on the very top.

Voice Routing Policies

So the Voice Routing Policy is what you assign to a user. This is the part that holds all the Usages, as we said before in our analogy the usages are the Keys to the doors (voice routes), therefore by assigning Voice Routing policy to the user, we are giving him the keyring with all keys that he requires.

This customer has a business requirement for different levels of policies.

  • User with only Emergency dialling permissions
  • User with local, national and mobile dialling permissions
  • User with local, national, mobile and international dialling permissions
  • User with local, national, mobile, international and premium dialling permissions
  • User with Unrestricted dialling permissions

The following voice routing policies have been created:

Name PSTN Usages
UK London – Emergency ·      UK_Emergency_London
UK Birmingham – Emergency ·      UK_Emergency_Birmibngham
UK London – National ·      UK_Emergency_London

·      London_Local

·      UK_Landline

·      UK_Mobile

·      UK_Service

UK Birmingham – National ·      UK_Emergency_Birmingham

·      Birmingham_Local

·      UK_Landline

·      UK_Mobile

·      UK_Service

UK London – International ·      UK_Emergency_London

·      London_Local

·      UK_Landline

·      UK_Mobile

·      UK_Service

·      UK_International

UK Birmingham – International ·      UK_Emergency_Birmingham

·      Birmibngham_Local

·      UK_Landline

·      UK_Mobile

·      UK_Service

·      UK_International

UK London – Premium ·      UK_Emergency_London

·      London_Local

·      UK_Landline

·      UK_Mobile

·      UK_Service

·      UK_International

·      UK_Premium

UK Birmingham – Premium ·      UK_Emergency_Birmingham

·      Birmingham_Local

·      UK_Landline

·      UK_Mobile

·      UK_Service

·      UK_International

·      UK_Premium

UK London – Unrestricted ·      UK_Emergency_London

·      London_Local

·      UK_Unrestricted

UK Birmingham – Unrestricted ·      UK_Emergency_Birmingham

·      Birmingham_Local

·      UK_Unrestricted

So you will ask at this point, why are we duplicating the Voice Routing Policies? The answer is simple, usually, Emergency routing requires special routing only through the local gateway to the site. This means you need to send a call to the 999 for example only through the correct gateway where the user is homed. This is why pretty much every Class of Restriction above is duplicated so that the Emergency numbers are routed correctly.

Of course this above is just an example, and in real production, things can get even more complicated. For example, a centralised SIP Trunk implementation would be different, we may have the least cost routing implemented, and many other aspects of the business requirements may affect the architecture of the dial plan. But nevertheless the above should give you a good starting point to be able to design a dial plan for a large company with offices around the globe.

Escape code dialling

This is basically an unfortunate leftover from the old legacy world, with physical phones on every user’s desk. Where to dial an outside PSTN number, you would have to first dial an escape code, like 9 or 0 to cease the outside line.

Nowadays, all major players like Microsoft and Cisco (probably others too) are trying to push the industry to use +e164 numbers, which is great and provides for a neater dial plan. But unfortunately, we have to still cater for people’s older habits.

Lucky for you, this is fairly easy to accommodate.

We will make use of the Dial Plans section of Microsoft Teams and create a new dial plan.

Dial Plans

Usually, every country has a different PSTN escape code. In Europe, a 0 is quite common, but the UK uses 9 for this functionality.

Therefore I would normally create this per country.

The following was created for the UK.

For the moment this contains no normalisation rules, therefore accomplishes nothing. So let’s go and create normalisation rules.

Normalisation rules are the rules that transform the User’s dialled digits into the final digits that Teams will consider to match the voice route patterns.

Normalisation Rules

We add the following normalization rules.

Also in the normalisation rules, we can accommodate the extension dialling from one user to another.

For example, if the users were used to calling each other via the last 4 digits of their PSTN number, and the business for some reason wants to maintain that functionality.  Rule number 4 in the above was to accommodate that.

In my example, the DDI range of the users, in this case, are within the range +442010002XXX in London and +441210003XXX for Birmingham, and they were used to dialling each other via 2XXX and 3XXX only. So the rule number 4 and 5 will take any number within range 2XXX or 3XX and translate it to the full +e164 number, for example from 2001 to +442010002001

I hope this information was useful. If you would like me to cover something that you are struggling with let me know and I will write about it.

Leave a Reply

2 Comments

  • Adam

    Hi,

    I’m really struggling with the RegEx expressions that are used in Teams translations rules, I understand you’re matching using the expression in the “pattern” column, but in the translation column where you have $1 for some rules, what signifies if what you matched is prefixed or stripped away/replaced? Thanks for the excellent article.

    • Hi,

      $1 means the first instance of whatever is in the first set of brackets () in the regular expression. $2 would mean a second set of brackets.
      For example in the regular expression ^(\d{4})\d{4}(.)$ if you dialled 811155552
      $1 = 8111
      $2 = 2

      Hope this helps,