LiveSwitch Server Deployment Architecture

Discover how to set up a basic on-premise LiveSwitch server deployment, including the recording processor system. In this guide, we'll walk you through the architecture diagram and breakdown of components, as well as optional features such as SIP support and S3-compatible storage, offering valuable insights for a seamless LiveSwitch Server deployment.

Architecture Diagram

Check out the architecture diagram illustrating the basic server deployment with LiveSwitch:

Key Components and Setup

1. Load Balancers (minimum 2):

   • Client TLS terminating load balancer for SDK traffic.

   • Admin TLS terminating load balancer for admin traffic.

2. Gateways (minimum 2).

3. Media Servers (minimum 2, CPU Optimized):

   • TCP port 8445 is used for clustering.

4. Database Servers (3 or more):

   • Redis Database.

   • Rabbit MQ (optional).

   • PostgreSQL database (two instances can be used to separate recording from SDK database connections).

5. Recording Monitor (optional).

6. Recording Muxer(s) (optional, CPU optimized, at least 1).

7. Recording Mover(s) (optional, at least 1).

8. S3 API compatible storage (optional).

9. SIP Connector (optional, CPU optimized).

Including load balancers, a LiveSwitch server deployment with recording requires a total of 10 servers.

Optional Components

Recording Processors

Recording processors are not mandatory for LiveSwitch Server deployments. If not deployed, the following components can be omitted:

1. RabbitMQ
2. Recording Monitor
3. Recording Muxer(s)
4. Recording Mover(s)

By excluding these components, you can save at least 4 servers; however, you won't have recording processing. 

Without recording processors, server-side recording for channels is still possible, but the recordings will remain as individual files on the media server storage drive. Each connection will create 1 audio recording and 1 video recording on the server. The recording processors combine these individual files into a single recording for the session and facilitate their transfer to long-term storage.

SIP Support

This is not mentioned above but hosting the SIP Connector allows bridging SIP calls directly to the media server. This requires at least one CPU-optimized server and a HTTPS VPN connection to the gateways. Adding SIP support brings the minimum deployment server count to 11.

Multiple PostgreSQL Databases

Recording and regular SDK database traffic can be split into separate instances or combined into a single PostgreSQL database.

Load Balancers

In a single gateway deployment, load balancers are not required.

S3 Compatible Storage

When using Recording Processors, you can get away without using the Recording Movers and S3 Compatible Storage. However, note that Recording Webhooks will not fire! You can find lots of S3 Storage options online (e.g. Amazon, Linode, Digital Ocean), or you can host one locally using Docker. It is recommended to have at least one Mover connected to an S3 API storage provider, even if it's locally hosted.

Extra Information

• Typically, having 1/3 the number of Gateways compared to Media Servers is sufficient. For example, if you deploy 9 media servers in your cluster, 3 gateways should be sufficient to handle the traffic.

• The number of recording Muxers and Movers depends on the speed of processing the recordings. You can generally have 1/2 or fewer movers compared to muxers, depending on file sizes. The larger the channel and the longer it was open, the longer the muxing process will take. It's common to have a 1:1 ratio in group conferences, where the muxing process takes nearly as long as the session was alive. 

For more information on LiveSwitch Server, please refer to LiveSwitch Server documentation.

Need assistance in architecting the perfect WebRTC application? Let our team help out! Get in touch with us today!