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

​
频道 Channel

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

​
打开与销毁

  • 第一个用户加入时，频道若未打开会自动打开
  • 也可以提前手动打开 —— 需要预先设置频道扩展属性时用得上
  • 频道开启后 2 小时内无人加入，或最后一个用户离开 2 小时后，自动销毁
如果频道属性要在第一个人进来前就位（例如布局配置、业务标记），用服务端接口提前手动打开频道并写入属性，避免”先进来再改属性”导致的短暂不一致。

​
用户 User

SRTC 没有自己的用户体系。 所有用户信息由你定义，SRTC 只认 Token 里签发的 uid。 uid 与频道的关系有两条规则：
  • 一个 uid 可以同时加入多个不同频道
  • 同一个 uid 加入同一个频道时，后加入的会顶掉先加入的
一般直接把业务系统的用户 ID 当作 uid 即可。如果要让同一个业务用户在一个频道里有多个并存身份（比如多设备同时在线），把 sessionId 或设备标识拼进 uid。 需要”一个 uid 同时只能在一个频道里”这类限制，由你的后端自己控制 —— SRTC 不做这个约束。 uid 怎么签发见 Token 与鉴权。

​
流轨道 Track

每一路音频、每一路视频都是一个流轨道。一个用户可以：
  • 发布多个本地轨道（摄像头、屏幕共享、麦克风……）
  • 订阅多个远端轨道
SRTC 只负责传输轨道里的媒体数据，每个轨道的业务含义由你定义 —— 用 desc 字段标记这一路是摄像头还是屏幕共享，接收端据此决定怎么渲染。

​
订阅是显式的

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

​
消息通道

除了音视频，SRTC 还提供两条消息通道。它们的区别只有一个：收发消息时，人在不在频道里。
这里的「IM」不是聊天产品。 名字容易让人联想到微信、客服系统或第三方 IM 云服务，但 SRTC 的 IM 只是一条频道之外的实时消息通道，用来在用户还没进频道时把消息推给他。它不提供：会话列表、聊天记录、消息漫游、群组、已读回执、离线消息队列。消息不做持久化存储 —— 只保证断线重连期间的补发。接收方长时间离线时的兜底（存库、转推送、短信）需要你自己的业务侧做。
发送必须走后端是有意设计的：消息先经过你的服务端，你才有机会做敏感词过滤、频率限制、权限校验这些业务规则。 同一个 uid 可以在多台设备上同时连 IM，每个连接有独立的 sid —— 所以「发给某个人」和「发给某台设备」是两件事。

​
与 SMeeting 的关系

如果你需要的是主持人、举手、静音全场这类会议规则，它们不在 SRTC 里 —— 那是 SMeeting 的范围。SRTC 给的是通道，规则要你自己写。 两者怎么选见 选 SRTC 还是 SMeeting。

​
下一步