场景接入
多台设备如何加入同一个房间进行语音对讲？
从两台设备验证收发，再扩展多人房间。了解 PTT、成员同步、通话抢占和断线恢复，区分在线、加入请求与实际入房。
先回答：用房间组织成员，用 PTT 控制发言
多人对讲适合一组设备持续处在同一个交流空间，例如会议终端、巡检调度和家庭房间间的语音交流。一对一通话通常先选择联系人再呼叫；房间模式则先加入共同房间，再按规则发言和收听。本文以探鸽公开示例说明最小体验与接入思路，不把示例默认配置当作所有产品的限制。
先准备两台设备，确认各自能上线
至少准备两台已绑定、已上线且身份独立的设备。Windows Python 模拟器可按文档启用 --with-mic 来使用麦克风和扬声器；Linux C 示例默认发送文件，实际出声需要接入播放 sink。两个进程不应复用同一份设备身份。初次验证可让两端分开放置，减少同一房间扬声器反馈的干扰。
创建房间、加入、检查成员
在 Web 设备列表中打开设备 A 的“多人对讲”，创建房间并记下六位房间号；需要密码时按界面设置。再打开设备 B 的多人对讲，输入同一房间号与密码。房间号按字符串处理，保留前导零。返回设备列表不等于退出房间，要结束房间关系时使用明确的退出操作。
当前模拟器可用 room status 检查房间号、在线人数和成员状态。创建或加入请求被保存，只说明业务关系已经记录；设备可能仍离线、正在连接或被其他通话占用。需要确认实际入房，再开始声音测试。
分别验证 A 到 B 和 B 到 A 的声音
先由 A 按住说话键，确认 B 能听到；松开后停止发送，再由 B 发言，确认 A 能听到。模拟器对应命令为 room ptt down 和 room ptt up。文件模式发送测试音频，麦克风模式发送真实采集。两台通过后，再加入第三台检查成员变化和多人发言。
模拟器操作清单：建立一个可重复的双向测试
下面的命令输入到已启动且绑定在线的设备模拟器终端，不是 PowerShell 或系统命令。A、B 两端使用独立身份；真人说话测试应先配置 Windows --with-mic，文件模式则使用测试音频。
A 端输入 room create，创建无密码房间，记下返回的六位房间号。需要密码时用 room create 后接四位数字密码。
B 端输入 room join 后接 A 返回的房间号；有密码时再追加密码。使用实际返回值，保留房间号前导零。
两端输入 room status，核对同一房间和成员状态。加入请求已保存但成员尚未出现时，先等实际连接结果并刷新，不要立刻测试声音。
A 输入 room ptt down 开始发送，B 收听；A 输入 room ptt up 停止。然后交换操作，分别确认两个方向。
测试完成用 room leave 明确退出。仅关闭 Web 页面或返回首页，不代表设备已退出房间。
断线恢复怎样验证，而不是只看“重新在线”？
保持 A、B 已入房，断开 B 的网络，观察两端状态变化；成员移除可能受租约影响，不要求断网瞬间立即消失。
恢复 B 网络，等待它同步原房间关系和新连接。先用 room status 确认成员，再重新进行 A 到 B、B 到 A 的声音测试。
重启后若返回 40921，先重新同步关系并等待旧租约释放后重试，不要循环退出、建房消耗新的关系状态。
在房间中发起其他受支持通话，结束后确认房间恢复、PTT 状态符合产品设计，再验证发送与收听。
一台设备在该示例中同一时间只属于一个房间，切换房间前需先退出。成员人数统计的是租约有效且已报告加入成功的设备，不能拿 MQTT 在线数代替房间成员数。多人同时发言时由 Ti RTC 混音，但真实回声、音量与弱网效果仍需在目标设备上验证。
无声或成员不同步时，怎样收集有效信息？
Python 模拟器可输入 room debug on，复现后同时收集发言端和收听端日志，再输入 room debug off。记录房间、设备、发生时间和失败方向，检查 room_snapshot 是否收到；共享日志前去除连接凭证。Windows 声音发闷时，可先用系统录音检查输入设备，再关闭音频增强做对比。
房间关系与当前连接有什么区别？
房间关系表示设备应属于哪个房间；当前连接表示设备此刻是否真正接入音频服务。断线不一定清除房间关系，重连时应先同步服务端状态，再申请当前连接所需凭证。Ti RTC 在这套示例中负责音频传输与混音，业务服务管理房间关系，设备负责采集播放和发言交互。
移植到自己的产品，接入顺序是什么？
按当前文档的顺序：查询 assignment；在关系有效且资源可用时，生成新的 session_id 并领取 connect-token；建连后发送 join_room；收到确认后上报 joined 并续租；最后收发音频并同步成员。心跳和租约按服务端返回值处理，不在官网指南中固定成永久参数。
本机 PTT 开关负责是否真正发送声音，set_mic_state 负责同步发言状态。只更新成员状态不会自动采集声音；只发送声音也可能让成员列表显示不准确。上下行媒体格式以协商结果和当前 SDK 文档为准，不把公众号中的编码别名直接作为兼容性承诺。
其他通话、断网与重启后怎样恢复？
当前示例在 AI、微信通话或设备互呼占用资源时暂停房间对讲，结束后重新同步并恢复。产品应明确恢复后的麦克风状态，避免未经用户操作就继续发送。重连后重新获取成员快照，清理旧连接回调，保证旧会话不会覆盖新状态；房间已关闭时则提示重新加入。
常见问题与验收重点
加入请求成功但人数为零：检查实际入房结果，再刷新成员。能看到成员但没声音：检查 PTT、输入源、协商格式和播放 sink。重启后关系过期：重新同步服务端关系与连接状态，不要循环退出重进。其他通话结束后没恢复：检查媒体资源是否释放及房间是否仍有效。
建议验收：第三台加入与退出、双向声音、多人发言、松键停止、密码错误、断网重连、设备重启，以及其他通话结束后的恢复。会议更关注多人声音与回声，调度更关注按键和恢复，看护类使用则要明确谁能收听、何时采集。真实声音和网络表现需实机验证。
资料核对：2026 年 11 月 7 日。本文依据公开参考实现整理，具体接口与支持范围以当前文档为准。
视频参考：4G 设备多人对讲
探鸽智能发布的约 1 分钟演示，以利尔达 EC718PM 开发板为例，介绍插入 SIM 卡、多台设备加入同一房间的体验路径。适合结合本文理解设备、房间管理与语音传输的分工；具体板卡固件和操作以视频关联项目的当前文档为准。