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 ~100 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 ~50 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 / 50. 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.