English for LiveKit Developers

LiveKit conversations often involve explaining why real-time audio and video needs dedicated infrastructure rather than a simple WebSocket, so the vocabulary covers rooms, tracks, and the selective forwarding model that keeps calls scalable.

Key Vocabulary

Room — a LiveKit session that participants join to exchange audio, video, and data, acting as the container that scopes who can see and hear whom. “Each interview gets its own room — participants who join the wrong room ID simply won’t see or hear anyone from a different session.”

Track — an individual stream of audio, video, or data published by a participant into a room, which other participants can choose to subscribe to independently. “You don’t have to subscribe to every participant’s video track — mute the ones off-screen to cut bandwidth without dropping the call.”

SFU (Selective Forwarding Unit) — the server architecture LiveKit uses to receive each participant’s media once and selectively forward it to other participants, avoiding the bandwidth cost of full mesh peer-to-peer connections. “With ten participants, a mesh connection means each browser uploads its stream nine times — the SFU means everyone uploads once and the server handles distribution.”

Data channel — a low-latency, non-media channel within a LiveKit room used to send arbitrary application data (like chat messages or cursor positions) alongside audio and video tracks. “Send the reaction emoji over the data channel instead of encoding it into a video track — it’s much lighter and arrives with much lower overhead.”

Simulcast — publishing a video track at multiple quality levels simultaneously, letting the server forward the appropriate resolution to each subscriber based on their bandwidth and screen size. “Enable simulcast on the publisher side — a participant on a slow connection can then get the low-resolution layer instead of the whole call degrading for everyone.”

Common Phrases

• “Are these participants actually in the same room, or is that why they can’t see each other?”
• “Do we need to subscribe to this track at all, or can we skip it to save bandwidth?”
• “Is this scaling problem because we’re doing mesh instead of going through the SFU?”
• “Should this update go over the data channel instead of being embedded in the video stream?”
• “Is simulcast enabled here, or is that why mobile users on weak connections are getting a frozen call?”

Example Sentences

Explaining the architecture to a new backend developer: “Every call is a room. Each participant publishes their own audio and video tracks into it, and the SFU forwards those tracks to everyone else without each client uploading to every peer directly.”

Debugging a bandwidth issue: “Check whether simulcast is turned on for this publisher — without it, everyone gets the same high-resolution stream regardless of their actual connection speed.”

Explaining a feature decision: “We’re sending the whiteboard cursor position over the data channel rather than a custom video overlay — it’s much cheaper and doesn’t need a codec.”

Professional Tips

• Clarify room scoping early when debugging visibility issues — a surprising number of “call not working” bugs are actually participants joining different room IDs.
• Explain tracks as independently subscribable — this helps justify bandwidth-saving features like muting off-screen video.
• Use the SFU explanation to justify infrastructure cost to non-technical stakeholders — it’s the reason group calls scale past a handful of participants.
• Recommend the data channel for anything that isn’t audio or video — a common anti-pattern is smuggling small data updates through media tracks.

Practice Exercise

1. Explain what a room and a track are, and how they relate to each other.
2. Describe why an SFU scales better than a full mesh peer-to-peer architecture for group calls.
3. Write a sentence explaining to a teammate why simulcast would help a user on a poor connection.