Skip to main content

Build by Outcome

Start with the product result you need, find it in the feature directory, and then choose the SDK already used by your application. The platform guide names its components, methods, success states, and cleanup steps.

Start with a secure room​

Build a room that users can create or join without putting long-lived MediaSFU credentials in a browser or app bundle.

  • MediaSFU provides: the selected SDK's room runtime and its documented participant, media, rendering, and exit workflows.
  • Your backend provides: application authentication, room and role policy, rate limiting, and the protected connection to MediaSFU.
  • Start here: choose your SDK implementation.

Each linked operation guide contains a complete package-specific example or an explicit platform boundary. Test the complete two-user media flow in your supported browsers and devices before release.

Make a compact call experience​

Begin with a working room, then keep the runtime while changing only the visual surfaces that make the experience feel like your product.

  • MediaSFU provides: room lifecycle and the card/control extension surfaces documented by the selected SDK.
  • Your app provides: navigation, visual design, product copy, and the layout rules for your call experience.
  • Start here: product recipes, then use the selected SDK's rendering and UI-ownership path. React applications can use the complete media rendering walkthrough.

Validate device permission, local media, remote media, and leave behavior before investing in visual polish.

Then add device selection, virtual backgrounds, and translation or large-room pagination and moderation through the selected SDK's focused section.

Run a class, workshop, or meeting​

Use a room-shaped experience when participants need to join, see each other, and share audio, video, or a screen.

  • MediaSFU provides: the room and media runtime; available prebuilt surfaces depend on the SDK and room configuration.
  • Your app and backend provide: enrollment, identity, role policy, attendance, and any business records.
  • Start here: choose your SDK implementation, then follow its room and participant-collaboration guides.

Add moderation, collaboration, and capture features only after the core room works and the chosen SDK documents the required APIs.

Build a host-led live experience​

For webinar and broadcast-style products, first prove the room and media flow, then move to a host workspace if the supplied room layout no longer fits.

  • MediaSFU provides: the selected room runtime and its documented controls.
  • Your app provides: stage composition, host workflow, audience experience, and product-specific moderation screens.
  • Start here: choose your UI mode, then use the host dashboard recipe and the moderation guide linked from your SDK page.

The dashboard starter demonstrates layout. The linked operation guides provide the supported actions and their confirmation behavior; actions without a documented contract remain hidden.

Put calls inside a support workspace​

Choose a headless path only when your CRM, ticketing, or operator workflow must own the visible shell from the first screen.

  • MediaSFU provides: the room runtime and documented live state/action handoff for the chosen SDK.
  • Your app and backend provide: customer context, operator authorization, audit records, escalation, and external-service integrations.
  • Start here: headless mode and the support-console starter.

For an existing configured MediaSFU call, use the server-side AI call controls. CRM actions and handoff policy remain application responsibilities.

Add screen sharing safely​

Screen sharing is an operation, not just a button. Users need a clear permission path, a visible success state, and a reliable stop/cleanup path.

  • MediaSFU provides: the screen-share action or component documented by the selected SDK.
  • Browser and operating system provide: the capture chooser and permission decision.
  • Your app provides: denial/retry messaging and any product-specific sharing policy.
  • Start here: screen sharing and rendered media by SDK, followed by the complete React rendering path for custom layouts.

Screen annotation is a separate product surface. Use the documented screenboard or whiteboard path for the selected SDK; do not assume that an arbitrary captured screen becomes annotatable.

Add external media or HTTP-only control​

Use MediaSFU's server APIs when a backend process, encoder, player, or operator tool needs to act without holding an SDK room UI.

The backend owns authorization, policy, and resource cleanup. An SDK can stay mounted for WebRTC participants while the backend controls these separate resources.

Choose the right level of UI ownership​

If your product needs...Start with
A working room quicklyPrebuilt room UI
Branding and selected surface changesUI overrides
A new workspace around room runtimeCustom component replacement
A fully app-owned interfaceHeadless mode
A framework adapter or lower-level runtime workmediasfu-shared

Stay with the highest-level option that fits. Moving lower gives your application more control, but it also makes your team responsible for more UI, lifecycle, and recovery behavior.

Platform-specific guidance​

Choose an SDK after choosing the outcome. Available operations and APIs differ by platform, so every SDK page links to its own operation examples.

Continue with your platform​