Глава 1. Входные данные

Предпосылки к созданию платформы «Era»

  • Санкции, совпровождающие нашу Родину, рост стоимости западных продуктов и их поддержки, объявленный Правительством РФ курс на импортозамещение.

  • Возросшее количество запросов на поставку коммуникационных решений от крупных организаций, не способных быть удовлетворенными односерверным решением (до 1000 абонентов).

  • Рост количества запросов на продукты класса UC (unified communications), организацию сервисов омни-канального обслуживания, ВКС.

  • За пару десятилетий произошло укрупнение ряда компаний и их большей частью стихийная автоматизация. Как результат накопились большие объемы разносортного оборудования и софта, отвечающих за коммуникации. Они "как-то" работают, будучи кем-то когда-то настроенными, но не поддерживаются или поддерживаются с недостаточным качеством и не имеют возможности быть адаптированы к новым задачам. По известным данным ежедневно выходит из строя несколько наименований оборудования. В крупных компаниях, где одномоментная замена невозможна, но связь является стратегическим ресурсом, это своего рода рулетка. Управление таким материальным активом осуществляется с помощью армий администраторов, распределенных по стране и имеющих разрозненные знания. Среди таких активов обнаруживаются в том числе продукты ушедших с отечественного рынка компаний.

  • Массовый отказ от западных решений в пользу свободно распространяемого ПО.

  • Развитие технологий ускоряется, коммуникации все больше становятся основой деятельности и проникают в глубинные бизнес-процессы, все больше интегрируясь с другими инструментами.

Требуется решение, готовое к функциональному развитию, архитектура которого позволяет без потери управляемости и стройности объединять результаты работы разных команд, работающих в разных технологиях и с разной скоростью, которое горизонтально масштабируется до размеров 1 000 000+ абонентов и пользователей.

Основные задачи платформы «Era»

  • Серверная распределенная платформа для телефонии и смежных бизнес-задач (call-центр, Omni, UC и др.), решаемых на ее основе.

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

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

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

  • Настраивается, мониторится и управляется через открытый API, постепенно обретает собственное клиентское приложение, работающее через тот же API.

  • Поддерживает привычные крупному сектору телефонные сервисы.

  • Управляемый масштаб 1000+. Методики увеличения масштаба.

  • Управляемая доступность 99,(9)%. Методики увеличения доступности.

  • Разнесение по территориально распределенным площадкам с сохранением их работоспособности при сетевой недоступности.

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

  • Поддерживает встраивание в другие продукты.

  • Поддерживает функциональное расширение в корпоративном направлении, SaaS, PaaS.

Требования

Базовые функциональные требования

  • Полная поддержка протокола SIP.

  • Регистрация телефонов под учетными записями пользователей.

  • Звонки между пользователями, удержания, переводы, перехваты.

  • Второй входящий вызов при активном разговоре.

  • Redial на номер предыдущего абонента.

  • Подключение к внешним АТС и провайдерам с регистрацией и без с возможностью подмены номеров.

  • Конференц-связь на телефоне.

  • Серверная конференц-комната (>100 абонентов).

  • Селекторные совещания с голосованиями (>100 абонентов).

  • IVR-сценарии обслуживания голосовых звонков с поддержкой распознавания и синтеза речи.

  • Управление данными через API.

  • Мониторинг активности и доступности через API.

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

  • Ведение лог-журналов по звонкам, сценариям, бизнес-логике.

  • Интеграция с LDAP.

  • Централизованное обновление.

  • Групповые номера.

  • Поддержка очередей.

  • Поддержка множественных вызовов.

  • Сохранение событий телефонии и данных, отправка в брокер.

  • Сохранение записи разговоров.

  • Поддержка приложений софтфонов.

  • Поддержка софтфонов в браузерах.

  • Виртуализация: несколько независимых компаний на одной инфраструктуре.

  • Механизмы уведомления внешних систем о событиях.

  • Поддержка видео-звонков.

  • Управление звонками через API.

  • Управление моделью данных с подписками на изменения.

  • Поддержка различных хранилищ и протоколов.

  • Подключение к почтовым ящикам.

  • Подключение к мессенджерам.

  • Боты автоматизированного обслуживания текстовых и голосовых каналов.

  • Поддержка и управление доступностью сторонних микросервисов и веб-приложений.

  • Снифферы из внешних сетей не получают ответов от системы и не проявляют к ней интереса.

Нефункциональные требования

Перечислены атрибуты качества в порядке убывания приоритета – драйверы архитектуры.

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

  • Доступность/Надежность

  • Изменяемость/Модифицируемость

  • Скорость разработки

  • Соответствие стандартам

  • Производительность

  • Сопровождаемость

  • Защищенность от атак

  • Документированность

  • Интегрируемость

Выборочные сценарии к атрибутам качества

  • Произвольный SIP телефон подключается к системе за 2 минуты, регистрируется и имеет возможность совершать и принимать звонки, удерживать, переводить.

  • При произвольном выключенном сервере абонент набирает номер и совершает успешный вызов и соединение с другим абонентом.

  • При наличии 1000 активных разговоров абонент набирает номер и соединяется с другим абонентом.

  • При наличии 200 cps абонент набирает номер и соединяется с другим абонентом.

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

  • Система развернута в Москве и Казани. Связь между городами отсутствует. Абонент в Казани регистрируется и звонит другому абоненту в Казани. Абонент в Москве регистрируется и звонит другому абоненту Москвы.

  • После восстановления связи между городами абонент в Москве набирает номер казанского абонента и соединяется с ним.

  • Администратор разворачивает площадку в Новосибирске менее чем за 1 час при наличии серверов и плана развертки.

  • Сотрудник поддержки в течение часа выявляет причину падения сервера.

  • Сотрудник поддержки в течение часа выявляет причину неудачи в совершении звонка.

  • Злоумышленник в 56-й раз пробует зарегистрироваться или позвонить под несуществующей учетной записью или с неверным паролем в течение 30 секунд. Система не отвечает ему и блокирует IP адрес на нижнем уровне на 20 минут. Последующие запросы злоумышленника не получают ответов и создают десятикратно меньшую нагрузку на процессоры серверов системы.

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

  • Во время телефонного разговора выключается любой сервер, и связь не рвется, звук пропадает не более чем на 1 секунду.

  • Один сервер обслуживает 200 одновременных звонков без потерь и задержек при cps 10 в секунду.

  • В конференцию заходит 201й пользователь менее чем за 3 секунды и слышит говорящего абонента, его тоже все слышат.

  • Программист добавляет новый компонент сценария менее чем за 1 день.

  • Программист добавляет новый микросервис сценария менее чем за 1 день.

  • Произвольная Web CRM система подключает API системы на базе «Era» менее чем за 1 неделю.

  • Администратор добавляет 1 сервер в кластер на сайте и увеличивает производительность на 100 cps / 200 одновременных звонков / 1000 BLF в секунду / 1000 регистраций в секунду.

  • Во время перезагрузки любого сервера абонент производит вызов и совершает звонок с задержкой не более 5 секунд.

  • Во время телефонного разговора связь с внешними устройствами пропала. Разговор завершается сервером принудительно в течение 2 часов, запись разговора оказывается в хранилище в течение 2 часов.

  • MVP системы управления заявками или хелпдеск создается менее чем за 8 часов.

  • Табличный отчет, диаграмма по агрегированным данным, дашборд с показателями на основе данных в объектной модели создается за 30 минут.

Более подробно сценарии к атрибутам качества сформулированы в wiki.

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

  • Поддержка протокола SIP/2.0 по UDP, TCP, TLS, WebSocket, WebSocket secure.

  • Поддержка RTP, DTLS (в том числе для WebRTC).

  • HTTP, HTTPS, WebSocket API.

  • Поддержка требований различных SIP провайдеров:

    • требующих отправки медиа-трафика с адреса подключенного устройства;

    • запрещающих REFER;

    • требующих отправки запросов от единой учетной записи;

    • ограничивающих количество одновременных диалогов;

    • требующих поддержки OPTIONS или осуществления встречных пингов через OPTIONS.

  • Поддержка различных SIP устройств (то есть ориентация на самый базовый набор RFC для SIP)

    • не поддерживающих согласование нескольких кодеков;

    • не умеющих работать с NAT и подменять медиа-адрес-порт в SDP;

    • не понимающих русского языка;

    • не умеющих перерегистрироваться по запросу.

  • Поддержка широкополосных кодеков (Speex, OPUS).

  • Поддержка голосовых кодеков g.711a, g.711u, g.729ab, g722, g726, gsm610, iLBC.

  • Поддержка видео кодеков H.263, H.264, VP8/VP9.

  • Использование свободнораспространяемой БД PostgreSQL, в том числе установленной у заказчика.

  • Поддержка распределения на несколько площадок.

  • Поддержка независимой работы площадок в случае отсутствия связи между ними.

  • Поддержка архитектуры x64.

  • Кроссплатформенность: поддержка Linux, Windows, виртуальных машин VMWare, HyperV.

  • Поддержка многопроцессорных систем (NUMA и пр).

  • Поддержка поставки в docker-контейнере.

  • Персонализация
  • Увеличить шрифт
  • Уменьшить шрифт