Система облачной телефонии 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

• вызов устройства
• вызов пользователя (будут вызваны все его устройства)
• голосовые меню
• голосовую почту
• маршрутизацию по времени
• перенаправления звонков
• приём и отправку (через 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, сами по себе работают очень быстро. Авторы очень хорошо думали, прежде чем писать код, и выбор инструмента и структура ядра были не случайны. В результате самое медленное что происходит внутри логического слоя — это запись системных журналов

Уникальным качеством платформы KAZOO является её полнофункциональный REST 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)

• System configs (элементы конфигурации системы)
• Resources (ресурсы внешних подключений), глобальные для системы
• Hangups (статистика кодов завершения разговоров), предназначен для мониторинга и обнаружения аномалий

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

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

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

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