Welcome back! Last time we discussed (at a high level) what you will need to consider to implement Teams in your environment. This time, we’ll be taking a deep dive into each of these areas so you can get a full understanding about what is required to ensure a successful implementation. Specifically, we’ll start off with learning what Microsoft Teams uses to communicate and how this ties into your network.
Real Time Communications? What’s that?
For those of you that have never dealt with products like Lync, Skype for Business, Teams or other non-Microsoft real time media workloads you may not be too privy to this concept. Basically real time communications is broken down into 3 different things:
- Audio
- Video
- Desktop Sharing
So, if you had a meeting, call, or screen share with someone, guess what? You just used real time communications! Now that you know what real time communications entails, let’s talk about what’s under the hood and how it works. As you will find out, all real time communication traffic is very sensitive to delay. For example, if you are on a phone call and you talk but the audio isn’t received on the other end until 5 seconds later, this will cause a bad experience for you and the receiving end. Have you ever heard the saying, “better late than never”? Well if so, this is the exact opposite of what we want for real time communications. Instead, we’d rather have it be “better never than late”. In real time communications, if we lose some of the packets along the way, we don’t really care. The other end may hear some slight audio glitches, but the session will continue. If we were to inspect every packet going across the network, receiving acknowledgement on our end that it was delivered successfully, and resubmit any missing packets, then this would introduce lots of latency which would result in large gaps of lost audio severely impacting the call. With all that said, this leads me to my next conversation, the internet traffic protocols used in Teams.
TCP vs UDP
Teams has the ability to leverage either TCP or UDP internet protocol. However, it will become apparent very quickly as to which protocol is the preferred option when using any type of real time communication.
TCP
TCP is a great protocol in that it makes sure each packet is sent and acknowledged by the receiver. For any packets not sent properly, TCP will resend those missing packets. This is a great option if you are sending any type of file, but not so great when it comes to sending any type of real time communications. As we mentioned earlier, if you need to receive an acknowledgement after each packet being sent as well as have any lost packets resent, this will cause all subsequent packets to be delayed, thus creating latency.
UDP
UDP on the other hand works as a “send it and forget it” protocol. UDP does not require that extra step of having to receive an acknowledgement nor does it resent missing packets. This is the preferred option for all real time communication traffic, as we care more about the speed that the packets arrive and not so much about if they arrived, and are acknowledged by the receiver or not. If you notice that the traffic is using UDP but so many packets are being lost that audio/video/desktop sharing is severely impacted, then this means you are looking at a network that can’t support real time communications.
As mentioned, Teams uses UDP for all real time communications/media scenarios. If there is an endpoint in the firewall blocking UDP, it will fallback to TCP but as mentioned, this will result in a poor end user experience due to the delay it would cause. There is however one exception to this, Teams Live Events attendees. In this scenario we have a Live Event with both the presenter and the producer leveraging a Teams meeting. All attendees will consume their audio, video, and desktop sharing with TCP rather than UDP. This is because they will consume all of these modalities as a one way stream since the attendees are only watching and not able to give audio,video, desktop sharing feedback from their end, thus the second stream is not needed. Likewise, since they are just listening to this stream they may be receiving this a little delayed but this won’t impact their experience since they don’t need to worry about replying. The producers and presenters of this meeting will still be using UDP though since they are the ones sending the real time communications traffic.
This wraps up the first piece of the deep dive into planning your network for Microsoft Teams. In the next article we’ll breakdown a media session and explain how media is transferred from one end to the other. In addition, we’ll take a look at some of the network impairments and the impact they can have on your network. I hope you have found this article helpful and check back soon for the next blog!
