Ringotel works as a secure VoIP tunnel, accepting traffic from remote users and passing it to the PBX server. Communication between the Ringotel apps and the Ringotel server is encrypted by default with TLS/SRTP protocols. The RTP port range could be configured and set according to NAT/Firewall configuration.

Even in the case of on-premise deployment, provisioning of Ringotel apps, including codecs settings, dial plan, and user contacts list, will still be available via the Ringotel admin portal or API.

With the on-premise version of Ringotel, you still have access to our cloud infrastructure and will be able to choose between creating users on an on-premise server or on any of Ringotel’s cloud servers.

Main advantages:

Minimizes voice path for user calls
All users’ data is located in your private network
Secures core VoIP infrastructure without deploying VPN or SBC

Ringotel on-premise deployment scheme

Requirements

Ringotel back-end can be deployed on CentOS or Debian virtual or physical instances.
Scalable cloud file storage with replication and high availability should be mounted on servers to host user files such as call recordings, shared files, etc. (e.g., AWS Elastic File System, Azure Storage, etc.).
MySQL (or MySQL compatible) database cluster with replication and HA.
Recommended configuration for 1000 users: CPU 4/8 vCPU, RAM 16 Gb.
Recommended configuration for 100,000 users: CPU 64 vCPU, RAM 64 Gb.
Can be located behind NAT.

FAQ

What ports do you need to open on the firewall?

These ports need to be accessible from the internet for the softphone users:

443 (TCP)
6000-9999 (UDP, or another RTP port range considering 4 ports per call)

Additionally, consider adding these ports to register SIP endpoints via Ringotel using "Terminal password":

5060, 5061, 5062 (UDP/TCP)

In addition, the following ports needs to be opened for server maintenance:

4887 (TCP)
22 (SSH, or any other port)

The maintenance ports need to opened for the Ringotel IPs (provided during the project).

In case of a failover configuration (two on-premise servers), allow communication between the servers on the following ports:

443 (TCP, HTTPS)
3306 (TCP, in case of a non-recommended local MySQL deployment)
2049 (TCP/UDP, in case of a non-recommended local folder cross-mounting configuration)

How is the load balancing/failover handled?

A failover/HA configuration consists of a primary and secondary(standby) node and is activated using the DNS failover mechanism.

A DNS record is created in the Ringotel DNS zone that points to the primary server's IP address.
The health monitoring component continuously checks the nodes and, in the event of a primary server failure, updates the DNS record with the standby node's IP address, which is then automatically activated(launched) to become the primary node.
Total failure recovery time is expected to be between 60 and 120 seconds.
In the event of a failover, all existing connections will be dropped.
Note that there is no fallback mechanism, i.e., switching back to the previous primary node must be done manually during routine maintenance to avoid disruptions.
Although not required, to switch back to the primary server:

Restore the Ringotel process on the primary server (it will start in standby mode).
Then, the Ringotel service should be stopped on the secondary server (which became primary after a failover).
After the recovery time, the Ringotel service should start on the primary node and the clients re-register.
Lastly, launch the Ringotel service on the secondary node to restore the initial state.