Feature Request: Participant A/V Status in Breakout Rooms (Meeting SDK for MacOS)

The Problem

The native Zoom desktop client’s breakout room controller displays real-time per-participant status inside each room: mute/unmute state, audio activity indication (animated when audio is detected), video on/off, and screen sharing. This data clearly reaches the host’s client already.

The Meeting SDK’s breakout room data helper (ZoomSDKBODataHelper) exposes room lists, per-room participant lists, names, and join/leave events — but none of the A/V or sharing state that the native UI renders. SDK integrators have zero visibility into participant state once rooms are opened.

Requested API Additions

Status queries on ZoomSDKBODataHelper:

Method Returns
getBOUserAudioStatus(withUserID:) Muted / unmuted / no audio
isBOUserSendingAudio(withUserID:) Bool (mic is transmitting)
isBOUserVideoOn(withUserID:) Bool
isBOUserSharing(withUserID:) Bool

Change callbacks on ZoomSDKBODataHelperDelegate:

Callback Fires when…
onBOUserAudioStatusChange:boID: Participant mutes/unmutes
onBOUserActiveAudioChange:boID: Active audio participants change (speaking indication)
onBOUserVideoStatusChange:boID: Camera state changes
onBOUserShareStatusChange:boID: Screen sharing starts/stops

Including the room BO ID lets the host attribute events to specific rooms without extra lookups.

Rationale

This is a parity request. The native breakout room controller already surfaces all of this information to the host in real time. The SDK should expose the same data so that custom-UI integrations can match the functionality of the built-in Zoom experience.

Why Workarounds Don’t Work

  • Polling the data helper — no A/V or sharing fields exist to poll
  • Joining each room — host can only be in one room at a time; doesn’t scale
  • Zoom Apps SDK — different architecture; not a native SDK integration
  • REST API — no real-time per-participant status in breakout rooms

Platform & Version

macOS Meeting SDK 7.0.0. Same gap exists on Windows/Linux.