Skip to main content

Overview

A meeting has two “request” flows that go in opposite directions and are easy to confuse. Tell them apart first: HandupType has four raise-hand types: .mic asks to turn on the microphone, .camera asks to turn on the camera, .chat asks for the right to speak, and .share asks to share.

Members raise a hand


The host receives a raised hand

UserHandupStep indicates which step of the flow the event is at: In other words, this one event carries two kinds of notifications—“raise-hand requests” and “responses to the host’s request”—and you handle them differently based on step.

The host approves a raised hand

The approval result is delivered to the relevant members through an event:
Approval doesn’t turn on the member’s microphone or camera automatically—after receiving this event, the member side needs to call requestOpenMic() / requestOpenCamera() itself.

The host asks a member to turn on media

The member side receives:
To accept, pass byAdmin: true together with adminUid to the turn-on API, so the SDK takes the “respond to the request” path instead of “request on your own”:
To decline:
Whether the member accepts or declines, the host side receives a userDidHandup with step set to .confirmOpen or .rejectOpen.

The host turns off a member’s devices directly

Turning off doesn’t require consent:
The affected member’s SDK stops the stream automatically and reports userMicStateDidChange / userCameraStateDidChange once, with byAdmin set to true and opUid set to the operator; you can use this to show the user a message such as “The host turned off your microphone.”

A complete interaction example