Привет, Хабр! Сегодня мы расскажем про замену телефонии для одного крупного корпоративного клиента. Это проект из тех, что начинаются как локальная стройка, а заканчиваются возведением вавилонской башни. Простое внедрение дополнительного функционала системы обернулось переходом на новое ПО с разработкой, тестированием и исправлением «на лету».

Под катом – специфические подробности про работу корпоративных «связистов», длинный список требований от заказчика, активное допиливание решения и, несмотря ни на что, позитивный финал.



Техническое задание с многоточием


В начале 2022 года один крупный заказчик пришел к нам с маленькой специфической проблемой. Требовалось сделать новую кнопку звонка в интерфейсе CRM, чтобы сотрудники компании могли связываться друг с другом и контрагентами без ручного набора, просто по клику. Эту функцию так и назвали — click to call (C2C).


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

Несколько лет назад мы уже развернули у этого заказчика телефонию от Cisco, там был колл-центр, реализованный на базе решения GENESIS и система корпоративной телефонии на базе CUCM — Cisco Unified Communication Manager. Мы освежили в памяти архитектуру решения, оценили потребности сотрудников заказчика и предложили за два с половиной месяца перейти на российское решение, у которого есть модуль C2C. Но пока мы готовили КП, требования начали меняться…

В апреле от заказчика пришёл запрос на подготовку ТКП по C2C. А к началу августа пришло новое ТЗ на полную замену системы телефонии.

При этом реализация click to call сама по себе никуда не делась. В ее рамках средствами маршрутизации нужно было обеспечить два плеча звонка. То есть сделать так, чтобы при помощи модуля C2C можно было соединить звонок с клиентом и внутренний номер абонента вне зависимости от того, где в корпоративной телефонной сети он находится или даже если он в данный момент работает на мобильном.

Выбираем вендора


Что же, заказчик сказал: надо! Интегратор ответил: есть!

Сразу после ухода с рынка западных вендоров мы потратили много времени на анализ рынка российских решений PBX и UC. К моменту начала этого проекта многие решения мы уже протестировали в лаборатории и узнали их слабые и сильные стороны. Со многими вендорами пообщались лично и поняли, кто из них гибок в плане взаимодействия и готов развивать свой продукт, если это требуется клиенту, а с кем будет сложнее работать. Так что мы оперативно проанализировали требования конкретного проекта и предложили для интеграции UC-платформу РТУ от компании САТЕЛ.

  • Компания работает на рынке телефонии аж с 1995 года, но их систему мы выбрали в первую очередь из-за функциональности. Наши тесты показывали, что РТУ:
  • поддерживает функционал базовых и расширенных ДВО УПАТС;
  • поддерживает функции UC;
  • поддерживает протоколы SIP, H323, WebRTC;
  • поддерживает работу шлюзов по H.248, SIP;
  • поддерживает Provisioning для ТА, работает с телефонами Cisco, в том числе по SCCP (проприетарный протокол Cisco);
  • поддерживает шифрование TLS для SIP взаимодействий;
  • поддерживает SNMP;
  • обеспечивает георезервированную архитектуру.

В общем, решение удовлетворяет базовым потребностям VoIP UC платформы и корпоративной телефонии. При этом почти вся функциональность РТУ, кроме мобильных приложений, была реализована в ядре системы. И телефония, и провиженинг телефонов, и запись. Это позволило сократить число необходимых для развертывания виртуалок. А вишенкой на торте стала возможность реализовать click to call путем интеграции системы с CRM заказчика посредством API платформы РТУ.

Толстый клиент вместо Web



Примерная архитектурная схема нашего решения

Вскоре прямо по ходу работ над проектом выяснилось еще одно серьезное требование к системе телефонии. Несмотря на общий тренд ухода в Web, оказалось, что заказчик предпочитает раскатывать у сотрудников десктопные приложения. Объяснялось это заботой об удобстве пользователей. При работе с браузерной версией, каждый сотрудник компании должен сам перейти по нужной ссылке и добавить ее в закладки, выдать необходимые разрешения, например, на доступ к микрофону и так далее. А десктопное приложение можно автоматически залить на корпоративные компьютеры и оно сразу заработает.


Веб-клиент РТУ

Конечно, можно обучить пользователей работать с браузерной версией, но когда у тебя 5 тысяч сотрудников, хочется по максимуму избежать проблем. Желание понятное, но новый клиент должен был что-то написать. Мы обратились к САТЕЛ, описали ситуацию и заручились готовностью вендора помочь реализовать пожелание заказчика. Но самое интересное началось потом.

Обкатка нового релиза в полевых условиях


Как раз в этот момент вендор готовил к выпуску новую версию РТУ. Она еще требовала доработок, но клиент настоял, чтобы ему поставили самую последнюю версию системы — еще до официального релиза. Мы обсудили это с вендором и договорились, что вместе доработаем, внедрим и испытаем РТУ. Заказчик идею поддержал. Дальше в работе полноценно участвовали три стороны: К2ТЕХ в лице нашего подразделения, разработчики САТЕЛ и представители заказчика. Силами трех команд мы тестировали и допиливали, и снова допиливали и тестировали новое решение в процессе внедрения.

Еще на начальном этапе проекта были очевидны некоторые плюсы новой версии РТУ. Например, в старой версии интерфейс программного клиента РТУ был доступен только через личный кабинет пользователя — в новой версии реализовали возможность регистрации через WebRTC-клиент. Улучшили такие функции, как конференц-комнаты, чаты и статус присутствия. А в ходе проекта коллеги из команды разработчиков САТЕЛ написали и проверили десктопную версию программного клиента РТУ — сначала портативное Progressive Web Applications, а потом MSI-инсталлятор на базе фреймворка Tauri. И не просто написали, а внедрили его у заказчика.

Добавили и другие полезные фичи:

  • Доработали функцию Do Not Disturb, доработали веб-интерфейс, доработали консультативный перевод, сделали сохранение истории звонков.
  • Вся эпопея начиналась с click to call. Это тоже реализовали совместными усилиями на базе REST API и функции Callback РТУ.
  • У заказчика были серьезные требования к LDAP интеграции с Active Directory. Пришлось ее заметно проапгрейдить.
  • Для C2C реализовали аутентификацию на основе JWT-токена. Изначально эта задача была поставлена не совсем корректно, и в результате разработчики САТЕЛ не попали в ожидания заказчика. Служба безопасности требовала, чтобы при входящих и исходящих запросах от CRM генерация токена происходила в системах заказчика. Мы договорились, что САТЕЛ переделает этот момент, но уже после сдачи проекта и перевода системы на техподдержку. В итоге сейчас все работает как надо.

Миграция или будни подопытных кроликов



Схема организации связи функционала C2C

На проведение приемо-сдаточных испытаний мы выехали в московский офис заказчика. Сначала обкатывали систему на тестовой группе телефонов Cisco. В компании было установлено всего несколько десятков таких аппаратов, но все равно планировалось продолжить их поддержку. Предыдущая версия РТУ с ними работала, но все равно возникли небольшие сложности. Например, телефоны 7906 и 7821 моделей не регистрировались с конфигом, который должен был быть рабочим, а Cisco 8851 не загружались, если из AD поступало длинное имя из нескольких атрибутов. Вроде бы мелочь, но эта проблема остановила процесс перехода пользователей на новую систему, так как именно эти телефоны использовались руководством вплоть до гендиректора компании.


Злополучные Cisco 7906 и Cisco 7821

Чтобы исправить баги, аппараты пришлось отвезти в Нижний Новгород в лабораторию вендора. Там проанализировали ситуацию — отображение имен оказалось результатом ограничений со стороны Cisco, но проблему удалось решить доработками на стороне РТУ. Еще у заказчика были телефонные станции Coral (с телефонами Tadiran Coral DKT-2320 и DKT1110) — старое решение, которому уже больше 10 лет. Его пришлось заменить. Пользователи Coral в итоге пересели на WebRTC клиенты РТУ.

Хотелось бы сказать, что в остальном все прошло гладко, но нет. Фактически это был масштабный бета-тест, так что естественно без багов не обошлось.

Некоторые были сравнительно безобидными, например, не всплывало оповещение о перехвате вызова для пользователей в группе перехвата, кнопка настроек исчезала при сворачивании webphone в размер меньше половины экрана, webRTC клиент РТУ не работал со старыми версиями браузеров, не отображалось DisplayName внешних абонентов в истории звонков. Другие — серьезнее. Так, несколько месяцев не могли отловить баг, связанный со списком допустимых кодеков, когда в составе присутствовал Opus. Наличие этого кодека в списке приводило к сильному треску и вызывало искажения, появление «металлического» голоса во время звонков — это страшно раздражало пользователей. Чинили переадресацию вызовов и групповые звонки во время разговора.

До последнего момента с новым релизом не работали мобильные клиентские приложения под Android и iOS. Они позволяют использовать смартфоны как полноценные офисные телефонные аппараты с коротким номером, бесплатной связью внутри компании и переадресацией звонков с многоканального корпоративного номера. Вот только они работают через отдельный модуль РТУ-DMZ, который отвечает за регистрацию внешних мобильных подключений. Для нас, как интегратора, это — черный ящик. САТЕЛ всегда внедряет его самостоятельно.

Что на выходе


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


Архитектура итогового решения

Заработала новая IP-АТС, которая объединила офисы и разбросанных по стране сотрудников заказчика в общую телефонную сеть с возможностью подключения WebRTC клиентов, обширным функционалом ДВО, опцией подключения мобильных клиентов из внешней сети. Когда мы сдавали проект, на новую систему перешли больше 1 тыс. пользователей. Сейчас клиент у нас на технической поддержке. Постепенно переводим остальных, всего заказчик хочет переключить на РТУ 5000 сотрудников.

Проект оказался непростой, но усилия себя оправдали. Мы получили отличный проект в копилку опыта, заказчик — зрелую, подходящую под свои задачи отечественную систему, которая не схлопнется в один прекрасный день (как западная). Вендор значительно продвинулся в развитии своего решения в части UC, WebRTC-клиента и общей функциональности. Все исправления и доработки выполнялись в рамках основной ветки продукта, попали в официальный релиз РТУ и стали доступны всем пользователям телефонии САТЕЛ.

Комментарии (0)