Plan Your Network in Microsoft Teams (2019) – Part 4

Welcome back to part 4 of “Planning Your Network in Microsoft Teams” blog series. Last time we talked about the anatomy of a Teams call as well as some of the network impairments that can severely impact your call quality. Now that you have a good understanding of that, it is time to move on to the different types of media flows within Microsoft Teams.

Media Flows in Teams

There are two main types of calls when using Microsoft Teams:

Direct Calls

Direct calls are classified as a call between 2 users (no more than 2). In addition, a direct call needs to be an audio call. For example, if Alice were to go into her Teams client and select the user she wanted to call, the media will flow as directly as possible to Bob on the receiving end. This means that the media will simply go from point A (Alice) to point B (Bob) without traversing any type of server or proxy along the way (provided the network allows this).

Meetings

Meetings are classified in a few different ways. The first being a call that has more than 2 users (3+) at one time. Another scenario that classifies a meeting would be a scheduled call. This would mean that Alice goes into her Outlook client and selects “Teams Meeting” or she goes into her Teams client, navigates to the “Meetings” tab, and then selects “Schedule a meeting”. A meeting call flow will differ from a direct call in that the meeting will leverage something called the conferencing service. In a meeting, all participants of that meeting will send their audio, video, screen sharing sessions to that conferencing service and the conferencing service will in turn mix that audio and send it out accordingly to each endpoint. There is one caveat though, in order to guarantee a direct connection from each endpoint to the conferencing service you must ensure that the high ports (1,024-65,535) are opened. If the high port range is closed, the endpoints will connect via the Transport Relay on ports 3478-3481 UDP.

Note: If Alice is in a direct call with Bob but decided she wanted to invite an additional user, what would happen to our media flow? Well, upon her dragging in the third user, the media will switch from a direct call path and instead everyone will start to leverage the conferencing service thus escalating this to a meeting call type.

Now that we understand the types of calls in Microsoft Teams, let’s take a look at some visual examples of the call between Alice and Bob.

Direct 1:1 Call

In this first scenario, let’s say we have Alice and Bob whom both work at the same location. Alice goes to call Bob and as a result her signaling will go out to Office 365 via 443 TCP to check if Bob is online and how to reach him. Now let’s say Bob is signed in as well thus his signaling too will go out to Office 365 via 443 TCP. The media however will go directly between Alice and Bob meaning that all traffic will stay within their enterprise network and there won’t be a need to redirect traffic to Office 365 to establish the media session. As a result, this will reduce the latency and network path that the traffic would have experienced if it had to go out to the internet.

1:1 Call via Relay

Revolutionize Your Business With Generative AI

From product design and software development to virtual agents, content creation, and reporting, GenAI is transforming business. Our AI experts help you unlock GenAI’s full potential and drive growth.

Let’s Get Started

What if the previous scenario isn’t applicable and we are unable to send this traffic directly from Alice to Bob? A good example of this would be if Alice is at home and Bob is in the office on the corporate network. In this scenario, as expected, the firewall will block connections between internal and external users. Fear not, we have a solution for this as well. From a signaling perspective nothing will change. This means that the signaling will still go from Alice to Office 365 network on port 443 TCP. However, since the media will be unable to connect directly from Alice to Bob we must use something called a transport relay. In this specific scenario Alice will send her media to the transport relay and from the transport relay this media will be sent to Bob. In order to reduce the latency that may be introduced by adding in this transport relay, Microsoft Teams will select the relay closest to them (based on IP routing) to ensure the quickest path from Alice to Bob. In short, if a direct connection is not possible, the media traffic will be sent over this transport relay.

Meeting Locations

Now that we know what P2P (Peer-to-Peer) call scenarios look like, let’s talk a little bit about our conferencing service which we briefly mentioned earlier and how these calls work in Microsoft Teams. So from what we already know on meetings, each conference (3+ users) will always have their media sent to the conferencing service in Office 365. To expand on this, Teams will always choose a conferencing service that’s in the same region as the first user that joins the meeting. If you were thinking that the conferencing service is located closest to the meeting organizer, you would be sadly mistaken. This is often the case since the meeting organizer is typically the first one in the meeting, however it is first comes first serve in terms of where the meeting will be homed. So it may pay to be early to your meetings for once ;).

So now let’s see an example of this. Let’s say we have a few users scattered around the United States with a US based tenant. In this scenario users  will look for the closest peering point to the Microsoft Global Network and whomever is first to join the meeting will find a conferencing service that is geographically closest to them. Now any subsequent users that decide to join the meeting will look for the closest peering point to the Microsoft Global Network (like before) but then join the meeting in the region where the first user joined.

So what if we still have a US based tenant but have users in Europe trying to join a meeting? Well, similar to before, these users will look for the closest peering point to the Microsoft Global Network. However, now since the first user who joins that meeting is based out of Europe the meeting will be homed in that region and they won’t have to send all of their traffic around the world.

Live Events

This is a fairly new addition to Teams. Live Events are very similar to your Broadcast Meetings if you come from a Skype for Business background. Basically, live events allow you to have up to 10,000 participants in a meeting at once. This would typically be used at a town hall meeting where your CEO may want to talk to all employees. Live Events will have 3 different types of roles: presenter, producer, and participant. Presenters and producers will have the ability to share audio, video, and desktop within this special Teams meeting. Participants on the other hand are unable to use those modalities and only have the ability to consume/watch the stream. One of the most important things to take into consideration when planning for Live Events is that if a presenter experiences any type of network degradation, ALL participants will see this and be affected. On the other hand since the participants are only consuming the stream if one participant experiences network degradation, it will only affect that particular participant. With all that said, it is important to use the same type of planning that you would for “regular” Teams meeting planning for your presenters and producers. As far as the participants go, each endpoint that will be consuming media will need approximately 1.2Mbps of bandwidth. In addition, user education can go a long ways by having your participants all watching from a meeting room rather than having each user stream this from their individual PC. This would require that bandwidth to only be delivered once to that meeting room instead of several times to each individual endpoint.

CDN & eCDN

Your participants consuming the media in a Live Event will do this via the Azure Content Delivery Network (CDN). This is part of the Microsoft Global Network and is used to deliver the stream worldwide via the local peering points that we covered earlier in order to avoid buffering. There is also something called the Enterprise Content Delivery Network (eCDN), which basically allows for  certified partners (Hive, Kollective, and Ramp) to integrate their solutions where each office location would only require a single stream from the internet to be consumed and then distributed out to the enterprise network. So if you have 100+ users in a the same office trying to watch a town hall meeting you only need to have sufficient bandwidth from your office to the internet to support that single stream.

This wraps up everything that we will discuss today on media flows. Check back soon when we’ll take a look at the Office 365 network in more detail and how it works on the back-end. I hope you have found this helpful, and I encourage you to check out some of the documentation provided by Microsoft on Live Events and CDN’s/eCDN’s.