What Is Direct Routing for Microsoft Teams?
In This Article
Microsoft Teams Phone System provides traditional PBX functionality to Microsoft Teams, allowing users to make and receive phone calls over the Public Switched Telephone Network (PSTN). Direct Routing with Microsoft Teams allows customers to connect their existing on-premises telephony infrastructure to Microsoft Teams Phone System using a Microsoft-certified partner session border controller (SBC). Direct Routing is available world-wide and supports virtually any telephony carrier.
Microsoft Teams Phone System has been developed with native calling capabilities to allow organizations to replace their legacy on-premises PBX.
- Inbound & outbound PSTN calling.
- Custom dial plan and voice routing policies.
- Dynamic E911.
- Call hold, forward, transfer and simultaneous ring.
- Cloud voicemail.
- Auto attendants & call queues (hunt groups).
- Call park and pickup groups.
- Music on hold.
- Analog device and common area phones.
- Direct Routing uses a secure SIP trunk connection between Microsoft Teams and a Microsoft certified SBC deployed in the customer's on-premises network, or in a cloud-hosted service like AWS or Azure.
- The customer SBC is connected to the PSTN using existing carrier SIP trunks or TDM lines.
- Inbound and outbound calls flow between the customer on-premises SBC and Microsoft Teams via the Direct Routing SIP trunk.
Direct Routing benefits
- Leverages existing carrier contracts.
- Provides integration with legacy on-premises telephony infrastructure (PBX, call centers, analog devices etc.).
- Enables a phased voice migration from Skype for Business on-premises Enterprise Voice or other telephony platform to Microsoft Teams Enterprise Voice.
- Supports Media Bypass and Local Media Optimization to keep media traffic on net.
- Supports dynamic E911 for emergency calls.
- Provides location-Based routing for regulatory requirements in countries that have toll-bypass restrictions.
Direct Routing requirements
- Microsoft 365 or Office 365 E1, E3 or E5 license (Phone System Add-on License required with E1 or E3 licenses).
- New or existing connection to the PSTN (SIP or TDM) with direct inward dial numbers (DIDs).
- Dynamic E911 partner or ELIN gateway for emergency calls.
- Microsoft certified partner SBC (AudioCodes, Cisco CUBE, Ribbon Communications, Oracle).
- Public IP address, public DNS record and third party SSL certificate for each SBC connection to Microsoft Teams Direct Routing.
- Firewall rules to allow communication between the on-premises SBC and Microsoft Teams Phone System.
Supported end points
- All Microsoft Teams clients
- Common area phones
- Skype for Business 3PIP phones
- Each customer SBC connecting to Microsoft Teams for Direct Routing must be able to communicate with the Microsoft global Phone System FQDNs and IP addresses.
- TCP and UDP port must be opened to allow signaling and media traffic between the SBC and Microsoft Teams Phone System.
- It is highly recommended to configure quality of service on the network to optimize voice traffic.
Session border controllers
- Direct Routing is supported by major SBC vendors like AudioCodes, Cisco, Oracle and Ribbon Communications.
- SBCs are available in physical and virtual form factors.
- See a list of Microsoft supported SBCs.
Media bypass enables you to shorten the path of PSTN media traffic and reduce the number of hops in-transit for better performance. With media bypass, media is kept on net between the SBC and the Teams client, instead of sending it via the Microsoft 365 Cloud.
Call flow with media bypass
If the Teams client has direct access to the public IP address of the SBC, the call flow is as follows:
- Signaling traffic is routed between the Teams client and Microsoft Phone System.
- Media traffic is routed between the Teams client and the SBC public IP address.
- For media bypass, the Teams client must have access to the public IP address of the SBC even from an internal network. If direct media is not desired, the media can flow via Transport Relays.
- This is the recommended solution when a user is in the same building and/or network as the SBC -- remove Microsoft Cloud components from the media path.
- Signaling always flows via the Microsoft Cloud.
- The Teams client and the SBC must be configured in the same network location.
Without media bypass, when a client makes or receives a PSTN call, both signaling and media flow between the Teams client, Microsoft Phone System and the SBC. This can cause significant quality issues in networks which do not have sufficient bandwidth to support the real-time media packets for voice calls.
Call flow without media bypass
The diagram below shows the call flow for non-media bypass calls:
- Signaling and media traffic flow from the Teams client to Microsoft Phone System and back to the on-premises SBC.
Local Media Optimization (LMO) allows the Teams client to connect to either the private or public IP address of the SBC depending on where the user is located. When using media bypass without local media optimization, the Teams client must be able to connect to the public IP address of the SBC regardless of user location -- causing a traffic hairpin when users are making calls from within the corporate network.
LMO leverages the same location information services configuration used with location-based routing and dynamic E911, where the SBC is associated with a region, site and subnet. When a user makes a call from a subnet within the same site as the SBC, the Teams client routes the media traffic directly to the SBC private IP address. When the user is external, media traffic is routed via the SBC public IP address.
LMO for Direct Routing lets you manage voice quality by:
- Controlling how media traffic flows between the Teams clients and the customer SBCs.
- Keeping media local within the boundaries of corporate network subnets.
- Reducing voice network complexity by allowing media streams between the Teams clients and the SBCs, even if the SBCs are behind corporate firewalls with private IPs and not visible to Microsoft directly.
LMO supports two scenarios: centralized SBD and SIP trunks, and downstream SBC connect via a proxy SBC.
Centralize all local trunks through a centralized SBC connected to the main Session Initiation Protocol (SIP) trunk -- providing telephony services to all local branch offices of the company.
With downstream SBC, you can build a virtual network topology of SBCs -- where the SBCs in the local branch offices are connected to a centralized proxy SBC that is visible to, and communicating with, Microsoft Phone System through its external IP address. In a virtual network topology, downstream SBCs are communicating through internal IPs and are not directly visible to Phone System.
Questions or comments? Sound off in the comment section below and feel free to reach out to discuss your specific architecture.