Thanks — this is a very clear report and the logs help a lot. I’ll respond to each of your numbered questions, point out the likely causes, and give next steps and focused diagnostics you can run on the ESP32 to narrow this down. Quick acknowledgement of what I’m responding to • You’ve confirmed signaling, TLS validation, DTLS/SRTP init, and TURN relay candidates succeed, but the device reaches RTC state then disconnects and reconnects. The key symptoms are the WebSocket closing with “unexpected data readable on socket” and occasional “UDP: Failed to select: Bad file number.” Answers and guidance 1) Is this a known issue or limitation for livekit/livekit=0.3.6 on ESP32‑S3? • There is no explicit confirmation that 0.3.6 has a known, documented bug that causes this exact RTC teardown on ESP32‑S3. The ESP32 SDK integration is optimized for constrained devices and can be sensitive to underlying WebRTC/esp_peer and network stack behavior. • What I can say: ESP32 deployments are more likely to run into resource / socket lifecycle issues during ICE/DTLS transitions or reconnections. That makes it plausible the behavior is caused by the embedded stack (esp_peer/esp-idf/LWIP) encountering socket state or descriptor issues during the SDP/ICE finalization or shortly after. 2) Recommended esp_peer / ICE settings for LiveKit Cloud on ESP32‑S3, especially relay‑only • Relay-only mode is supported and TURN relay candidates are expected when you force relay. • Recommended checks and settings: ◦ Prefer TURN over TLS (443) if you must traverse firewalls — ensure TLS TURN is reachable from the device. ◦ Keep ICE timeouts and retransmit values conservative for constrained devices (increase timeouts slightly so ICE/DTLS have time to complete under CPU/network load). ◦ Ensure the esp_peer/esp-idf components are up-to-date (esp_peer and WebRTC layers receive fixes that affect stability). ◦ Limit simultaneous heavy operations during ICE/DTLS handshake (e.g., avoid CPU-heavy tasks while the peer state is transitioning). • I can help suggest exact esp_peer option names/settings if you share the current ICE and esp_peer configuration you’re using. 3) Is skipping TCP TURN candidates expected here, or could that be related? • Skipping TCP TURN candidates can be expected depending on how the esp_peer stack is configured. Many embedded stacks prioritize UDP/UDP-TURN and may skip TCP variants unless explicitly enabled. • If your network blocks UDP and you rely on TCP/TLS TURN, skipping TCP TURN candidates would be a problem — verify whether TCP/TLS TURN is enabled and allowed by your esp_peer config. • Action: confirm whether the client is configured to accept TCP/TLS TURN (port 443) candidates. If not enabled, enable them and retest (especially useful in restrictive networks). 4) Does

transport_ws: unexpected data readable on socket

usually indicate a signaling transport problem, or is it often secondary to an RTC teardown? • This log often appears as a symptom, not necessarily the root cause. Common patterns: ◦ A media/ICE/DTLS failure triggers the client to teardown and reconnect signaling; the websocket stack then notices unexpected data or an unclean state and logs that message. ◦ Alternatively, a real signaling-layer interruption can also cause the RTC to tear down. • Given your sequence (DTLS/SRTP OK, TURN candidates acquired, SDP exchange, then websocket close), it’s more likely the websocket closure is secondary — a media transport failure (ICE/DTLS/UDP socket lifecycle) causes the higher-level connection to restart, and the websocket stack logs the socket state error during the teardown/reconnect. • To verify: enable verbose websocket/signaling logging and correlate timestamps with DTLS/ICE logs. If websocket close entries come after ICE/DTLS errors, the websocket message is secondary. 5) Has anyone seen

UDP: Failed to select: Bad file number

in the ESP32 client during reconnect or peer restart? • That exact message isn’t documented as a LiveKit-specific error, but it strongly suggests a socket/file-descriptor lifecycle problem at the LWIP/esp-idf level (for example, using a socket after it was closed or not initialized). • Likely causes: ◦ A socket was closed while select()/poll still tried to use it during reconnection. ◦ Race conditions in socket cleanup during ICE restart or peer disconnect/reconnect. ◦ Running out of file descriptors or improper error handling when recreating sockets. • Diagnostics to focus on: ◦ Turn on verbose LWIP and esp_peer logging to capture socket create/close calls and any errno around select() failures. ◦ Check for code paths where sockets are closed asynchronously (e.g., in timers or callbacks) while another task still uses them. Concrete next steps and tests (short list) 1. Enable verbose logging: ◦ esp_peer/WebRTC layers, LWIP (socket layer), and websocket/signaling. Correlate exact timestamps to see which error precedes the other. 1. Verify TURN transport capabilities: ◦ Confirm whether TCP/TLS TURN (port 443) is enabled in your esp_peer config. If skipped, enable it and test in case UDP is blocked or unstable. 1. Increase ICE/DTLS timeouts: ◦ Slightly increase ICE checks/timeouts so the constrained device has more time to complete exchange under load. 1. Reproduce with a minimal test: ◦ Run a minimal repro that only performs signaling → ICE → DTLS without starting heavy capture/encode tasks. If stable, the issue is likely resource/CPU related. 1. Watch socket lifecycle: ◦ Add logs around socket create/close calls (or enable LWIP socket tracing) to capture when a UDP socket is closed relative to the “Bad file number” message. 1. Try alternative network path: ◦ If possible, test with a different network or temporarily allow non-relay ICE to see whether the problem reproduces only under relay-only mode. 1. Share config and extra logs: ◦ If you can, share the esp_peer/ICE config snippet (which candidates/transports are enabled) and a slightly longer timestamped log around the failure. I can point to exact places to add debug logs or which options to toggle. If you want, I can: • Walk through the exact esp_peer configuration keys to change for enabling TCP/TLS TURN and adjusting ICE timeouts. • Help parse an extended log (10–20 seconds before/after the failure) to identify the ordering of DTLS/ICE vs websocket errors. Thanks again — you’ve done the right thing by isolating auth/signaling and confirming TURN candidates. If you send the esp_peer config and a timestamped extended log snippet, I’ll give precise edits to try next. Sources: LiveKit SDK for ESP32: bringing voice AI to embedded devices | LiveKit | Firewall Tips, with interactive elements