Причины поиска альтернативы существующему оборудованию

Проблемы с коммутатором Huawei SoftX3000 копились постепенно и были обусловлены разными факторами:

  • Физическое устаревание оборудования. На момент замены оборудование работало без замены более 12 лет. ЗИПа не было.
  • Сбои серверов управления. В системе использовались несколько серверов: основной и резервный сервера предварительного биллинга, основной и резервный сервера управления конфигурацией, сервер взаимодействия с СОРМ. Все они работали на ОС Windows 2000 Server, установочные пакеты ПО для серверов невозможно было установить на более свежую версию ОС. Виртуализировать эти сервера корректно у нас также не получилось. Кроме того, при работе в одной сети с машинами на ОС Windows 7 сервера на Windows 2000 регулярно выдавали BSOD. Предпринимались попытки изменить защиту установочных файлов серверного ПО и установить его на Windows Server 2003, но стабильной работы добиться не удалось.
  • Сбои и ошибки на транковом шлюзе UMG8900. Регулярно получали сообщения о кратковременном сбое/восстановлении на субмодулях потоков E1. Какого-либо влияния на сервис замечено не было, но определить причины и риски данных сообщений не удалось.
  • Ограничения в функционале. На данной АТС все функции ограничены лицензией: количество абонентов, количество транков, количество абонентов, которым доступно определенная опция (ДВО). По большинству из этих параметров мы начали подбираться к максимальным значениям. Некоторые современные функции были вообще недоступны.
  • Ограниченный выбор голосовых шлюзов. Основное количество абонентских лицензий было закуплено для протоколов MGCP и H.248. Выбор оборудования, работающего по этим протоколам, на рынке сильно ограничен. Шлюзы и телефоны, работающие по протоколу SIP, более распространены. Но количество таких лицензий у нас было резко ограничено.
  • Отсутствие персонала, который имел бы ясное понимание, как вся эта система собрана, настроена и работает. Люди, которые проходили обучение по работе со станцией или участвовали в ее запуске, отошли от дел по разным причинам: кто-то перешел в другие направления, кто-то уволился.
  • Отсутствие технической поддержки. В случае необходимости решить какую-то нестандартную задачу помощи ждать было неоткуда. Не говоря уже о каких-то экстренных ситуациях.

Для устранения всех описанных выше проблем предлагалось единственное решение — полное обновление станции за очень внушительный ценник. Руководство стремилось минимизировать затраты и запрашивало альтернативные варианты. Решений по системам коммутации такого уровня не так много в мире, а в РФ тем более. Наши поиски привели нас к системе от российского производителя «Элтекс».

Причины выбора Eltex

После рассмотрения различных предложений на рынке выбор пал на продукт от российского разработчика — ECSS-10 Eltex. Основным решающим фактором для руководства стала стоимость решения — примерно в 3 раза ниже других предложений, которые мы получали. Также у нас был опыт работы с VoIP-оборудованием данного производителя и опыт взаимодействия с технической поддержкой: всегда можно было получить нужную информацию по функционалу и методам настройки устройств. Да и при выявлении критичных багов разработчики реагировали оперативно.

Из других особенностей для себя мы можем выделить:

  • Большое количество ДВО без дополнительной платы за лицензии (самая интересная нам — multiline).
  • Ядро станции — полностью программный продукт. Не нужно каких-то специализированных корзин, плат и модулей, просто установили ОС и ПО на нее.
  • Снижение энергозатрат и количества оборудования. Вместо 4 полноразмерных 19” стоек всё уместилось в одну. Хотя, возможно, это заслуга технического прогресса.
  • Наличие в открытом доступе подробной технической документации.
  • Русскоязычная техническая поддержка.

В дальнейшем после начала эксплуатации выявились ещё некоторые моменты:

  • Графический интерфейс. Конечно, это «не круто» и вначале отношение было довольно скептическое. Но на деле интерфейс оказался весьма удобным и достаточным для большинства повседневных задач.
  • Довольно простая и логичная настройка маршрутизации вызовов. Всегда понятно, откуда приходит вызов, по каким точкам он проходит и как обрабатывается.
  • Простая настройка «нетелефонных» параметров. Так как станция установлена на обычный Linux, настроить IP-адреса, маршрутизацию или фильтрацию трафика довольно просто.
  • Стандартные инструменты доступа к оборудованию. Не нужно устанавливать какие-то специальные терминалы для управления станцией или её мониторинга. Нужны только WinSCP, Putty и web-браузер.

Существующая конфигурация

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

  • Ядро станции Huawei SoftX3000. Оборудование состоит из корзины с платами и четырех коммутаторов Ethernet, которые связывают всё воедино.
  • Сервера управления. В той же стойке установлены: основной сервер управления (BAM), основной сервер предварительного биллинга (IGWB0), резервный сервер предварительного биллинга (IGWB1). Отдельно установлен резервный сервер управления станцией (EWS), а также стойка оборудования СОРМ, включающая в себя сервер взаимодействия со станцией (XPTU) и кучу разных конвертеров.
  • Транковый шлюз Huawei miniUMG8900. Предназначен для подключения к станции транков E1. Наша конфигурация позволяла подключить до 32 потоков. Лицензиями было ограничено количество присоединений (только 10 присоединений) и только по ОКС7 (каждое присоединение может включать несколько потоков).
  • Два пограничных контроллера сессий (SBC). В работе был только один, второй не был корректно сконфигурирован и использовался для различных тестов. В последующем наличие свободного SBC очень облегчило задачу миграции: использовали его для предварительных тестов и в итоге как основной SBC в новой схеме.
  • Абонентские шлюзы, работающие по протоколу MGCP. Таких устройств было много, но хотелось в итоге прийти к единой схеме, поэтому решено было перевести их на работу по протоколу SIP (такая возможность была заложена на всех устройствах).
  • Абонентские устройства SIP (шлюзы и телефоны).
  • Очень мутно настроенная схема прохождения голоса. В существующей станции за обработку голоса и обработку сигнализации отвечали разные платы, которые к тому же работали в разных подсетях. Если между ядром и транковым шлюзом это нормальная схема работы, то при взаимодействии с внешними абонентами через SBC, видимо, были какие-то проблемы с прохождением голоса. В результате родилась схема, где кроме самой станции и SBC участвовали четыре коммутатора L3, 7 разных подсетей, 3 роутера OSPF и один Junniper MX480. Для чего это сделано и как оно работало, я так до конца и не разобрался.

В итоге было решено поэтапно перенастроить абонентские устройства MGCP, переводя их на работу по SIP-протоколу. Также сохранили существующие SBC от Huawei, сконфигурировав под новую схему с нуля. Всё остальное было запланировано на замену.

Ожидаемые проблемы

  • Большое количество голосовых шлюзов подлежит перенастройке (смена режима с MGCP на SIP).
  • Вероятность большого простоя при миграции (особенно, присоединений к операторам).
  • Необходимость настройки и сдачи СОРМ.
  • Необходимость настройки сопряжения с биллингом.
  • Вопрос совместимости с SBC от Huawei.

Подбор конфигурации оборудования

Согласно конфигурации нашей существующей сети и требованиям по минимизации затрат у нас получилось следующее:

  • Сервера использовали собственные, закупленные ранее под другой проект. Предварительно согласовали это с производителем.
  • К серверам приобретена лицензия (прислали токены) на необходимое нам количество абонентов для системы с резервированием (два сервера в кластере).
  • Для присоединения к операторам по E1 (стыки ОКС7) использовали 2 единицы транковых шлюзов Eltex SMG-1016 в полной комплектации (закуплены ранее как альтернатива Huawei miniUMG8900, но полноценно их интегрировать с SoftX3000 не получилось).
  • Для сопряжения с пультом СОРМ закуплена лицензия на SMG-1016, а также комплекс работ по настройке и сдаче. Таким образом, большая часть работ по этому этапу настройки выполнена технической поддержкой производителя.
  • SBC оставили существующие, от Huawei (с прицелом на обновление в будущем). На данный момент функционал этих железок устраивает. Вопрос по надёжности остается открытым. В будущем нужно искать альтернативу этому оборудованию.
  • Лицензии на подключение шлюзов MGCP закупать не стали. Решили перенастроить существующие шлюзы (поддержка протокола SIP есть на всех устройствах).
  • Закуплены два коммутатора MES3324 и стекирующие DAC-кабели к ним, для подключения всего оборудования.

Начальное конфигурирование

Обычно производитель присылает предварительно настроенное и работоспособное оборудование — сервера на Ubuntu Server и установленное на них ПО Eltex ECSS-10. В нашем случае мы подготовили сервера самостоятельно (установили на них ОС), после чего предоставили удалённый доступ техническим специалистам производителя, которые уже подняли софтсвитч. В итоге мы получили две полностью работоспособные несконфигурированные АТС, с которыми начали работать и осваиваться.

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

План миграции

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

  1. Соединение новой станции с основной по SIP-транку. На этом этапе выделили несколько номеров из основной ёмкости и завели их в новый софтсвитч, проверили входящие и исходящие вызовы, потренировались в настройке различных параметров абонентов и настройке маршрутизации. В этот момент ECSS-10 являлась как бы внутренней мини-АТС по отношению к SoftX3000.

  2. Настройка работы станции в паре с SBC, чтобы можно было подключать к ней абонентов из основной сети и тестировать в реальных условиях. Как уже указывалось ранее, в распоряжении был незадействованный SBC с какими-то тестовыми настройками. SBC был сброшен к заводским настройкам и поэтапно настроен по аналогии с основным. Этот этап помог лучше понять принцип работы и настройки SBC. Просто перенести настройки с рабочего устройства на новое не получилось, нужно было понимать, что именно выполняет каждая команда и как её изменить под новую конфигурацию.

  3. Перевод нескольких абонентов в новую станцию. Это абоненты нашего офиса, чтобы не влиять на основных клиентов.

  4. Тестирование и сбор статистики по проблемам.

  5. «Заворот» трафика от одного из операторов на новую станцию. Все входящие вызовы с этого оператора сразу транзитом направляются в новую станцию. В новой станции, если вызов предназначен абонентам, зарегистрированным в этой станции, вызов «приземляется». Иначе возвращается по тому же транку в старую станцию, где маршрутизация происходит по старой схеме.

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

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

  2. «Заворот» всего внешнего трафика на новую станцию. На этом этапе проверяли работоспособность схемы маршрутизации, устраняли недочеты, тестировали стабильность оборудования при реальной нагрузке.

  3. Работы по настройке выгрузки CDR и подготовке к интеграции с биллингом. Договаривались о том, какие данные и в каком формате отдавать в АСР. Здесь следует отметить, что в станции, кроме непосредственно контекстов маршрутизации, существует еще несколько инструментов для корректировки номеров:

  • Модуль «Модификация номеров» — корректирует номера для нужд маршрутизации.
  • Модуль «Адаптация номеров» — подготавливает номера для CDR, то есть приводит к формату, необходимому для системы биллинга. Довольно удобно, что они друг на друга не влияют.

  1. Работы по настройке СОРМ и подготовке к переключению на новую систему. Приемо-сдаточные испытания и получение всех согласований. Эта часть выполнялась технической поддержкой производителя на платной основе, так как не было даже примерного представления, а тем более опыта, как это работает и как взаимодействовать с этим ведомством.

  2. Перевод всех абонентов (кроме абонентов, работающих через SIP-транки) на новую станцию. Ночные работы с перерывом связи. Одновременно с этим переходим на новый СОРМ. СОРМ переключил товарищ майор. Абонентов переключили путем переноса интерфейса регистрации абонентов (172.16.0.3) со старого SBC на новый.

  3. Биллинг пока остался на старой станции. Так как все внешние стыки идут через неё, то это некритично. Звонки внутри станции у нас не тарифицируются.

  4. Перенос абонентских sip-транков на новую станцию (через второй SBC).

  5. После сопряжения биллинга с новой станцией, по одному, с перерывами сервиса, перенесли внешние стыки с операторами с miniUMG8900 на SMG-1016.

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