IoT 对讲常见的问题不只是音质。设备显示在线却没有响铃、手机接通后没有声音、上一位用户挂断后设备仍被占用，都可能破坏体验。设计 RTC 对讲时，应先画清呼叫的完整生命周期，再决定媒体参数。
在线、收到呼叫、媒体连通分别确认
设备在线通常只说明业务系统知道它的存在，不代表用户一定能立即通话。列出空闲、呼叫中、响铃、接通、结束和异常恢复等状态，并说明每次状态变化由谁确认。
业务通知到达后，还需要完成权限检查、媒体准备和通信连接。WebRTC 的实时媒体能力不替应用定义这些业务流程。每个状态都应有超时处理，避免设备一直停在“正在连接”。
把并发来电规则写清
同一台设备是否允许多人观看、是否只允许一人说话、正在通话时第二个来电怎样处理，需要由产品先定规则。若支持管理员介入，应明确其权限与原会话如何变化。
设备绑定、用户退出和权限撤销也应进入测试。更换使用者后，旧账户是否还能发起对讲，是业务系统需要验证的问题，不能仅依赖 RTC 房间名称不同。
接听端状态影响完整体验
手机应用在前台、后台或关闭时，通知与接听行为可能不同。浏览器接听端则需实际验证媒体权限、播放行为和支持版本。若项目依赖系统推送或设备唤醒，应把它们列为独立接入项。
测试时让设备或接听端分别断网、重启和挂断，检查另一端是否及时结束；再快速发起下一次呼叫，确认麦克风、摄像头和房间资源没有残留占用。
按场景定义可用标准
门口对讲、远程巡检和家庭设备通话，对接通时间、持续时长与画面的要求不同。先记录实际使用动作，再设置通过标准。硬件端同时运行录像或其他任务时，也应重新测通话表现。
采购资料中建议包含设备类型、操作系统、接听端、参与者关系、网络条件及预计峰值，并附呼叫状态图。以上是通用设计建议，具体功能、兼容性和时延需以样机验证为准。
需要咨询 IoT RTC 接入与报价时，可先提交你的呼叫流程和设备条件，明确通信服务应承担的部分。
参考：W3C WebRTC 标准，用于了解实时媒体通信与业务信令的边界。