Skip to main content

​
Video room consoles: Sessions, Widget, Templates, and Live

Four consoles under Voice → Video run the day-to-day operation of your video rooms:
  • Sessions (/voice/video/sessions) — the per-meeting audit log. Every room session that ever ran, who joined, how long it lasted.
  • Widget (/voice/video/widget) — the builder for the embedded “video call us” button on your own site — presets, lobby options, and the copy-paste embed snippet.
  • Templates (/voice/video/templates) — the saved room-setup library. Create rooms that always open with the same configuration.
  • Live (/voice/video/live/[id]) — the in-dashboard viewer for a room’s live broadcast (HLS or WHEP playback) by room ID.
Each is read from or writes to a different slice of the video stack, so the right answer to “where do I look?” depends on the question — the closing section maps questions to surfaces.

​
1. Sessions: the per-meeting audit log

Open Voice → Video → Sessions. The page lists every session that ran in your rooms, newest first — not the list of live rooms, the history of individual meetings. A scheduled room that runs every Tuesday shows one row per occurrence, so “which guests joined the 3pm room on Tuesday?” is a look-up, not a guess.
  1. Scan the session list. Each row names the room, when the session started, its duration, and the participant count. Sessions stay in the list after the room ends — when the media server garbage-collects an idle room from the live listing, its sessions remain reachable here.
  2. Open a session for detail. Click a row to drill into one session: the join/leave timeline per participant, and when media was rich enough to synthesize it, the session’s summary, chapter breakdown, and QA scorecard.
  3. Use it as a support surface. This is the console an agent opens when a customer says “I joined but the host couldn’t hear me” — find the session by room and time, and the per-participant timeline shows who joined, left, and rejoined.
Sessions is read-only and append-only: sessions are added as rooms close and are never edited in place. Any role with access to the video area can read it; there is nothing to mutate.

​
2. Widget: the embedded consultation button

Open Voice → Video → Widget. This console builds the drop-in “video call us” pattern for your website: pick a consultation preset, tie it to a persistent room, tune the lobby behaviour, and copy the resulting embed snippet. The page is write-gated to owner, admin, and developer roles — every action on it (presets drive waiting-room and recording options, and the snippet has to be generated) needs video:write, the same gate the API applies.
  1. Pick a preset. Two cards cover the two consultation patterns: a queued visitor (the guest arrives in a waiting room and an agent admits them — the intake/consultation shape) and a direct drop-in (the guest joins the room immediately — the quick-answer button shape). Choosing a preset re-derives the snippet options and the lobby guidance below it.
  2. Tie it to a room. Select which of your persistent rooms the button opens. A room is required: until one is chosen, the snippet stays incomplete so you can’t copy an embed that goes nowhere.
  3. Check the retention readout. The console shows the tenant’s recording-retention window as context (set under retention settings); it is read-only here.
  4. Copy the snippet. Choose the embed format tab — an iframe, or the script component for a JS app — and copy the generated snippet into your site. Guests clicking the button land in the selected room under the preset’s rules.
For the full hosted button flow — styling, queue routing, and the agent-side experience — see Embed a video consultation button. The Widget console is where the button’s room and preset wiring happens.

​
3. Templates: the saved room-setup library

Open Voice → Video → Templates. Every saved room template is a card with its name, description, and a badge summary of the settings it locks in — for example “Up to 20 participants”, “Ends after 30 min”, “Recording on”. The room templates guide covers the full lifecycle and what each setting locks in; this section is the console walkthrough.
  1. Create a template. Click New template, name it, and pick the room defaults it applies — participant cap, duration limit, recording behaviour, waiting room, captions, encryption, media region. Every setting is optional; leave one unset and rooms created from the template inherit the normal room default.
  2. Edit or duplicate. The pencil on a template’s card reopens its configuration. To branch off a variant, open a template, change the one or two settings you want to vary, and save under a new name.
  3. Create a room from a template. Click Create room on the card, name the room, and it opens with everything the template saved. From then on, any host in the workspace spins up the same room in one click instead of a dozen fields.
Templates are a tenant-wide library — one saved template works for everyone on your workspace — capped at 100 entries. Like Widget, the console is write-gated to owner, admin, and developer (video:write); roles with only read access cannot open it.

​
4. Live: the livestream viewer

Open Voice → Video → Live → room ID (/voice/video/live/[id]) — the live page is per room, so you reach it at a room-specific address rather than from a list. It plays the room’s live broadcast inside the dashboard, over HLS or WHEP depending on how the room’s livestream is distributed.
  1. Open the viewer for a room. Take the ID of a room whose livestream is running and open /voice/video/live/<room ID>. The player fetches the room’s playback URL and starts the stream — no LiveKit session, no host seat.
  2. Watch, don’t join. The viewer is playback-only: audio/video in, nothing out. It is for monitoring a broadcast — a supervisor checking the webinar feed, a colleague watching an all-hands — not for participating. To join as a participant, enter the room itself, not the live page.
  3. HLS vs WHEP in one sentence. WHEP is the low-latency path (sub-second, for the “watch it as it happens” seat); HLS is the scale-out path (seconds of latency, for large audiences over CDNs). The page plays whichever the room’s livestream is broadcasting.
The audience-facing guest player an embed or public link opens is a separate surface — covered in the WHEP guest player guide. The Live console is the in-dashboard watch seat for your own team.

​
5. Which surface answers which question

The video area has more tabs than the four consoles above. The rule of thumb: consoles operate on a room’s run; meetings and webinars are the rooms themselves; history and analytics are the reports about them. Meetings vs Webinars. Reach for Meetings when everyone in the room talks — a consultation, a standup, a working session. Reach for Webinars when a few present to many — a registration-gated broadcast where attendees stay largely in listen mode. A one-off room goes straight into Meetings; run it repeatedly, and a template turns it into one click.