Description
I call “List meeting participants QoS API” to know how often meeting participants speak.
In the case of “type=past”, there is no problem.
In the case of “type=live”, I have the following problems.
Only the last 30 minutes of data is returned (is this a specification?).
For the first 10 minutes or so of the meeting, audio_output for most participants is returned empty
I have attached a graph of the audio_output for each of “type=live” and “type=past” for the same meeting.
“type=live”
“type=past”
Error?
No error messages.
As mentioned above, audio_output, which should be present, may come up empty.
API Endpoint/s?
GET /metrics/meetings/{meetingId}/participants/qos
How To Reproduce
GET /metrics/meetings/{meetingId}/participants/qos?type=live (with any meeting ID)
QoS query logic is 30-minutes&meeting-start-time meaning the response shows 30 minute intervals from the time the endpoint is called up to the meeting start time.
If the participant joins before meeting start time, there will be many blank objects returned for the time the participant was in the meeting before it started.
Subsequently, if the participant joins after the meeting starts, there will be blank objects for the time in which the participant was not present.
QoS query logic is 30-minutes&meeting-start-time meaning the response shows 30 minute intervals from the time the endpoint is called up to the meeting start time.
I understood that this is a specification.
If the participant joins before meeting start time, there will be many blank objects returned for the time the participant was in the meeting before it started.
Subsequently, if the participant joins after the meeting starts, there will be blank objects for the time in which the participant was not present.
In the cases I have reported, no one has joined in the middle of the meeting.
So I don’t think this explanation applies.
Ahh I see. We need to look at your requests more in depth then. Can you please submit a support ticket with the following info:
account id
app credentials you’re using to make the requests
a sample of the full request/response bodies for the “type=live” requests where you’re seeing unexpected behavior (screenshot and JSON please)
the graphs of the audi_output for each type you shared here
steps to reproduce
link to this dev forum post
and mention that Gianni worked with a customer who experienced something similar in ZOOM-326008, but it does not seem to apply here (for the reasons you shared in your most recent response)