Recently there was a discussion between myself and a few fellow colleagues about how media is treated by Microsoft based on the client and tenant location. This came about as a result of an Ignite session delivered by Korneel Bullens over the use of Transport Relays with Microsoft Teams media. It caused quite the debate…
The issue we debated was the bullet point “EU tenants use Transport Relay in EU and US” as a result of EU privacy laws. Searching the wide open internet revealed no clarification, or supporting evidence relating to this specific scenario, which contributed towards trying to get to the bottom of issue.
Our understanding, as per current documentation on docs.microsoft.com is that a transport relay closest to the client’s geographical public IP address is chosen where possible.
What is seemingly missing from this statement are the words “feasibly and legally” possible, according to the statement in the above slide extract.
So now consider your organisation has global presence, especially in APAC regions, but you have an EU tenant. What does this mean for your media paths for APAC users?
On the face of it seems that their media path is going to take a significant path across the internet for calls.
Well, after testing the answer is, it depends…
First, let’s take Teams meetings. A Teams meeting is spun up in the region that the first joiner is located. If this person happens to be in APAC, then the Teams meeting and MCU will be located in the APAC region e.g. Hong Kong, Singapore etc.
The behaviour now depends on your outbound security settings on the corporate firewall, and taking some assumptions about internet breakout.
If the APAC users break out of the corporate network in APAC, their client will have an APAC geo-ip. In an unrestricted deployment where the Teams client can use high ports to connect to media, the Teams client will connect directly to the media processor closest to the conferencing server. In the scenario above, this is great news for APAC users, because they are not using transport relays and therefore, are able to connect directly to the B2BUA (MP).
However, where this falls apart is when APAC users join a conference that was started by someone in EMEA, or NORAM. In the unrestricted deployment, media will be connected over the internet between the corporate APAC Internet IP and the Media Processor in EMEA for instance. This opens up lots of potential for media issues traversing unmanaged internet routers and links.
In a restricted deployment, the Teams client would be blocked from connecting to high ports, instead being allowed only to establish media using Transport Relays. This is the current recommended deployment model from Microsoft and their Office 365 IP and URL ranges (Rule ID 11) only recommends UDP is open on 3478-3481. When this is enforced, the Teams client must connect to a transport relay to proxy its media to either the media processor, or to the SBC in the case of a PSTN call.
This is where the potential issue lies. If we have an APAC hosted conference, then in this mode according to the slide at the top of this page, the APAC users would relay their media by via a server in EMEA which would then relay that to the media processor in APAC. Not an ideal media route and we start to have conflict between an organisation that has stricter controls on outbound connections and the technology we are trying to implement.
Before we conclude this scenario, let’s now understand how PSTN calls behave in the same situation.
In a non-media bypass scenario and in an unrestricted deployment, the Teams client will connect to the Media Processor that is closest to the terminating SBC and not to the client. In APAC, it is likely that the SBC will be located in the same region as the APAC user, again this appears optimised.
However, if the APAC user is making an international call, and the organisation has deployed least cost routing, regulation permitting, international calls would be placed using SBCs in distant regions. In the unrestricted model, the APAC Teams client would connect to the Media Processor in EMEA for European international calls and NORAM for North American Calls etc. Similar to the way that conferencing works.
In a restricted deployment where transport relays are enforced, or media bypass has been enabled on the SBC, the above slide suggests that media would be relayed from APAC to EMEA and back to APAC for PSTN calls if media bypass was not possible.
Putting this to the test. I deployed a virtual machine in an AWS datacenter in Singapore. I wanted to be sure to be using a network that was not owned by Microsoft and conducted several tests.
The first test was a PSTN call to an international number based in EMEA with no restrictions. The below is a trace route of the media flow.
We can see that media is connected between the APAC client and the Media Processor on high ports. When IP tracing the IP 126.96.36.199 it returns a location of Dublin, Ireland.
So as expected, the Media Processor closest to the SBC was selected and the APAC client uses the internet to transport media from the client edge to the Media Processor in Ireland.
Now the same scenario, but with high ports blocked and the client forced to use transport relays. If the slide above is correct, the IP of the transport relay should also return either an EMEA, or US geo-ip.
Performing an IP trace on 188.8.131.52 resolves a location of Singapore!!
This seems to discredit the interpretation of the slide that caused the debate, but then neither of us attended it and we’re probably missing a lot of context. The reality is that the IP address is just the Azure Edge IP that the client connects to. The actual server can be anywhere inside Azure. We just don’t know and neither should be be concerned about it. The point is that media path is optimised. What happens inside Azure is outside your control and if there were problems, you’re backed by a financial SLA by Microsoft.
The same experience is found for meetings as well during the tests. For EMEA conferences, APAC users in a restricted deployment connected media via the Singapore relay server and EMEA users connected to an EMEA transport relay for an APAC conference.
Why is this better or worse than just allowing unrestricted connectivity to Microsoft?
The key difference in all scenarios is that a transport relay is selected based on the connecting client’s public IP address and not the closest media processor to the termination point (conference mcu or sbc). This ultimately means that the media path between the connecting client and Microsoft Azure Edge is always optimal and shortest possible. The relay server will then relay that media to the conference server, or SBC using the Azure global network as opposed to the wild internet, which in most circumstances will offer a greater experience to everyone in the meeting or call.
It is also highly recommended to enforce relay if you’re deploying hosted Direct Routing as with or without media bypass you are always going to ensure that the closest relay point to the client / site is chosen and you leverage the Azure network to optimise the media between the relay and the hosted SBC.
APAC Client —> Internet —> Azure APAC —> APAC Transport Relay —> EMEA Media Processor —> EMEA Azure —> Internet —> Hosted SBC —> PSTN
as opposed to
APAC Client —> Internet ——————————> Azure EMEA —-> EMEA Media Processor —-> Internet —-> Hosted SBC —> PSTN
In summary, the transport relay may or may not be in the EU or US as per the slide. The important design factor here is that by enforcing relay, you are optimising your media paths to take the shortest hop across the internet to the Microsoft network as possible in all scenarios and that is a good thing!
Mark is an Independent Microsoft Teams Consultant with over 15 years experience in Microsoft Technology. Mark is the founder of Commsverse, a dedicated Microsoft Teams conference and former MVP. You can follow him on twitter @UnifiedVale