Team Voice Calls Architecture

This guide provides a high-level overview of the Team Voice Calls architecture, detailing how various components interact to deliver integrated voice communication within Rocket.Chat. Understanding this architecture is crucial for effective deployment, configuration, and troubleshooting.

The Team Voice Calls architecture is currently being improved. A detailed architecture diagram will be provided soon.

FreeSWITCH configuration

Team Voice Calls is powered by FreeSWITCH, an open-source telephony platform responsible for core VoIP functions. In this setup, FreeSWITCH acts as the primary telephony engine, handling:

SIP server functions: Manages the registration of Rocket.Chat clients (acting as SIP User Agents) and controls the setup, negotiation, and teardown of calls.
Media processing: Delivers real-time audio streams using RTP (Real-time Transport Protocol) and secures them with SRTP (Secure RTP) to prevent eavesdropping.
Communication with Rocket.Chat: Exchanges call data and control states with the Rocket.Chat server via the Event Socket Library (ESL) API.

Essentially, while Rocket.Chat manages user interactions and the front-end experience, FreeSWITCH handles the underlying call mechanics.

Websockets (WSS) is used to carry SIP signaling between the Rocket.Chat frontend and FreeSWITCH in a secure, real-time manner. This is crucial for enabling VoIP directly in the browser.

Choosing your deployment architecture

When deploying Team Voice Calls, you have two primary architectural options for integrating Rocket.Chat and FreeSWITCH.

	Co-located Rocket.Chat and FreeSWITCH	Distributed Rocket.Chat and FreeSWITCH
How it works	Both Rocket.Chat and FreeSWITCH run as containers on the same physical or virtual host, often sharing the same network.	Rocket.Chat and FreeSWITCH are deployed on different hosts or VMs, communicating over a LAN or secure network.
Ideal for	Small deployments, proof-of-concept testing, and environments with limited infrastructure.	Medium to large-scale production environments, or when high availability, performance, and robust security are critical priorities.
Advantages	Simpler setup with fewer moving parts Lower communication latency via local networking Fewer servers to manage	Dedicated resources for each component Improved scalability as components scale independently Better fault isolation (one service failing doesn't bring down the other) Enhanced security through network segmentation
Disadvantages	Shared resources can lead to performance bottlenecks Single point of failure as server outage can impact both services Limited scalability for larger environments	More complex network configuration Slightly higher latency for ESL communication Increased operational overhead due to managing more infrastructure

Known limitations

The current Rocket.Chat VoIP implementation using FreeSWITCH has a few limitations you should be aware of:

Limited to 24 users on EKS: When deploying FreeSWITCH on Amazon EKS using a Network Load Balancer (NLB), there is a limit of 24 simultaneous users. This happens because the NLB supports a maximum of 50 open ports, and FreeSWITCH requires 2 ports per user. Keeping one port reserved for SIP signaling reduces the number of usable ports to 48, effectively allowing only 24 users to be connected simultaneously. This limitation is imposed by the NLB, not by FreeSWITCH or Rocket.Chat. If you need to support more concurrent users, consider switching to a different type of load balancer or deploying FreeSWITCH using a NodePort setup or an alternative approach.
Single client instance limitation: Currently, each user can only use a single Rocket.Chat client instance at a time to make or receive calls. That means if a user opens multiple tabs or browser windows to make calls, voice calls may fail or not work as expected.

These are known architectural limitations and we’re actively working on improvements to lift these restrictions in future updates.