MS Teams Call History and CQD

Question

Dear Members.

i would like to understand more specific on individual call quality in MS teams admin center - End user individual call analytics or history.

from the office network / home network (WFH. now a days) . users are complaining they are disconnecting from the MS Teams meetings / calls / conference.

While am checking the call history, some calls are marked as GOOD and POOR.

The problematic meeting was marked as GOOD. however in the network parameters, they values of jitter, packet loss, RTT - any of the values are more than threshold .

1st thing - I would like know, how the meeting marked as GOOD, even the network measurements are more than high value.

2nd thing - As a proactive measure, i would like analysis the Call / conference quality in MS Teams from the CQD data in network perspectives for a subnet, or building etc . so that i can give the data to the network guys to improve the quality of network if there is any impairments.

what are the measurements should i select from CQD for betterment . there are many in jitter , packet, RTT, concealed

Answer 1

Hi @Ramki

how the meeting marked as GOOD, even the network measurements are more than high value.

The metric and conditions used to classify Stream are shown in the tables. It shows different conditions we met will mark as Poor for your reference:

https://learn.microsoft.com/en-us/microsoftteams/stream-classification-in-call-quality-dashboard#classifier-definitions

For audio streams, any of the five classifiers, which are calculated for the average based on the length of the call, could all be within "good" parameters. It doesn't mean the users didn't experience something that contributed to an audio drop out, static, or glitch.

what are the measurements should i select from CQD for betterment . there are many in jitter , packet, RTT, concealed

To determine if it was a network problem, look at the delta between the average values for the session and the max values. Max values are the maximum detected and reported during the session.

If network metrics look good in the averages and max values, then look to other telemetry data:

Check CPU Insufficient Event Ratio to see if the detected CPU resources available were insufficient and caused poor quality.
Was the audio device in Half Duplex mode to prevent feedback due to microphones that are to close to speakers?
Check the Device Half Duplex AEC Event Ratio. Was the device glitching or the microphone glitching introducing noise or static due to USB Audio Drop outs when plugged into a Hub or Docking Station?
Check the Device Glitches and Microphone glitches event ratios. Was the device itself functioning properly?
Check the Capture and Render Device Not Functioning Event Ratios.

---

If the response is helpful, please click "Accept Answer" and upvote it.

Note: Please follow the steps in our documentation to enable e-mail notifications if you want to receive the related email notification for this thread.