Applications group your SFU resources. Sessions represent WebRTC connections. Media tracks carry audio or video, and DataChannels carry application messages.
An SFU application has an App ID and App Secret. Its sessions can publish and subscribe to resources within that application. Use separate applications for development, staging, or other environments that need isolation.
Your backend uses the App Secret to authorize SFU API calls. Your application's own authentication and permission checks determine which end users can request those calls.
A session represents one endpoint's WebRTC connection to the SFU. In a browser, an RTCPeerConnection object manages that connection. Native applications use the equivalent peer in their WebRTC library. One connection can send and receive multiple media tracks and DataChannels.
A participant does not have to correspond to exactly one session. The video-room example uses separate publishing and receiving sessions. Cloud gaming uses one session per browser for incoming media and outgoing controls.
Calling POST /sessions/new with no request body returns a sessionId, but does not establish the WebRTC connection. Follow a connection recipe to complete the offer/answer exchange, then wait for the endpoint's connection state to become connected.
Create each session when ready to begin negotiation. An unconnected session can expire before its first track or DataChannel operation. Activity on another session does not keep it alive.
If setup expires, later operations can return HTTP 410 with session_error. Create a new session and repeat connection setup.
Follow per-session mutation ordering during setup and later updates.
A media track carries audio or video. Publishing sends that media into the SFU. Subscribing requests a copy of another endpoint's publication. A browser supplies a MediaStreamTrack, while a native endpoint supplies the corresponding encoded media through its WebRTC implementation.
To publish a track, call tracks/new with location: "local" and give the publication a trackName. To subscribe, call tracks/new on the receiving session with location: "remote", the publisher's sessionId, and the same trackName.
The main identifiers have distinct purposes:
| Identifier | Purpose |
|---|---|
appId |
Selects the SFU application |
sessionId |
In the URL, selects the target session. In a remote track entry, identifies the publisher |
trackName |
Names the publication within its publishing session |
mid |
Identifies a media section/transceiver in a particular PeerConnection's session description |
| Application member or device ID | Identifies an entity in your own state and permission model |
Use the publisher's session ID together with the track name to locate remote media. A track's mid belongs to its connection. A subscriber can receive that publication on a different mid.
Your application maintains a list of available publications and shares it with authorized subscribers. Each subscriber chooses which tracks to request.
For a room, that state might contain members and their camera/microphone publications. For a device, it might contain its active publisher session and telemetry channel names. Keep discovery state current when publications end or sessions are replaced.
A successful HTTP response can contain errors for individual tracks. Check each result before recording a publication or subscription as ready.
DataChannels carry application messages such as telemetry, text, and control events. They have negotiated channel IDs and delivery settings, and use separate DataChannel API operations. They are not browser MediaStreamTrack objects.
Remove a publication from discovery when your application stops offering it. This does not close existing subscriptions. Retain its SFU identifiers privately while cleanup remains outstanding.
Follow the media-close sequence or DataChannel closure when resources are no longer needed. Refer to limits for expiration and reuse, and Best practices for cleanup ownership.
Run the video room to publish camera and microphone tracks, discover another participant, and pull remote media. Its architecture guide ↗︎ maps each identifier to the component that owns it.