2600hz KAZOO Cloud Telephony System

Introduction

The KAZOO telecommunications project of a young company called 2600hz (USA) has already managed to collect several industry awards and is being used by many large telecom operators.

This article is a brief review of the possibilities and architecture of the project from the person who has devoted the last year and a half to its study and application in practice.

KAZOO is a fast-growing open-source virtual cloud telephony platform , on the basis of which you can build virtual PBX services, virtual mobile networks and other large-scale cloud telecommunications carrier-class solutions.

The scope and purpose of this article does not allow a detailed account of the system structure from the point of view of kernel and component development. Separate materials will probably be devoted to this. The purpose of the article is to briefly describe the functions and architecture of the wonderful 2600hz KAZOO system.
')
The illustrations for the article are in the format of concept cards, contain many small letters and imply a thoughtful gazing.

The project (previously called Whistle) is named after the Kazoo wind instrument [1]. The renaming took place after the authors considered that their creation was no longer just a whistle (whistle), but something more suitable for use in serious applications.

The theme of the whistle is reflected in the name of the company itself (2600hz). 2600hz - the famous sound frequency, with which young Steve Wozniak and Steve Jobs, deceived telephone switches [2]. The company's early product, 2600hz, the web interface to FreeSWITCH and Asterisk, called BlueBox (blue box), was named after the device for deceiving the then telecoms.

about the project

In fact, KAZOO is the first open (open-source, MPL) large-scale virtual telephony cloud platform [4]. KAZOO - functionally rich, distributed, fault-tolerant, scalable, high-performance, API-managed virtual PBX platform, designed for telecom operators who want to provide advanced IP-telephony services and virtual offices, but do not want to pay millions of dollars for solutions "from market leaders" .
Below I will reveal each of the above properties (functionality, distribution, fault tolerance, scalability, high performance, management via API) in more detail.

Story

The founders of the project are the Americans Darren Schreiber and Patrick Sullivan, who decided to try to create something new in the field of telecommunications. The official history of the project, posted on the wiki site [3], says that Darren and Patrick met at a restaurant in San Francisco, where they decided to start a new startup and see what it would lead to. This is how the Whistle project was born.

By the end of 2010. 6 people have already been involved in the project; in 2011, about 20. Hot interest from companies in the telecommunications industry made it possible to attract funding and not only continue to develop, but also launch its own commercial service in 2012 based on its own platform.

In 2013, the first conference was held for users and project participants, the company by this time already had 30 people employed.

The next conference will be held in October 2014 and the author of this article is going to make a report there on the successful experience of using the platform and participating in the project.

Architecture

KAZOO uses several “time-tested and expensive” components:

Kamailio SIP proxy server (with its own db_kazoo module designed to access KAZOO data). Kamailio servers provide SIP device registration, presence data transfer and load sharing between FreeSWITCH servers (using the standard dispatcher module). The db_kazoo module, specially developed by the authors of the system for kamailio, provides interaction with KAZOO through AMQP.
IP PBX FreeSWITCH (with its own mod_kazoo module, through which integration of FreeSWITCH into the Erlang environment). The IP PBX FreeSWITCH, known to many, is used in the project as a call handler, while all the management of calls falls on the shoulders of KAZOO applications written in Erlang. A special FreeSWITCH module turns IP-PBX into a so-called Erlang C-Node, directly interacting with Erlang nodes.
NoSQL DBMS BigCouch (yes, everyone knows that this project has died, sooner or later there will be a transition to CouchDB), written in Erlang high-performance, scalable, distributed DBMS
Message server AMQP RabbitMQ, also written on Erlang high-performance messaging server
HAPROXY load balancer (used to distribute access to DBMS servers)
Erlang platform and programming language on which the system logic is written: eCallMgr components and Whistle apps applications

The components actively interact with each other and form a complete cloud-based VoIP platform.

Functionality

Each virtual PBX (account) inside KAZOO out of the box supports the following functions (in fact, a complete gentleman's set):

device call
user call (all his devices will be called)
voice menus
voice mail
time routing
call redirection
receiving and sending (via API or e-mail) faxes
talk recording
calling external scripts (there is a Twilio compatibility mode)
dialer groups
call pickup
call parking
call forwarding
hot-desking (device assignment)
intercom
DND
call queues (simple ACD)
CallerID management
meet-me conferences
conference servers (with room number entry)
the ability to connect "their" trunks (for example, an FXO gateway with a beloved "analog" number)

The operator can limit to the client the number of used trunks of various directions, provide numbering capacity, monitor the expenditure of funds, etc. etc.

Since the station is managed through the API (more below), the system can be equipped with a completely arbitrary “personal account” that implements almost any control logic, from the “installation wizard” to the interface with dragging icons (adopted in some modern IP PBXs). The system includes a demo interface, alas, poorly suitable for commercial use.

Distribution

KAZOO components can (and should) be located on different nodes, and clusters can form geographically distributed nodes connected via a WAN. In the presence of high-speed communication channels, cluster elements can be separated between different sites for additional fault tolerance.

System components work well in a virtual environment and can be placed in private, public, or hybrid IaaS clouds, which greatly simplifies deployment and operation.

KAZOO can be delivered on one server (to “see”), but even the laboratory environment for development is better to have a minimum cluster of 7 nodes, since a very large amount of work in the project was done precisely to ensure the work of the distributed environment.

fault tolerance

Practically all (with the only exception, in the form of Kamailio-RabbitMQ, which does not have a fallback path), the system components can be duplicated many times, both with the aim of increasing productivity and ensuring reliability and high availability. Several Kamailio proxy servers balance traffic between FreeSWITCH servers, which are managed by eCallMgr servers. Multiple Whistle apps application servers interact with eCallMgr servers via AMQP and exchange data with BigCouch servers, “closed” HAPROXY. API services are provided by Whistle apps servers and can be hidden behind balancing proxy servers.

All communication with storage systems and external scripts takes place via the HTTP protocol, which allows to achieve fault tolerance of the entire complex (using PaaS platforms or multi-level fault-tolerant server farms with scripts).

Scalability

About scalability is partly written in the previous paragraph, it suffices to add only that performance, in fact, is increased by adding resources. Overhead with horizontal scaling is minimal, so built architecture.

High performance

High system performance is partly realized due to good scalability, but all components used are very fast in themselves:

Kamailio has long been known for its high performance [5] and is widely used by telecom operators around the world
FreeSWITCH feels great in a virtual environment and, if properly installed, can handle thousands of simultaneous calls to the server
RabbitMQ is written in Erlang, scales well on its own and is capable of showing very high performance [6]
DBMS BigCouch is also written in Erlang and was chosen by the authors of the system, in particular, for the performance shown [7]
The “business logic” of the system, the components of eCallMgr and Whistle apps written in Erlang, work very quickly by themselves. The authors thought very well before writing the code, and the choice of the tool and the structure of the kernel were not accidental. As a result, the slowest thing that happens inside the logical layer is to write the system logs.

As the chefs say: “From a set of good products it’s very difficult to cook a bad dish (of course, if you’re a cook).” The author conducted stress testing of the system in various configurations and can confirm: hundreds of CPS and many thousands of simultaneous calls in the virtual PBX mode (with all functions) on a cluster of the available (average operator) price range - this is the place to be here and now.

API

The unique quality of the KAZOO platform is its full-featured REST API. It is through this API that client applications manage entities within virtual PBXs, and administrators can change system settings.

The main entities for which APIs are provided to end users:

Accounts (accounts, tenants). Actually, virtual PBX. Each account is identified by its SIP-realm (domain name) and unique ID. Accounts can be nested in each other, which allows you to build agency schemes for the provision of services
Users Individuals, owners of devices (devices) used for calls
Devices (devices). The actual terminals to which calls can be directed. Devices belong to users and can be called either separately or together.
Callflows (call scripts). In fact, dialplans. Numbers are assigned to callflow, any call to a number actually results in the execution of a particular callflow script.
Menus (voice menus). IVR-menu, implying the input of the caller numbers
Media (media resources). Media files or TTS
Faxboxes (fax boxes). Used to receive and send faxes
VMBoxes (voice mail boxes). Used to receive and store voice mail (which can be sent to e-mail)
CDRs (CDR records). Give the opportunity to receive information about the calls
Resources (external connection resources) that are local to account
Temporal rules (time routing rules)
Lists (lists of numbers or regular expressions)
Metaflows (DTMF command scripts during a call)
Limits (limiting the number of trunks)
Click-to-call (call initiation via API)
Webhooks (web calls when initiating, responding, ending calls)
Queues
Agents (data from ACD operators)

Administrators through the API, in particular, are granted access to system settings and components:

System configs (system configuration items)
Resources (external connection resources), global for the system
Hangups (statistics of call completion codes), designed to monitor and detect anomalies

What can you do about it?

On the basis of KAZOO, relatively quick creation of services like Grasshopper, RingCentral, SendHub, virtual PBXs of varying complexity and capacity is possible. Of course, to make a full-fledged service of one KAZOO is not enough, but as a basis for the solution, it fits perfectly and allows you to build a very decent growth in the architecture and get broad functionality.

KAZOO is not easy. This is a rather difficult decision for those who already need a scale that has traditionally been very, very expensive. The absence of royalties significantly reduces the cost of entering the virtual telephony business, especially during a crisis.

Future of the project

The project is developing very quickly. SMS support, improved documentation, realtime-sockets interface and other very useful and convenient features are just around the corner. 2600hz receives awards and regularly reports on successful projects and integrations. The future of the product seems bright and bright, the authors are trying hard for the joy of the community to support the open-source version, for which I bow to them and thank you very much.

Summary

The KAZOO project is a unique open-source cloud-based carrier-based virtual telephony platform that allows telecom operators to provide their customers with modern virtual PBX services, as well as to build other complex telecommunications solutions (for example, virtual mobile networks).

"Big picture" KAZOO looks like this: