Cloud telephony system 2600hz KAZOO

Introduction

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

This article is a short author’s review of the project’s capabilities and architecture from a person who has devoted the last year and a half to its study and practical application.

KAZOO is a rapidly developing open-source virtual cloud telephony platform , on the basis of which it is possible to build virtual PBX services, virtual mobile networks and other large-scale carrier-grade cloud telecommunication solutions.

The scope and purpose of this article does not allow us to talk in detail about the structure of the system in terms of developing the kernel and components. Separate materials may be devoted to this. The purpose of the article is to briefly talk about the functions and architecture of the wonderful 2600hz KAZOO system.

The illustrations for the article are made in the format of concept cards, contain many small letters and imply thoughtful examination.

The project (formerly 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, English), 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 the help of which young Steve Wozniak and Steve Jobs, deceived telephone exchanges [2]. 2600hz's early product, a Web interface to FreeSWITCH and Asterisk, called BlueBox (blue box), was named after the device for cheating the then telecoms.

about the project

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

History

The founders of the project are 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], states that Darren and Patrick met in a restaurant in San Francisco, where they decided to establish a new startup and see what it leads to. And so the Whistle project was born.

By the end of 2010 6 people were already involved in the project, in 2011 - already about 20. The keen interest from companies in the telecommunications industry made it possible to attract financing and not only continue development, but also to launch their own commercial service in 2012 on the basis of their own platform.

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

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 and road proven” components:

• SIP-proxy server Kamailio (with its own module db_kazoo, designed to access KAZOO data). Kamailio servers provide SIP device registration, presence data transfer and load balancing 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 via AMQP.
• IP-PBX FreeSWITCH (with its own module mod_kazoo, through which FreeSWITCH is integrated into the Erlang environment). Known to many IP-PBXs, FreeSWITCH is used in the project as a call handler, and all call management falls on the shoulders of KAZOO applications written in Erlang. A special FreeSWITCH module turns IP-PBXs into the so-called Erlang C-Node, which interacts directly 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 is a high-performance, scalable, distributed DBMS
• AMQP RabbitMQ message server, also written in 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

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

Functionality

Each virtual automatic telephone exchange (account) inside KAZOO "out of the box" supports the following functions (in fact, a full gentleman's set):

• device call
• user call (all of his devices will be called)
• voice menus
• voicemail
• time routing
• call forwarding
• receiving and sending (via API or e-mail) faxes
• call recording
• call external scripts (there is compatibility mode with Twilio)
• 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, the FXO gateway with the beloved "analog" number)

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

Since the station is controlled via 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 and dropping icons (accepted in some modern IP PBXs). The system includes a demo interface, alas, poorly suited for commercial use.

Distribution

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

The system components work perfectly in a virtual environment and can be hosted in private, public or hybrid IaaS clouds, which greatly simplifies deployment and operation.

KAZOO can be installed on one server (to “see”), however it is better to even have a laboratory environment for development in the form of a minimum cluster of 7 nodes, since a very large amount of work in the project has been done just to ensure the work of a distributed environment.

fault tolerance

Almost all (with the only exception, in the form of a Kamailio-RabbitMQ connection that does not have a fallback communication path), system components can be duplicated many times both in order to increase productivity and to ensure reliability and high availability. Several Kamailio proxies balance traffic between FreeSWITCH servers that are managed by eCallMgr servers. Multiple Whistle apps application servers communicate with eCallMgr servers via AMQP and communicate with BigCouch servers that are “closed” by 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 for fault tolerance of the entire complex (using PaaS platforms or multi-level fault tolerant server farms with scripts).

Scalability

Partly about scalability was written in the previous paragraph, it’s enough to add only that productivity, in fact, is increased by adding resources. The overhead with horizontal scaling is minimal, so the architecture is built.

High performance

High system performance is partly realized due to good scalability, however, all the components used by themselves are very fast:

• 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, with proper installation, is able to handle thousands of simultaneous calls to the server
• RabbitMQ is written in Erlang, it scales well by itself and is capable of showing very high performance [6]
• BigCouch DBMS is also written in Erlang and was chosen by the authors of the system, in particular, for the shown performance [7]
• The "business logic" of the system, the components of eCallMgr and Whistle apps, written in Erlang, themselves work very quickly. The authors thought very well before writing the code, and the choice of tool and the structure of the kernel were not accidental. As a result, the slowest thing that happens inside the logical layer is the recording of system logs

As the culinary experts say: “It’s very difficult to make a bad dish from a set of good products (of course, if you are 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 an affordable (average operator) price range - this is the case 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 exchanges. 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 agent service delivery schemes
• Users Individuals, owners of devices used for calls
• Devices The actual terminals to which calls can be routed. Devices belong to users and can be called both separately and together
• Callflows (call scripts). In fact, dialplans. Numbers are assigned for callflow, any call to a number, in fact, leads to the execution of a callflow script
• Menus (voice menus). IVR menus, which mean entering numbers by callers
• Media (media resources). Media files or TTS
• Faxboxes (fax boxes). Used to receive and send faxes.
• VMBoxes (voicemail boxes). Used to receive and store voice mail (which can be sent by e-mail)
• CDRs (CDR Records). They provide an opportunity to receive information about calls made
• Resources (external connection resources), local to accounts
• Temporal rules
• Lists (lists of numbers or regular expressions)
• Metaflows (DTMF command scripts during a conversation)
• Limits
• Click-to-call (call initiation via API)
• Webhooks (web calls when initiating, answering, ending calls)
• Queues (ACD Queues)
• Agents (ACD statement data)

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

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

What can be done with this?

Based on KAZOO, it is possible to relatively quickly create services like Grasshopper, RingCentral, SendHub, virtual exchanges of varying complexity and capacity. Of course, to make a full-fledged service, KAZOO alone is not enough, but as a basis for a solution, it fits perfectly perfectly and allows you to lay a pretty decent growth in the architecture and get wide functionality.

KAZOO is not easy. This is a rather complicated solution for those who already need a scale that traditionally costs a lot of money. The lack of royalties significantly reduces the cost of entering the virtual telephony business, especially during a crisis.

Future project

The project is developing very fast. Not far off is SMS support, improved documentation, realtime-sockets interface and other very useful and convenient features. 2600hz receives awards and regularly reports on successful projects and integrations. The future of the product seems bright and bright, the authors are trying very hard to please the community to support the open-source version, for which they bow low and thank you very much.

Summary

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

KAZOO “big picture” looks something like this:

References:

[1] en.wikipedia.org/wiki/Blue_box
[2] en.wikipedia.org/wiki/Kazoo
[3] wiki.2600hz.com
[4] github.com/2600hz/kazoo
[5] www.kamailio.org / docs / openser-performance-tests
[6] blog.pivotal.io/pivotal/products/rabbitmq-hits-one-million-messages-per-second-on-google-compute-engine
[7] blog.2600hz.com / post / 22783650775 / couchdb-bigcouch-bulk-insert-update