The platform is designed to provide telecom service providers and / or Internet service providers a "Virtual PBX" to end users (their subscribers). It is designed to be installed on the infrastructure of the operator or in the cloud.

Features

From the point of view of the subscriber

Allows you to perform all the typical features of PBX:

• Internal numbering (2-4 digits)
• Receiving incoming calls: binding of any number of external numbers (DID)
• Making of outgoing calls
• Organization of multi-level voice menus depending on different conditions, for example:
  
  • time / date
  • source / destination numbers
  • caller interactive selection
  • dynamic routing (not defined in advance and can be set at the time of the call based on the client-side service)
• Queuing, which allows you to distribute calls between employees in various schemes. Key features of the queues are:
  
  • the ability to set music to play to the caller while waiting, as well as periodic sound announcements.
  • request from the caller to assess the quality of service at the end of the conversation. 
  • dynamic binding of the caller to the employee for a certain time is possible (so that the same employee receives repeated calls)
  • call rating after the call ending
  • the following call distribution schemes are supported:
    • call all employees at the same time
    • uniform distribution
      
      • the first to be called is the employee who has not taken calls for the longest time
      • the employee with the shortest talk time is called first
      • the first person to be called is the person who receives the least number of calls.
    • randomly
    • sequentially
    • by priority
• Ability to download your own sound files for presets, announcements, call waiting music and voice mail
• Setting up forwarding for employees based on different criteria
• Blacklists
• Voice mail
• Call management directly from the phone (intercept, barge-in, monitor and whisper) and the ability to configure permisions for these actions.
• Call management via API: transfer, barge-in, monitor,  whisper, adding to a conference, putting on hold, taking off hold, parking, intercept
• Binding of mobile / city number to the extension 
• See the Presence of Colleagues
• Conferences
• Support any RFC3261 compliant phones/softphones 
• Ability to use many codecs (G711, G722, OPUS and so on)
• Recording conversations (with notification when nearing low disk space)
• WebRTC - making calls directly from the browser (WebRTC browser extension is included)
• Web Call / API Initiation
• Task scheduler: it is possible to create a list of call numbers, make a call to the list and get a report on it
• Receive / send faxes via web interface / API
• Receive alerts for missed calls in the mail
• Generating PBX events for integration with third-party systems (for example, CRM)
• Independent configuration of PBX parameters via the web interface / API
• 2 levels of web interface / API: for PBX administrator and employee
• CallCenter live dashboard
• Receiving a variety of reports on calls through the web interface / API

From the point of view of the operator

• Multi-domain setup
• The ability to create dealers: accounts that have access only to their customers
• Creating clients with different languages and time zones
• Block / unblock clients
• Setting client limits (number of employees, simultaneous calls, disk space, etc.)
• Creating trunks to interact with other operators
• Registration of channels on other operators
• Getting numbers (DID) through trunks and distributing them among clients
• Control of routing outgoing calls through trunks, the ability to have many different routes for dealers / customers
• Login to the client interface on behalf of the client
• Access to configuration change logs
• Configuration backups for cluster recovery
• Set email templates for clients (password reset, disk space, missed call, etc.)
• Restriction of access to the service by geography (GeoIP) 

API / Web Interfaces

An important advantage of the platform is its customizability through the API.  The library is implemented in accordance with the REST architecture, data transmission is carried out via the HTTPS protocol, authorization is performed using the OAuth 2.0 protocol. The library allows you to build an interface (front-end) and various automation scripts in any familiar programming language. 

API access levels

• administrator
• dealer
• customer
• group of employees (department)
• employee (extension)

Any higher level has access to the features of the subordinate level.

An API-based operator can implement the web interface for themselves and for the client. Nevertheless, the interface already includes 2 interfaces

• for the admin
• for the client (with the ability to log in at the employee level as well as and the level of the entire PBX)

Admin interface

Provides a graphical interface to many admin API features. For example

Page with a list of clients

Configure outgoing call routing

Client interface

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

Example with colors

COLOR_1 = #399efc (blue)
COLOR_2 = #ff9800 (orange)

COLOR_2 you can see on Settings button (displayed when hovering over buttons/icons)

Schematic diagram

Component Description

Server requirements

For small operators (about 500 simultaneous calls maximum) it is possible to install on one middle-level server. Example configuration for such a server:
64 GB of RAM (128 GB of RAM is better), 2 SSD disks of 512 GB (mirror), 2 HDD of 1024* GB (mirror), CPU 2x Intel Xeon E5-2609 v4
*note: if there is no separate server for storing call recordings, a minimum of 2 HDDs of 2024 is recommended* GB (mirror)

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 (spring 2024), the operators are successfully running two installations:

1. A relatively small cluster of two servers, about 15 thousand  phone extension numbers and 120 thousand calls per day.
2.  A cluster of eight servers serving about 130 thousand phone extension numbers, up to 3000 simultaneous calls at the peak and about 600 thousand calls per day.