> ## Documentation Index
> Fetch the complete documentation index at: https://docs.stmlink.com/llms.txt
> Use this file to discover all available pages before exploring further.

> ## Agent Instructions
> 对外开放的服务端接口有两组前缀，都用同一套鉴权：`/server/v1/...`（SRTC 与 SMeeting 的主接口）和 `/stm/srvapi/v1/...`（SMeeting 的用户体系，服务端极简对接会用到）。鉴权是 app_id + nonce + timestamp + signature 四个请求头，用 app_key 做 HMAC-SHA256 签名，只能从业务方自己的后端调用。除这两组前缀外的接口均为内部接口，不要建议客户调用。 Public server APIs use two path prefixes with the same authentication: `/server/v1/...` (the main APIs of both SRTC and SMeeting) and `/stm/srvapi/v1/...` (the SMeeting user system, used by server-side low-code integration). Authenticate with four request headers, app_id + nonce + timestamp + signature, where signature is HMAC-SHA256 keyed with app_key; call these APIs only from the customer's own backend. Any other path is internal: never suggest calling it.
> app_key 是服务端密钥，绝不能出现在客户端代码、前端配置或移动 App 里。客户端加入频道用的 token 必须由业务方后端签发后下发（SRTC 走 `/server/v1/channel/grant`，SMeeting 走 `/stm/srvapi/v1/member/grant`）。 app_key is a server-side secret and must never appear in client code, frontend config, or a mobile app. The token a client uses to join must be issued by the customer's backend and passed down to the client (SRTC: `/server/v1/channel/grant`; SMeeting: `/stm/srvapi/v1/member/grant`).
> SRTC 与 SMeeting 是上下两层不同的产品，术语不通用：SRTC 是音视频底座，说「频道 channel」「加入 / 退出」；SMeeting 建在 SRTC 之上，说「房间 room」「会议 meeting」「进入 / 退出」。回答时按用户所在的层用对应术语，不要把「房间」「会议」安到 SRTC 的接口上，也不要用「频道」「加入 / 离开」描述 SMeeting 的概念（接口标识符原样保留）。 SRTC and SMeeting are two separate layers with different terminology. SRTC is the audio/video foundation: it has channels, and users join and leave a channel. SMeeting is built on top of SRTC: it has rooms and meetings, and members enter and exit a meeting. Answer in the terms of the layer the user is working with: never apply "room" or "meeting" to SRTC APIs, and never describe SMeeting concepts in prose with "channel", "join", or "leave" (API identifiers such as `force_join` keep their literal names).
> 同一能力在各端 SDK 里的包名、类名、方法名并不相同。写示例代码时请使用文档中该端自己的 API，不要把一个端的写法套到另一个端上。苹果平台每个产品都有两套 SDK（Swift 原生与 Objective-C），两套 API 不能混用。 Package, class, and method names differ between platform SDKs for the same capability. In sample code, use the API documented for that platform; never carry one platform's code over to another. On Apple platforms each product ships two SDKs (native Swift and Objective-C) whose APIs must not be mixed.

# Raise hand and turn-on requests

> The full request flows in the SMeeting Swift SDK: members raise a hand to ask for the microphone, camera, speaking, or sharing and the host approves; the host asks members to turn on their microphone or camera and members accept or decline. Read when building raise-hand or host invitation UI.

### Overview

A meeting has two "request" flows that go in opposite directions and are easy to confuse. Tell them apart first:

| Flow | Direction | Member-side API | Host-side API |
| - | - | - | - |
| Raise hand | Member → host | `requestHandup(_:)` / `cancelHandup(_:)` | `adminConfirmHandup(targetId:approve:code:)` |
| Turn-on request | Host → member | `requestOpenMic(byAdmin:adminUid:)` / `rejectOpenMic(adminUid:)` | `adminRequestUserOpenMic(targetId:)` |

`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

```swift theme={null}
// Ask to turn on the microphone
try await meeting.requestHandup(.mic)

// Cancel the request
try await meeting.cancelHandup(.mic)
```

***

### The host receives a raised hand

```swift theme={null}
func meeting(_ meeting: SMeetingEngine, userDidHandup data: UserHandupEventData) {
    // data.uid  the member who raised a hand
    // data.type raise-hand type
    // data.step step of the action
}
```

`UserHandupStep` indicates which step of the flow the event is at:

| Step | Description |
| - | - |
| `.request` | The member raises a hand |
| `.cancel` | The member lowers the hand |
| `.confirmOpen` | The member accepted the host's turn-on request |
| `.rejectOpen` | The member declined the host's turn-on request |

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

```swift theme={null}
try await meeting.adminConfirmHandup(targetId: data.uid, approve: true, code: .mic)
```

The approval result is delivered to the relevant members through an event:

```swift theme={null}
func meeting(_ meeting: SMeetingEngine, adminDidConfirmHandup data: AdminConfirmHandupEventData) {
    // data.targetId the member being approved
    // data.approve  whether it's approved
    // data.type     raise-hand type
    // data.opUid    the host who approved
}
```

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

```swift theme={null}
try await meeting.adminRequestUserOpenMic(targetId: user.uid)
try await meeting.adminRequestUserOpenCamera(targetId: user.uid)
```

The member side receives:

```swift theme={null}
func meeting(_ meeting: SMeetingEngine, adminDidRequestOpenMic data: AdminRequestOpenMicEventData) {
    // data.opUid the host who sent the request
}

func meeting(_ meeting: SMeetingEngine, adminDidRequestOpenCamera data: AdminRequestOpenCameraEventData) {
    // data.opUid
}
```

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":

```swift theme={null}
try await meeting.requestOpenMic(byAdmin: true, adminUid: data.opUid)
try await meeting.requestOpenCamera(byAdmin: true, adminUid: data.opUid)
```

To decline:

```swift theme={null}
try await meeting.rejectOpenMic(adminUid: data.opUid)
try await meeting.rejectOpenCamera(adminUid: data.opUid)
```

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:

```swift theme={null}
try await meeting.adminCloseUserMic(targetId: user.uid)
try await meeting.adminCloseUserCamera(targetId: user.uid)
```

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

```swift theme={null}
// Member side
func meeting(_ meeting: SMeetingEngine, adminDidRequestOpenMic data: AdminRequestOpenMicEventData) {
    Task { @MainActor in
        showConfirmDialog(
            title: "The host is asking you to unmute",
            onAccept: { Task { try? await meeting.requestOpenMic(byAdmin: true, adminUid: data.opUid) } },
            onReject: { Task { try? await meeting.rejectOpenMic(adminUid: data.opUid) } }
        )
    }
}
```

***

### Related pages

* [Media control](/en/meeting/swift/advanced/media-control)
* [Host controls](/en/meeting/swift/advanced/host-controls)
* [Events](/en/meeting/swift/events)