Exception: LiveKit Exception: [MediaConnectException] Timed out waiting for PeerConnection to connect, please check your network for ice connectivity StackTrace: #0 Engine.connect.<anonymous closure> (packagelivekit client/src/core/engine.dart233:26) #1 _RootZone.run (dartasync/zone.dart1843:54) #2 Future.timeout.<anonymous closure> (dartasync/future impl.dart1054:34) <asynchronous suspension> #3 EventsListenable.waitFor (packagelivekit client/src/managers/event.dart212:14) <asynchronous suspension> #4 Engine.connect (packagelivekit client/src/core/engine.dart230:7) <asynchronous suspension> #5 Room.connect (packagelivekit client/src/core/room.dart273:7) <asynchronous suspension>

Thanks for reaching out, hardeep. I'm an AI assistant and I'm here to help. Give me a moment while I research this topic.

using self-hosted livekit server on corporate network. I have configured turn server, and using Webrtc. Facing this issue after every 30...40 mins. when i face this issue once, it occurs frequently. Im not using any VPN

Thanks — I see you’re on a self‑hosted LiveKit server inside a corporate network, with TURN configured, no VPN, and the ICE timeout starts after ~30–40 minutes and then recurs. I’ll focus on fixes that address intermittent network/NAT/firewall behavior. Please try these steps (in order) and report results/logs for any step that changes behavior: 1. Force TURN-only on the client to rule out flaky direct ICE paths • Set rtc config when connecting:

connectOpts.rtcConfig = { 'iceTransportPolicy': 'relay' };

1. Ensure TURN over TLS (port 443) is available and used • Corporate firewalls frequently block/interrupt UDP; TURN/TLS on 443 is most firewall-friendly. Confirm your TURN server accepts allocations on TCP/TLS 443 and that your load balancer forwards 443 to it. 1. Check corporate NAT/firewall timeouts and UDP behavior • Many corporate firewalls aggressively drop UDP NAT mappings. Ask your network team whether UDP session timeouts or connection tracking rules could be expiring around 30–40 minutes. 1. Use ICE/UDP multiplexing (single UDP port) if you need UDP • Reduce port exposure and NAT churn by configuring a single UDP port for ICE traffic on the server (UDP mux). 1. Run the LiveKit Connection Test during a failure • Run WebSocket, WebRTC, and TURN checks (especially TURN). Share the results — they’ll show whether TURN allocations or WebRTC handshake are failing. 1. Enable debug logs on the LiveKit server and inspect failures • Set

log_level: debug

and look for DTLS/ICE candidate pairing, TURN allocation errors, or repeated ICE restarts around the timeouts. 1. Check for corporate DPI / TLS inspection interference • If the network performs TLS inspection (Zscaler-like), TURN/TLS or WebSocket traffic may be interrupted. Whitelist your LiveKit and TURN domains or disable protocol inspection for those domains. 1. Ensure client reconnection handling is enabled • The SDK will reconnect automatically, but confirm your client logs show reconnect attempts and any error events (e.g.,

reconnecting

,

reconnected

). What I need next • Results of the Connection Test (WebSocket, WebRTC, TURN) when the issue is happening. • Relevant debug log snippets from the LiveKit server around the time of a failure (ICE/DTLS/TURN messages). • Whether forcing

iceTransportPolicy: 'relay'

prevents the recurrent failures. If you share those results/logs, I’ll help interpret them and recommend the precise server or network changes to stop the recurring timeouts. Sources: Firewall Tips | Deploying LiveKit | LiveKit docs | Ports and firewall | LiveKit docs | Deploy to a VM | LiveKit docs | Configuring firewalls | LiveKit docs