...
Provides a graphical interface to many client API features. Used as a personal account by PBX owners. When deploying the platform, it is possible to configure the color scheme, add your logo and contact information. The screenshots show sample pages in neutral gray.
Home Page:
Settings page
Call Log Page
Schematic diagram
Component Description
Designation | Component | Description |
|---|---|---|
| kamailio | Kamailio | Based on open source project . Is the entry point of SIP traffic. Responsible for authorizing incoming requests, routing outgoing calls, registration |
| fs1, fs2... | FreeSwitch | Based on open source project . Interacts only with kamailio via SIP, is engaged in processing media |
| CouB1,CouB2... | Couchbase | Compiled on the basis of the project of the same name . Used to store FreeSwitch dynamic configurations and store temporary data (in memcached bucket) |
| Sql | MariaDB | MariaDB sql server, is used to ensure data integrity required for kamailio and CDR archive. |
| API (web backend) | Rest API | API based on the REST architecture. Used to configure PBXs and receive reports. The user can work with the API directly or through interfaces based on this API. Built on Flask and nginx |
Server requirements
For small operators (about 200 simultaneous calls maximum) it is possible to install on one middle-level server. Example configuration for such a server:
16 GB of RAM 2 SSD disks of 128 GB (mirror) 2 HDDs of 512 GB (mirror) CPU Intel (R) Xeon (R) CPU E5-2407 v2 @ 2.40GHz
To increase reliability (redundancy) and system performance, it is recommended to use a scheme with at least two servers.
Scalability, fault tolerance
For fault tolerance, 2 servers are sufficient: one of them will be the entry point and serve all services, the second is only part of the RTP traffic. In case of problems with the 1st server, its address is automatically (VRRP protocol) picked up by the 2nd server and the entry point changes. Servers are preferably located in different data centers.
The platform is designed in such a way that there is a possibility of increasing productivity with an increase in the number of calls, by adding new servers. For example, add 2 media processing servers to the previous scheme.
In this case, "Server 1" and "Server 2" remain as interchangeable entry points for telephony / API, and "Media 1" and "Media 2" are used exclusively for voice / video processing.
When any server with the role of processing media fails, it is automatically excluded from the cluster, and when it comes back on line, a reverse addition occurs.
Examples of working clusters
At the moment (autumn 2018), the operators are successfully running two installations:
- A relatively small cluster of two servers, about 7 thousand additional and 35 thousand calls per day.
- A cluster of eight servers serving about 100 thousand additional, up to 2500 simultaneous calls at the peak and about 500 thousand calls per day.