WebRTC 只管流，不管控——自研信令服务器的状态机设计
视频流是 WebRTC 的事。谁发起、谁接听、谁踢人、谁旁观——这些是信令的事。
一、问题
WebRTC 搞定了音视频传输。两个浏览器之间怎么建 PeerConnection、怎么传递 SDP、怎么走 ICE 打洞——这些都是现成的。
但一个视频帮办系统不只是"两个人能看见对方"。还需要：
- 坐席发起通话，参保人接听
- 坐席可以邀请第三方加入旁观
- 坐席可以踢人
- 多方加入时，每个人知道房间里有哪些人
- 有人断线，其他人要知道
- 通话结束后，知道是谁挂断的、挂了多久
这些 WebRTC 不管。得自己搭一层信令服务器。
二、自研信令协议
设计一套轻量 JSON 信令。WebSocket 传输，每条消息一个类型：
| 信令方向 | 说明 | 谁来 | 谁收 |
|---|---|---|---|
create | 坐席创建房间成功 | 服务器 | 坐席 |
joined | 有人加入房间后，给此人发的确认（带了所有在房间的人列表） | 服务器 | 加入者 |
called | 有人申请加入，通知坐席是否允许 | 服务器 | 坐席 |
allow | 坐席允许加入 | 坐席 | 服务器 |
deny | 坐席拒绝加入 | 坐席 | 服务器 |
refused | 服务器通知申请者被拒绝 | 服务器 | 申请者 |
otherjoin | 有其他人加入房间（通知给已经在房间里的人） | 服务器 | 其他人 |
bye | 有人主动离开 | 离开者 | 服务器 |
leaved | 有人离开，服务器通知房间里其他人 | 服务器 | 其他人 |
kick | 坐席踢人 | 坐席 | 服务器 |
kicked | 被踢的人收到通知 | 服务器 | 被踢者 |
关键设计决策：所有业务操作不走 P2P，全部经过信令服务器中转。坐席踢人不是直接发给参保人，是发给服务器 → 服务器发给被踢者 + 通知其他人。单一控制点，状态不会分叉。
三、房间状态机
一个房间的生命周期：
┌──────────┐ │ idle │ 等待坐席创建 └────┬─────┘ │ create ▼ ┌──────────┐ │ created │ 房间已建，等参保人加入 └────┬─────┘ │ join ▼ ┌──────────┐ │ joined │ 参保人已加入，等坐席允许 └────┬─────┘ │ allow ▼ ┌──────────┐ │ called │ 通话中（可能多人） └────┬─────┘ │ bye / kick / timeout ▼ ┌──────────┐ │ ended │ 所有人离开，房间销毁 └──────────┘每个状态允许的操作不同：
| 状态 | 允许的操作 |
|---|---|
created | 参保人加入、坐席取消 |
joined | 坐席允许/拒绝、第三方加入 |
called | 踢人、邀请第三方、正常挂断 |
状态机保护了异常路径——比如坐席在created状态还没人加入就发踢人指令，服务器直接拒绝，不会崩溃。
四、三种角色的加入和退出逻辑
坐席
- 建房：发
create→ 服务器创建房间，分配 roomId - 退出：发
bye→ 服务器通知所有人leaved→ 房间销毁
参保人
- 加入：发
join（带 roomId）→ 服务器暂存 → 发called给坐席 - 被允许：服务器发
joined→ 参保人开始建 P2P 连接 - 被拒绝：服务器发
refused→ 参保人收到拒绝原因 - 被踢：坐席发
kick→ 服务器发kicked给参保人 → 通知其他人leaved
第三方（旁观）
- 加入：同参保人，但坐席收到
called时能看到是"旁观"角色 - 退出：发
bye或坐席踢，逻辑同参保人 - 差别：不参与音视频流，只收到其他人的存在通知
五、一次完整通话的信令时序
以坐席 → 参保人一对一通话为例：
坐席 信令服务器 参保人 │ │ │ │──────── create ────────▶│ │ │◀───── create OK ────────│ │ │ │ │ ◀────── join ───────│ │◀───── called ───────────│ │ │ │ │──────── allow ──────────▶│ │ │◀───── allow OK ──────────│ │ │ │────── otherjoin ────────▶│ │ │ │ │════════════ WebRTC P2P 音视频流 ═══════════════════│ │ │ │ │ ◀─────── bye ───────│ │◀───── leaved ────────────│ │Notes:
- 坐席建房后，房间处于
created状态，等待参保人。 - 参保人 join 后，状态变为
joined，坐席决定 allow 还是 deny。 - allow 后状态变为
called，视频流开始。 - 参保人主动挂断（bye），服务器通知坐席（leaved），房间结束。
- 如果是坐席主动 bye，服务器直接销毁房间，通知所有人 leaved。
六、异常处理：断线、超时、重复加入
断线
WebSocket 断连时，服务器检测到连接关闭，等同于该用户主动 bye。处理逻辑：
- 走正常离开流程，通知其他人
leaved - 保留房间 N 分钟，等待重连
- 超时没重连的人，从房间列表移除
超时
joined状态等待坐席 allow 超过 N 分钟 → 服务器自动给参保人发refused，房源回退到created。
重复加入
同一个 roomId，同一个 userId 重复发 join → 服务器忽略，返回"已在房间中"。
七、总结
WebRTC 搞定了音视频流的传输。但它不负责：
- 谁有权建房
- 谁有权加入
- 谁有权踢人
- 旁观和发言有什么区别
- 断线了怎么处理
这些是信令服务器的活。
这套自研协议只有 10 条左右信令，覆盖了远程帮办的全部业务场景。核心设计原则是：所有状态变更必须经过服务器——不是性能最优的方案，但状态一致性最高。政务场景不需要百万人并发，但绝对不能在通话中丢了状态。
信令层的代码不复杂。复杂的是想清楚"每个状态下谁可以做什么"。这个想清楚了，代码是自然推导出来的。
