What is right for your organization? Direct Routing, Microsoft Calling Plans or maybe Both?
Let's look at Direct Routing first. There are seven steps of planning Direct Routing.
Self-deployed vs. Hosted
Should you do a self deployed SBC (session border controller) or partner hosted SBC?
Self Deployed SBC
Benefits: You have full control over your SBC and you'll be able to use your existing PBX.
Disadvantages: You are responsible to configure your SBC and you'll need to purchase, maintain and host the device.
Partner Hosted SBC (basically the opposite of everything above)
Benefits: You won't need to purchase, maintain or host the SBC
Disadvantages: You don't have control over your SBC configuration and the support model could be more complex.
Understand the initial costs and if you have the technical support and expertise in house.
Licensing and Endpoints
To use Direct Routing with Teams, you will need a Microsoft Phone System License. If included in your plan, the Microsoft Teams plus Skype for Business Plan 2. It's important to note, even if you are in Teams Only mode, do not remove the MS Teams+SfB Plan2 license. Because even in Teams Only mode, some SfB components are being used.
Another license to consider is the Audio Conferencing License. This is not mandatory for Direct Routing, however this license gives users the ability to have a Dial-In number for their Microsoft Teams meetings.
Direct Routing supports endpoints on any Teams client, Common area phones and Skype for Business third-party IP Phones.
SBC
An SBC is needed to be the interface between Microsoft Phone System and Teams, and PSTN or legacy PBXs.
An SBC has 3 main functions: Connectivity, Security and Media Services.
An SBC can be a certified physical hardware device or software deployed in the cloud, such as Azure or AWS. To find a certified SBC for Direct Routing. Check this link out. https://docs.microsoft.com/en-us/MicrosoftTeams/direct-routing-border-controllers
This diagram shows how the SBC connects to Teams and Phone System to legacy PBX and PSTN systems.
The SBC must have a fully qualified domain name (FQDN)
Some requirements to think about when assigning a name:
You can't use the default domain name of your Microsoft tenant.
You must have at least one domain name to your Microsoft tenant. That way you can assign a valid name to the SBC.
A sub-domain name is not valid name unless you have registered the domain.
See the examples below.
Certificates
MTLS is used to communicate with SBCs, so you need to assign a digital certificate from a supported certification authority to each SBC device. This will be easy if you only have one SBC. Obviously, you will buy one certificate and assign it. A private certificate is the most secure. If you have more than one SBC, you can use a wildcard certificate and assign it to all devices. Its the most cost effective way, but almost the most non-secure way to do it. You could purchase a separate certificate for each SBC. But my recommendation would be to purchase one certificate and use it for all of your SBC. This is a trade-off between cost and security.
IP ranges and ports must be set correctly so the SBC can communicate with the Phone System being used.
This is best described as a visual.
Voice Routing. If you thought SBCs were fun...just you wait! Voice Time!!
There is a lot to cover when configurating voice to allow users to place calls.
There are three objects that work together to specify the class of service and calls of restriction for calls.
Voice routing policy
PSTN usage record
Voice route
A PSTN usage record specifies a class of call (internal, local, or international). The PSTN record is assigned to both a Voice Routing Policy and a Voice Route. A Voice Routing Policy is assigned to a group of users and a PSTN usage record. If a valid PSTN usage record can't be found the user or a voice routing policy be found, the call will fail. It is important to remember the PSTN usage records need to be in the correct order. If a number matches the first record, it will stop there. If it doesn't match, it will go in order of the records, until it finds one that matches. This is the same configuration of Skype for Business, so there shouldn't be any surprises for you. And of course, if it can't find a record that matches, the call fails.
In the Teams admin center, you'll find these settings in Voice->Voice routing policies->Teams Voice Route.
You will have remembered Dial Plans from Skype as well. A dial plan translates a shortened version of a number into one that adheres to E.164. The benefit of a dial plan is you can migrate to Teams without interruptions to your users habits (good or bad). There is a maximum of 1,000 dial plans per tenant and 500 normalization rules per dial plan. There are three types of dial plans:
Service dial plan->this can't be changed and is the same for everyone per country. For some companies the service dial plan will cover all their dial plan needs. (lucky dogs you).
Tenant global dial plan->this can be customized and it will affect all your users.
Tenant user dial plan->this can be customized as well, but you can assign user dial plans for specific users.
Take the below planning steps into consideration:
A couple of extra notes for Voice. Evaluate the volume of calls you currently have. You need to decide if you need multiple SBCs. To manage high loads, you can group multiple SBCs in a single voice route. For HA consider configuring voice routes so they are assigned a priority level. And of course Disaster Recovery. Voice routing policies can be configured to allow certain users to use specific routes. So if an SBC is the US aren't available, users could be routed to the SBCs in Europe.
Let's talk Media Bypass. Media bypass enables you to shorten the path of the media to go directly between the end user and the SBC, instead of sending it via the MS Phone System. Sounds great!! Right!? Well, it does come with limitations. This will only work if the SBC and client are in the same location or network. For media bypass to work, it must be enabled on the SBC. The Teams user must have access to the public IP address of the SBC, whether or not they're on the same network, unless you're using Local Media Optimization (next section).
See below for call flows with and without Media Bypass.
When media bypass is implemented, users inside the network need access to the public IP address of the SBC. The administrator has to configure a "hairpin", with the connection going out from the Teams client and back into the SBCs public IP address. You must also configure media processors and assign IP addresses for them. SBCs need to communicate with transport relays. Check below for the IP address requirements.
Local Media Optimization controls how media traffic flows between the Teams client and the SBCs. If you are not able to configure a "hairpin" (discussed above), you will need to configure local media optimization. When this is configured, the internal IP address of the SBC is used, rather than the external IP address. This means the SBCs can be behind a firewall and not necessarily seen by Teams.
So to finish up the Voice section of Teams. Here is a high-level of Direct Routing:
