Key Concepts¶

This page explains the core concepts you'll encounter when using, deploying, or contributing to La Suite Meet.

Room¶

A room is a virtual meeting space. Each room has:

• A unique slug/ID used in the URL (e.g., meet.example.com/my-room-name)
• An owner (the user who created it) with full control
• Access settings: open, authenticated-only, or invite-only
• A configuration that can include recording options, participant limits, and feature flags

Rooms are non-persistent by default — chat history and ephemeral state are not stored between sessions.

Participant¶

A participant is anyone connected to a room. Participants have:

• A role: owner, moderator, or attendee
• Media tracks: camera video, microphone audio, and optionally screen share tracks
• Metadata: display name, avatar, and connection state

LiveKit¶

LiveKit is the open-source WebRTC infrastructure that powers Meet's real-time media. It is a Selective Forwarding Unit (SFU) — unlike an MCU (Multipoint Control Unit), an SFU does not transcode media. It receives streams from senders and selectively forwards them to receivers, which is dramatically more scalable and CPU-efficient.

Meet uses LiveKit for: - All audio and video streaming - Screen sharing - In-meeting chat (via LiveKit Data Channels) - Recording (via LiveKit Egress) - Transcription (via LiveKit Agents)

SFU vs MCU¶

Token / JWT¶

LiveKit uses JSON Web Tokens (JWTs) for authentication. When a user joins a meeting:

1. The Django backend generates a short-lived JWT signed with the LiveKit API secret
2. This token encodes the user's identity, room name, and permissions
3. The client presents this token when connecting to LiveKit
4. LiveKit validates the token and grants access

Tokens are issued by the Django backend — the LiveKit server itself never needs to know about users or OIDC.

OIDC / SSO¶

Meet uses OpenID Connect (OIDC) for user authentication. Any standards-compliant OIDC provider works:

• Keycloak (bundled in the development stack)
• ProConnect (used by French government instances)
• Authentik, Dex, Auth0, Okta, Google, etc.

OIDC handles who the user is. LiveKit tokens handle what the user can do in a room.

Egress¶

LiveKit Egress is a LiveKit component that processes room output. Meet uses it for:

• Room composite recording: Records the entire room view as a video file
• Track recording: Records individual participant tracks

Egress saves output to object storage (Garage/S3). It requires: - Access to the LiveKit server - Access to Redis (shared with LiveKit) - Access to S3-compatible storage

Celery¶

Celery is a distributed task queue used in two places:

1. Django backend Celery worker: Handles async tasks like sending recording notification emails
2. Summary service Celery workers: Two separate workers for transcription (transcribe-queue) and summarization (summarize-queue)

Both use Redis as the message broker.

Garage / S3¶

Meet stores binary files — recordings, uploaded files — in S3-compatible object storage. For self-hosted deployments, Garage is recommended. In production, you can also use Garage, AWS S3, Scaleway Object Storage, OVH Object Storage, or any S3-compatible service.

The Django backend uses a webhook from S3-compatible storage to detect when a recording file has been uploaded, which triggers the recording state to update in the database.

Simulcast¶

Simulcast is a WebRTC technique where a participant's browser encodes and sends the same video stream at multiple quality levels simultaneously (e.g., 1080p, 360p, 180p). LiveKit then forwards only the appropriate quality level to each receiver based on their available bandwidth. This dramatically improves quality in meetings with participants on varying network conditions.

Room configuration¶

Rooms can have a configuration object controlling:

• Whether recording is allowed
• Whether transcription is allowed
• Participant limits
• Feature flags for specific capabilities

This configuration is set by the room owner and enforced by both the backend and the frontend.