LiveSwitch Server consists of three server components:
- The Gateway - provides signaling capability allowing your clients to make connections to Media Servers.
- The Media Server - provides WebRTC connections allowing your clients to stream media through SFU or MCU connections.
- The SIP Connector - provides interoperability with third-party SIP services.
Set Up a Development Environment
- For development, you are required to 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, you are recommended to set up the following:
- At least two (load balanced) Gateway Servers for redundancy.
- Depending on your peak concurrent usage, you may require a cluster of Media Servers to handle your media traffic.
- If your use case requires SIP interoperability, you need a SIP Connector.
The following specifications describe the hardware requirements for each LiveSwitch Server component:
- Allow inbound TCP traffic on port 8080 (default, configurable) for HTTP
- Allow inbound TCP traffic on port 8443 (default, configurable) for HTTPS
- 2x CPU
- 2 GB RAM
- Moderate network performance
- 4x CPU
- 4 GB RAM
- High network performance
- 2+ gateways
- Load balance the with high-availability guarantees
- For clustering, allow TCP traffic on port 8445. If 8445 is unavailable, Media servers try the next port incrementally until one is available. That is 8446, 8447, 8448, 8449, etc.
- For client connections, allow inbound UDP traffic on ports 49152-65535 on public interfaces.
- 4x CPU
- 4 GB RAM
- High network performance
- 8x CPU
- 8 GB RAM
- Highest network performance
- 2+ media servers
- For SIP requests, allow UDP and 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 very heavily on expected concurrency. It doesn't matter how many users you have - 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, that means 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 (2xCPU, 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 of traffic, far more than our example of 320 concurrent connections. We run our demo environment Gateway on the equivalent of an AWS-EC2 c5.xlarge (4xCPU, 8 GB RAM), and it can handle thousands of concurrent clients. That said, we recommend running two Gateways behind a standard load balancer for redundancy purposes.
For MCU and SFU connections, relay is generally not required. See STUN/TURN Use Cases for the reasons for this. If you do 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 1mbps, so with 96 relayed connections, you can get away with a single server that has 100Mbps of available upstream/downstream bandwidth. For redundancy, you need two servers. No load balancer is required - round-robin DNS to spread the load across the two is generally considered to be 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 your actual servers have?
Number of Connections
Let's look at the number 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 perhaps 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 would typically add one additional upstream connection (as usually, only one participant shares their screen at a time) and n-1 downstream connections (one for each person viewing the screen share).
Number of CPUs per Server
It is 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.