Asterisk + WebRTC = любовь и обожание наконец

На сегодняшний день технология WebRTC стала одним из ключевых драйверов изменений в сфере VoIP и контакт-центров. Переход на удалённый формат работы оказал значительное влияние на организацию рабочих мест операторов: всё больше сотрудников контакт-центров работают из дома, и именно здесь WebRTC демонстрирует свою максимальную эффективность.
Основным преимуществом WebRTC является минимальный порог вхождения. Отпадает необходимость закупки аппаратных телефонов или развертывания софтфонов на устройствах сотрудников. Внедрение телефонии в CRM-систему значительно упрощается, так как отпадает необходимость интеграции с Asterisk через AMI или ARI. Более того, результат оказывается независимым от конкретной IP-АТС — решение работает на любой системе, поддерживающей WebRTC-клиентов.
Для самых простых сценариев доступны браузерные расширения, реализующие базовый функционал WebRTC-телефона с возможностью API-интеграции, например, для Click-to-Call или отображения карточки клиента при входящем вызове.

Технические требования и архитектура

С точки зрения технических требований всё предельно просто: доменное имя, корректный SSL-сертификат и актуальная версия Asterisk. Старт развития данной технологии связан с потребностью пользователей в живом общении в сети, а не только в просмотре видеоконтента. Основополагающей технологией WebRTC является ICE (Interactive Connectivity Establishment), позволяющая организовывать одноранговые соединения между браузерами и передавать медиаданные по UDP.

Однако важно учитывать, что ICE, будучи идеальной для браузеров, может создавать сложности для серверных решений. Например, при работе Asterisk за NAT ICE может передавать клиентам внутренние IP-адреса, что недопустимо. В таких случаях необходимо ограничивать ICE только одним, заранее определённым внешним адресом. Это позволяет направлять в сторону браузера исключительно допустимые кандидаты соединения, избегая проблем с NAT.

На практике оказалось, что боязнь необходимости использования TURN-серверов для ретрансляции медиапотоков оказалась необоснованной — практически во всех случаях медиапотоки успешно проходили NAT и достигали браузеров напрямую.

Безопасность и шифрование

WebRTC по умолчанию использует обязательное шифрование медиапотоков, отключить которое невозможно. Это делает невозможным прослушивание трафика при помощи стандартных инструментов анализа, таких как sngrep. Однако на помощь приходит HEP-модуль Asterisk, который позволяет передавать расшифрованную сигнализацию в sngrep через HEP-протокол. Рекомендуется использовать программный продукт Homer, который обеспечивает сбор, хранение и визуализацию истории вызовов и сигнализации.

Голосовая информация передаётся в стандартных RTP-пакетах, которые можно анализировать на предмет потерь и джиттера. Единственным ограничением остаётся невозможность прослушивания аудиоданных, так как payload зашифрован. Также используется протокол RTCP, который позволяет мониторить качество медиасессий.

Пример практического применения

В одном из кейсов операторы перед началом работы запускали эхотест и проверяли, как они себя слышат. Далее при каждом вызове Asterisk записывал в CDR RTCP-статистику канала. Эти данные анализировались CRM-системой, которая, например, могла не назначать важные обращения операторам с плохим качеством связи. Таким образом, обеспечивался не только контроль за качеством, но и автоматизация бизнес-логики распределения вызовов.

Мониторинг и метрики

Для подключения WebRTC-абонентов в Asterisk используется встроенный HTTP-сервер. Начиная с 18 версии, появилась поддержка метрик в формате Prometheus, что стало значительным шагом вперёд по сравнению с SNMP. Теперь возможно мониторить состояние конечных точек, каналов, длительность разговоров и другие параметры, отправлять их в Google Cloud Monitoring и строить дашборды на PromQL. Простой пример — график в реальном времени, показывающий количество активных операторов в системе.

Вопросы безопасности

С точки зрения безопасности WebRTC может считаться даже более надёжным решением, чем традиционные SIP-сессии по UDP. Подключение по HTTPS требует прохождения дополнительной валидации, включая имя хоста. Это создаёт дополнительное препятствие для потенциального атакующего. Сканы портов эффективно блокируются с помощью fail2ban. Рекомендуемой практикой является передача из CRM в заголовке вызова SX токена, который Asterisk проверяет перед осуществлением вызова. Благодаря тесной интеграции между браузером и CRM, реализовать это крайне просто.

Обеспечение отказоустойчивости

Для повышения надёжности решений широко применяется архитектура с использованием real-time конфигурации Asterisk. Конфигурационные данные хранятся в той же базе данных, что и CRM, которая, как правило, уже имеет резервирование и бэкап. Дополнительно развёртывается простой кластер с Active/Standby-ноды, что позволяет достичь высокой доступности без существенных затрат и с возможностью быстрого восстановления работоспособности.