Deploying Direct Routing for Microsoft Teams
I recently spoke at the European Teams User Group on how to plan and deploy Direct Routing for Microsoft Teams. Since this content has been presented, I have converted this information into a blog post for everyone to enjoy as the content of the presentation is extremely useful. This guide serves to explain why one would want to, what is required to, and how to deploy Direct Routing for Microsoft Teams.
This guide will be broken down into four main sections:
- Planning & Prerequisites
- Deploying Direct Routing
- Testing & Verification
- Troubleshooting
Planning & Prerequisites
What is Direct Routing and why should I care about it?
Direct Routing for Microsoft Teams expands the capabilities of the product, below features that it provides for customers:
Interop with third-party systems
- Allows companies to migrate users in groups from one phone system to another and provides interop between them.
- Integrates with third-party PBXes, analog devices, and Microsoft Phone System.
Leverage existing contracts with service providers
- Leveraging existing infrastructure would allow a much simpler migration path as the organizations do not have to migrate DIDs from one provider to another.
Single DID for every user
- This can be provided in Teams with a Calling Plan, however, it would be cheaper with more users as $12 a month is a VERY high cost.
Where calling plans are not available
- Calling plans are not available in certain countries so direct routing would allow users to leverage a local trunk.
Can be combined with Calling Plans
- Some users can use a calling plan license, or they can use direct routing. This can be mixed within the organization.
- Perhaps after a migration away from another phone system and a local SBC is used, the company may want to remove the need for the SBC and another vendor. Numbers can then be ported over to Microsoft/Bandwidth.
Less Hardware Footprint (Compared to Skype for Business)
- On-Prem servers for Cloud Connector Edition (CCE) is no longer required and only the SBC in a perimeter network is required
- Some organizations are deploying a software-based SBC in Azure to eliminate the need for any on prem infrastructure. (AnyNode)
When would one not want to use Direct Routing?
1. The organization does not want to manage any infrastructure as SBC’s require:
- Updates
- SSL Certificates
- Partner or internal employee for configuration changes/management
2. Small Businesses that have <25 employees may save money with a calling plan rather than managing a SBC
3. An extra layer for failure outside of Microsoft’s Control
- Calling Plans with MS Phone System is all within Microsoft’s cloud where the SBC does not
Infrastructure/Licensing Requirements
What do I need to get started?
- A Teams Certified SBC that is available via the edge (Own external IP Address)
Can be NATed based on the manufacturer of the SBC
- Telephony Trunks (SIP, POTS, Other PBX, etc)
- Office 365 Tenant with E3 w/Phone System or E5
- User homed in Office 365
- Dedicated domain with SSL certificate pointing to the SBC
Cannot use the .onmicrosoft domain as the SBC must be reachable via its own FQDN
Must be registered to the tenant
SSL Certificate must have the FQDN in the SAN or a Wildcard cert can be used
- Correct Firewall ports open – See TechNet
Where Should I deploy the SBC(s)?
The location of the SBC depends on the needs of the organization.
On premises connectivity to services directly (PSTN)
- Physical SBC from Audio Codes, Ribbon, etc.
On prem or in the cloud but connecting to a virtual SIP provider
- Virtual SBC from anynode, AudioCodes, etc.
- Appliances are available in the Azure store.
Branch Survivability
- If exploring a dual registration scenario for DR/HA, might be required for each site to have its own SBC.
- Teams uptime is 99.9%
Voice Routing
Dial Plans, Voice Policies, PSTN Usages, route like Skype for Business Server.
- Priorities for one PSTN usage can be set over another
- Some calls can be routed via direct routing trunks and some can be routed towards another trunk or Microsoft Calling Plan
- Useful for integration with a legacy PBX or other system
Needs need to be determined before implementation
Open to your imagination, but keep it simple if possible
Voice Routing Example
The below slide shows what happens when a user makes a call. There are many paths that the call can take this chart is a simple guide that explains the different ways calls can or cannot make it to their destination.
Deploying Direct Routing
Step 1: Deploy the SBC(s)
In this demo environment we are going to be using a virtual anynode SBC in a brand-new environment. There are no integrations with any other phone systems and calls will only be routing to one sip provider. This process will be different depending on the manufacturer of the SBC, but the end goal is the same. In the event that physical hardware is used, be sure that all necessary connections are made when deploying the device(s).
When configuring the SBC, be sure that the below items are configured correctly:
- SSL Certificate
- Connection to the PSTN
- All necessary firewall/DNS configurations
Step 2: Connecting to Skype for Business Online
At the time of writing, SBC’s cannot be paired to Microsoft Teams via the online GUI. This is potentially an upcoming feature, but I am not sure if this will ever come to the admin center. In order to pair the SBC to the tenant, a connection to Skype for Business Online PowerShell is needed. Follow the link below to setup the necessary prerequisites to connect to Teams Online/SFBO:
Installing the Microsoft Teams PowerShell Module
Now that the prerequisites are now satisfied, it is time to connect to Skype for Business Online. Follow the link below to get the commands needed to connect to Teams & SFBO.
Connecting to Microsoft Teams & Skype for Business Online via PowerShell using the new Teams Module
Step 3: Pairing the SBC to the Tenant
Now that the computer is connected to SFB Online, the process to pair the SBC to the tenant can begin. Looking at the below command, there are a few things to take into consideration:
New-CsOnlinePSTNGateway -Fqdn <SBC FQDN> -SipSignallingPort <SBC SIP Port> -MaxConcurrentSessions <Max #> -Enabled $true –MediaBypass $true
- <SBC FQDN> refers to the publicly accessible domain for the SBC.
- <SBC SIP Port> refers to the port that the SBC is listening on for SIP signals from O365.
- <Max #> refers to the maximum concurrent sessions that the SBC can handle. It is HIGHLY recommended to set this to prevent SBC fraud. This is optional.
- -Enabled setting this to $true will allow O365 to use this SBC for call routing.
- –MediaBypass setting this to $true will allow media to flow from the client directly to the SBC. This will only work if the SBC supports the feature. If it is not set it will be configured as $false
Below is an example of the command I used in my demo environment and a sample of the output received:
New-CsOnlinePSTNGateway -Fqdn az-sbc1.msftnettest.co -SipSignallingPort 5067 -MaxConcurrentSessions 20 -Enabled $true –MediaBypass $true
Now that the command has been ran, navigate to the Microsoft Teams Admin Center and verify that the SBC is showing under the “DIrect Routing” area under the “Voice” tab. Disregard any errors that may be shown as the SBC has not been used to make any calls in the past 24 hours.
Navigate to the configuration page of the SBC and verify that the States to Microsoft Teams Direct Routing is showing as “Active” and “Ok” (If using an anynode SBC).
Step 4: Enabling Users for Direct Routing
Since the SBC is now paired to the tenant, we can begin the process to enable users to use the new SBC for phone calls. One big thing does need to be addressed first and that is that the user must be homed in Skype for Business Online. If in the event the user is currently homed on-prem, the user needs to be moved to SFBO.
To verify where a user is homed, run the below PowerShell command:
Get-CsOnlineUser -Identity “<User name>” | fl RegistrarPool
Once the user’s home has been identified, he user can be enabled for Enterprise Voice, Voicemail, and have their phone number assigned. To do this, the below command will be ran per user:
Set-CsUser -Identity “<User name>” -EnterpriseVoiceEnabled $true -HostedVoiceMail $true -OnPremLineURI tel:<E.164 phone number>
- <User name> refers to the UPN of the user that you wish to edit the properties for
- tel:<E.164 phone number> refers to the E.164 format of the number needing to be assigned to the user.
Below is an example of the command I used in my demo environment and a sample of the output received:
Set-CsUser -Identity “Teams User1″ -OnPremLineURI tel:+13305768160 -EnterpriseVoiceEnabled $true -HostedVoiceMail $true
Note: There is a chance you may have to use the DN of the user instead of the name. Use the following cmdlet to retrieve this!
- Get-CsOnlineUser | select Alias,DistinguishedName
Step 5: Configuring Voice Routing
This part is where the needs of an organization come into play with how redundancy and other items are to be configured. This guide will be very basic since it is only a single SBC and trunk, but if information is needed for much more complex deployments, please refer to https://bit.ly/2Zum1da for more information. Follow the below four steps to configure voice routing:
1. Configure a PSTN Usage
A PSTN usage is a group of rule(s) that determines if a call is to be routed via one of its SBC’s based on its voice routes. Use the below command to create the first PSTN Usage. Name this what you would like.
Set-CsOnlinePstnUsage -Identity Global -Usage @{Add=”US”}
2. Build a Voice Route
Routes determine if the call should use the PSTN Usage or not and which SBC the call should be routed to. Use the below command to create the first voice route in the PSTN Usage. A catchall is used in this instance.
New-CsOnlineVoiceRoute -Identity “OH1-1” -NumberPattern “.*“ -OnlinePSTNGatewayList az-sbc1.msftnettest.co -Priority 1 -OnlinePstnUsages “US”
3. Creating a Voice Routing Policy
PSTN Usages cannot be directly assigned to a user so a Voice Routing Policy must be created. Use the below command to connect the PSTN Usage into the Voice Routing Policy(s).
New-CsOnlineVoiceRoutingPolicy “OH1” -OnlinePstnUsages “US”
4. Assigning the Voice Policy to Users
Now that the Voice Policy has been created, it can be assigned to users via PowerShell or via the Microsoft Teams Admin Center. In this environment, it is going to be set via PowerShell with the below command for two test users:
Grant-CsOnlineVoiceRoutingPolicy -Identity “TeamsUser1@msftnettest.co” -PolicyName “OH1”
Grant-CsOnlineVoiceRoutingPolicy -Identity “TeamsUser2@msftnettest.co” -PolicyName “OH1”
Note: An error may appear stating that “Policy “OH1″ is not a user policy. You can assign only a user policy to a specific user”. Ignore this, go do something else, come back in 30 minutes, and retry the process again.
Congratulations! Direct Routing for Microsoft Teams has been deployed! Move to the next section for information to test and verify that the configuration was successful.
Testing & Verification
To test each deployment, there is no one guide to verify that everything is working in an environment as some environments may have integrations with other phone systems with different dial strings. Below is a basic set of tests to run to verify that everything is working correctly:
- Verify that the Dialpad appears in the Teams Client
- Verify that calls can be made outbound
- Verify that calls normalize correctly
- Verify that inbound external calls are routed to the internal user
- Verify that Incoming calls route to voicemail
Troubleshooting
Some issues may occur during the deployment. Below are a few that may occur with their solutions. (I will try and keep this list updated if/when issues occur)
One Way Audio on External Calls
- Symmetric RTP is enabled Twilio will detect where the remote RTP stream is coming from and start sending RTP to that destination instead of the one negotiated in the SDP. This resolved the one-way audio issueTwilio is my SIP provider for my lab environment. There was a setting not set on the trunk to enable Symmetric RTP.
The error: “Policy “OH1″ is not a user policy. You can assign only a user policy to a specific user” appears when assigning a newly created Voice Policy to a user
- Due to the speed in which Office 365 replicates changes in the backend, there may be a bit of a delay when creating a new voice policy. Ignore this, go do something else, come back in 30 minutes, and retry the process again.
Special Thank You!
Leave a Reply