Server

Server Components

LiveSwitch Server consists of three server components:

  • Gateway: Provides signaling capability allowing your clients to make connections to Media Servers.
  • Media Server: Provides WebRTC connections allowing your clients to stream media through SFU or MCU connections.
  • SIP Connector: Provides interoperability with third-party SIP services.

Set Up a Development Environment

For development, you must set up at least one Gateway and one Media Server for your clients to get SFU or MCU connections.

Set Up a Production Environment

For production, we recommend that you set up the following:

  • At least two load-balanced Gateway Servers for redundancy.
  • A cluster of Media Servers to handle your media traffic depending on your peak concurrent usage.
  • A SIP connector if your use case requires SIP interoperability.

Server Requirements

The following specifications describe the hardware requirements for each LiveSwitch Server component.

Gateway

Firewall

  • For client connections:
    • Allow inbound TCP traffic on port 8080 (default) on public interfaces for HTTP
    • Allow inbound TCP traffic on port 8443 (default) on public interfaces for HTTPS
  • For admin console access:
    • Allow inbound TCP traffic on port 9090 (default) for HTTP on interfaces intended for admin access
    • There is no default port for HTTPS access, but you can configure one.
Note

To configure these port values, refer to HTTP/HTTPS Bindings

Minimum Hardware

  • 2x CPU
  • 2 GB RAM
  • Moderate network performance
  • 4x CPU
  • 4 GB RAM
  • High network performance

High Availability

  • 2+ Gateways
  • Load balancer with high-availability guarantees

Media Server

Firewall

  • For clustering, allow TCP traffic on port 8445. If the port 8445 is unavailable, Media servers try the next port incrementally until one is available. That is, 8446, 8447, 8448, 8449, and so on.
  • For client connections:
    • Allow inbound UDP traffic on ports 49152-65535 (default) on public interfaces for RTP traffic.
    • Allow inbound UDP/TCP traffic on port 3478 (default) on public interfaces for STUN/TURN traffic.
    • There is no default port configured for TURNS traffic, but you can configure one. Port 443 is recommended.
Note

To configure these port values, refer to Port Range Configuration

Minimum Hardware

  • 4x CPU
  • 4 GB RAM
  • High network performance
  • 8x CPU
  • 8 GB RAM
  • Highest network performance

High Availability

  • 2+ Media Servers

SIP Connector

Firewall

For SIP requests, allow UDP or TCP traffic on port 5061 on public interfaces.

How Many Server Instances Do You Need?

Estimating exactly the number of servers you need depends on expected concurrency. It doesn't matter how many users you have, but it matters how many users you expect to have active at the same time.

As a general best practice, concurrency is estimated using the 100:10:1 rule, which states that for every 1,000 named users, 100 are quite active, and about 10 are concurrent at any given point in time. Using 32,000 as a starting point means that we need to plan for 3,200 active users and 320 concurrent at any moment in time.

In general, you can expect one Media Server, on the equivalent of an AWS-EC2 c4.large (2x CPU, 4 GB RAM) instance, to handle ~240 concurrent connections in SFU mode with a standard 480p stream. So, to handle the load described here, you would require at least four Media Servers in a clustered environment.

A single Gateway can handle a lot more traffic than 320 concurrent connections. We run our demo environment Gateway on the equivalent of an AWS-EC2 c5.xlarge (4x CPU, 8 GB RAM), and it can handle thousands of concurrent clients. We recommend running two Gateways behind a standard load balancer for redundancy purposes.

P2P Connections

For MCU and SFU connections, relay is generally not required; see STUN/TURN Use Cases. If you use P2P connections, you can expect that some portion of these is over relay. About 20-30% of P2P connections require TURN; so with the example numbers discussed here, we need to plan for 96 concurrent TURN users. For this example load, the recommended server is also the equivalent of an AWS-EC2 c5.xlarge. TURN is very demanding on bandwidth. A typical standard-definition audio/video stream is about 1 Mbps; so with 96 relayed connections, you can use a single server that has 100 Mbps of available upstream/downstream bandwidth. For redundancy, you need two servers. Load balancer isn't required. Round-robin DNS to spread the load across the two servers is generally considered to be the best practice.

How Many Server Instances Do You Need for SFU Connections?

It varies significantly from use case to use case. Currently, LiveSwitch can handle ~120 connections per virtual CPU for audio/video connections with 720p video (or less).

The metrics for calculating the number of servers is Number of connections / Number of CPUs per server / 120. With this, you need to figure out:

  • How many connections are required to support your use case?
  • How many virtual CPUs do your actual servers have?

Number of Connections

Let's look at the number of connections for two common use cases: the conference use case and the huddle use case.

Conference Use Case

In a conference, you typically have one person or sometimes two or three people who are sending media, and you have many people, sometimes thousands, receiving media. In this case, each sender has an upstream connection to the Media Server, and each receiver has a downstream connection to the Media Server. This works out to #broadcasters + (#broadcasters * #receivers).

Want to add screen sharing? That's another connection per participant, so double the result.

Huddle Use Case

A huddle refers to a group of people who are all sending and receiving each other's media. This is typically a much smaller number of people than what a broadcast would target. In this case, each person has an upstream connection to the Media Server, and each person has a downstream connection for each other person in the huddle. This works out to n2 connections for n participants.

Screen sharing typically adds:

  • One additional upstream connection; usually, only one participant shares their screen at a time
  • n-1 downstream connections; one for each person viewing the screen share

Number of CPUs per Server

It's entirely up to you. You have to consider the cost of the different offerings from your Cloud Infrastructure Provider, weigh it against your expected volume and peak concurrency, and decide what works best for your usage and budget.

How Many Server Instances Do You Need for MCU Connections?

There are many variables that affect how many server instances are required for an MCU connection. In general, the recommended configuration is four MCU connections per CPU.

How to Set Server Capacity Thresholds

Up until 1.18.0, Media Server capacity was estimated by the number of CPU Cores as well as the number of connected MCU and SFU connections. The server configuration specifies the number of connections of each type that can be handled by a single CPU core.

In 1.18, credit-based Media Server capacity settings were introduced. These settings indicate not only the connection type, but also the video direction (send vs send/receive vs receive-only), payload resolution and frame rate, as well as whether server-side simulcast is enabled on the channel. Pre-1.18 capacity settings can still be used with 1.18 Media Servers and Gateways. They became deprecated in 1.19 and will be removed in future releases. Customers are encouraged to migrate to the new credit-based capacity thresholds. The new encoding-based thresholds are being introduced to reflect the fact that server capacity utilization depends on the video quality.

Each Encoding Threshold itself specifies:

  • An encoding, which includes resolution, frame rate and (optionally) bitrate, to which these thresholds apply
  • number of credits required to handle non-simulcast SFU downstream connection with media containing this encoding for a:
  • SFU downstream connection
  • SFU upstream connection
  • MCU downstream connection
  • MCU upstream connection
  • SFU Simulcast upstream connection with two simulcast substreams

A separate setting indicates the total number of credits that can be handled by a single CPU core.

EXAMPLE: Consider the following configuration containing two encodings:

Encoding: 480p, 30 fps; 1 credit for SFU Upstream; 1 credit for SFU Downstream; 12 credits for MCU Upstream; 12 credits for MCU Downstream; 27 credits for SFU Simulcast Upstream

and

Encoding: 720p, 30 fps; 1 credit for SFU Upstream; 1 credit for SFU Downstream; 12 credits for MCU Upstream; 12 credits for MCU Downstream; 55 credits for SFU Simulcast Upstream

CreditsPerCPU = 120

In this example, the number of credits required for non-simulcast connections is independent of encoding (resolution and frame rate). After subsequent updates, encoding will be taken into account. For now, specify the same amount of credits for each encoding.

MCU connections require separate credits for upstream and downstream. MCU connections are send-receive. This means that an MCU connection will typically take a sum of the send and receive credits (in this example, 12 + 12 = 24 credits).

To calculate the capacity for a meeting with 2 SFU publishers (upstream connections) and 100 viewers (downstream connections) with simulcast enabled, use the formula: 20 x 2 (SFU Simulcast Upstream) + 1 x 100 (SFU Non-simulcast Downstream) = 40 + 100 = 140 credits. A single 2-CPU Media Server can handle 240 credits.

Note that publishing above 1080p and 24 fps to a simulcast-enabled channel is not currently supported. Clients exceeding this restriction will be limited to 1080p and 24 fps.

Encoding not specified in the thresholds list inherits the credits from the next larger encoding. For example, 720p at 15 fps uses the 720p at 30 fps configuration.

When converting old settings to the new credit-based settings, consider the example of 120 SFU connections and 5 MCU connections per CPU. Each SFU connection requires 1 credit, resulting in 120 credits per CPU. For MCU connections, divide the total credits (120) by 5 which makes it 24. Then divide by 2 to obtain the credits per direction (12).

Review the resulting settings in the Server Console and ensure they match your use case. Server startup logs display capacity calculations based on the settings.

Old thresholds will become obsolete in the 1.21.x series and will no longer be used.