我们提供两款产品，SMeeting 建在 SRTC 之上。先看一句话区分：
- SRTC 给你音视频通道。谁能说话、谁是主持人、会议什么时候开始 —— 这些规则由你自己写。
- SMeeting 连会议规则一起给你。主持人、举手、静音全场、等候室、录制这些都是现成的。
如果你还不确定，从下面这个问题开始：“会议里谁能干什么”这套规则，你想自己写，还是想直接用？
怎么选
拿不准的时候优先看 SMeeting。会控这套规则看着简单，真正实现起来（多端状态同步、主持人权限、断线重入后的状态恢复）是会议产品里最耗时的部分。如果你的形态就是会议，自己写一遍不划算。
两者的关系
SMeeting 不是 SRTC 的替代品，而是它的上层封装：
用 SMeeting 时，底层的 SRTC 仍在工作，只是被包在里面 —— 你不需要直接调它。
术语对照
两层的术语不通用，看文档时留意自己在哪一层：
两层的接口不能混用。SMeeting 的服务端接口不接受频道名，SRTC 的接口也不认识会议号。文档里给的示例代码只在对应的那一层有效。
能力差异
常见疑问
用了 SMeeting，还能直接调 SRTC 吗？
一般不需要。SMeeting 已经把音视频能力包装成会议语义。少数端（如 Swift）保留了访问底层的入口，用于我们没覆盖到的场景，但正常接入用不到。
以后从 SRTC 换到 SMeeting，成本大吗？
客户端代码基本要重写 —— 两层的 API 和概念模型不同。服务端如果本来就把音视频当成独立模块，改动会小一些。所以选型尽量一次到位，不要抱着”先用 SRTC 顶一下，以后再换”的想法。
两个能同时用吗？
同一个业务场景里不建议。不同场景可以分开，比如会议用 SMeeting、客服单聊用 SRTC，各自独立接入即可。
私有化部署有区别吗？
都支持。SMeeting 会多部署一个会议层服务。
下一步
选好了就从对应产品的概览开始：
还是拿不准，可以直接联系我们，说明你的业务形态。 
