房间与会议
两个词经常同时出现，含义不同：
日常接入中你主要打交道的是会议 ID：创建会议拿到它，之后的进入、会控、录制都用它。房间号更多用于对外分发（把号码发给参会者）。
生命周期
- 登录之后才能调用会议管理接口
- 进入会议之后才能调用会中接口（媒体控制、会控、消息）
- 退出会议不影响登录状态，可以接着进下一场
成员与角色
SMeeting 内置了一套会中角色，三档，覆盖大多数会议场景，不需要你自己设计。接口和各端 SDK 里的role 字段默认就是这三个取值：
另有观众（入会时的
is_audience），它不是角色而是入会形态：只收流、不参与互动、不出现在成员列表里，与上面三档相互独立。它对应的是底层 SRTC 的「听众」——注意 SRTC 也有个 role 字段（普通成员 / 听众），和会议层这三档不是一回事。
如果业务上还要区分「讲师 / 助教 / 学员」这类身份，最省事的做法是：会控权限仍用上面三档承载，业务身份放在成员的扩展字段（extend_info）里，由你自己的界面按需渲染。身份体系差异大到三档装不下时，内置角色可以整套换掉，见下面的「自定义角色」。
会控动作大多是请求 - 批准的形态：成员举手申请开麦，主持人批准；主持人邀请成员开麦，成员同意或拒绝。这样设计是因为开摄像头麦克风涉及用户隐私，不能由主持人单方面强开。
自定义角色
内置的三档角色可以整套不启用，换成完全由你定义的角色体系。有些项目的角色和「主持人 / 联席主持人 / 普通成员」根本不是一回事：典型的是招投标，专家、澄清人、见证人、监督人各是一类身份，谁能看到谁的画面、谁听到的是真声谁听到的是变声，都按身份来。招投标这个场景我们已经做过：有一套角色定制好的标准招投标会议产品，对接时直接用，不需要你自己实现这套角色和界面。其他需要自定义角色的场景，你可以自己开发，也可以委托我们定制开发——都请联系我们。
app.enable_role，默认关闭，需要私有化部署，联系我们开启），role 就变成一个业务自己定义的字段：
- 取值和含义完全由你定义，服务端只存储和透传，不再解释它。自定义值从
1开始编号，0表示未设置（按普通成员处理） - 角色只认成员登记表：建会 / 改会时用
conferee_details[].role预设，会中用「主持人更新用户会中角色」接口调整（会中改的也会落库，重新入会依然生效）。不再从creator/co_hosts推导，没有登记过的人不会有角色 - 服务端不再按角色做会控判定：内置的那些「普通成员不许自行解除静音 / 开视频 / 发起共享」限制全部跳过，谁能干什么由你定制的客户端界面决定
- 没有内置主持人概念：转移主持人接口在这个模式下直接返回错误
- 聊天禁用对所有人一视同仁：全体禁言 / 单人禁言照常生效，服务端不会再给主持人留例外
role 这个字段。差异化的收听收看要在客户端实现——拿到成员列表里的 role 后，自己决定订阅哪些人的流、把哪些人静音、哪些画面不渲染；变声这类音频处理同理，由业务侧自行实现。
三条消息通道
SMeeting 里有三种「消息」，接口和适用场景都不同。开发者最常搞混的是后两者：
三者的关系可以这样记：会中聊天给人看，自定义消息给程序看，IM 在会议之外找人。
底层上，会中的两种消息走的是 SRTC 的频道内消息，会议外消息走 SRTC 的频道外 IM 通道 —— 但你用 SMeeting 时不需要直接接触这一层。
一个用户，多端同时在线
SMeeting 内置了多端在线的支持：同一个用户在手机和电脑上同时进会，会被识别成两个参会身份（按设备类型区分），互不顶替。 这一层映射由 SMeeting 自动完成 —— 底层每个设备各占一个 RTC 身份，但在会议语义上它们属于同一个用户。你不需要自己拼 uid。与 RTC 层的术语差异
SMeeting 建在 SRTC 之上，两层的名词不通用。混用会让你在读接口文档时反复卡壳：
在 SMeeting 的接口里你只会看到会议语义的命名。
少数地方会看到 RTC 层的说法，那不是笔误：错误码里带「频道」字样的（如「该会话不在频道中」）确实来自底层 RTC，原样透传给你便于排查。