Transcription vidéo (EN)
When monitoring Microsoft teams’ performance, there is one important fact to remember in a Microsoft teams’ session, all users connect to the same Microsoft media server, which serves as communication really between the different attendees. The choice of the media server to use depends on the location of the first attendee who connects to the session.
So for example, if you are based in Europe and you have a call with colleagues living in the U.S., if you are the first to connect to the Microsoft teams session, you will connect to a local media server located in Europe. All your colleagues will connect to the same server, which is far away from them in this case.
This will obviously add network latency and can lead to poor voice and video quality for these U.S. Based users. As a best practice, Microsoft recommends to keep the network latency below 100 milliseconds to guarantee proper streaming traffic performance. To achieve this. Microsoft recommends to connect as quick as possible to its backbone. So the ISP you are connected to should ideally peer directly to the Microsoft network.
Let’s have a look at how you can assess these best practices by using the Kadiska platform. In this example. We are monitoring the connectivity performance to Microsoft media servers located in the U.S.
From the different colors you see that accessing these media servers from different locations in the U.S. Is not a problem. For example, here I have a round trip time of 46 milliseconds from here. 29 milliseconds from here. 55 milliseconds.
But you see that when users located in Australia have to take part to the Microsoft team sessions using these media servers, they can experience very poor, call quality. In this case, the average round time is 225 milliseconds, which is far and beyond the recommended 100 milliseconds as a maximum value.
Now let’s analyze the second Microsoft recommendation, which is to connect as quickly as possible to its backbone. Let’s focus on the users located in Perth. I select the users by simply clicking on this icon. And I navigate to the past performance view.
You see immediately here that before reaching to Microsoft backbone, the traffic is being routed through four different ISPs. I first connect to Integrate Group. Then I go to the Collocation Australia. Then the traffic is being routed to the Internet Association of Australia, then reaches the Megaport before finally reaching the Microsoft backbone, which obviously will introduce additional network latency.
If I now focus my attention on where the delay is mainly introduced, I see that I have some delays introduced while traversing, the Colocation Australia ISP, nevertheless, most of the delay is still introduced by links within the Microsoft backbone itself. This means that the traffic reached the Microsoft backbone in Australia before crossing the ocean to the United States.
So as a conclusion, you see with this small example how easy it is for Kadiska to assess Microsoft network best practices, when it comes to monitoring Microsoft Teams performance.
