1. Home
3. Guides
5. Scaling calls
7. Best practices to scale large experiences

Best practices to scale large experiences

As the number of call participants increases, the number of audio, video, and screen media tracks that need to be routed and then handled by each web client multiplies. This can drain CPU, strain networks to their limits (risking undelivered media streams), and degrade user experience quickly, especially on older or mobile devices.

To optimize performance on calls with hundreds of participants, pagination, track subscriptions, and simulcast layer control can all be implemented using Daily’s APIs. Analyzing call logs can also help improve call quality.

Pagination

Pagination limits the number of participants displayed on a screen at a time, so a call participant has to click to rotate through all other attendees. This reduces the load on any individual participant’s CPU and bandwidth.

The gif highlights a demo app built on React, but pagination can be implemented regardless of the framework used.

Use the Daily participants() method to access the full list of active participants in a call. Once the participants are known, you can do the following to build out your pagination logic:

1. Establish constant UI elements like the minimum participant video tile width, default aspect ratio, and the maximum number of tiles per page.

2. Use the UI constants and the number of call participants to calculate the total number of pages. The number of pages, and which participants are on each page, should update as the number of call participants changes, so set up the state management of your choice.

3. Add click handlers to the pagination buttons that update the app state to reflect the current page being viewed.

4. Set up a handler to determine the visible participants on a given page, using the current page, number of participants, and maximum number of tiles per page to make a copy of the participants object that only includes visible participants.

5. Iterate over the visible participants object to render each participant in the UI.

Track subscriptions

Daily calls operate on a publish-subscribe model: participants publish audio, video, and screen MediaStreamTracks, and are subscribed to other participant’s tracks.

By default, Daily routes a participant’s distinct set of tracks to all the other participants on a call. In large calls with hundreds and thousands of participants, decoding all that video can demand a lot of network bandwidth and processing power.

Turning off Daily’s default track handling in favor of manual track subscriptions can deliver better call quality during sessions with many participants. Track subscriptions can also enable features like breakout groups, and improve features like pagination.

There are three steps to set up direct track subscriptions:

1. Set the subscribeToTracksAutomatically call object property to false.

This turns off Daily’s default track management. This property can be passed on join(), at createCallObject(), or via the setSubscribeToTracksAutomatically() method. The latter is a good option if you want to wait to turn on track subscriptions until a certain number of participants have joined the call.

2. Call updateParticipant() or updateParticipants() to change the subscribed value of a participant's tracks property.

Each individual participant’s tracks property can be found on the Daily participants object.

The tracks for a participant include audio (microphone), video (camera), and screenAudio and screenVideo (screenshare) properties. Each track type contains: a raw media stream track object available on both track and persistentTrack, the state of the track, and its subscribed value.

state indicates if the track can be played (full possible states in the participants() documentation).

subscribed tells us whether or not the local participant is receiving the track information from the participant who the track belongs to. Its value is true if the local participant is receiving, false if they are not, or "staged".

A subscribed status of "staged" keeps the connection for that track open, but stops any bytes from flowing across. Compared to a complete connection teardown through an unsubscribe, staging a track speeds up the process of showing or hiding participants' video and audio. Staging also cuts out the processing and bandwidth required for that track.

On calls with many participants, setting the subscribed value to staged or false depending on the interface can minimize the load on participants’ connections, improving the user experience. Paginated grid apps (including Daily Prebuilt!) often subscribe to the tracks of participants on a current page, stage those on the previous and next pages, and unsubscribe from the rest.

Use the updateParticipant() and updateParticipants() Daily methods to update participants’ subscribed states.

updateParticipant() receives an object with the participant’s id as the key, and the value a setSubscribedTracks object indicating the new subscribed status of each track type.

If using updateParticipants(), combine all participants’ updates into one object.

3. Listen for participant events to reflect updated participant state in the app interface.

The updateParticipant() method fires a corresponding "participant-updated" event. Add a listener to this event to update the app interface as participants’ subscribed statuses change.

Simulcast layer control

Once a third participant joins a Daily call — or if recording, transcription, or a live stream is started — instead of direct peer-to-peer (P2P) connections, tracks are first sent to a Selective Forwarding Unit (SFU). From there, the SFU processes, re-encrypts, and routes media tracks to participants, allowing tracks to be "selectively" forwarded.

With WebRTC simulcast, instead of sending a single track to the SFU, a publishing participant’s web client sends the same source track at a few different resolutions, bitrates, and frame rates. Each of these groups of settings is known as a simulcast layer.

By default, the Daily client and SFU will work to send the highest layer possible.

There are several factors that affect which layer a participant receives. Those factors include:

1. The available bandwidth on the receiving end: The SFU will send a lower layer if the current one exceeds the available bandwidth.
2. The send-side is not sending all the layers: This typically occurs when the browser detects network or CPU issues or the highest video resolution of the device does not support the highest layers. It's also worth noting that the browser can and will modify the actual bitrate, frame rate, and resolution sent on each layer for these same reasons, so the actual settings used may not match the configuration.

Daily call object default desktop simulcast layers and their settings

Daily call object default mobile simulcast layers and their settings

While the default Daily simulcast management suits most use cases, it is possible to adjust the quality of both the video a participant publishes to the server (send-side) and the video that participants receive (receive-side). This can be useful in large calls as a tool to optimize bandwidth, but proceed with caution. Attempting to make changes while calls are in progress or to use values beyond browsers' capacities can cause problems. Please reach out if we can help.

Change send-side video quality

Adjusting the quality of the video that participants send to the server can be useful in large calls. For example, the main active speaker showcased prominently in the UI could send higher quality video than the other call participants.

There are two properties that can be manipulated to adjust send-side video quality: sendSettings or userMediaVideoConstraints.

Use the sendSettings property to specify spatial layer settings

The sendSettings call object property defines maxBitrate, maxFramerate, and scaleResolutionDownBy values to set encodings for spatial layers that differ from Daily defaults.

• maxBitrate: the desired video bitrate for the layer, in bits per second.
• maxFramerate: an integer value lower than the maximum rate expected from the camera, in frames per second.
• scaleResolutionDownBy: an integer of 1 or greater. The horizontal and vertical dimensions of the source video will be divided by this number to get the resolution for the layer.

sendSettings can be configured when the call object is created (via createCallObject()) or by using the updateSendSettings() call object instance method.

Set video input quality with userMediaVideoConstraints

The userMediaVideoConstraints property determines the 'input quality' of the video that a browser gets from a web cam by defining a maximum resolution (width and height values) and a maxFramerate.

Adjust receive-side video quality

The Daily receiveSettings API can be used to override the SFU estimated forwarding and request a specific simulcast layer instead.

If many participant videos will be displayed or if they will be rendered on small mobile screens, for example, programmatically requesting a lower bitrate layer can improve call performance. Lower quality videos not only save downstream bandwidth, but also can dramatically improve CPU performance since they require fewer resources to render.

To use Daily receiveSettings to request a specific simulcast layer:

1. Request the updated simulcast layer, either through updateReceiveSettings() or by passing a receiveSettings object on join().

2. Listen for the "receive-settings-updated" event to update the app interface in response.

Analyzing large call performance

See the logs and metrics guide for details on analyzing call quality.

Tutorials about scaling large calls