Skip to main content
本页给出接入 SRTC 的最短路径。先看清分工，再照平台入口往下走。

​
谁负责什么

一次接入涉及四个角色：两个是你的，两个是我们的。 一句话记住这条边界：我们不碰你的用户体系，你不碰媒体流。
  • 你不需要在我们这边注册用户 —— uid 直接用你业务系统里现成的用户 ID
  • 音视频数据不经过你的服务器 —— 客户端直连我们的媒体服务，你的带宽账单不会因为开会而涨
整条链路里，你的后端负责「换钥匙」，你的客户端负责「用钥匙」，媒体走我们，业务判断走你。

​
接入前

三件事按顺序做完，再去看具体平台的文档：
1

申请应用

拿到 AppID 和 AppKey。AppKey 是服务端密钥，绝不能放进客户端 —— 详见 Token 与鉴权。
2

理解模型

SRTC 只有三个对象：频道、用户、流轨道。它不带用户体系，也不带业务规则。花五分钟读一遍 核心概念，后面所有接口都会好懂很多。
3

打通 Token 签发

上图第 3 步，是整个接入里唯一必须写的服务端代码：校验完你自己的用户身份后，用 AppKey 签名调我们的 grant 接口，把 token 返给客户端。调试阶段可以先在开发者后台生成临时 Token 跑通客户端，正式环境必须走后端签发。后端这段怎么封装、权限边界怎么划，有一份现成的说明：业务后端参考实现。

​
选择你的平台

微信小程序场景建议用 <web-view> 嵌入基于 Web SDK 实现的页面，一套代码同时覆盖浏览器和小程序。详见 Web SDK 集成。

​
典型接入顺序

各端 API 名称不同，但流程是一致的：
最容易踩的坑是回调注册晚于加入频道 —— 那样会漏掉”已在频道内的用户”这批事件，表现为进会后看不到别人。各端文档的快速开始都按正确顺序给了示例。

​
几个最常问的边界问题

音视频要经过我的服务器吗？ 不需要。客户端直连我们的媒体服务，你的后端只参与鉴权和业务判断。 用户要先在你们那边注册吗？ 不需要。我们不存你的用户资料，uid 用你自己的用户 ID 即可。 AppKey 放前端会怎样？ 拿到它的人可以签发任意用户身份的 token、踢人、销毁频道。它只能待在服务端。 权限规则谁来判？ 你。我们只认签发出来的 token 里写了什么，「这个人能不能进这个频道」是你的后端在第 2 步做的判断。

​
如果你要做的是会议

主持人、举手、静音全场、等候室这些不在 SRTC 里，需要自己实现。如果你的形态本来就是会议产品，先看一眼 选 SRTC 还是 SMeeting 再决定从哪一层接入。