Breakout Rooms Information in Participants Endpoint

Description
Breakout room information is not captured properly in the participants endpoint. Currently, going into a breakout room triggers a leave and a join event in the response we get. It would be incredibly helpful to add additional information for these join/leave events so that we know these are not simply people dropping off of calls. (Either change the leave_reason to say something like “Left for a breakout room” or include a room type so that we know if it is the main room, waiting room, or breakout room they are joining/leaving).

Error
The full error message or issue you are running into.

Which App Type (OAuth / Chatbot / JWT / Webhook)?
API

Which Endpoint/s?
/metrics/meetings/{meetingId}/participants

Related to Breakout rooms API - #114 by centangle

It is related, but not quite. This is specifically about the participants endpoint

This is a serious problem (bug?) for a couple of reasons:

  • The participants that sent to the breakout rooms did not leave the meeting. They’re still here. It’s against the purpose (of participant_left / participant_joined events).

  • We need to know the attendance (exact duration in minutes) of each participant. This issue messes up the attendance stats (which we process on our end).

  • When 100 or so participants go to the breakout rooms or come back, often 5 - 6 times each meeting , a considerable amount of participant_left and participant_joined events get sent to the receiving endpoint (our end). This is an unnecessary strain both for Zoom’s servers and ours.

  • The bug has a bug in itself :man_facepalming:t2: The payloads that sent when joining / leaving breakout rooms do not include the meeting id. This is much troublesome since our endpoint serves multiple parallel meetings. I put those payloads into a separate db table named as rogue, then traverse the records of it one by one looking up the email of user through all active events to determine which meeting that payload belongs to.
    Here is an example of incoming event:

 {
  “payload”: {
   “account_id”: “-- ACCOUNT ID --”,
   “object”: {
    “uuid”: “-- UUID --”,
    “participant”: {
     “leave_time”: “-- Leave Time --”,
     “user_id”: “-- Some random code not related to the user, it’s just 2 timestamps stitched together?! → 16578240 2021-01-00 09:17:21:084”,
     “user_name”: “–First and Last Name of User–”,
     “id”: “-- Again some random code not related to the user --”,
     “email”: “-- Email of User --”
    },
    “id”: null, → This should be the Meeting ID !
    “type”: 0,
    “topic”: null,
    “host_id”: “”,
    “duration”: 0,
    “start_time”: null,
    “timezone”: null
   }
  },
  “event_ts”: – A timestamp --,
  “event”: “meeting.participant_left”
 }

@Moderators: all private values have been changed, no need to edit this post.

 
 
Hope that Zoom’s developers could find time to fix this.

~ Fatih

Faith - the corresponding join/leave of the main meeting alongside a join or leave of a breakout room almost entirely correspond with one another. Even without a user being logged in, 99% of the time, you can track users through out. IE the user_id of joining or leaving a breakout room corresponds with a join or leave of the main room.

If any one still cares about this, I can expand more on this with all the details. This was an annoying thing to deal with when I wanted to track users via webhook including breakout rooms.

I have a buggy bot manually go into each breakout room to track the UUIDs. Otherwise, you’ll know things based on different UUIDs for breakout rooms and the main meeting, but not which is which. This works for my set up because breakout rooms are created beforehand

1 Like

Hi @chase_ats, thanks for your reply.
I didn’t know that the timestamps are identical for the leave-main-room & join-breakout-room and vice versa.
I’ll definitely look into it, maybe as an additional verification.

Alas, the main issues are yet to be addressed:

• Joining to breakout room and leaving it shouldn’t be sent as meeting.participant_left or meeting.participant_joined events. They did not leave the meeting. Some other tag / event as meeting .participant_joined_breakout and meeting.participant_left_breakout would be much more useful and less confusing (for the receiving and processing endpoint).

• The bug in bug thing, I’ve mentioned, is more troublesome. The sent event does not include meeting id. There’s no way that my (our) backends would determine which meeting that particular payload belongs to. This is just a sloppy code-writing, nothing else. I wonder if some freelance wannabe developer hired by Zoom copy-pasted a couple of lines of code from a random github library and nobody else cared to look at it :confused:

~ Fatih

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.