As a Teams administrator I have access to a lot of data, which is helpful to improve the call quality in Microsoft Teams using the Call Analytics and the Call Quality Dashboard.
By interpreting this data, I can derive causes for reported incidents, I can provide the network team with helpful hints about bottlenecks in the corporate network, and I can specifically monitor impacts of planned changes in the infrastructure.
Which metrics are relevant for me as a Teams Administrator?
Microsoft provides the Poor Stream Rate (PSR) to set a baseline. If my value here is below 3% on average, I’m basically in a good position. I may find optimization potential by looking at the individual details.
| Network type | PSR | Setup failure | Call drops | |
|---|---|---|---|---|
| Alle | Intern | 2,0 % | 0,5 % | 2,0 % |
| Insgesamt | 3,0 % | 1,0 % | 3,0 % | |
| Konferenzen | Intern | 2,0 % | 0,5 % | 2,0 % |
| LAN intern | 1,0 % | 0,5 % | 1,0 % | |
| WLAN 5 GHz intern | 1,0 % | 0,5 % | 1,0 % | |
| WLAN 2,4 GHz intern | 2,0 % | 0,5 % | 2,0 % | |
| Insgesamt | 2,0 % | 0,5 % | 3,0 % | |
| P2P | Intern | 2,0 % | 0,5 % | 2,0 % |
| LAN/WLAN 5 GHz intern | 1,0 % | 0,5 % | 1,0 % | |
| LAN/WLAN 5 GHz allgemein | 2,0 % | 1,0 % | 1,0 % | |
| Insgesamt | 2,0 % | 1,0 % | 3,0 % |
The consideration of streams instead of calls allows a more detailed view: A call always consists of several call legs, which are represented by the streams.
The PSR is relevant for the trend analysis in the Call Quality Dashboard. When interpreting the data make sure your data is sufficient: It only makes sense to look at the PSR if there are 100 streams or more.
Why? If there is little activity in the analyzed period and one of a total of two streams is classified as poor, we are ad hoc at a PSR of 50%.
The classification of an audio stream as poor is based on the following metrics:
| Metric average | Description | User experience |
|---|---|---|
| Jitter >30 ms | This is the average change in delay between successive packets. Teams and Skype for Business can adapt to some levels of jitter through buffering. It’s only when the jitter exceeds the buffering that a participant notices the effects of jitter. | The packets arriving at different speeds cause a speaker’s voice to sound robotic. |
| Packet loss rate >10% or 0.1 | This is often defined as a percentage of packets that are lost. Packet loss directly affects audio quality—from small, individual lost packets that have almost no impact to back-to-back burst losses that cause audio to cut out completely. | The packets being dropped and not arriving at their intended destination cause gaps in the media, resulting in missed syllables and words, and choppy video and sharing. |
| Round-trip time >500 ms | This is the time it takes to get an IP packet from point A to point B and back to point A. This network propagation delay is tied to the physical distance between the two points and the speed of light, and includes additional overhead taken by the various devices in the network path. | The packets taking too long to arrive at their destination cause a walkie-talkie effect. |
These metrics are also used in the Call Analytics, where they are highlighted as the cause of a poor stream.
Why should I get involved with Power BI as a Teams Administrator?
Microsoft provides a Power BI Connector in addition to the Graph API as an external interface for retrieving data from the CQD. Microsoft MVP Matt Wade has designed an ingenious Power BI template whose reports leave no wishes open.
What should I definitely do to get most out of the CQD?
I can upload information about my subnets to my company’s tenant. This information is then linked to the call detail records and helps me to map the good and bad audio streams to my network segments. An absolute added value when looking for bottlenecks and monitoring planned changes in the infrastructure!
You must be logged in to post a comment.