3.5 KiB
状态机就是“把一次视频会话/设备流程拆成明确状态，并规定状态之间怎么流转”的机制。 device-bootstrap 就是“设备启动或上线时，先来云端报到、认证，并领取连接 MQTT/实时系统所需临时配置和凭证”的接入服务。
- 状态机是什么意思 1.1 通俗解释 状态机可以理解成一张流程规则表。
比如一次智能锁视频通话，不应该只是简单地说：
开始通话 结束通话 而是应该有一系列明确状态：
待创建 -> 呼叫中 -> 已接听 -> 连接中 -> 已连接 -> 通话中 -> 已结束 每个状态只能按照规则进入下一个状态。
例如：
pending -> ringing -> accepted -> connecting -> connected -> ended 不能乱跳，比如：
pending -> connected 通常就不合理，因为中间还没经过设备接听和媒体连接。
1.2 在你这个智能锁项目里的含义 你们旧方案里可能是通过 UDP 字段告诉 APP 或锁：
开始视频 结束视频 这种方式简单，但问题是：
APP 以为开始了，设备没收到
设备接听了，APP 已经取消
网络抖动导致消息重复
云端不知道现在到底是“呼叫中”还是“已连接”
通话失败后不好追踪原因
所以新方案里要用 session-orchestrator 管理状态机。
也就是云端统一记录：
这个 sessionId 当前到底处于什么状态 2. 视频会话状态机例子 2.1 推荐状态 pending ringing accepted connecting connected degraded switching_route recovered ended rejected timeout failed 可以翻译成：
状态
中文含义
pending
会话刚创建，等待发起呼叫
ringing
正在呼叫设备 / 设备响铃
accepted
设备已接听
connecting
APP 和设备正在建立媒体连接
connected
音视频已连通
degraded
通话质量下降
switching_route
正在切换媒体线路
recovered
切换后恢复正常
ended
正常结束
rejected
被拒接
timeout
超时未响应
failed
异常失败
2.2 状态流转例子 一次正常视频通话：
pending -> ringing -> accepted -> connecting -> connected -> ended 中文就是：
创建会话 -> 呼叫设备 -> 设备接听 -> 建立 WebRTC / ZLM 连接 -> 通话成功 -> 挂断结束 2.3 异常情况例子 设备不在线 pending -> failed 原因：
device_offline 设备没有响应 pending -> ringing -> timeout 原因：
invite_timeout 用户取消 pending -> ringing -> ended 原因：
caller_cancelled 设备拒接 pending -> ringing -> rejected 原因：
device_rejected WebRTC 连接失败，切 ZLMediaKit pending -> ringing -> accepted -> connecting -> failed_p2p -> switching_route -> connected 或者更规范一点：
connecting -> degraded -> switching_route -> recovered -> connected 3. 为什么一定要状态机 3.1 保证流程不乱 没有状态机时，可能出现：
已经挂断了，又收到设备 accept 那系统不知道该怎么办。
有状态机后可以规定：
ended 状态下收到 accept，直接忽略或记录为迟到事件 3.2 方便排查问题 有状态机后，每个会话都能查：
sessionId = abc123 pending at 10:00:01 ringing at 10:00:02 accepted at 10:00:05 connecting at 10:00:06 timeout at 10:00:16 reason = ice_timeout 这样就能知道失败原因是：
设备接了，但 WebRTC 没连上 而不是一句模糊的：
通话失败 3.3 方便做超时和重试 比如：
呼叫设备 15 秒没响应，自动超时
WebRTC 10 秒没连上，切 ZLM
设备 ACK 没回来，重发 invite
通话结束后清理 token 和流资源
这些都依赖状态机。