Broadcast Using SFU or MCU
LiveSwitch supports massive-scale broadcasting of audio/video data from both SFU and MCU upstream connections to SFU downstream connections. There are two call-flow models available for different use cases: Reactive Downstreams and Proactive Downstreams.
Note
About the code examples on this page:
- For .NET MAUI and Unity, use the C# code.
- For macOS, use the iOS code.
Reactive Downstream Connections
The reactive model is easy to implement and preferable for small audiences that are less than 1,000. In this model, you should create SFU downstreams when you receive an upstream notification.
To create reactive SFU downstream connections, pass by an instance of RemoteConnectionInfo
into the CreateSfuDownstreamConnection
channel method.
_Channel.OnRemoteUpstreamConnectionOpen += (remoteConnectionInfo) =>
{
SfuDownstreamConnection downstream = _Channel.CreateSfuDownstreamConnection(remoteConnectionInfo, ...);
};
The remote upstream connection can be any SFU or MCU connection in the same channel with an upstream (sending) component.
SfuUpstreamConnection upstream; // or MCU
upstream = _Channel.CreateSfuUpstreamConnection(...);
The lifespan of an SFU downstream connection created this way is tied to the remote upstream connection. When the remote upstream connection closes or fails, the SFU downstream connection also closes.
Note
A sudden flood of downstream connection requests are generated if a large audience is present and actively waiting when the SFU or MCU upstream connection is created, or if the upstream connection loses network connectivity and has to create a new connection. LiveSwitch can handle this burst traffic if sufficient server resources are available. Consider the proactive model if you anticipate large audiences.
Proactive Downstream Connections
The proactive model is preferable for large audiences. In this model, you create and manage SFU downstreams independent of any remote upstream connection events. You use a media ID to associate an upstream connection with any downstream connections.
Use Media IDs
The media ID allows listeners to open their receiving/downstream connection ahead of time.
Under the normal group conferencing model, downstream connections are opened in response to a remote upstream connection event. This model works well with small-to-medium-sized group conferences where everyone connects to everyone else.
However, in cases where hundreds or thousands of people may be waiting for the presenter to start, it creates a distributed denial-of-service (DDoS) attack on the Media Servers when the presenter connects. Allowing the listeners to connect in ahead of time means the load is distributed normally leading up to the event.
A media ID is an optional parameter that you can specify when the broadcaster creates their sending (upstream) connection. It must be unique to a given channel. You can use any string for the media ID. Listeners must use the same media ID when creating their receiving (downstream) connection. The media ID replaces the remote connection info that's normally used to support group conferencing.
To create proactive SFU downstream connections, pass by a media ID into the CreateSfuDownstreamConnection
channel method.
SfuDownstreamConnection downstream = _Channel.CreateSfuDownstreamConnection("upstream media ID", ...);
You must use the same media ID for the remote upstream connection.
SfuUpstreamConnection upstream; // or MCU
upstream = _Channel.CreateSfuUpstreamConnection(..., "upstream media ID");
Tip
You still receives notifications when the remote upstream connections open and close OnRemoteUpstreamConnectionOpen
and OnRemoteUpstreamConnectionClose
. You can use these events to update the UI in response to upstream connection state changes.
Disable Remote Client Events
By default, everyone in the channel is notified when clients come and go, and when sending/upstream connections are opened and closed. In a large conference, this information can negatively impact the performance of the presentation. You can disable remote client events to reduce the impact by updating your channel claim with the following:
DisableRemoteClientEvents = true;
Note
- It's important to set this flag for listeners who only watch the presentation.
- It's also helpful to set this flag for presenters. However, don't set this flag if the presenter wants to see the full participant list.
Use a Third-Party JWT Library
If you are generating tokens using a third-party JWT library instead of the LiveSwitch SDK, just add disableRemoteClientEvents
to the channel claim object:
{
"id": "...my channel ID...",
"disableRemoteClientEvents": true
}
Set Connection Permissions
Once users have a token, they are permitted to join any of the channels within that token. To prevent users from changing stream directions and making unauthorized broadcasts, you can set the disableSendAudio
and disableSendVideo
properties on the channel claim (each channel under channel
or channels
).
By adding the additional flags you can limit whether a user is send-only or receive-only. It's especially important for your JavaScript app since users could use the browser console to access the LiveSwitch Web SDK and create connections that weren't created by your app. You should ensure that if users did this, they are restricted to what the token allows.