Deep Dive: Teams Direct Routing Media Bypass
This article will assume you already have Teams Direct Routing in place. If you are not there yet, consider looking at my article on this subject: https://www.lee-ford.co.uk/teams-direct-routing-with-an-audiocodes-sbc/
Introduction to Media Bypass
A welcome addition to Teams Direct Routing is Media Bypass. Before Media Bypass was released, all media when using Direct Routing would need to route up to one of six regional Teams Media Processors and back even if the Teams client and SBC were in the same location. Whilst this does work, it can be sub-optimal. If you then add on the fact that Media Processors are only available in six datacentres worldwide, it can add up to some large round trip times dependent on your location.
By using Media Bypass the Teams client can (if allowed) communicate directly with an SBC (using it’s public IP) instead of routing via Teams Media Processors.
If using Media Bypass and the Teams client is unable to communicate with an SBC directly it can instead use Transport Relays. Transport Relays in this scenario effectively relay the media between the Teams client and the SBC. The key benefit for Transport Relays over Media Processors is amount of them (‘multiple’) and the likelihood they will be in closer proximity to users. Users will be routed to the ‘closest’ Transport Relay based on it’s Anycast IP address.
It is worth bearing in mind there are some scenarios where Media Bypass will not be available such as conference calls, escalating a 1:1 PSTN call to a 3-way call or transferring a call to a SfB user.
One last point to make here is, Media Bypass will not offer any transcoding between the SBC and the Teams client. So, if you want to use a codec such as SILK with your Teams client, your SBC needs to be able to support that (and potentially transcode it).
How does Media Bypass work?
Media Bypass is achieved by the SBC supporting ICE lite. ICE lite, as the name suggests, is a slimmed down implementation of the ICE (Interactive Connectivity Establishment) protocol. ICE is used in the establishment of media between two parties.
ICE isn’t exclusive to Media Bypass or even Teams, so I won’t go in to too much depth here. Essentially, when establishing a media session between two parties, both parties send an preferred list of candidates to each other. Candidates are a potential way media can be established to that party - it typically includes IP addresses, ports and protocols. So for Media Bypass, the Teams SIP Proxy will send a list of candidates to the SBC and the SBC will send a list to the Teams SIP Proxy and eventually candidates will be chosen from those lists.
For our purposes, the main difference between ICE and ICE lite clients is ICE lite clients can only offer a single candidate and wait for further instruction on the candidates from the other party. ‘Standard’ ICE clients, such as Teams, can perform the connectivity checks to discover candidates and decide upon preferred candidates.
Enabling Media Bypass
Pre-requisites
Before you can enable Media Bypass you need to ensure you are prepared and enabling it won’t have a negative impact.
-
Ensure all Teams clients you plan to use are supported - Currently, the web-browser version of Teams or 3PIP phones do not support Media Bypass. If you plan to use these disable Media Bypass or set up a separate connection to the SBC with no Media Bypass.
-
Ensure your Teams clients have local internet breakout - This should be the case when using Teams anyway! For example, if a user and SBC are based in London with no connectivity between the two, but the user’s internet breakout is at the corporate HQ in New York, the Teams client will attempt to use to a Transport Relay close to New York, which will then relay traffic back to London to SBC- effectively sending the traffic half way around the world and back!
Technically, in this extreme example, this would also be an issue even if you are not using Media Bypass as the Teams client would also talk to a Media Processor in the wrong region.
-
Ensure the Teams clients can reach the Transport Relays - These should already be in place when using Teams, but just in case:
Traffic Source Port Destination IP Destination Port Candidate Discovery Any 52.112.0.0/14 443 TCP, 3478 UDP Audio Any 52.112.0.0/14 443 TCP, 3479 UDP Video Any 52.112.0.0/14 443 TCP, 3480 UDP Desktop Sharing Any 52.112.0.0/14 443 TCP, 3481 UDP -
Ensure the SBC can reach the Transport Relays (and vice-versa) - These are in addition to the media ports used for Direct Routing with no Media Bypass (Media Processors):
Traffic Source IP Source Port Destination IP Destination Port Audio and Candidate Discovery SBC IP Media Ports (Defined on SBC) 52.112.0.0/14 3478, 3479, 50,000-59,999 Audio 52.112.0.0/14 50,000-59,999 SBC IP Media Ports (Defined on SBC) -
Ensure the SBC and Teams client can communicate with each other - This should only be for ‘internal’ Teams clients only. Microsoft recommend Teams clients ‘outside’ of the network should connect via Transport Relays instead. By restricting to ‘internal’ Teams clients this also means you don’t expose 10,000+ ports to the SBC from any external IP address! In the current version of Media Bypass only the SBC’s public IP address is used, so you will need to ensure your Firewall is capable of hair-pining internal traffic back in to the SBC.
Traffic Source IP Source Port Destination IP Destination Port Audio SBC IP Media Ports (Defined on SBC) Teams client 50,000-50,019 Audio Teams client 50,000-50,019 SBC IP Media Ports (Defined on SBC)
Enable the use of Media Bypass on the SBC
I only have access to do this on an AudioCodes SBC, here under the Teams IP Profile I have changed the ICE Mode to ICE lite. For other SBC vendors, check their documentation.
Enable Media Bypass in Office 365
You will need to connect to Skype Online PowerShell and run the following command (for each SBC you wish to enable Media Bypass on).
Set-CSOnlinePSTNGateway -Identity <SBC FQDN> -MediaBypass $true
Verifying Media Bypass
The example below is taken from an AudioCodes SBC Syslog, as it is much easier to capture the SIP messaging from here (Teams client does not show this in any logs that I can see).
In this example it is a call originating from Teams, terminating on the SBC and then being sent to a SIP provider. Whilst your own example may differ slightly you should be able to see the ICE negotiation in any case.
Teams SIP Proxy Device SIP Provider
| | |
| INVITE (SDP) F1 | |
|--------------------------------->| |
| 100 Trying F2 | |
|<---------------------------------| |
| | INVITE (SDP) F3 |
| |--------------------------------->|
| | 100 Trying F4 |
| |<---------------------------------|
| | 183 Session Progress (SDP) F5 |
| |<---------------------------------|
| 183 Session Progress (SDP) F6 | |
|<---------------------------------| |
| | 180 Ringing F7 |
| |<---------------------------------|
| 180 Ringing F8 | |
|<---------------------------------| |
| | 200 OK (SDP) F9 |
| |<---------------------------------|
| 200 OK (SDP) F10 | |
|<---------------------------------| |
| ACK F11 | |
|--------------------------------->| |
| | ACK F12 |
| |--------------------------------->|
| INVITE (SDP) F13 | |
|--------------------------------->| |
| 200 OK (SDP) F14 | |
|<---------------------------------| |
| ACK F15 | |
|--------------------------------->| |
| BYE F16 | |
|--------------------------------->| |
| | BYE F17 |
| |--------------------------------->|
| | 200 OK F18 |
| |<---------------------------------|
| 200 OK F19 | |
|<---------------------------------| |
| | |
1. Initial Candidate Exchange
On the initial INVITE from Teams (F1) and the returned 183 Session In Progress (F6) the initial list of candidates are exchanged. At this stage, no decisions have been made on what candidates to use.
Initial candidates from Teams SIP Proxy (F1)
The initial INVITE from the Teams SIP Proxy to the SBC has the following candidates listed. These are potential candidates the SBC will use to send it’s media to.
a=candidate:10 1 UDP 184544767 52.114.124.220 53138 typ relay raddr 94.172.111.111 rport 50014
a=candidate:10 2 UDP 184544254 52.114.124.220 51016 typ relay raddr 94.172.111.111 rport 50015
a=candidate:5 1 UDP 2130704383 192.168.141.129 50014 typ host
a=candidate:5 2 UDP 2130703870 192.168.141.129 50015 typ host
a=candidate:6 1 tcp-act 2121004030 192.168.141.129 50000 typ host
a=candidate:6 2 tcp-act 2121004030 192.168.141.129 50000 typ host
a=candidate:9 1 UDP 1694494719 94.172.111.111 50014 typ srflx raddr 192.168.141.129 rport 50014
a=candidate:9 2 UDP 1694494206 94.172.111.111 50015 typ srflx raddr 192.168.141.129 rport 50015
a=candidate:11 1 tcp-act 1684793854 94.172.111.111 50014 typ srflx raddr 192.168.141.129 rport 50002
a=candidate:11 2 tcp-act 1684793854 94.172.111.111 50014 typ srflx raddr 192.168.141.129 rport 50002
a=candidate:12 1 tcp-pass 174450686 52.114.124.216 59000 typ relay raddr 94.172.111.111 rport 50014
a=candidate:12 2 tcp-pass 174450686 52.114.124.216 59000 typ relay raddr 94.172.111.111 rport 50014
a=candidate:13 1 tcp-act 174843390 52.114.124.216 59000 typ relay raddr 94.172.111.111 rport 50014
a=candidate:13 2 tcp-act 174843390 52.114.124.216 59000 typ relay raddr 94.172.111.111 rport 50014
In priority order the candidates are:
| Priority | Candidate | Destination | Protocol | Description |
|---|---|---|---|---|
| 1 | 5 | Teams client | UDP | IP address of the Teams client. If the SBC and Teams client can talk directly to each other (same ‘internal’ network) it is the ideal scenario |
| 2 | 6 | Teams client | TCP (Active) | IP address of the Teams client. This is the same as the candidate above, but using TCP (UDP is always preferred) |
| 3 | 9 | Teams client (behind NAT) | UDP | Public IP address of the Firewall the Teams client is behind. Traffic is then forwarded (using NAT) to the IP address and port of the Teams client. This should be blocked. |
| 4 | 10 | Transport Relay | UDP | Transport Relay IP address. Traffic is sent to the Transport Relay which is then relayed to the remote IP address and port mentioned |
| 5 | 11 | Teams client (behind NAT) | TCP (Active) | Public IP address of the Firewall the Teams client is behind. Traffic is then forwarded (using NAT) to the IP address and port of the Teams client. This should be blocked. |
| 6 | 12 | Transport Relay | TCP (Passive) | Transport Relay IP address. Traffic is sent to the Transport Relay which is then relayed to the remote IP address and port mentioned |
| 7 | 13 | Transport Relay | TCP (Active) | Transport Relay IP address. Traffic is sent to the Transport Relay which is then relayed to the remote IP address and port mentioned |
The general order is:
- Direct connection between SBC and Teams client
- Direct connection between SBC and the Teams client behind NAT (this should be blocked as per Microsoft’s recommendation)
- Use of Transport Relay
UDP connections preferred over TCP
Initial candidates from SBC (F6)
The SBC will also send it’s candidates to the Teams SIP Proxy. As the SBC is using ICE lite, only a single candidate can be sent - which is it’s public IP address and a port in it’s defined media range.
a=candidate:529565244 1 udp 2130706175 51.143.222.222 6860 typ host
a=candidate:529565244 2 udp 2130706174 51.143.222.222 6861 typ host
As only a single candidate can be sent, the SBC will send it’s public IP address as this may be needed to communicate with Teams Media Processors/Transport Relays.
2. During call establishment, Teams SIP Proxy will notify chosen candidates (F13)
As the call is being established, Teams will send a chosen candidates in a RE-INVITE (F13). This is based on connectivity checks Teams has undertaken to determine the most preferred candidate that can be used. As you can see below, it has chosen candidate 10 - to route traffic via a Transport Relay using UDP.
a=candidate:10 1 UDP 184544767 52.114.124.220 53138 typ relay raddr 94.172.111.111 rport 50014
a=candidate:10 2 UDP 184544254 52.114.124.220 51016 typ relay raddr 94.172.111.111 rport 50015
a=remote-candidates:1 51.143.222.222 6860 2 51.143.222.222 6861
This is what I expected as the Teams client was not able to reach the SBC directly (over the internet).
There is also remote-candidates mentioned - even though there is only one candidate offered from the SBC, the SBC is still told which candidate to use for receiving traffic.
Comparison to non Media Bypass calls
For non Media Bypass calls the SBC will still send the same single candidate (it’s public IP address). The Teams SIP Proxy will instead send two candidates:
a=candidate:1 1 UDP 2130706431 52.114.116.72 51526 typ srflx raddr 10.0.32.6 rport 51526
a=candidate:1 2 UDP 2130705918 52.114.116.72 51527 typ srflx raddr 10.0.32.6 rport 51527
a=candidate:2 1 tcp-act 2121006078 52.114.116.72 49152 typ srflx raddr 10.0.32.6 rport 49152
a=candidate:2 2 tcp-act 2121006078 52.114.116.72 49152 typ srflx raddr 10.0.32.6 rport 49152
These are both to the same Media Processor on UDP and TCP. I believe the remote IP mentioned (10.0.x.x) is an internal IP address within Microsoft’s Teams service.
Wrap Up
Hopefully you now should understand what Media Bypass is, when to use it and when not to use it, how to configure it and finally - how to verify it is working as intended. Feel free to comment on the article and give some feedback.
References
BRK4016 - Understanding Media Flows in Microsoft Teams
