Hi,
We Just found out that Zoom is not able to provide Meeting Quality Score per meeting and per participant. We are looking at the following endpoints:
Meeting API? - only returns aggregated quality score for all meetings in a given time range
Meeting API - does not return a meeting quality score , just raw stats about packet loss, etc.
We’d like to determine which Zoom participant has a low score on a specific meeting so we can act on it. Surprised that zoom doesn’t have this.
Any help or guidance is appreciated.
Amer
Hi @amer.bashimam
Thanks for reaching out to the Zoom Developer Forum, I am happy to help here!
Have you taken a look at our QSS APIs?
Hi, one of Amer’s co-workers here. Those endpoints look like they’re simpler than the meeting participants QoS endpoint in that they return aggregated values instead of minute-by-minute stats, and I guess if a user disconnects and reconnects it combines them instead of returning separate collections for each connection. However, they’re still returning bitrate in Kbps, latency in ms, etc. What we’re really looking for is a very high level “was the call quality good or bad” endpoint that doesn’t require us to research how much packet loss of 1% affects the user’s subjective experience. The bad/poor/fair/good breakdown in the dashboard endpoint would be great if we could just get that for a selected meeting (and separated out per-user) instead of just giving us an aggregated count of good/bad calls.
On a somewhat related note, we’re also seeing an issue with the meeting participant QoS endpoint which, it’s not entirely clear what’s going on, but my best guess is that it’s returning incomplete data shortly after the meeting ends, and then when we call it again later the results are different/complete. Is that something that can happen with that endpoint?
Hi @kyle.kinney
Thanks for sharing more information with me, I totally understand what you are saying.
Unfortunately, we do not have an endpoint that will only return a high-level score of the call quality. We only have those that you have used and identified.
Disappointing, but not unexpected. What about the seemingly-incomplete data we’re seeing shortly after the meeting ends? I can’t say for sure that that’s what’s happening, but I don’t know how else to explain some of these results. Is that something that can happen with the meeting participant QoS endpoint?
@elisa.zoom ? Any thoughts on the results seeming to change?
Hi @kyle.kinney
Sorry for the late reply here, I did not get a notification from your previous message.
I was able to look internally and it looks like for QoS endpoints, that is the expected behavior because there is a lag in the data we are sending back.
All right, I guess we’ll have to figure out a way to work around that. Is there a way to detect the incomplete data, either on the QoS endpoint or the QSS endpoint you mentioned above?
What we’re trying to accomplish here is call the call quality endpoint once when our meetings end and process and save the results. That way, we can load up the call quality metrics for a page full of meetings at once without having to call this heavy endpoint a couple dozen times on every page load. If the endpoint can return incomplete data when we call it too soon after the meeting ends, we’ll need some way to notice that and flag it to retry later.
Thanks for understanding!
The only workaround that I can think of for this issue could be if you set up webhook events on your application, the only problem is that these webhooks are only available for QSS and this normally requires you to contact the Sales team to be able to access these events