Skip to main content

Technology

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

Business Continuity

Welcome back to Part 3 of “Planning Your Network in Microsoft Teams” series! Last time, we talked about what real time communications was and the protocols used for media traffic in Microsoft Teams. In this article, we’ll be going a step further and breakdown the anatomy of a media session in Microsoft Teams. Then we’ll discuss what types of impairments Microsoft Teams can face and how to combat those impairments. Lastly, we’ll discuss the types of calls in Microsoft Teams and how the signaling and media flows from your client to wherever the destination may be.

Anatomy of a Teams Call

So let’s say Alice wants to call Bob in Microsoft Teams? For Alice and Bob this is a seamless process, it’s as easy as selecting the call button and having Bob answer on his end. But what is actually happening in the background, and how does my call “automagically” reach Bob? Well, you can think of the audio call as an audio wave (as seen below) where the audio wave gets broken down/sliced into pieces and put the information of these pieces into a packet. From there, we send the packet over the network where Bob’s end puts those pieces in the packet back together and recreating that audio wave.

Image provided by: https://www.youtube.com/watch?v=vi3M7ZzF2NU&t=1457s

The image above is an example of a call where every piece of audio that is sent over the network is received on the other end. However, not every call you have will be a perfect call. For example, if you or the receiving end has a poor network connection you may see something like the next example.

Now, let’s say Alice tries to call Bob again, but this time Alice is in a crowded Starbucks getting some coffee where everyone is on one congested network. Well, Microsoft Teams planned for this and is able to combat some of this network degradation with a thing call Forward Error Correct (FEC). Forward Error Correction mitigates packet loss by including redundant information in these packets, so in the case where we lose some packets we have the redundant packets as backup. This is illustrated in the image below, where you can see we have built packets with information of audio part 1&2, another packet with part 2&3, another packet with part 3&4, and another packet with 4&5. This way, if we lose a single packet information is still available.

Image provided by: https://www.youtube.com/watch?v=vi3M7ZzF2NU&t=1457s

So if you lose the second packet with 2&3 the information of 2&3 can be retrieved from the other packets. Now that we know there is some sort of redundancy built into these transmission of these packets, let’s take a look at what happens when we lose two consecutive packets (as illustrated in the image below).

Image provided by: https://www.youtube.com/watch?v=vi3M7ZzF2NU&t=1457s

In the image above we see that packet 2&3 and 3&4 are lost when being sent to the other client. Now when the receiving client attempts to recreate the audio from the information that it retrieved, packet 3 cannot be found. In order to provide a good audio experience something called the “Audio Healer” will kick in and attempt to recreate that packet by recreating the audio information. So even though we have lost two packets along the way there won’t be a noticeable difference on the receiving end. In short, even though we have packet loss, Teams can recover from this and emphasizes the importance of using UDP over TCP. Since we are using UDP, these packets are sent to the receiver and any lost packets won’t cause any additional delay nor will any packets be resent. On the other hand, if were to use TCP these packets would have to be resent thus causing additional delay and a poor end user experience.

Network Impairments

Now that we know how packets are sent over the network to another client, let’s take a look at some of the network impairments and how we can combat those impairments in your environment.

Packet Loss

  • When packets are lost/discarded between two different endpoints
    • Symptoms:
      • Loss of audio or choppy audio
      • Robotic voice due to Audio Healer
      • Frozen video/fragmented video
      • Delays in your hearing/being heard
    • Mitigating packet loss:
      • Using wired network connection instead of Wi-Fi
      • Improving Wi-Fi reception
      • Increase bandwidth

Latency

  • Delay that packages have between two endpoints when going from endpoint A to endpoint B
    • Symptoms:
      • Talking over one another
      • Dropped packets (shows same symptom as packet loss)
    • Mitigating latency:
      • Improve Wi-Fi reception
      • Allow direct connection between internal endpoints
      • Optimize routing to Office 365

Jitter

  • Packets arriving in the wrong sequence from when they were sent
  • “Jitter Buffer” buffers packets to restore the original sequence
    • Symptoms:
      • Jitter Buffer increases latency (leading to same symptoms as latency)
      • If packets arrive too late, they are discarded/dropped (leading to same symptom as packet loss)
    • Mitigating jitter:
      • Reduce network congestion
      • Increase bandwidth

Bandwidth

  • Lack of bandwidth
    • Symptoms:
      • Forces use of lower quality codecs
      • Leads to additional latency, jitter, or packet loss
      • Media quality degradation
    • Bandwidth Planning:
      • Must determine number of users and used workloads
      • Use Microsoft Network Planner for appropriate bandwidth
      • Plan for Live Events separately

Now that we have discussed how packets are sent over the network as well as the network impairments that stand between you and a good quality call, hopefully this will help prepare you for your network planning in Microsoft Teams. However, there is still more to discuss when planning your network for Microsoft Teams, which will be covered in the next blog! In part 4 of the blog series, we’ll jump into media flows and discuss the types of calls in Microsoft Teams including Live Events and how to properly plan for that. I hope you have found this blog helpful, and encourage you to check out some of my other blogs on Teams, which can be found here!

 

 

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Brian Siefferman

Brian is a Technical Consultant for Perficient’s Unified Communications practice focusing primarily on Skype for Business and Microsoft Teams workloads. He has been in this role since December 2017 and has an active presence blogging about all things Teams related. Currently, Brian resides in the suburbs of Chicago and enjoys running, swimming, weight lifting, and playing soccer in his free time.

More from this Author

Follow Us
TwitterLinkedinFacebookYoutubeInstagram