Room crashes after screen share

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

mostly participant lefts due to connection timeout , and it happens after screen sharing only for some partcipants

Thanks — that extra detail helps. I understand participants are being disconnected with connection timeouts, and this reliably happens after someone starts screen sharing for some (but not all) participants. I can help track this down — a few targeted questions and a short set of tests will narrow the root cause quickly. Quick clarifying questions • Platform(s) for the affected participants: are the timeouts happening to web users (which browsers/versions), mobile (iOS/Android), or desktop apps? • Are the affected participants on the same network type (e.g., corporate VPN, Wi‑Fi, mobile data) or are they spread across different networks? • Do the participants who time out share any common characteristics (same ISP, same geographic region, same device model)? • Which LiveKit SDK version are you using (server and client)? • Is the screen sharer publishing at a much higher resolution/bitrate than usual (e.g., 1080p/4K or a high encoder bitrate)? • Do you use simulcast, layer switching, or any custom bandwidth/bitrate limits? • Do you see any server-side logs around the time of the disconnections (connection timeout messages, transport errors)? • Can you reproduce this consistently (same room/participants) or only intermittently? Immediate tests to run (fast and high-value) 1. Reproduce with a minimal room ◦ Have the sharer publish screen share while only 1–2 participants are connected. Does timeout still occur for those participants? 1. Swap networks ◦ Ask an affected participant to switch to a different network (e.g., from corporate Wi‑Fi to a phone hotspot). If they no longer time out, the issue is network-related (NAT, firewall, or bandwidth). 1. Reduce share quality ◦ Temporarily reduce screen-share resolution or encoder bitrate and test again. If timeouts stop, the likely problem is bandwidth or CPU/encoder overload. 1. Test different browsers or clients ◦ If web clients are affected, try Chrome vs Firefox vs Edge. If timeouts are browser-specific, capture the browser console logs. 1. Check for NAT/firewall issues ◦ Long-lived large streams (screen share) can expose NAT timeouts or blocked ICE candidates. If affected clients are behind symmetric NATs or strict firewalls, they may lose connectivity when bitrate spikes. 1. Collect logs ◦ For web: paste browser console logs around the disconnect. ◦ For native: collect client logs / crash reports and server logs for the same timestamp. Likely causes to consider (based on the pattern you described) • Bandwidth spikes from screen share causing packet loss and transport timeouts for weaker links. • NAT/connection keep-alive issues where increased bitrate or different transport behavior triggers connection re-establishment that fails for some networks. • Browser or OS-specific encoder/decoder resource exhaustion causing the client to drop the connection. • TURN server capacity or routing: if TURN is used and becomes saturated by high-bandwidth screen share, some clients may time out. If you can share any of the following, I’ll provide concrete next steps: • Platform(s) of affected participants and their network type. • SDK version and whether you use TURN (and TURN deployment details if possible). • A short snippet of the browser console or server log showing the timeout/transport error (timestamps help correlate). Once I have that, I’ll suggest specific configuration changes (bitrate limits, simulcast adjustments, TURN scaling), exact log lines to look for, and tests to confirm the root cause. , with interactive elements

WebSocket ✓ (1556ms)WebRTC ✓ (2008ms)TURN ✓ (2932ms) i got this data while i was doing this

// Run LiveKit connection checks with timing
const checker = new ConnectionCheck(url, token);

const ws = await timedCheck(() => checker.checkWebsocket());
const webrtc = await timedCheck(() => checker.checkWebRTC());
const turn = await timedCheck(() => checker.checkTURN());

Thanks — that timing data is useful. I see WebSocket, WebRTC, and TURN checks all succeeded with increasing latency (WebSocket 1556ms, WebRTC 2008ms, TURN 2932ms). I’ll walk through what that means and the most likely next steps to narrow down why some web participants time out after a screen share starts. What the checks tell us • All connectivity types reached the server (WebSocket, direct peer WebRTC, and TURN), so basic connectivity and candidate gathering are working. • The TURN check is noticeably slower (~2.9s). High TURN latencies or TURN server saturation can cause timeouts or packet loss when screen sharing drives up bandwidth. • The relative delays (WebSocket < WebRTC < TURN) are normal, but the absolute values indicate potentially marginal network conditions for high-bitrate streams like screen share. What to try next (prioritized) 1. Confirm whether affected participants are using TURN ◦ Ask the affected users to open the browser console and look for ICE candidate pair / connection logs to confirm whether their active candidate is via TURN. If they are using TURN, the TURN path is likely the bottleneck. 1. Temporarily lower screen-share bitrate/resolution ◦ Reduce the screen-share resolution or encoder bitrate and test. If timeouts stop, this strongly indicates bandwidth or TURN capacity issues. 1. Try a participant on a different network ◦ Have an affected participant switch to a mobile hotspot (or different ISP). If they stay connected, the original network (NAT, firewall, ISP) is a contributor. 1. Scale/verify TURN capacity ◦ If you expect many participants to receive the screen share via TURN, ensure TURN servers can handle the increased concurrent throughput. High TURN latency + high bandwidth can cause connection timeouts for weaker clients. 1. Reproduce with minimal participants ◦ Test with just the sharer and one watcher. If the watcher times out even with one viewer, this points to a client-specific or single-path problem rather than overall room load. 1. Capture logs at disconnect ◦ Web console: copy ICE / RTCTransport / SCTP / connection state change logs around the disconnect time. ◦ Server: check room/participant logs for transport errors or connection timeout entries at matching timestamps. Specific console checks to paste here • Any ICE connection state transitions (e.g., "failed", "disconnected") and ICE candidate pair selection lines. • Errors mentioning TURN, STUN, transport, or DTLS timeouts. • Any warnings about encoder failures, high frame/bitrate drops, or WebRTC bandwidth adaptation messages. Quick hypothesis checklist • If affected users are on TURN and TURN latency is high or TURN bandwidth is saturated → reduce screen-share bitrate or scale TURN. • If affected users are on networks with strict NAT/firewall behavior → ICE rekeying or bitrate spikes can break the session; switching networks or enabling keepalives may help. • If only certain browsers or OS versions are affected → browser-specific encoder/decoder resource issues could be causing disconnects. If you can share: • Which clients (browser & version) the affected participants use, • Whether their active ICE candidate is TURN (console logs), • Any browser console lines at the time of disconnect (paste snippets), I’ll analyze those logs and recommend exact configuration changes (bitrate caps, simulcast/layering configuration, TURN scaling options) and precise log lines to watch for to verify the fix. , with interactive elements