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

# Key concepts

> The SRTC model of channels, users, and tracks: when channels open and are destroyed, how uid maps to channels, explicit subscription, and in-channel vs. out-of-channel IM messages. Read before calling any SRTC API.

SRTC does only three things: **real-time message delivery, state sync, and audio and video transport**. It has no user system and no business rules—those are up to you. The whole model has just three objects:

```text theme={null}
Channel
 └── User
      └── Track
```

***

## Channel

A channel is an audio and video space; users in the same channel can send and receive audio and video with each other. You define the channel name and channel info yourself.

### Opening and destruction

* When the first user joins, the channel **opens automatically** if it isn't open yet
* You can also open it manually in advance—useful when you need to set channel properties beforehand
* If no one joins within 2 hours of the channel opening, or 2 hours after the last user leaves, the channel is **destroyed automatically**

<Tip>
  If channel properties need to be in place before the first person arrives (for example, layout configuration or business flags), use the server API to open the channel manually in advance and write the properties, to avoid the brief inconsistency of "join first, then change properties".
</Tip>

***

## User

**SRTC has no user system of its own.** You define all user information; SRTC only trusts the `uid` issued in the token.

Two rules govern how a uid relates to channels:

* One uid can join **multiple different** channels at the same time
* When the same uid joins the **same** channel again, the later join replaces the earlier one

Usually you can use your system's user ID directly as the uid. If the same business user needs multiple coexisting identities in one channel (for example, online on multiple devices at once), append a sessionId or device identifier to the uid.

If you need a restriction like "a uid can only be in one channel at a time", enforce it in your backend—SRTC doesn't impose this constraint.

For how uids are issued, see [Token and authentication](/en/rtc/token).

***

## Track

Each audio stream and each video stream is a track. A user can:

* Publish multiple local tracks (camera, screen sharing, microphone, and more)
* Subscribe to multiple remote tracks

SRTC only transports the media data in tracks; **you define what each track means for your business**—use the `desc` field to mark whether a track is the camera or screen sharing, and the receiver decides how to render it accordingly.

### Subscription is explicit

Joining a channel doesn't mean you automatically receive all video. You need to subscribe to the tracks you want, or turn on auto-subscribe. This design lets you control bandwidth as needed—for example, a 3×3 grid subscribes only to the nine tracks on the current page and switches when the user pages.

***

## Messaging

Besides audio and video, SRTC provides two messaging paths. They differ in only one way: **whether the user is in the channel when sending and receiving messages.**

| | In-channel custom messages | Out-of-channel IM messages |
| - | - | - |
| Prerequisite | Joined the channel | IM enabled (`enableIm`); no need to be in any channel |
| How to send | Sent directly by the client SDK | **Only sent by your backend calling the server API** |
| How to receive | Channel event `custom_msg` | IM event `im_msg` |
| Typical use | In-call signaling such as raise hand, whiteboard sync, and status broadcasts | Pre-call ringing, meeting invitations, notifications and reminders |
| Lifecycle | Ends with the channel | Independent of channels; received as long as the connection is up |

<Warning>
  **IM here is not a chat product.** The name suggests WeChat, customer service systems, or third-party IM cloud services, but SRTC's IM is just a **real-time messaging path outside of channels**, used to push messages to a user before they join a channel.

  It **does not provide** conversation lists, chat history, message roaming, groups, read receipts, or offline message queues. Messages aren't persisted—the only guarantee is that messages missed during a disconnect are resent after reconnecting. Fallbacks for a recipient who is offline for a long time (storing in a database, forwarding as push notifications, SMS) must be handled on your side.
</Warning>

Requiring sends to go through your backend is intentional: because messages pass through your server first, you get the chance to apply business rules such as sensitive-word filtering, rate limiting, and permission checks.

The same uid can connect to IM on multiple devices at once, and each connection has its own `sid`—so "send to a person" and "send to a device" are two different things.

* Client usage: [Web channel messages](/zh/rtc/web/channel-messages) (Chinese)
* Server API: [Server API · IM messages](/en/rtc/server-api/im)

***

## Relationship to SMeeting

If what you need are **meeting rules** such as host, raise hand, and mute all, they aren't in SRTC—that's the scope of [SMeeting](/en/meeting/overview). SRTC gives you the transport; you write the rules yourself.

For how to choose between them, see [Choosing SRTC or SMeeting](/en/choose).

***

## Next steps

* [Token and authentication](/en/rtc/token)—the step you must understand before integrating
* Choose your platform and start integrating: [Web](/en/rtc/web/integration) · [Android](/en/rtc/android/integration) · [Windows](/zh/rtc/windows/integration) (Chinese) · [Swift](/en/rtc/swift/integration) · [iOS](/zh/rtc/ios/integration) (Chinese) · [C](/zh/rtc/capi/integration) (Chinese)