I encountered a problem where a user camera suddenly stopped working (suddenly stopped streaming video images) mid interview. What happened? Is it a problem on the livekit side or the user device side? Or an internet problem?

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

So, there's a connection problem. The user internet connection quality suddenly becomes POOR. The camera looks like as if it was freezing (video doesn't change). But audio input is still ok.

Thanks — that helps. What you described (video freezing while audio continues when the connection becomes POOR) is expected behavior from LiveKit’s congestion control: when packet loss or available bandwidth drops, LiveKit will prioritize audio and reduce or pause video to keep the call alive. What’s happening • Poor connection (high packet loss or low bandwidth) causes the server/client to drop higher‑bitrate video layers or pause video to preserve audio. • Simulcast/adaptive streaming will try lower layers first; if congestion is severe, video can appear frozen while audio stays fine. How you can confirm this • Listen for the client/server connection quality events (Poor/Good/Excellent). • Watch for

stream_state_update

or

trackStreamStateChanged

events — they indicate video was paused/resumed due to congestion. • Check WebRTC stats at the time: packet loss, bitrate drops, or

qualityLimitationReason = "bandwidth"

on the publisher. Immediate fixes to try • Ask the user to switch to wired Ethernet or a stronger Wi‑Fi network. • Have the user stop other heavy uploads/downloads or close background apps. • Reduce the published video resolution/bitrate or disable high‑res simulcast temporarily. • If using adaptiveStream, ensure it’s enabled so LiveKit can automatically select lower layers. If you want, send me: • the Room/participant ID and timestamp of the incident, plus any client-side logs or WebRTC stats, and I’ll help interpret them and suggest specific config changes. Sources: How is Connection Quality determined? | Bringing Zoom's end-to-end optimizations to WebRTC | LiveKit | Managing Video Quality During Network Congestion | An introduction to WebRTC Simulcast | LiveKit, with interactive elements

Means everybody need to have good internet to work with livekit? How can we use livekit with poor internet then?

Great question — you don’t strictly need perfect internet for LiveKit, but better connections give better video quality. LiveKit is built to tolerate varying networks and offers tools to keep calls usable on poor connections. Here’s how to use it when bandwidth is limited. What LiveKit does automatically • Prioritizes audio over video so conversations stay live. • Uses simulcast/adaptive streaming to send multiple video layers and switch to lower-bitrate layers when needed. • May pause or drop video streams under severe congestion to preserve audio. How you can make LiveKit work better on poor networks • Enable adaptive streaming (

adaptiveStream: true

) so clients automatically pick lower layers. • Limit published resolution/bitrate on constrained devices (reduce camera resolution, set a lower max bitrate). • Reduce simulcast layers or disable high‑res layers for low‑bandwidth participants. • Allow video to be paused when subscribers are congested (this preserves audio). • Offer an explicit “audio-only” mode in your UI so users can switch when video is unreliable. • Encourage practical user steps: switch to wired Ethernet, move closer to Wi‑Fi, close background apps, or limit other uploads/downloads. Monitoring and detection • Use connection quality events and

trackStreamStateChanged

/

stream_state_update

to detect when video is paused due to congestion and show UI guidance. • Inspect WebRTC stats (packet loss, bitrate,

qualityLimitationReason

) to tune settings per network conditions. If you tell me your primary platform (web/iOS/Android), current SDK version, and typical user bandwidth, I can recommend specific configuration values (resolution, target bitrate, simulcast layers) and UI flows for an “audio-first” experience. , with interactive elements