[Из песочницы] Система облачной телефонии 2600hz KAZOO

Введение

Телекоммуникационный проект KAZOO молодой компании под названием 2600hz (США) уже успел собрать несколько отраслевых наград и используется многими крупными операторами связи.

Эта статья — краткий авторский обзор возможностей и архитектуры проекта от человека, посвятившего последние полтора года его изучению и применению на практике.

KAZOO — быстро развивающаяся открытая (open-source) платформа виртуальной облачной телефонии, на основе которой можно строить сервисы виртуальных АТС, виртуальные мобильные сети и другие масштабные облачные телекоммуникационные решения операторского класса.



Объём и назначение этой статьи не позволяет детально рассказать об устройстве системы с точки зрения разработки ядра и компонент. Этому, возможно, будет посвящены отдельные материалы. Цель статьи — кратко рассказать о функциях и архитектуре замечательной системы 2600hz KAZOO.

Иллюстрации к статье выполнены в формате концепт-карт, содержат много мелких букв и подразумевают вдумчивое разглядывание

Проект (ранее называвшийся Whistle) назван в честь духового инструмента Kazoo [1]. Переименование произошло после того как авторы посчитали что их творение — это уже не просто свисток (whistle, англ.), а нечто большее, пригодное для использования в серьёзных приложениях.

Тема свиста отражена и в названии самой компании (2600hz). 2600hz — знаменитая звуковая частота, с помощью которой молодые Стив Возняк и Стив Джобс, обманывали телефонные коммутаторы [2]. Ранний продукт компании 2600hz, веб-интерфейс к FreeSWITCH и Asterisk, под названием BlueBox (синяя коробка), был назван как раз в честь устройства для обмана тогдашних телекомов.

О проекте

Фактически, KAZOO — это первая открытая (open-source, MPL) масштабная облачная платформа виртуальной телефонии [4]. KAZOO — функционально богатая, распределённая, отказоустойчивая, масштабируемая, высокопроизводительная, управляемая через API платформа виртуальных АТС, предназначенная для операторов связи, которые хотят предоставлять расширенные услуги IP-телефонии и виртуальных офисов, но не хотят платить миллионы долларов за решения «от лидеров рынка».

Ниже я раскрою каждое из вышеперечисленных свойств (функциональность, распределённость, отказоустойчивость, масштабируемость, высокую производительность, управление через API) более подробно.

История

Основатели проекта — американцы Darren Schreiber и Patrick Sullivan, которые решили попробовать создать что-нибудь новое в области телекоммуникаций. Официальная история проекта, размещённая на wiki-сайте [3], гласит что Darren и Patrick встретились в ресторане в Сан-Франциско, где решили основать новый стартап и посмотреть к чему это приведёт. Так и родился проект Whistle.

К концу 2010г. в проекте уже было задействовано 6 человек, в 2011-м — уже около 20. Горячий интерес от компаний из отрасли телекоммуникаций позволил привлечь финансирование и не только продолжить разработку, но и запустить в 2012-м году собственный коммерческий сервис на базе своей же платформы.

В 2013-м году прошла первая конференция для пользователей и участников проекта, в компании к этому моменту уже было занято 30 человек.

Следующая конференция пройдёт в октябре 2014 года и автор этой статьи собирается выступить там с докладом об успешном опыте применения платформы и участия в проекте.

Архитектура

KAZOO использует несколько «проверенных временем и дорогами» компонент:

• SIP-прокси сервер Kamailio (с собственным модулем db_kazoo, предназначенным для обращения к данным KAZOO). Серверы Kamailio обеспечивают регистрацию SIP-устройств, передачу данных presence и распределение нагрузки между серверами FreeSWITCH (с помощью стандартного модуля dispatcher). Модуль db_kazoo, специально разработанный авторами системы для kamailio, обеспечивает взаимодействие с KAZOO через AMQP.


• IP-АТС FreeSWITCH (с собственным модулем mod_kazoo, посредством которого осуществляется интеграция FreeSWITCH в Erlang-окружение). Известная многим IP-АТС FreeSWITCH используется в проекте в качестве обработчика звонков, при этом всё управление звонками ложится на плечи приложений KAZOO, написанных на Erlang. Специальный модуль FreeSWITCH превращает IP-АТС в так называемый Erlang C-Node, напрямую взаимодействующий с узлами Erlang.


• NoSQL СУБД BigCouch (да, все знают что этот проект умер, рано или поздно произойдёт переход на CouchDB), написанную на Erlang высокопроизводительную, масштабируемую, распределённую СУБД


• Сервер сообщений AMQP RabbitMQ, также написанный на Erlang высокопроизводительный messaging-сервер


• Балансировщик нагрузки HAPROXY (используется для распределения доступа к серверам СУБД)


• Платформу и язык программирования Erlang, на которой написана логика системы: компоненты eCallMgr и приложения Whistle apps

Компоненты активно взаимодействуют между собой и формируют цельную облачную VoIP-платформу.

Функциональность

Каждая виртуальная АТС (account) внутри KAZOO «из коробки» поддерживает следующие функции (на самом деле — полный джентльменский набор):

• вызов устройства


• вызов пользователя (будут вызваны все его устройства)


• голосовые меню


• голосовую почту


• маршрутизацию по времени


• перенаправления звонков


• приём и отправку (через API или e-mail) факсов


• запись разговоров


• вызов внешних скриптов (есть режим совместимости с Twilio)


• группы дозвона


• перехват вызовов


• парковку вызовов


• переадресацию


• hot-desking (присвоение устройств)


• интерком


• DND


• очереди звонков (простой ACD)


• управление CallerID


• конференции meet-me


• серверы конференций (с вводом номера комнаты)


• возможность подключения «своих» транков (например, шлюза FXO с горячо любимым «аналоговым» номером)

Оператор может ограничивать клиенту количество используемых транков различной направленности, предоставлять номерную ёмкость, следить за расходованием средств, и т.д. и т.п.

Так как управление станцией производится через API (подробнее ниже), система может быть оснащена совершенно произвольным «личным кабинетом», реализующим практически любую логику управления, от «мастера установки» до интерфейса с перетаскиванием пиктограмм (принятым в некоторых современных IP АТС). В состав системы входит демонстрационный интерфейс, увы, слабо подходящий для коммерческого использования.

Распределённость

Компоненты KAZOO могут (и должны) размещаться на разных узлах, а кластеры могут формировать географически распределённые узлы, связанные через WAN. При наличии высокоскоростных каналов связи, элементы кластера могут быть разнесены между различными площадками для дополнительной отказоустойчивости.

Компоненты системы отлично работают в виртуальном окружении и могут размещаться в частных, публичных или гибридных IaaS-облаках, что существенно упрощает развёртывание и эксплуатацию.

KAZOO можно поставить на одном сервере (чтобы «посмотреть»), однако даже лабораторное окружение для разработки лучше иметь в виде минимального кластера из 7 узлов, так как очень большой объём работы в проекте проделан именно с целью обеспечения работы распределённого окружения.

Отказоустойчивость

Практически все (за единственным исключением, в виде не имеющей fallback-пути связи Kamailio-RabbitMQ) компоненты системы могут быть многократно продублированы как с целью повышения производительности, так и с целью обеспечения надёжности и высокой доступности. Несколько прокси-серверов Kamailio балансируют трафик между серверами FreeSWITCH, которые управляются серверами eCallMgr. Множественные серверы приложений Whistle apps взаимодействуют с серверами eCallMgr через AMQP и обмениваются данными с серверами BigCouch, «закрытыми» HAPROXY. Сервисы API предоставляются серверами Whistle apps и могут быть скрыты за балансирующими proxy-серверами.

Всё общение с системами хранения и внешними скриптами происходит по протоколу HTTP, что позволяет добиться отказоустойчивости всего комплекса (используя PaaS-платформы или многоуровневые отказоустойчивые фермы серверов со скриптами).

Масштабируемость

О масштабируемости отчасти написано в предыдущем абзаце, достаточно добавить лишь то, что производительность, фактически, наращивается добавлением ресурсов. Накладные расходы при горизонтальном масштабировании минимальны, так построена архитектура.

Высокая производительность

Высокая производительность системы отчасти реализуется за счёт хорошей масштабируемости, однако все используемые компоненты сами по себе очень быстры:

• Kamailio издавна известен своей высокой производительностью [5] и широко используется операторами связи пр всему миру


• FreeSWITCH отлично чувствует себя в виртуальном окружении и, при правильной инсталляции, способен обрабатывать тысячи одновременных звонков на сервер


• RabbitMQ написан на Erlang, хорошо масштабируется сам по себе и способен показывать очень высокую производительность [6]


• СУБД BigCouch также написана на Erlang и была выбрана авторами системы, в частности, за показанную производительность [7]


• «Бизнес-логика» системы, компоненты eCallMgr и Whistle apps, написанные на Erlang, сами по себе работают очень быстро. Авторы очень хорошо думали, прежде чем писать код, и выбор инструмента и структура ядра были не случайны. В результате самое медленное что происходит внутри логического слоя — это запись системных журналов

Как говорят кулинары: «из набора хороших продуктов очень сложно приготовить плохое блюдо (конечно, если ты кулинар)». Автор проводил стресс-тестирования системы в различных конфигурациях и может подтвердить: сотни CPS и многие тысячи одновременных звонков в режиме виртуальной АТС (со всеми функциями) на кластере доступного (среднему оператору) ценового диапазона — это имеющая место быть здесь и сейчас реальность.

API

Уникальным качеством платформы KAZOO является её полнофункциональный REST API. Именно посредством этого API клиентские приложения управляют сущностями внутри виртуальных АТС, а администраторы могут изменять системные настройки.

Основные сущности, для которых конечным пользователям предоставляются API:

• Accounts (аккаунты, арендаторы). Собственно, виртуальные АТС. Каждый account идентифицируется своим SIP-realm (доменным именем) и уникальным ID. Аккаунты могут быть вложены друг в друга, что позволяет строить агентские схемы предоставления услуг


• Users (пользователи). Физические лица, владельцы устройств (devices), используемых для звонков


• Devices (устройства). Фактические оконечные устройства, на которые могут быть направлены вызовы. Устройства принадлежат пользователям и могут вызываться как отдельно, так и вместе


• Callflows (сценарии вызовов). Фактически, dialplan-ы. Для callflow назначются номера, любой вызов номера, фактически, приводит к выполнению того или иного callflow-сценария


• Menus (голосовые меню). IVR-меню, подразумевающие ввод звонящим цифр


• Media (медиа-ресурсы). Медиа-файлы или TTS


• Faxboxes (факсовые ящики). Используются для приёма и отправки факсов


• VMBoxes (ящики голосовой почты). Используются для приёма и хранения голосовой почты (которая может отправляться на e-mail)


• CDRs (записи CDR). Дают возможность получать информацию о состоявшихся звонках


• Resources (ресурсы внешних подключений), локальные для account-ов


• Temporal rules (правила маршрутизации по времени)


• Lists (списки номеров или регулярных выражений)


• Metaflows (сценарии DTMF-команд во время разговора)


• Limits (ограничения количества транков)


• Click-to-call (инициация вызовов через API)


• Webhooks (веб-вызовы при инициации, ответе, завершении разговоров)


• Queues (очереди ACD)


• Agents (данные операторов ACD)

Администраторам через API, в частности, предоставляется доступ до системных настроек и компонент:

• System configs (элементы конфигурации системы)


• Resources (ресурсы внешних подключений), глобальные для системы


• Hangups (статистика кодов завершения разговоров), предназначен для мониторинга и обнаружения аномалий

Что с этим можно делать?

На основе KAZOO возможно сравнительно быстрое создание сервисов наподобие Grasshopper, RingCentral, SendHub, виртуальных АТС различной сложности и ёмкости. Разумеется, чтобы сделать полноценный сервис одной KAZOO недостаточно, но в качестве основы решения она подходит совершенно замечательно и позволяет заложить в архитектуру весьма приличный рост и получить широкие функциональные возможности.

KAZOO не проста. Это — довольно сложное решение для тех, кому уже нужен масштаб, который традиционно стоит очень и очень дорого. Отсутствие лицензионных платежей существенно снижает стоимость входа в бизнес виртуальной телефонии, особенно во время кризиса.

Будущее проекта

Проект очень быстро развивается. Не за горами поддержка SMS, улучшенная документация, интерфейс realtime-sockets и другие очень полезные и удобные функции. Компания 2600hz получает награды и регулярно отчитывается об успешных проектах и интеграциях. Будущее продукта видится светлым и радужным, авторы очень стараются на радость сообществу поддерживать open-source версию, за что им низкий поклон и большое спасибо.

Резюме

Проект KAZOO — уникальная open-source облачная платформа операторской виртуальной телефонии, позволяющая операторам связи предоставлять своим заказчикам современные услуги виртуальных АТС, а также строить другие сложные телекоммуникационные решения (например, виртуальные мобильные сети).

«Большая картина» KAZOO выглядит примерно так:

Ссылки:

[1] http://ift.tt/1kBKAz8

[2] http://ift.tt/1iyoRVO

[3] wiki.2600hz.com

[4] http://ift.tt/1n1OBcq

[5] http://ift.tt/1n1OAFm

[6] http://ift.tt/1n1OAFo

[7] http://ift.tt/1n1OAVC

This entry passed through the Full-Text RSS service — if this is your content and you're reading it on someone else's site, please read the FAQ at http://ift.tt/jcXqJW.