> ## 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.

# Out-of-meeting messages

> The out-of-meeting message (IM) path of the SMeeting Swift SDK: enable and disable it after login, receive calls, meeting reminders, waiting room admissions, and sub-meeting help requests before entering a meeting, and track its connection state. Read when users need notifications outside a meeting.

### Overview

Out-of-meeting messages (IM) are a **notification path independent of the meeting**. They solve problems like "how does a user get notified before entering a meeting":

* Someone in a meeting is calling you
* A scheduled meeting is about to start
* You've been admitted from the waiting room
* A sub-meeting you're responsible for is asking for help

In-meeting chat messages don't go through this path—those are [In-meeting messages](/en/meeting/swift/advanced/messaging), which work only during the meeting.

***

### Enable and disable

```swift theme={null}
// You can enable it right after logging in; you don't need to be in a meeting
try await meeting.enableIm()

// When no longer needed
await meeting.disableIm()
```

Key points:

* You must call `login(token:)` first; calling it before logging in throws `SMeetingError.notLoggedIn`
* `logout()` disables this path internally, so you don't need to call it again in your logout flow
* Once set up, the path stays up regardless of whether you're in a meeting

The typical place to enable it is right after a successful login:

```swift theme={null}
try await meeting.login(token: token)
meeting.delegates.add(delegate: self)
try await meeting.enableIm()
```

***

### Events

Every out-of-meeting message event carries a `base` (`ImBaseEventData`) and a `content`:

| `ImBaseEventData` field | Description |
| - | - |
| `sid` | Session ID |
| `uid` | Sender's user ID |
| `name` | Sender's nickname |
| `avatar` | Sender's avatar |

#### Someone is calling you

```swift theme={null}
func meeting(_ meeting: SMeetingEngine, imCallCalling data: ImCallCallingEventData) {
    // data.base.name caller
    // data.content.roomNo / data.content.meetingId / data.content.title
    // Show the incoming call UI; after the user answers, call enterRoom to enter
}
```

#### Meeting reminders

```swift theme={null}
func meeting(_ meeting: SMeetingEngine, imMeetingRemind data: ImMeetingRemindEventData) {
    // data.content.title / creatorName / planTime / planDur
}
```

#### Admitted from the waiting room

```swift theme={null}
func meeting(_ meeting: SMeetingEngine, imAdminMoveOutWaitingRoom data: ImAdminMoveOutWaitingRoomEventData) {
    // data.content.meetingId is the target meeting, which you can enter
}
```

#### A sub-meeting asks for help

```swift theme={null}
func meeting(_ meeting: SMeetingEngine, imUserHelpSubMeeting data: ImUserHelpSubMeetingEventData) {
    // data.content.meetingId / title the sub-meeting asking for help
    // data.content.parent main meeting ID
}
```

***

### Connection state

This path has its own connection state events; don't confuse them with the meeting's reconnection events:

| Event | Description |
| - | - |
| `meetingImIsReconnecting(_:)` | The message path starts reconnecting |
| `meetingImDidReconnect(_:)` | The message path reconnected successfully |
| `meeting(_:imDidDisconnect:)` | The message path is disconnected; `data.reason` describes the reason |

The corresponding connection events for the meeting itself are `meetingIsReconnecting(_:)` / `meetingDidReconnect(_:)` / `meeting(_:didDisconnect:)`.

***

### Related pages

* [In-meeting messages](/en/meeting/swift/advanced/messaging)
* [Waiting room](/en/meeting/swift/advanced/waiting-room)
* [Sub-meetings](/en/meeting/swift/advanced/sub-meetings)