Thanks — I hear you: the backend intermittently fails to publish back to the client with the error "engine: connection error: could not establish publisher connection: timeout." I’ll outline the most likely causes, practical checks you can run, and focused mitigations you can try. Likely causes • Network instability between the backend (agent) and client causing ICE/DTLS handshakes to fail or take too long. • Firewall/NAT behavior that allows initial traffic but blocks media/DTLS packets, so publishing never completes. • A transient or overloaded agent process (CPU, memory, or thread starvation) slowing or preventing timely publisher setup. • Single-worker dispatch timeouts: if the agent handling the job is unresponsive, job dispatch can time out. • ICE candidate exchange or TURN fallback not occurring quickly enough, hitting the publisher connection timeout. What to check first (quick diagnostics) • Reproduce and capture logs around a failure window: backend agent logs, LiveKit server logs, and client SDK logs (ICE state changes, DTLS handshake, connection state transitions). • Run a connection test from both client and backend environments using the Connection Test utility to verify WebRTC, WebSocket, and TURN reachability. • Inspect ICE candidate exchange in logs (are candidates being sent/received?) and check whether DTLS completes or stalls. • Check network/firewall devices between client and backend for dropped UDP packets or port filtering; note whether corporate NATs or strict firewalls are involved. • Monitor resource usage on the agent host (CPU, memory, threads) and any GC pauses or process restarts around the timeout times. Targeted mitigations to try 1. Force TURN/relay if firewall/NAT issues are suspected ◦ Configure

iceTransportPolicy: 'relay'

so the client and backend use TURN over TCP/TLS and avoid UDP blocking issues. 1. Increase resilience and redundancy ◦ Run multiple agent workers for the same

agent_name

so a single slow/unresponsive worker won’t cause dispatch timeouts. ◦ Ensure the agent host isn’t running other heavy workloads that might cause scheduling delays. 1. Improve connection robustness ◦ Ensure the SDK reconnection and ICE restart behavior is enabled (the SDK performs reconnection/ICE restart/renegotiation in sequence). ◦ If possible, tune timeouts where jobs/dispatch occur (note: there is a 10-second connection timeout used for dispatch in some agent flows; if your environment commonly has higher latency, optimize the network path or increase allowable time where configurable). 1. Observe and measure ◦ Enable agent observability dashboards/log aggregation to correlate failures with network metrics, eou_delay/llm_ttft/tts_ttf (if relevant), and any ICE/DTLS failure events. ◦ Capture a failing session’s ICE logs (candidate pairs, selected candidate, state transitions) to see if candidate selection stalls or DTLS never completes. If you run the checks above, please share: • A brief snippet of the agent + client logs around one failure (ICE state changes and the timeout error). • Whether you’re seeing any repeated ICE candidate failures or DTLS errors. • Whether the environment uses restrictive corporate NAT/firewall or a public cloud with TURN available. With those details I can help interpret the logs and recommend the next concrete steps (for example, TURN config changes, timeout tuning, or agent-side fixes). Sources: client-sdk-js | livekit/livekit_composite | DeepWiki | Understanding the STATE_MISMATCH Disconnect Reason | Firewall Tips | Diagnosing Connection Errors with Connection Test Utility | Streamline troubleshooting with Agent Observability | LiveKit, with interactive elements