> ## 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 还是 SMeeting

> SRTC 音视频 SDK 与 SMeeting 会议 SDK 的分层关系、能力差异与选型建议

我们提供两款产品，**SMeeting 建在 SRTC 之上**。先看一句话区分：

* **SRTC** 给你音视频通道。谁能说话、谁是主持人、会议什么时候开始 —— 这些规则由你自己写。
* **SMeeting** 连会议规则一起给你。主持人、举手、静音全场、等候室、录制这些都是现成的。

如果你还不确定，从下面这个问题开始：**"会议里谁能干什么"这套规则，你想自己写，还是想直接用？**

***

## 怎么选

| 你的情况                              | 选                       |
| --------------------------------- | ----------------------- |
| 做的就是会议产品，需要主持人、举手、静音全场、等候室这类会控    | **SMeeting**            |
| 想最快上线，能接受我们提供的会议界面                | **SMeeting**（带 UI 极简对接） |
| 交互形态不是会议：直播连麦、客服双人通话、AI 语音对话、远程巡检 | **SRTC**                |
| 已有一套自己的业务规则和 UI，只缺音视频传输能力         | **SRTC**                |
| 服务端旁路录制、转推、AI Agent 接入            | **SRTC**（C SDK 或各端 SDK） |

<Tip>
  拿不准的时候优先看 SMeeting。会控这套规则看着简单，真正实现起来（多端状态同步、主持人权限、断线重入后的状态恢复）是会议产品里最耗时的部分。如果你的形态就是会议，自己写一遍不划算。
</Tip>

***

## 两者的关系

SMeeting 不是 SRTC 的替代品，而是它的上层封装：

```text theme={null}
┌─────────────────────────────────────────┐
│  你的业务                                │
├─────────────────────────────────────────┤
│  SMeeting   房间 / 会议 / 成员 / 会控     │  ← 会议语义
├─────────────────────────────────────────┤
│  SRTC       频道 / 用户 / 流轨道          │  ← 音视频通道
└─────────────────────────────────────────┘
```

用 SMeeting 时，底层的 SRTC 仍在工作，只是被包在里面 —— 你不需要直接调它。

***

## 术语对照

两层的术语**不通用**，看文档时留意自己在哪一层：

|      | SRTC         | SMeeting                 |
| ---- | ------------ | ------------------------ |
| 空间   | 频道 `channel` | 房间 `room` / 会议 `meeting` |
| 进出动作 | 加入 / 退出      | 进入 / 退出                  |
| 参与者  | 用户 `uid`     | 参会成员                     |
| 媒体   | 流轨道 `track`  | 由会议层管理                   |

<Warning>
  两层的接口不能混用。SMeeting 的服务端接口不接受频道名，SRTC 的接口也不认识会议号。文档里给的示例代码只在对应的那一层有效。
</Warning>

***

## 能力差异

| 能力                       |   SRTC   |   SMeeting   |
| ------------------------ | :------: | :----------: |
| 音视频通话、屏幕共享               |     ✅    |       ✅      |
| 自定义信令（给程序看的业务消息）         |     ✅    |       ✅      |
| 会中文字聊天（带历史记录、可禁言）        |   自己实现   |       ✅      |
| 会议外通知通道（呼叫、提醒）           | ✅（IM 通道） |       ✅      |
| 云端录制、MCU 合流              |     ✅    |       ✅      |
| 主持人与会控（静音全场、踢人、改角色）      |   自己实现   |       ✅      |
| 举手、邀请开麦                  |   自己实现   |       ✅      |
| 等候室、子会议、签到               |   自己实现   |       ✅      |
| 会议的预约与生命周期管理             |   自己实现   |       ✅      |
| 现成的会议界面                  |     ❌    | ✅（带 UI 极简对接） |
| 一个用户多端同时在线               | 自己规划 uid | ✅（按设备类型自动区分） |
| 服务端 / 嵌入式接入（录制、AI Agent） | ✅（C SDK） |       ❌      |

***

## 常见疑问

**用了 SMeeting，还能直接调 SRTC 吗？**

一般不需要。SMeeting 已经把音视频能力包装成会议语义。少数端（如 Swift）保留了访问底层的入口，用于我们没覆盖到的场景，但正常接入用不到。

**以后从 SRTC 换到 SMeeting，成本大吗？**

客户端代码基本要重写 —— 两层的 API 和概念模型不同。服务端如果本来就把音视频当成独立模块，改动会小一些。所以**选型尽量一次到位**，不要抱着"先用 SRTC 顶一下，以后再换"的想法。

**两个能同时用吗？**

同一个业务场景里不建议。不同场景可以分开，比如会议用 SMeeting、客服单聊用 SRTC，各自独立接入即可。

**私有化部署有区别吗？**

都支持。SMeeting 会多部署一个会议层服务。

***

## 下一步

选好了就从对应产品的概览开始：

* [SRTC 概览](/zh/rtc/overview) —— 音视频 SDK
* [SMeeting 概览](/zh/meeting/overview) —— 会议 SDK

还是拿不准，可以直接联系我们，说明你的业务形态。