Microsoft Teams Direct Routing is General Available as of June 28, 2018. This is the means for you to bring your own SIP trunk to Microsoft Teams. To be clear, this will only give your Teams users PSTN connectivity, your Skype for Business Online users still needs to use CCE or Skype for Business Server hybrid to get PSTN connectivity.
The goal of this article is to explain the basic around Direct Routing from an infrastructure point of view.
Licenses
- You need a Phone System License per user, which is part of Office 365/Microsoft 365 E5 or add-on for Office 365/Microsoft 365 E3
- Phone System is not available as add-on for Office 365 Business Premium or Microsoft 365 Business
- To get a phone number in Teams meetings, you need the Audioconferencing license per user, which is part of E5 and can added as add-on for E3 and Business SKU’s
Firewall ports and protocols
- To connect a sip trunk to Microsoft Teams, a SIP proxy is used.
- From your SBC to the SIP proxy you need always to use port 5061
- From SIP proxy to your SBC you can choose any port between 1024 – 65 6536
- I prefer to use 5061 since it is the same port as SIP proxy and it may be simpler in the long run
- Traffic needs to be open both ways
- You can limit the connectivity to the pstnhub.microsoft.com addresses specified below and the IP addresses they resolve to
- you should always use sip.pstnhub.microsoft.com as primary as it is a Global FQDN
- sip-all.pstnhub.microsoft.com is mentioned in the documentation and can be a possible source DNS name
- From your SBC to the SIP proxy you need always to use port 5061
- Media range is UDP between the ports 49 152 – 53 247
- 52.112.0.0 /14 (IP addresses from 52.112.0.1 to 52.115.255.254)
- Traffic needs to be open both ways
SBC requirements
- SBC is really easy to configure and have dramatically lower footprint in the datacenter than Skype for Business Server and CCE
- The SBC can be either AudioCodes or Ribbon, more certified SBC’s will be available at GA
- Documentation AudioCodes
- https://www.audiocodes.com/solutions-products/products/products-for-microsoft-365/direct-routing-for-microsoft-teams
- Guide to configure AudioCodes in Azure with Direct Routing by Lee Ford https://www.lee-ford.co.uk/deploying-an-audiocodes-sbc-in-azure-using-the-azure-marketplace/
- Documentation Ribbon
- https://ribboncommunications.com/solutions/service-provider-solutions/microsoft-solutions/direct-routing-service-providers
- Guide on how to configure Ribbon with Direct Routing by Damien Margaritis: https://dmunified.com/2018/05/18/configure-direct-trunking-to-microsoft-teams-with-ribbon-sbc-edge/
- Documentation AudioCodes
- To connect the SBC to the Microsoft Teams SIP Proxy you need three things
- Public IP, which is where the sip signaling will be routed
- DNS name, which resolves the public IP
- can be sbc.domain.com or more location specific, sbceu.domain.com or sbccountry.domain.com
- Public certificate from one of the providers listed below
- Wildcard is supported, easy to use if you have multiple sbc’s within same domain
- SAN certificate is supported
- Some SBC’s can only use one TLS certificate which means you need to update existing certificate with new name or make sure you add all TLS names your SBC is using
- You only need one certificate per tenant, not per sipdomain, as long as the certificate contains the names of all SBC’s connected
- The domain name for your connection does not need to be part of any of your sipdomains, it has nothing to do with any of your sipdomains
- NAT is not supported with Direct Routing, public IP address needs to be directly assigned to the SBC
- After you have prepared the FQDN and certificate and configured your SBC, you need to register it Office 365, read more here
Media Bypass internally
- The advantage of media bypass in a Direct Routing scenario where server is in the cloud is that media stays local and the media path is more optimal
- Media bypass is supported by AudioCodes and Ribbon
- needs to be configured specifically on SBC and enabled in Office 365
- both vendors support ICE light which is used for connectivity checks when finding optimal media path
- The clients need to be able to resolve and connect the public IP of the SBC
- traffic needs to be open both ways, same media ports are used
- requires hair pinning on NAT device
Media Bypass externally
- Media bypass is possible from clients logged on outside the corporate network
- The client needs to resolve the SBC FQDN and connect to the IP
- This results in allowing any IP as source ip on the media port range on the SBC
- Since only TLS connections are allowed, I think this is something that can be considered
- If the client cannot connect to the IP it will relay media via the SIP Proxy
Migrating to Direct Routing
Since CCE or Skype for Business Server cannot provide voice for Microsoft Teams, the only viable migration path is to introduce a SBC or configure the current SBC to connect to Microsoft Teams. From there you can start moving users by routing specific numbers and number series over to the new SIP trunk.
If you use direct SIP trunk with your Skype for Business Server today, then you can test Direct Routing by implementing a SBC and connect it to Microsoft Teams. Then provide a SIP trunk from Skype for Business using the inter trunk routing feature in Skype for Business Server, which allows you to move some test numbers to the SBC and Microsoft Teams. When you are ready to move to Microsoft Teams, you can switch the PSTN SIP trunk to go directly to the SBC.
Summary
When you have the correct approach from an infrastructure point of view, then you are ready to create PSTN usages and voice policies in Office 365. After that, users need to be enabled for enterprise voice and get assigned a number. Then you are ready to succeed with Microsoft Teams Direct Routing
References
- Official Microsoft announcement on Direct Routing Preview
- YouTube Video on deep dive Direct Routing preview
- Plan and configure Direct Routing official documentation
- Considerations for Microsoft Teams Direct Routing by MVP Mark Vale
- Great resource in German by MVP Frank Carius
msunified.net 
If you’re looking for an end to end configuration guide when using a Ribbon (Sonus) SBC Edge, check out my guide here: https://dmunified.com/2018/05/18/configure-direct-trunking-to-microsoft-teams-with-ribbon-sbc-edge/
Great, thanks for sharing, updated the article with link to your guide
Hei Ståle . Har du fått ordnet dette via en norsk leverandør?
Hi Ståle – you mention easy first step is to use inter-trunk routing and just have the SBC sit off the side of the mediation server – have you tried this?
I also thought this would be simple first option but I cannot get it to work – at least in my SfB hybrid model. When you have Teams user with telephony they need to be moved to Online which means in hybrid you need to move them off the on-prem SfB server. However, this leaves their phone number still registered on SfB server (which assumes they are a hybrid voice user) and I think this is a problem as inter-trunk routing will never occur as SfB checks via reverse lookup first for any users with that LineURI, before trying the PSTN usages. Would be interested in your thought on this?
I have not tried it, but I think you need to remove the number before you move the user to online, set him migrate teams only and then assign the number via direct routing, alternatively choose a new number for the users for PoC. It may also be a good idea that may not work in real life and it is more for a PoC anyway. Then the next step is placing the SBC in front of the Skype for Business server.
Hi Ståle,
We are looking into enabling 50+ sites with Teams and telephony via Phone System.
This will be done via the SBC from either AudioCodes or Ribbon. Each location will have their own SBC since they have their own local ISDN line.
But in regards to the SBC and Direct Routing – I can see that every SBC needs it’s own Public IP adresses and that’s an issue – Is their a workaround for this or do Microsoft have a special setup for this or have to do it?
Thanks
Hi Nikolaj,
My 5 cents on this. I would recommend moving away from distributed ISDN trunks and centralise on highly available SIP Trunks SBCs. This model would only require 2 public IP addresses, and would ensure you have high availability of telephony services in the event of a single site outage. If supporting “single number migration” for each site is important, I would combine the deployment of the central SIP SBCs with a “floating” SBC that moves site to site to support single number migration. Once all users have been migrated to Teams, the number range(s) for that site can be ported to the centralised SIP Trunks, and you can then move onto the next site you want to migrate to Office 365 Cloud Voice.
Hope this helps?
Hi Damien,
I think I need to add some more info for you :). If we look at these 50+ sites, then 30 of them have a Cisco UCCE contact center with local Cisco gateways and SRST (survival mode), so in case of MPLS breakdown, they are still able to receive calls to the Contact Center. So for these 30 sites it’s very important that they have a local ISDN or SIP trunk… The 20 other sites are Skype for Business only, so here we maybe could have a centralised SIP trunk – but in this case, I guess the media traffic will flow through the MPLS network? – Our Skype onprem. is located in Denmark today, but we have offices all around the world from Australia, USA, Japan, Chile etc. So if the office in Australia needs to have a media stream running from a SBC in Denmark, then we risk having a lot media across the MPLS network…
Today at the Cisco Contact Center sites, we also use Skype for Business, but have Media Bypass setup on Skype, so the local users just connect diretly to the local Cisco gateway, so it’s only the signalling that travels over the MPLS.
Hope that gives a better overview of the setup 🙂
Thanks
Hi Nikolaj,
Understood from your Setup and me too have similar requirements too. But the workaround will be to use Call routing features on Sonus SBC where we can route calls based on Called Party ( Origin). We may need to have multiple SIP trunk from Directing routing SBC to internal Cisco Voice Gateways directly.
So for example from Site A users in Team initiate a call, then it will reach SBC wherein we have to route calls based on Called Party to respective Gateway to route calls outside to show proper Caller ID.( OG Calls)
For incoming, we have to route calls from CUCM to SBC and to Microsoft Teams endpoint. Since we have CUCM and retain IP Phones, we may have to use remote profile feature in CUCM and route calls in E164 format to SBC and to Team. Multiple Hops 😦
Hi,
Is there a workaround to the Public IP pr. SBC?
If I need to install 10 SBC with Direct Routing, do I need to have a Public IP for each SBC?
Thanks
No workaround. Only way to reduce number of IPs is to set up sbc’s in HA mode, then it will be one ip per sbc group, but I guess you have 10 different locations, then HA is not an option
[…] “Microsoft Teams Direct Routing explained” […]
Have you guys tried a virtual machine as a SBC to avoid hardware involved just for the sake of connecting a SIP trunk to teams?
Yes, most sbc vendors now have virtual appliances that can run on local hypervizor or in Azure
Hello Damien
We are planing to deploy direct routing of MS Teams and we have Sangoma PBXact UC 100 Installed (Existing) with 8 FXO Trunk Lines.
Now, instead of having a E1/T1 or SIP trunk physically installed in an SBC we have analog POTS lines and they are installed into PBX.
We want to use Ribbon’s SBC SWe Lite for SIP Trunking between MS Teams that IP PBX
My question is can the calls be still routed via PBX? What about the inbound and outbound dialplan for Teams users? For example, if a PBX user receives an inbound call and wants to transfer it to Teams user via SBC, is it possible? Also, vice versa, if Teams user wants to have an outbound call what can be the number translation that would connect to an extension (on PBX from Teams) and what would we have to do in case the teams user wants to make outbound call instead of reaching out to just an extension on the PBX?
Hi. As long as the SBC is connected to the PBX via a siptrunk, you can use routing in the SBC to route the calls between internal users. I recommend having the routing logic built in to the SBC and do the standard normalization in Teams.