205 lines
3.5 KiB
Markdown
205 lines
3.5 KiB
Markdown
|
状态机就是“把一次视频会话/设备流程拆成明确状态，并规定状态之间怎么流转”的机制。
|
|||
|
|
device-bootstrap 就是“设备启动或上线时，先来云端报到、认证，并领取连接 MQTT/实时系统所需临时配置和凭证”的接入服务。
|
|||
|
|
|
|||
|
|
1. 状态机是什么意思
|
|||
|
|
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 和流资源
|
|||
|
|
|
|||
|
|
这些都依赖状态机。
|