LiveSwitch Server Deployment Architecture

Unlock the potential of LiveSwitch with our comprehensive guide on setting up a basic on-premise LiveSwitch server deployment. Dive into an in-depth exploration of the architecture diagram and a detailed breakdown of components. This guide also covers optional features like SIP support and S3-compatible storage. Whether you're a beginner or looking to optimize your setup, you'll gain valuable insights for a seamless and efficient LiveSwitch Server deployment!

Architecture Diagram

Check out the architecture diagram below which illustrates the basic server deployment with LiveSwitch.

Key Components and Setup

Load Balancers

There should be a minimum of two (2) instances.

• Client TLS terminating load balancer for SDK traffic.
• Admin TLS terminating load balancer for admin traffic.

Gateways

There should be a minimum of two (2) instances.

Media Servers

There should be a minimum of two (2), CPU-optimized instances.

• TCP port 8445 is used for clustering.

Database Servers

There should be at least three (3) database servers.

• Redis Database
• Rabbit MQ (optional)
• PostgreSQL Database (two instances can be used to separate the recording from SDK database connections)

Recording Monitor

This is an optional component and is only needed when the Recording feature is used.

Recording Muxer(s)

Similar to the Recording Monitor, this is only necessary for the Recording feature. At least one (1) CPU-optimized instance is needed.

Recording Mover(s)

Recording Mover is also needed only for the Recording feature. At least one (1) instance is needed.

S3 API-compatible Storage

This is only optional for Recording.

SIP Connector

This is optional and is only needed for SIP. The instance also has to be CPU-optimized.

Overall, a LiveSwitch Server deployment requires a total of 10 servers, including load balancers and recording components.

Optional Components

Recording Processors

Recording processors are optional for LiveSwitch Server deployments. If you choose not to deploy them, you can omit the following components:

• RabbitMQ
• Recording Monitor
• Recording Muxer(s)
• Recording Mover(s)

Excluding these components can save at least four servers, though you will forgo recording processing capabilities.

Without recording processors, server-side recording for channels is still possible, but the recordings will remain as separate files on the media server storage drive. Each connection will generate one audio recording and one video recording on the server. The recording processors are responsible for merging these individual files into a single recording for the session and transferring them to long-term storage.

SIP Support

Although not previously mentioned, hosting the SIP Connector enables bridging SIP calls directly to the media server. This setup requires at least one CPU-optimized server and an HTTPS VPN connection to the gateways. Incorporating SIP support increases the minimum deployment server count to 11.

Multiple PostgreSQL Databases

Recording and regular SDK database traffic can either be separated into distinct instances or combined into a single PostgreSQL database.

Load Balancers

Load balancers are not required in a single gateway deployment.

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 our LiveSwitch Server documentation.

If you would like to try out our platform, sign up for now for free through our 30-day trial.

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