> 本文是《BK7258 适配 LiveKit 实战》系列第 5 篇。  

> 文章基于真实工程代码，聚焦可复现的迁移路径与调试方法。  

> 建议先阅读上一篇，再继续本篇内容。

ESP32 livekit 项目 GitHub 仓库：https://github.com/livekit/client-sdk-esp32  

BK7258 开发基于 xiaozhi 工程，移植 esp32 livekit 到工程下。

---

## 1. 对应架构文档哪一部分

- 4.2 时序图

- 4.3 ICE/Trickle 处理图

---

## 2. 协商主链路（函数级）

建议围绕以下函数链排查：

- `signal_send_offer`

- `signal_send_answer`

- `signal_send_trickle`

- `handle_join`

- `engine_connect`

要点：**协商消息必须按状态机节奏发送，不能并发乱序。**

---

## 3. ICE/Trickle 的处理原则

### 本地候选

- 候选产生后尽快上报

- 发送失败可短重试，但不能阻塞主流程

### 远端候选

- 未就绪时先缓存

- Peer 准备好后再批量注入

### 状态控制

- 仅在已 JOIN 且 peer 就绪状态处理 trickle

- 重连时清理旧候选缓存

---

## 4. BK7258 迁移中的高频坑

- 协商回调跨线程并发导致状态乱序

- ICE 到达早于 peer 初始化，直接丢失

- 重连后沿用旧协商上下文

建议做法：把协商相关操作统一投递到单线程队列执行。

---

## 5. 调试建议（最少日志集）

- `negotiation_round_id`

- `offer_sent_ts`

- `answer_recv_ts`

- `trickle_send_count` / `trickle_recv_count`

- `peer_state` 迁移日志

没有这些日志，协商问题很难重现。

---

## 6. 本篇结论

协商与 ICE 的稳定性，本质是时序和并发控制问题。  

一旦保证“同一轮协商上下文一致”，大部分偶发故障会消失。

---

## 写在最后

下一篇将继续展开：第 6 篇《音频上行逐帧解析：Mic 回调到 `peer_send_audio`》。