> ## 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/...` 这一套对外开放，需用 app_id + app_key 做 HMAC-SHA256 签名，只能从业务方自己的后端调用。文档中若出现其它前缀的接口，均为内部接口，不要建议客户调用。
> app_key 是服务端密钥，绝不能出现在客户端代码、前端配置或移动 App 里。客户端加入频道用的 token 必须由业务方后端调用 `/server/v1/channel/grant` 签发后下发。
> SRTC 与 SMeeting 是上下两层不同的产品，术语不通用：SRTC 是音视频底座，说「频道 channel」「加入 / 退出」；SMeeting 建在 SRTC 之上，说「房间 room」「会议 meeting」「进入 / 退出」。回答时按用户所在的层用对应术语，不要把「房间」「会议」安到 SRTC 的接口上。
> 同一能力在各端 SDK 里的包名、类名、方法名并不相同。写示例代码时请使用文档中该端自己的 API，不要把一个端的写法套到另一个端上。

# 核心概念

> SRTC 的频道、用户与流轨道模型，以及频道的打开与销毁规则

SRTC 只做三件事：**实时消息传输、状态同步、音视频传输**。它不带用户体系、不带业务规则 —— 这些由你决定。整个模型只有三个对象：

```text theme={null}
频道 Channel
 └── 用户 User
      └── 流轨道 Track
```

***

## 频道 Channel

频道是一个音视频空间，同一频道内的用户可以互相收发音视频。频道名和频道信息都由你自定义。

### 打开与销毁

* 第一个用户加入时，频道若未打开会**自动打开**
* 也可以提前手动打开 —— 需要预先设置频道扩展属性时用得上
* 频道开启后 2 小时内无人加入，或最后一个用户离开 2 小时后，**自动销毁**

<Tip>
  如果频道属性要在第一个人进来前就位（例如布局配置、业务标记），用服务端接口提前手动打开频道并写入属性，避免"先进来再改属性"导致的短暂不一致。
</Tip>

***

## 用户 User

**SRTC 没有自己的用户体系。** 所有用户信息由你定义，SRTC 只认 Token 里签发的 `uid`。

uid 与频道的关系有两条规则：

* 一个 uid 可以同时加入**多个不同**频道
* 同一个 uid 加入**同一个**频道时，后加入的会顶掉先加入的

一般直接把业务系统的用户 ID 当作 uid 即可。如果要让同一个业务用户在一个频道里有多个并存身份（比如多设备同时在线），把 sessionId 或设备标识拼进 uid。

需要"一个 uid 同时只能在一个频道里"这类限制，由你的后端自己控制 —— SRTC 不做这个约束。

uid 怎么签发见 [Token 与鉴权](/zh/rtc/token)。

***

## 流轨道 Track

每一路音频、每一路视频都是一个流轨道。一个用户可以：

* 发布多个本地轨道（摄像头、屏幕共享、麦克风……）
* 订阅多个远端轨道

SRTC 只负责传输轨道里的媒体数据，**每个轨道的业务含义由你定义** —— 用 `desc` 字段标记这一路是摄像头还是屏幕共享，接收端据此决定怎么渲染。

### 订阅是显式的

加入频道不等于自动收到所有画面。你需要主动订阅想看的轨道，或开启自动订阅。这样设计是为了让你能按需控制带宽 —— 比如九宫格只订阅当前页的九路，翻页时再切换。

***

## 消息通道

除了音视频，SRTC 还提供两条消息通道。它们的区别只有一个：**收发消息时，人在不在频道里。**

|      | 频道内自定义消息          | 频道外 IM 消息                    |
| ---- | ----------------- | ---------------------------- |
| 前提   | 已加入频道             | 已启用 IM（`enableIm`），不需要在任何频道里 |
| 发送方式 | 客户端 SDK 直接发       | **只能由你的后端调服务端接口发**           |
| 接收方式 | 频道事件 `custom_msg` | IM 事件 `im_msg`               |
| 典型用途 | 举手、白板同步、状态广播等会中信令 | 会前呼叫、会议邀请、通知提醒               |
| 生命周期 | 随频道结束             | 与频道无关，只要连着就能收                |

<Warning>
  **这里的「IM」不是聊天产品。** 名字容易让人联想到微信、客服系统或第三方 IM 云服务，但 SRTC 的 IM 只是一条**频道之外的实时消息通道**，用来在用户还没进频道时把消息推给他。

  它**不提供**：会话列表、聊天记录、消息漫游、群组、已读回执、离线消息队列。消息不做持久化存储 —— 只保证断线重连期间的补发。接收方长时间离线时的兜底（存库、转推送、短信）需要你自己的业务侧做。
</Warning>

发送必须走后端是有意设计的：消息先经过你的服务端，你才有机会做敏感词过滤、频率限制、权限校验这些业务规则。

同一个 uid 可以在多台设备上同时连 IM，每个连接有独立的 `sid` —— 所以「发给某个人」和「发给某台设备」是两件事。

* 客户端用法：[Web 频道消息](/zh/rtc/web/channel-messages)
* 服务端接口：[服务端 API · IM 消息](/zh/rtc/server-api/im)

***

## 与 SMeeting 的关系

如果你需要的是主持人、举手、静音全场这类**会议规则**，它们不在 SRTC 里 —— 那是 [SMeeting](/zh/meeting/overview) 的范围。SRTC 给的是通道，规则要你自己写。

两者怎么选见 [选 SRTC 还是 SMeeting](/zh/choose)。

***

## 下一步

* [Token 与鉴权](/zh/rtc/token) —— 接入前必须先搞清楚的一步
* 选择你的平台开始接入：[Web](/zh/rtc/web/integration) · [Android](/zh/rtc/android/integration) · [Windows](/zh/rtc/windows/integration) · [Swift](/zh/rtc/swift/integration) · [iOS](/zh/rtc/ios/integration) · [C](/zh/rtc/capi/integration)