对于 ESP32 客户端, SUBSCRIBER 传输的 SCTP 协商永远无法完成(服务器从未回复 SCTP INIT), 而 PUBLISHER 传输每次都成功

作者: ijustwant创建于 2026年8月31日更新于 2026年9月14日

服务器：LiveKit 服务器 v1.13.1（自主部署，Docker），配置与默认值接近（room.empty_timeout: 300、room.departure_timeout: 20，没有自定义 RTC/协商超时覆盖）
客户端：livekit/client-sdk-esp32 v0.3.10，在 ESP32-S3 上，使用 ESP-IDF v5.4
客户端角色：仅订阅（room_options.subscribe.kind = LIVEKIT_MEDIA_TYPE_AUDIO，room_options.publish 为零或 LIVEKIT_MEDIA_TYPE_NONE）
在我们自己的修补版 managed_components/livekit__livekit/core/ 中发现并解决了两个与客户端 SDK 相关的问题（不认为与此问题有关，但为了完整性，指出它们涉及相同的协商路径）：
1. esp_peer 的音频编解码器报告总是返回 ESP_PEER_AUDIO_CODEC_NONE，即使在协商了真实的编解码器（PCMA/8000）时也是如此 - 通过在报告为 NONE 时假设为 PCMA/8000 来解决此问题。
1. esp_peer 的 SDP 回复生成将为仅接收的音频流写入 a=inactive，而不是 a=recvonly，即使输入的方向标志是正确的 - 通过在输出 SDP 文本中进行原地字符串替换来解决此问题。
两个问题仍然存在，但已在我们的修补版中解决。

内容来源: livekit/livekit