产品接入
给自己的设备接入实时音视频，需要哪些部分？
从设备采集、实时传输、用户端播放到业务鉴权，拆清职责，按最小可验证的顺序完成产品接入。
先回答：需要设备端、用户端和业务服务协作
实时音视频接入通常包含四部分：设备采集与播放、音视频传输、用户端交互、业务身份与会话管理。SDK 可以承担其中一部分连接和媒体传输工作，但不会自动完成摄像头驱动、用户绑定、谁能查看设备等全部业务。先定义一次完整使用过程，再确定各部分由谁实现。
设备端：拿到真实的声音和画面
先确认目标芯片、操作系统、SDK 与工具链是否匹配，再验证摄像头、麦克风和扬声器。可以先用文件媒体排查 SDK 与网络，随后换成真实采集和播放。文件能够传输不等于硬件已接好；需要记录编码格式、采样率、分辨率和实际发送节奏。
通信与信令：传媒体，也要协调会话
媒体传输负责声音和画面的发送接收，信令负责会话建立前后的协调。以 WebRTC 为例，双方仍需要交换连接协商信息；某些网络无法直接连通时还需要中继。评估方案时，应同时检查跨网络连通性、连接失败反馈和恢复方式，不能只测试同一 Wi-Fi 下能否出图。
用户端与业务端：决定谁能连接谁
用户端可以是网页、App 或小程序，负责选择设备、播放媒体、发起对讲和显示状态。业务端负责用户与设备关系、访问授权以及会话凭证。设计时要回答：设备解绑后谁还能访问？用户取消呼叫时设备如何结束？设备离线时界面如何提示？这些问题应在接口联调前确定。
建议的接入顺序
第一步，在目标平台跑通测试媒体；第二步，接入真实采集和播放；第三步，加入用户登录、设备绑定和访问控制；第四步，验证中断、重连、拒接和结束会话。每一步都保留明确的验收结果，例如“网页能收到画面”与“设备能播放网页麦克风声音”分别记录。
最小项目：先让一台设备与一个网页双向有声
可以把第一次接入范围限定为一台目标设备、一个已授权用户和一种媒体业务。设备负责采集播放，用户端负责选择设备与授权麦克风，业务服务管理绑定和会话，Ti RTC 负责相应连接与媒体传输。先跑通这一条路径，再加 AI、微信或多人房间，便于定位资源冲突。
以公开服务端示例为例，设备怎样从绑定走到在线？
下面是 ThingConnect 参考实现的协议流程，不是所有 Ti RTC 产品都必须使用的统一业务接口，也不意味着开发者控制台 ID 可以直接代入体验平台。沿用该示例时，应同时沿用它的服务端身份与绑定规则。
没有本地 device_id 和 device_key 时，向 POST /v1/device/report 报告 mac，取得绑定码、temp_client_id 与 temp_token。
建立临时 MQTT：ClientID 与 Username 都使用 temp_client_id，Password 使用 temp_token。订阅临时 cmd 主题，等待用户绑定后的 auth_grant。
首次分配身份时，安全保存下发的 device_id 与 device_key，确认消息后结束临时连接。已有有效身份的设备从 token 步骤开始，不重复申请新身份。
调用 POST /v1/device/token 换取 mqtt_token。正式 MQTT 的 ClientID 为 sn_{device_id}，Username 为 device_id，Password 为 mqtt_token。
订阅 device/sn_{device_id}/cmd 和 device/sn_{device_id}/notify；cmd 消息需要向对应 ack 主题确认。随后接入选定的媒体业务，分别验证连接、上行和下行。
身份凭证、绑定码和会话 token 用途不同。参考实现中，设备解绑返回 HTTP 410 与业务码 6006 时应按文档进入带签名的重新绑定流程；普通网络失败不应清空已有身份。token 过期也不等于设备需要重新注册。
从文件媒体换成真实硬件，需要改哪些接口？
平台匹配：先核对目标 CPU、ABI、libc 与 SDK。Linux 文件示例跑通，只能证明这套运行环境和网络路径可用。
上行媒体：用麦克风或摄像头采集、预处理和编码替换文件源，核对发送格式、时间戳与节奏。
下行媒体：把 SDK 回调收到的帧复制到产品自己的有界队列，再由工作线程解码播放或显示；不要保留回调帧指针或在 SDK 回调里阻塞播放。
身份与恢复：替换演示 JSON 凭证文件，处理掉电写入、解绑、恢复出厂、token 刷新及网络重连。
会话与交互：将示例命令行接到按键或界面，定义业务优先级，停止旧媒体并释放资源后再切换会话。
Linux C 参考实现通过 DeviceAdapterV1 分开协议核心与产品适配。可以逐组替换默认实现并验证；非 Linux 目标应作为独立移植工程处理，不能把 Linux 构建命令直接套到 MCU 固件。
每一步留下什么验收结果？
冷启动与身份：第一次能绑定；再次上电能恢复正确身份；日志不输出完整密钥。
媒体方向：设备到用户端有声、用户端到设备有声，分别记录；有视频时再单独核对画面。
结束与恢复：主动结束后采集发送停止；断网有明确状态；恢复网络后不会残留旧会话或重复采集。
权限与资源：解绑或授权失效后按设计拒绝访问；重复连接、切换业务、持续运行时不泄漏连接与媒体资源。
遇到失败先定位阶段：SDK 无法加载查平台匹配；临时连接不成功查临时凭证和主题；正式在线但无媒体查业务建连；收到下行帧却无声查解码与播放。保存固件版本、阶段和错误码，比反复重新绑定更有助于定位。
使用探鸽时，从哪里开始？
如果选择 Ti RTC，可在探鸽开发者控制台自主注册。注册后赠送 10 个 ID，包含免费的 Ti RTC 基础流量，用于真实设备上的音视频开发与验证；其他服务按量付费。获取权益后，仍需按官方文档完成对应的应用、设备和 SDK 接入。这里的 ID 不应与体验平台的六位绑定码混用。
什么时候可以从演示进入试用？
建议至少覆盖正常连接、用户主动结束、断网恢复、设备重启、权限失效和持续运行。用目标网络、目标硬件和目标用户端共同测试，并事先定义可以接受的画面质量、声音质量和等待时间。一次演示成功可以作为阶段结果，不能替代产品验收。
资料核对：2026 年 11 月 7 日。本文提供接入思路；接口、板卡支持与平台条件请以所链接文档的当前版本为准。