Skip to main content

How Media Moves Through a Room

MediaSFU handles the live room and media lifecycle. Your app chooses what the user sees, when to request device access, and how to explain success or failure. This page explains the shared concepts; implementation details and runnable examples live in the package-specific guides linked below.

The media path​

  1. Create or join the room and wait until its media controls are ready.
  2. Ask for microphone, camera, or screen access in response to a user action.
  3. Let the active SDK room produce the local track and prepare remote tracks.
  4. Render the media handles or supplied components using that SDK's supported renderer.
  5. Keep remote audio playback alive even when a participant's video is hidden, paginated, or replaced by a screen-share view.
  6. On exit, stop media your app created, await the appropriate room leave/end action, then dispose subscriptions and renderers.

The supplied room UI already connects these stages. A custom or headless UI should use the SDK's room controller, hook, service, or facade. Do not rebuild socket or WebRTC transport negotiation inside a screen component.

State and rendering rules​

Use the current room state published by the SDK. Some headless APIs distinguish a pure state read from a call that republishes shared parameters; a publishing read does not belong in a render/build function, computed value, watcher, pagination read, or polling timer. Accept each state publication so controls do not retain an outdated room snapshot.

Treat media as participant-owned tracks, not as array positions or display names. Use the SDK's participant/producer projection to resolve the intended stream. When selecting a single main visual, prefer an active screen share, then the applicable remote camera, then the local camera preview. Keep the local preview muted to avoid feedback. Display shared-screen content unmirrored and contained; only mirror a local camera preview when that is the intended experience.

Remote audio is independent of visible video. Keep every prepared remote-audio renderer mounted outside video pagination and main/mini-video selection. Use the SDK's normal audio grid or platform-equivalent playback path; creating a second player for the same prepared audio can cause duplicate sound and confusing cleanup.

If somebody goes silent after join or a page change, check that the SDK has prepared their consumer, that its audio renderer remains mounted, and that the device output route is correct. On reconnect, use the SDK's consumer recovery path and refresh the current room projection before showing the person as audible again. Do not create a replacement player for the same consumer.

App-created canvas, element, file, or synthetic tracks remain app-owned. Stop and detach them during cleanup even when the room also leaves successfully. A late transport acknowledgement after leave or device shutdown must not recreate media for a closed room.

Continue in your SDK's guide​

Choose your package first, then use its dedicated media and recovery guide. The shared pages below explain the concepts; each package-specific section identifies the applicable implementation.

Start from a product example​

These public projects show how room media fits into a recognizable product. The repository guide records platform evidence separately; a multi-platform repository does not mean every port has identical runtime validation.

Use the Starter Projects catalog to compare their runnable scope, platforms, and evidence before choosing a starting point.

For a fully app-owned interface, read headless UI concepts, then follow the headless section in your SDK guide index. For device selection, virtual backgrounds, or translation, use the device and effects guide. For reconnect and control failures, see recovery and media controls. For semantic participant leave, host end, or host leave-without-ending, see leave, end, and rejoin.