Product patterns for live rooms

MediaSFU can sit behind very different products: a private call, a salesroom, a shared player, a production desk, a classroom, or a stage with a large audience. These reference patterns show where your application owns the experience and where MediaSFU supplies realtime room media.

Choose a pattern

Pattern	Best for	Primary experience
Familiar chat call	Two people who already think in contacts and calls	An invite-led private call
Live auction and shopping	Timed lots, bidders, and a host console	Ordered bidding beside live media
Watch together	A program with optional conversation	WHIP input with WebRTC or HLS output
Voice and vision agents	Realtime assistants with operator oversight	Ordered playback, media input, and human handoff
SIP and PSTN calling	Browser or mobile operators handling telephone calls	Audio-first calling, agent control, and human takeover
SpacesTek progression	Social rooms with listeners, speakers, and moderators	A staged path from product concepts to secure headless rooms
Broadcast control room	Producers choosing a source for air	Preview, program, and contributors
Interactive classroom	Moderated learning and Q&A	Polls, board, queues, and breakout groups
Hybrid stage and audience	A few active speakers plus many viewers	WebRTC stage with synced HLS

The six showcase pages are product blueprints, not cross-SDK promises or production backends. Each page names the authority boundary, media identity, failure recovery, cleanup, and the platform evidence that is actually available. Start with the product boundary, then select the SDK package and room operation guide for the platform you ship.

Use the Starter Projects catalog when you want runnable code. Product patterns explain architecture; the catalog separates public repositories, live showcases, tutorials, and SDK examples and records platform evidence independently.

The standalone references are available as MediaSFU familiar calls, MediaSFU Live Auction, and MediaSFU Watch Together repositories. They are implementation references; the Projecte pages above remain the canonical product guidance.

The ownership boundary

Your app owns names, roles, invitations, product state, layout, and recovery copy. Your backend should create and join rooms, authorize roles, protect credentials, and confirm cleanup. MediaSFU owns room transports, tracks, participants, and realtime media events.

Across these patterns, a good media surface follows four rules:

• Make screen share the primary surface when it is active; otherwise prefer an identified remote camera and then the local camera.
• Keep a secondary camera or participant visible as a mini card or rail.
• Mirror only a local camera preview. Show screens with contain so slides and code remain readable.
• Mount remote audio independently from visible video. A participant can be audible while their camera is off or while another source is on stage.

Catalog records

Broadcast control room

Producer-led contributor room with preview sources, a selected program surface, named guest invitations, and explicit end. The pattern is useful for rehearsals and custom control desks. It does not by itself provide HLS egress, recording, moderation, sign-in, or persistence; those belong in your application and backend design.

Interactive classroom

Teacher/moderator plus learners, with queued speakers, polls, shared board, breakout groups, and learner-specific room views. MediaSFU supplies realtime room media while the application owns classroom state and moderation. A participant invitation should bind both role and assigned display name.

Hybrid stage and audience

A small WebRTC speaker stage can stay conversational while a passive audience receives a program over HLS. Keep the stage floor and audience playback as two deliberate surfaces: the audience should not accidentally receive contributor audio or room controls. Use a backend-owned audience grant and a bounded playback policy.

Before release

Use an authenticated backend for reusable MediaSFU credentials, test a real host and a separate participant, verify camera, microphone, screen share, and remote audio on the target platform, and confirm that both the application state and upstream room are cleaned up after leave and end. A successful build does not prove live media behavior.