Plan for media bypass with Direct Routing
About media bypass with Direct Routing
Media bypass enables you to shorten the path of media traffic and reduce the number of hops in transit for better performance. With media bypass, media is kept between the Session Border Controller (SBC) and the client instead of sending it via the Microsoft Teams Phone. To configure media bypass, the SBC and the client must be in the same location or network.
You can control media bypass for each SBC by using the Set-CSOnlinePSTNGateway command with the -MediaBypass parameter set to true or false. If you enable media bypass, it doesn't mean that all media traffic will stay within the corporate network. This article describes the call flow in different scenarios.
The diagrams below illustrate the difference in call flow with and without media bypass.
Without media bypass, when a client makes or receives a call, both signaling and media flow between the SBC, the Microsoft Teams Phone System, and the Teams client, as shown in the following diagram:
But let's assume that a user is in the same building or network as the SBC. For example, assume a user who is in a building in Frankfurt makes a call to a PSTN user:
Without media bypass, media flows via either Amsterdam or Dublin (where Microsoft datacenters are deployed) and back to the SBC in Frankfurt.
The datacenter in Europe is selected because the SBC is in Europe, and Microsoft uses the datacenter closest to the SBC. While this approach doesn't affect call quality due to optimization of traffic flow within Microsoft networks in most geographies, the traffic has an unnecessary loop.
With media bypass, the media is kept directly between the Teams user and the SBC as shown in the following diagram:
Media bypass uses protocols called Interactive Connectivity Establishment (ICE) on the Teams client and ICE lite on the SBC. These protocols enable Direct Routing to use the most direct media path for optimal quality. ICE and ICE Lite are WebRTC standards. For detailed information about these protocols, see RFC 5245.
Call flow and firewall planning
Call flow and firewall planning depend on whether the user has direct access to the public IP address of the SBC, and whether the user is inside or outside of the network.
Call flow if the user has direct access to the public IP address of the SBC
If the user has direct access to the public IP address of the SBC, the call flow is as follows:
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 isn't desired, the media can flow via Transport Relays.
This flow 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 following diagram shows call flow when media bypass is enabled, the client is internal, and the client can reach the public IP address of the SBC (direct media):
The arrows and numeric values of the paths are in accordance with Microsoft Teams call flows.
The SIP signaling always takes paths 4 and 4' (depending on the direction of the traffic). Media stays local and takes path 5b.
Call flow if the user doesn't have access to the public IP address of the SBC
The following scenario describes call flow if the user doesn't have access to the public IP address of the SBC.
For example, assume the user is external, and the tenant administrator decided not to open the public IP address of the SBC to everyone in the Internet, but only to the Microsoft Cloud. The internal components of traffic can flow via the Teams Transport Relays. Consider the following:
Teams Transport Relays are used.
For media bypass, Microsoft uses a version of Transport Relays that requires opening ports 50 000 to 59 999 between the Teams Transport Relays and the SBC (in the future we plan to move to the version that requires 3478-3481 ports).
The following diagram shows call flow when media bypass is enabled, the client is external, and the client can't reach the public IP address of the Session Border Controller (media is relayed by Teams Transport Relay).
The arrows and numeric values of the paths are in accordance with Microsoft Teams call flows.
Media is relayed via paths 3, 3', 4 and 4'.
Call flow if a user is outside the network and has access to the public IP of the SBC
Note
This is not a recommended configuration because it does not take advantage of Teams Transport Relays. Instead, you should consider the previous scenario where the user does not have access to the public IP address of the SBC.
The following diagram shows call flow when media bypass is enabled, the client is external, and the client can reach the public IP address of the SBC (direct media).
The arrows and numeric values of the paths are in accordance with the Microsoft Teams call flows article.
The SIP signaling always takes paths 3 and 3' (depending on the direction of the traffic). Media flows using path 2.
Use of Media Processors and Transport Relays
There are two components in the Microsoft Cloud that can be in the path of media traffic: Media Processors and Transport Relays.
The Media Processor is a public facing component that handles media in non-bypass cases and handles media for voice applications.
Media Processors are always in the path for end user non-bypassed calls, but never in the path for bypassed calls. Media Processors are always in the path for all voice applications such as Call Park, Organizational Auto Attendant, and Call Queues.
The Transport Relay is used to connect to the closest Transport Service to send real time traffic.
Transport Relays might or might not be in the path for bypassed calls--originating from or destined to end users--depending on where the user is and how the network is configured.
The following diagram shows two call flows – one with media bypass enabled and the second with media bypass disabled.
Note
The diagram only illustrates traffic originating from--or destined to--end users.
The Media Controller is a microservice in Azure that assigns Media Processors and creates Session Description Protocol (SDP) offers.
The SIP Proxy is a component that translates HTTP REST signaling used in Teams to SIP.
The following table summarizes the difference between Media Processors and Transport Relays.
| Media Processors | Transport Relays | |
|---|---|---|
| In media path for non-bypassed calls for end users | Always | If client can't reach the Media Processor directly |
| In media path for bypassed calls for end users | Never | If client can't reach the SBC on the public IP address |
| In media path for voice applications | Always | Never |
| Can do transcoding (B2BUA)* | Yes | No, only relays audio between endpoints |
The IP ranges are:
- 52.112.0.0/14 (IP addresses from 52.112.0.0 to 52.115.255.255)
- 52.120.0.0/14 (IP addresses from 52.120.0.0 to 52.123.255.255)
Note
IP ranges presented in this document are specific to Direct Routing and may differ from the ones advised for Teams client.
* Transcoding explanation:
Media Processor is B2BUA, which means it can change codecs (for example, SILK from Teams client to MP and G.711 between MP and SBC).
Transport Relays aren't B2BUA, which means the codec is never changed between the client and the SBC--even if traffic flows via relays.
Use of Teams Media Processors if trunk is configured for media bypass
Teams Media Processors are always inserted in the media path in the following scenarios:
- Call is escalated from 1:1 to a group call
- Call is going to a federated Teams user
- Call is forwarded or transferred to a Skype for Business user
Ensure your SBC has access to the Media Processors and Transport Relays ranges as described below.
SIP Signaling: FQDNs
For SIP signaling, the FQDN and firewall requirements are the same as for non-bypassed cases.
Direct Routing is offered in the following Microsoft 365 or Office 365 environments:
- Microsoft 365 or Office 365
- Office 365 GCC
- Office 365 GCC High
- Office 365 DoD
Learn more about Office 365 and US Government environments such as GCC, GCC High, and DoD.
Microsoft 365, Office 365, and Office 365 GCC environments
The connection points for Direct Routing are the following three FQDNs:
sip.pstnhub.microsoft.com – Global FQDN – must be tried first. When the SBC sends a request to resolve this name, the Microsoft Azure DNS servers return an IP address pointing to the primary Azure datacenter assigned to the SBC. The assignment is based on performance metrics of the datacenters and geographical proximity to the SBC. The IP address returned corresponds to the primary FQDN.
sip2.pstnhub.microsoft.com – Secondary FQDN – geographically maps to the second priority region.
sip3.pstnhub.microsoft.com – Tertiary FQDN – geographically maps to the third priority region.
You must place these three FQDNs in order to:
Provide optimal experience (less loaded and closest to the SBC datacenter assigned by querying the first FQDN).
Provide failover when a connection from an SBC is established to a datacenter that is experiencing a temporary issue. For more information, see Failover mechanism below.
The FQDNs sip.pstnhub.microsoft.com, sip2.pstnhub.microsoft.com, and sip3.pstnhub.microsoft.com will be resolved to IP addresses from the following subnets:
- 52.112.0.0/14
- 52.120.0.0/14
You need to open ports for all these IP ranges in your firewall to allow incoming and outgoing traffic to and from the addresses for signaling.
Office 365 GCC DoD environment
The connection point for Direct Routing is the following FQDN:
sip.pstnhub.dod.teams.microsoft.us – Global FQDN. As the Office 365 DoD environment exists only in the US data centers, there are no secondary and tertiary FQDNs.
The FQDN sip.pstnhub.dod.teams.microsoft.us will be resolved to an IP address from the following subnet:
- 52.127.64.0/21
You need to open ports for all these IP ranges in your firewall to allow incoming and outgoing traffic to and from the addresses for signaling. If your firewall supports DNS names, the FQDN sip.pstnhub.dod.teams.microsoft.us resolves to all these IP subnets.
Office 365 GCC High environment
The connection point for Direct Routing is the following FQDN:
sip.pstnhub.gov.teams.microsoft.us – Global FQDN. As the GCC High environment exists only in the US data centers, there are no secondary and tertiary FQDNs.
The FQDN sip.pstnhub.gov.teams.microsoft.us will be resolved to an IP address from the following subnet:
- 52.127.88.0/21
You need to open ports for all these IP ranges in your firewall to allow incoming and outgoing traffic to and from the addresses for signaling. If your firewall supports DNS names, the FQDN sip.pstnhub.gov.teams.microsoft.us resolves to all these IP subnets.
SIP Signaling: Ports
Port requirements are the same for all Office 365 environments where Direct Routing is offered:
- Microsoft 365 or Office 365
- Office 365 GCC
- Office 365 GCC High
- Office 365 DoD
You must use the following ports:
| Traffic | From | To | Source port | Destination port |
|---|---|---|---|---|
| SIP/TLS | SIP Proxy | SBC | 1024 - 65535 | Defined on the SBC |
| SIP/TLS | SBC | SIP Proxy | Defined on the SBC | 5061 |
Media traffic: IP and Port ranges
Media traffic flows between the SBC and Teams client if direct connectivity is available or via Teams Transport Relays if the client can't reach the SBC using the public IP address.
Requirements for direct media traffic (between the Teams client and the SBC)
The client must have access to the specified ports (see table) on the public IP address of the SBC.
Note
If the client is in an internal network, the media flows to the public IP address of the SBC. You can configure hair pinning on your NAT device so traffic never leaves the enterprise network equipment.
| Traffic | From | To | Source port | Destination port |
|---|---|---|---|---|
| UDP/SRTP | Client | SBC | 50000-50019 | Defined on the SBC |
| UDP/SRTP | SBC | Client | Defined on the SBC | 50000-50019 |
Note
If you have a network device that translates the client's source ports, please make sure that translated ports are opened between the network equipment and the SBC.
Requirements for using Transport Relays
Transport Relays are in the same range as Media Processors (for non-bypass cases):
Microsoft 365, Office 365, and Office 365 GCC environments
- 52.112.0.0 /14 (IP addresses from 52.112.0.1 to 52.115.255.254)
Office 365 GCC DoD environment
- 52.127.64.0/21
Office 365 GCC High environment
- 52.127.88.0/21
The port range of the Teams Transport Relays (applicable to all environments) is shown in the following table:
| Traffic | From | To | Source port | Destination port |
|---|---|---|---|---|
| UDP/SRTP | Transport Relay | SBC | 50000-59999 | Defined on the SBC |
| UDP/SRTP | SBC | Transport Relay | Defined on the SBC | 50000–59999, 3478-3481 |
Note
Microsoft recommends at least two ports per concurrent call on the SBC. Because Microsoft has two versions of Transport Relays, the following are required:
v4, which can only work with port range 50000 to 59999
v6, which works with port range 3478 to 3481
Requirements for using media processors
Media Processors are always in the media path for voice applications and for Web clients (for example, Teams clients in Microsoft Edge or Google Chrome). The requirements are the same as for non-bypass configuration.
The IP range for media traffic is:
Office 365 and Office 365 GCC environments
- 52.112.0.0 /14 (IP addresses from 52.112.0.1 to 52.115.255.254)
Office 365 GCC DoD environment
- 52.127.64.0/21
Office 365 GCC High environment
- 52.127.88.0/21
The port range of the Media Processors (applicable to all environments) is shown in the following table:
| Traffic | From | To | Source port | Destination port |
|---|---|---|---|---|
| UDP/SRTP | Media Processor | SBC | 3478-3481 and 49152–53247 | Defined on the SBC |
| UDP/SRTP | SBC | Media Processor | Defined on the SBC | 3478-3481 and 49152–53247 |
Configure separate trunks for media bypass and non-media bypass
If you're migrating to media bypass from non-media bypass and want to confirm functionality before migrating all usage to media bypass, you can create a separate trunk and separate Online Voice Routing policy to route to the media bypass trunk and assign to specific users.
High-level configuration steps:
Identify users to test media bypass.
Create two separate trunks with different FQDNs: one enabled for media bypass; the other not.
Both trunks point to the same SBC. The ports for TLS SIP signaling must be different. The ports for media must be the same.
Create a new Online Voice Routing policy and assign the media bypass trunk to the corresponding routes associated with the PSTN usage for this policy.
Assign the new Online Voice Routing policy to users you've identified to test media bypass.
The following example illustrates this logic.
| Set of users | Number of users | Trunk FQDN assigned in OVRP | Media bypass enabled |
|---|---|---|---|
| Users with non-media bypass trunk | 980 | sbc1.contoso.com:5061 | false |
| Users with media bypass trunk | 20 | sbc2.contoso.com:5060 | true |
Both trunks can point to the same SBC with the same public IP address. The TLS signaling ports on the SBC must be different, as shown in the following diagram. Note you'll need to make sure that your certificate supports both trunks. In SAN, you need to have two names (sbc1.contoso.com and sbc2.contoso.com) or have a wildcard certificate.
For information about how to configure two trunks on the same SBC, see the documentation provided by your SBC vendor:
- AudioCodes deployment documentation
- Oracle deployment documentation
- Ribbon Communications deployment documentation
- TE-Systems (anynode) deployment documentation
Client endpoints supported with media bypass
Media bypass is supported with all standalone Teams Desktop clients, Android and iOS clients, and Teams Phone Devices.
For all other endpoints that don't support media bypass, we'll convert the call to non-bypass even if it started as a bypass call. This conversion happens automatically and doesn't require any actions from the administrator. This includes Skype for Business 3PIP Phones, and Teams Web Clients that support Direct Routing calling (WebRTC based clients running on Microsoft Edge, Google Chrome, Mozilla Firefox).