Microsoft Teams Direct Routing FAQ
Are you interested in Microsoft Teams Direct Routing? If you are thinking about implementing it and have questions, then perhaps this list of questions I frequently get asked can help you on your way.
Your SBCs get added to a gateway list in Office 365. You can assign them a priority if you wish. When a priority is set, calls from Teams will attempt to be routed to the SBC with the highest priority if it is available.
If no priority is set, or the preferred SBC is unavailable, calls will be routed to the SBC in the list that last provided SIP OPTIONS to Microsoft.
You can have as many as you want. All you need to consider is how you handle fail over if a particular SIP trunk is down
Microsoft have a handful of destinations your SBCs must be able to reach over the internet.
Your SBC must be able to reach the following IPs on target port 5061/tcp
They must also be able to connect media ports to 22.214.171.124/14 on 49152:53247/udp
In the same manner, Microsoft must be able to reach your SBC SIP Signalling Port and Media Ports you define on your SBC
Strictly here in the context of the common area phone Office 365 SKU, the answer is no. However, you can use normal accounts with E1+Phone System Licenses or even direct SIP registration to the SBC itself for common area phone usage.
Call Queues and Auto Attendant services are a cloud supplied solution. At the moment there is no support to allow numbers assigned to these services to route through Direct Routing. They must be ported into Microsoft Phone System or use the default Microsoft number allocation.
You need a public certificate for your SBCs to communicate with Microsoft Teams. This is because encrypting signalling and media traffic over the internet is important to prevent eves dropping / wire tapping.
You can obtain certificates from any of the common signing authorities e.g. GoDaddy, GlobalSign etc. But the SBC must have both the public and private key of the certificate installed.
You can have one of three certificate types
- Single Domain SSL – this must be the public FQDN of the SBC the certificate will be installed on
- SAN Certificate – useful for multiple SBC deployments – each SBC FQDN must be a SAN on the certificate
- Wildcard Certificate – useful for cost savings in multiple SBC deployments
The maximum supported key length is currently 2048 bits.
Well this depends. In theory this is possible, but not practical in many cases. In order to get voicemail services to work, the user requires a phone system license. You would need to enable the user with a number in Microsoft Teams that doesn’t need to be a real number if you don’t need it.
You’d then have to configure a route between your existing system and the Direct Routing SBC for the number range you’ve chosen.
Once that has been done, you’d need to tell your users to configure their forward no answer settings to their Teams number. If they are not using Teams, this will forward directly to their voicemail service. If they were using Teams, they would get the call offered in Teams first before forwarding to voicemail.
One note here is that their voicemail will be delivered to Exchange Online, so this is a pre-requisite as well (or configure hybrid for on-prem SMTP delivery)
Currently as of this moment, the answer here is no. Service numbers including conferencing numbers are not supported via Direct Routing. Conferencing numbers must be ported into Microsoft or use the default service number allocation that Microsoft provide for conferencing with respect to Microsoft Teams
Currently Microsoft Support only Audiocodes and Sonus / Ribbon SBCs for Direct Routing. This is not to say you may get some success with others, but they’re not officially supported. Microsoft are implementing media bypass support and this requires the SBC to support ICE Lite. Currently only Audiocodes and Ribbon have this capability.
The answer is “it depends on your use case”
If you need to connect your on-premises VoIP solution to Teams so that your users can call between systems without breaking out over the PSTN, then yes you need direct routing for those internal voice calls.
If you are moving to Teams and calling plans as a business and do not need any interop between VoIP systems and Teams, then probably the answer is no here.
Sometimes however, it may be that you have multiple offices in different countries. Users in the UK may spend a lot of the time calling USA numbers. Providing international calling plans, or PAYG minutes could be expensive at scale. However, if you have a PSTN breakout in the USA office for instance, you could use Direct Routing to route USA bound numbers across your WAN using Direct Routing and pay a local rate charge instead of a calling plan that covers multiple destinations and a bunch of minutes you may not need.
Direct Routing uses voice routing policies. Therefore, if a called number matches a route pattern in the voice routing policy that is assigned to the user, the call will be routed via Direct Routing. If no match and the user also has a calling plan, the call will be routed through Microsoft’s PSTN network if the calling plan permits the called number (Domestic or International).
Direct Routing can be used for the following incoming calling scenarios:
- Direct Person Calling – The ability to call someone within your organization using their direct dial number. This may reach the intended person, but if unanswered, may forward to delegates or voice mail services
- Reception / Switchboard – The ability to call an office main number, speak to an agent and that agent can service your inquiry by way of transfer, hold or terminate
- Multi-platform Call distribution – The ability to use your investment to route calls to other telephony services within your organization not directly related to Microsoft Teams
Direct Routing can also be used to place outbound calls to any destination