Шлюз отечественного производства (разработка, отладка, поверхностный монтаж)

Привет!

Мы тут протестировали совместную работу контакт-центра отечественного вендора Naumen и голосового транкового шлюза SMG-2 российской компании Eltex. Эти две штуки вместе дают полноценный отечественный колл-центр.

Отличается это решение от других тем, что оно подходит под понятие «импортозамещение». Я, когда слышу это слово, уже дёргаюсь: на рынке сейчас многие просто переклеивают наклейку и пишут документацию на русском. Но тут всё прямо как надо.

Больше деталей

Итак, я из департамента телекоммуникаций компании «КРОК». Наша команда занимается проектированием и внедрением контактных центров. Большая часть работ исторически была связана с «Авайей» — всё же этот вендор отлично знаком каждому на российском рынке. Сейчас мы закончили достаточно объёмное тестирование решений екатеринбургского «Наумена» и новосибирского «Элтекса».

Naumen — это российская компания с 15-летним опытом разработки программных решений на рынке контакт-центров. Они делают «всё в одном», обеспечивая решение большинства задач в рамках одного продукта: автообзвон, управление входящими и исходящими звонками, IVR, запись разговоров, анкетирование, управление качеством, поддерживают каналы почты, факса, SMS, веб-чатов, скайпа и многое другое. Обещают пять девяток надёжности — 5 минут простоя в год максимум. Самое важное для нас — есть SIP-протокол и возможность использовать VoIP-шлюзы и абонентские терминалы различных производителей. При этом «Наумен» не делает своё железо, что означает, что контакт-центры всё равно нужно было строить (до этого) на железе кого-то из США или Китая. А когда речь идёт про железо из США, сразу вспоминается «Авайя», у которой есть и связанные решения.

В качестве VoIP-шлюза нам было интересно использовать оборудование компании Eltex, российского предприятия с более чем 23-летней историей, разработчика и производителя телекоммуникационного оборудования, обладающего собственным производством, включая линии поверхностного монтажа. Всё железо Eltex работает под управлением собственного разработанного ПО.

По поводу «российского производства»… — думаю, оно настолько российское, насколько это вообще в принципе сегодня возможно. Естественно, вся компонентная база (микросхемы, транзисторы и прочее) идёт от ведущих мировых производителей. Здесь это конкретно Marvell Technology Group, Broadcom Corporation, Silicon Laboratories, PMC-Sierra International, Mindspeed Technologies, Inc., Infineon Technologies. Но Eltex, в отличие от многих других российских производителей (которые заказывают сборку изделий в странах Юго-Восточной Азии), не только сами проектируют и делают трассировки печатных плат, но и имеют собственные линии поверхностного монтажа, т. е. линии изготовления электронных изделий на печатных платах с использованием элементной базы. Полный цикл разработки — от схемотехники до отладки — тоже в России. Они же сами пишут своё ПО.

Поехали!

Что собой представляет шлюз SMG-2? По сути это конвертер протоколов между TDM и VoIP-сетями. SMG-2 в базовой поставке поддерживает один поток Е1 (ОКС-7, DSS-1) и 32 VoIP-канала (SIP). При покупке дополнительной лицензии возможна активация второго E1 потока и расширение количества VoIP-каналов до 64. Шлюз предоставляет богатые возможности управления вызовами (маршрутизация по номеру вызываемого и вызывающего абонента, RADIUS-маршрутизация, модификация номера до и после маршрутизации, использование нескольких планов нумерации), поддерживает большой набор голосовых кодеков (G.711, G.729, G.723.1, G.726) и аппаратное транскодирование медиапотоков. Качество обработки голоса достигается в том числе и за счёт возможности применения механизмов эхокомпенсации, детектора тишины, генератора комфортного шума, а также приоритизации трафика (QoS). Всё это упаковано в небольшую коробочку настольного исполнения. Вот в такую:



Мы использовали шлюз при исходящем обзвоне, инициированном контакт-центром Naumen, для маршрутизации вызовов в сеть традиционной TDM-телефонии.



Со стороны Naumen Contact Center необходимо прописать шлюз и настроить маршрутизацию вызовов через данный шлюз. Для этого открываем вкладку «Администрирование» и выбираем в разделе «Конфигурирование контактного центра» пункт «Серверы и маршрутизация»:



Далее для добавления шлюза в систему необходимо выбрать вкладку «Шлюзы», нажать кнопку «Добавить шлюз» и в открывшемся окне прописать параметры шлюза. В нашем случае мы используем для работы со шлюзом протокол SIP, и SMG-2 с IP-адресом 172.23.32.44 ожидает от нас приём SIP-сообщений на udp порту 5060:



Для маршрутизации вызовов через прописанный шлюз необходимо добавить правило маршрутизации с типом «Маршрутизация на произвольный номер»:



В правиле прописываем, что все вызовы, где вызываемый номер соответствует шаблону 98([0-9]{10}) (т. е. вызываемый номер начинается на 98 и содержит далее 10 произвольных цифр), мы без изменения (о чём говорит шаблон действия ${0}) переадресуем на прописанный ранее шлюз:



Для корректной передачи DTMF мы использовали RFC2833, т. е. передачу DTMF в пакетах протокола RTP. По умолчанию в Naumen для этой цели используются сообщения INFO протокола SIP c DTMF MIME Type — application/dtmf. Чтобы изменить способ передачи DTMF, необходимо поправить конфигурацию службы nautel. Для этого необходимо параметру FormatDTMF файла nautel.xml конфигурации контакт-центра задать значение «0»:

[root@localhost ~]# cat /opt/naumen/nauphone/spool/nautel/cfg/nautel.xml
<?xml version="1.0" encoding="utf-8" standalone="no" ?>
<Config type="phone">
<Config type="h323">
<Var name="Enable" type="bool" value="false"/>
</Config>
<Config type="sip">
<Var name="Enable" type="bool" value="true"/>
<Var name="AutoCalcListenUDPPort" type="bool" value="true"/>
<Var name="AutoCalcListenTCPPort" type="bool" value="true"/>
<Var name="ListenUDPPort" type="int" value="5070"/>
<Var name="ListenTCPPort" type="int" value="5070"/>
<Var name="FormatDTMF" type="int" value="0"/>
</Config>
</Config>

После рестарта сервиса nautel изменения вступят в силу:

[root@localhost ~]# naucore service nautel restart
stopping service <nautel> ...
service <nautel> offlined
starting service: <nautel> ...
service <nautel:0> started 

На этом, собственно, настройки со стороны Naumen Contact Center и закончились.

Настройка шлюза

Настройка шлюза займёт несколько больше времени. Нам необходимо настроить поток E1 для доступа в TDM-сеть, SIP-интерфейс, транк-группы и план нумерации для маршрутизации вызовов.

Мы использовали для доступа в TDM-сеть как систему сигнализации ОКС-7, так и сигнализацию Q.931 ISDN PRI.
В первом случае настройка E1 потока у нас выглядела следующим образом:



Здесь задаём название, выбираем протокол сигнализации, тип линейного кода, группу линий ОКС-7, номер канала, который используется в качестве D-канала (16-й в нашем случае), и включаем поток. На закладке «Настройка каналов» определяем ISUP CIC коды идентификатора каналов. В нашем случае мы используем 15 тайм-слотов E1 потока:



На скриншоте видно, что все 15 тайм-слотов мы отдали под транковую группу TDM (которую зададим позднее).
Далее нам необходимо прописать группу линий ОКС-7. В ней необходимо задать категорию доступа, если мы используем разграничение прав вызовов из входящего канала в исходящий и план нумерации (по умолчанию в системе создан 1 план нумерации). Остальные настройки во многом зависят от удалённой стороны, поэтому я не могу дать чётких рекомендаций по их значениям:



Настройка ISDN PRI осуществляется несколько проще. Включаем поток, выбираем протокол сигнализации (Eltex в нашем случае выступает как user side), категорию доступа, план нумерации. Остальные параметры опять же зависят от удалённой стороны:



Мы используем 15 тайм-слотов потока и отдаём их под транковую группу TDM. Это осуществляется на вкладке «Использование каналов»:



Далее необходимо создать и настроить SIP-интерфейс, в котором задаются основные параметры конфигурации стека SIP. Как и в настройках E1 потока, мы задаём название, категорию доступа и план нумерации. Остальные настройки специфичны для протокола SIP.



Поле «Режим» задаёт протокол для интерфейса (SIP/SIP-T/SIP-I), в поле «Имя хоста / IP-адрес» указываем IP-адрес контакт-центра Naumen, «Порт назначения SIP-сигнализации» выставляем в значение порта, который «слушает» служба nautel на сервере Naumen, другие параметры на данной вкладке не меняем. Вспоминаем про то, что используем рекомендацию RFC 2833 для передачи DTMF, и идём на закладку «Настройка кодеков/RTP»:



Там, помимо задания значения поля «Способ передачи DTMF», отмечаем используемые кодеки.
Другие параметры интерфейса SIP мы оставили без изменений.
В плане нумерации задаются префиксы выхода на транковые группы. Существует 2 основных критерия, по которым происходит маршрутизация звонков на устройстве:
• поиск по номеру вызывающего — CgPN (Calling Party Number);
• поиск по номеру вызываемого — CdPN (Called Party Number).

Мы будем использовать маршрутизацию по прямому префиксу, т. е. выход на префикс без анализа номера вызывающего либо вызываемого абонентов. Данный способ предназначен для коммутации всех вызовов из одной транковой группы в другую независимо от набранного номера (без создания масок в префиксах). Поэтому наши префиксы выглядят довольно просто:



Тип префикса — транковая группа, но так как мы ещё не создали ни одной транковой группы, то поле «Объект» указывает на несуществующую транковую группу 255. Было создано два префикса — 0 и 1. Префикс 0 соответствует TDM-транку, а префикс 1 — SIP-транку в сторону Naumen. Транки в префиксах мы пропишем после создания транков.

Прокомментирую уже созданные транковые группы:



Транковая группа 0 — это SIP транк-группа, которая все входящие вызовы без анализа номера вызывающего либо вызываемого абонентов маршрутизирует на ранее созданный прямой префикс 0, соответствующий TDM-направлению:



Транковая группа 1 объединяет 15 тайм-слотов потока E1 и маршрутизирует все входящие вызовы на прямой префикс 1, соответствующий SIP-направлению:



Вернёмся к плану нумерации и пропишем в префиксах плана нумерации созданные транк-группы:



На этом всё. Приведённые выше настройки позволяют шлюзу успешно принимать входящие SIP-вызовы от контакт-центра Naumen и перенаправлять их в TDM-сеть.

Пара слов про Eltex

У одного из наших заказчиков — финансовой организации — установлены системы исходящего обзвона. Вызовы идут по потокам Е1 к одному оператору связи.

У банка появилась идея звонить через большую тройку операторов, причём вызов абоненту, например МТС, должен идти через провайдера МТС. Это значительно снизит затраты на тарификацию по связи. Также один из новых операторов связи подаёт потоки через SIP. Оборудование системы исходящего обзвона позволяет совершать вызовы вплоть до 100 cps.
Итого имеем задачу:

1. Принимать вызовы по потокам E1, распределять их по операторам связи в зависимости от набираемого номера.
2. Обеспечить конвертацию трафика из ISDN в SIP для одного из операторов связи.
3. Обеспечить производительность системы в 100 cps.

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



Целевая конфигурация системы:



Маршрутизацию вызовов обеспечивает оборудование Элтекс БКП-М.

Конвертацию трафика производит голосовой шлюз SMG-2016M.

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

Ещё тест

До того, как подключать Элтекс, мы совместно с Naumen провели нагрузочное тестирование решения Naumen Contact Center 6.2 в среде виртуализации VMware vSphere. Мы развернули КЦ на ресурсах виртуального дата-центра КРОК. Эмулировались телефонные вызовы, устанавливающиеся в одну очередь и распределяющиеся на группу эмулируемых операторов. В соответствие со сценарием тестирования каждый оператор разговаривал от 60 до 120 секунд и заполнял анкету, состоящую из 3 форм и 15 параметров. В качестве ОС на ноды устанавливался Oracle Enterprise Linux 6.4 x64. На генерирующих нагрузку нодах (loader) использовался Ubuntu 12.04lts.

По результатам — среднее количество одновременно обслуживаемых вызовов (операторы + ivr) — 1080 из них 450 на операторах и 630 на ivr совпадает с расчетным значением. «Железные» сервера показывают производительность примерно на 20% более высокую, чем при работе под гипервизором VMWare.

Резюме

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

Ссылки

• Что должен уметь колл-центр по ИТ
• Распознавание русской речи для колл-центров и параноиков
• Голосовые отпечатки
• Моя почта — DPesotskiy@croc.ru