Thanks — that’s a great question. Brief answer: CONNECTION_TIMEOUT means the media connection (the WebRTC peer connection) between the client and server stopped sending/receiving ICE/STUN keep‑alive packets for about ~20 seconds, so the server assumes the media path is gone and disconnects the participant. What is timing out • The media transport (the WebRTC peer connection / ICE candidates), not the signaling channel. • WebRTC regularly sends ICE/STUN keep‑alive packets to verify the peer is still reachable. If the server doesn’t see those packets within the timeout window, it treats the media path as disconnected. Common causes • Temporary network blackout or poor connectivity on the client side • Firewalls or NAT devices that block or drop UDP after the session is established • Client crash, hard app kill, or abrupt device sleep that prevents a clean disconnect • NAT rebinding or routing changes that break the existing ICE connection Internal mapping • Internally this is reported as

ParticipantCloseReasonPeerConnectionDisconnected

, exposed publicly as

DisconnectReason.CONNECTION_TIMEOUT

. If you’d like, I can help you further by: • Suggesting client‑side checks (logs, network type, reconnect behavior) • Showing where to look for server logs or timestamps that confirm the ~20s gap • Helping narrow causes if you share when/under what conditions you see this disconnect (e.g., mobile devices, specific networks, after X minutes) Which of those would be most helpful? Sources: Understanding the STATE_MISMATCH Disconnect Reason | LiveKit | Server-side | livekit/livekit_composite | DeepWiki