Что нового

Article VoIP. Softswitch. (MVTS, RTU)

Vander 0

Vander

Команда форума
10.11.2019
432
947
Приветствую уважаемую аудиторию форума Protey!

v-voip-komponentah-operatsionnoj-sistemy-android-nashli-uyazvimosti-ccna-cyber-ops-chelyabinsk...png

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

Softswitch (программный коммутатор) — гибкий программный коммутатор, один из основных элементов сети связи следующего поколения NGN.

maxresdefault (7).jpg

Softswitch — это устройство управления сетью NGN, призванное отделить функции управления соединениями от функций коммутации, способное обслуживать большое число абонентов и взаимодействовать с серверами приложений, поддерживая открытые стандарты.

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

Схематично работу софтсвитча, можно представить так:

Diagram-VoIP-Softswitch.jpg

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

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

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

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

Начнем с SR-S4500 от SwitchRay, насколько мне известно, эта компания уже таковой не является, но их продуктом MERA VoIP Transit Softswitch (MVTS), многие, в том числе и мы, пользуются до сих пор.

1580925858022.png

SR-S4500 – система управления транзитным VoIP-трафиком. Предназначена для эффективной обработки большого количества одновременных вызовов за счет применения гибких схем авторизации и маршрутизации.

Функционально SR-S4500 состоит из двух основных подсистем:
  • Коммутации (Traffic Switch)
  • Управления (Traffic Manager)
Функции между ключевыми компонентами системы SR-S4500 распределены следующим образом: Traffic Manager (TMngr) осуществляет поиск информации о доступных маршрутах, правилах распределения нагрузки между терминирующим оборудованием и т.п., в то время как Traffic Switch (TS) обрабатывает данную информацию и формирует вызовы.

1580925897358.png

А так выглядит интерфейс управления свитчом из консоли:

1580925919967.png

А так из web-интерфейса:

1580925948764.png

В сети есть мануал на 300 страниц, а в этой статье я ограничусь краткими вводными данными и несколькими примерами работы с MVTS.

Пример 1: Аутентификация.

Процедура аутентификации пользователя состоит из следующих этапов:
  • Поиск аутентификационной записи клиента. При получении запроса от подсистемы коммутации TMngr аутентифицирует пользователя. Возможна авторизация по паре логин-пароль, IP-адрес.
  • Преобразование номеров. Если пользователь идентифицирован, и его учетная запись не блокирована, TMngr производит преобразование номеров вызывающего и вызываемого абонентов в соответствии с правилами преобразования, заданными в учетной записи оборудования и/или аутентификационной записи оборудования.
  • Выбор тарифного плана. По аутентификационной записи инициирующего оборудования TMngr определяет тарифный план, используемый пользователем.
  • Выбор плана маршрутизации. Система определяет план маршрутизации, к которой принадлежит данный пользователь. План маршрутизации – это совокупность маршрутов, в которой поиск маршрута выполняется в первую очередь. Если маршрут в плане найти не удалось, TMngr продолжает поиск вариантов среди маршрутов, не входящих в план.
  • Определение уровня протоколирования. TMngr определяет уровень детализации отладочного протокола и переходит к процедуре авторизации. Неудачные попытки аутентификации записываются в CDR.
Ниже пример авторизации для одного из клиентов:

1580925979246.png

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

Пример 2: Подмена номера.

В MVTS есть правила трансляции (преобразования) номеров.
  • In SRC преобразование – правило преобразования номера вызывающего абонента для случаев, когда устройство выступает в качестве инициатора.
  • In DST преобразование – правило преобразования номера вызываемого абонента для случаев, когда устройство выступает в качестве инициатора вызова.
  • Out SRC преобразование – правило преобразования номера вызывающего абонента для случаев, когда устройство выступает в качестве терминирующего.
  • Out DST преобразование – правило преобразования номера вызываемого абонента для случаев, когда устройство выступает в качестве терминирующего.
Рассмотрим, момент, когда необходимо подменить номер звонящего и отправить его в сеть оператора. Для выполнения данного фокуса требуется доступ к MVTS и софтфон.

Придумаем номер, с которого будем звонить:

1580926071954.png

Заходим на MVTS в раздел аутентификации, для зарегистрированного пользователя (в данном случае, меня) и указываем этот номер в поле SRC translate:

1580926095210.png

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

1580926107846.png

Ну и немного дампа, чтобы было понятно, как это происходит:

1580926128391.png

Пример 3. Прослушивание звонков.

Для выполнения данного трюка, уже необходимо иметь консольный доступ на правах root на подсистему коммутации Traffic Switch.

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

А декодировать мы будем только 729 кодек, усложним себе задачу, т.к. он имеет большую степень сжатия, и в Wireshark его не послушаешь, так как 711.

1580926149572.png

Выполняем следующую команду на Traffic Switch:


Код:
tcpdump -i any -s 65535 -w capital.pcap host 194.58.156.11
Ждем некоторое время, если активных звонков много – то пары минут достаточно, или мы ждем звонок с определенного номера, для этого надо еще и параллельно следить за поступающими звонками.

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

1580926189356.png

Дальше работаем по этой инструкции:

Первое, что нам предстоит сделать, это открыть .pcap файл, содержащий RTP пакеты, который будем декодировать. Щелкните по одному из RTP и перейдите в меню Telephony –> RTP –> Stream Analysis.

1580926216260.png

В открывшимся окне выбираем любой пакет (обратите внимание, что Wireshark будет отображать полезную информацию о потоке, включая джиттер, количество потерянных пакетов и продолжительность потока) и нажимаем “Save Payload…”

1580926235294.png

В открывшемся окне выбираем Format=.raw, Channel=forward и называем файл test-f.raw.

Если требуется декодировать два потока, то повторяем процедуру, изменив Channel=reverse и поменяв название файла.

1580926266593.png

Нажимаем на кнопку “Save payload” и далее выбираем Forma:.raw, даем название файлу и место, куда сохранить.

После того как raw файл был извлечен из RTP потока, Wireshark нам больше не понадобится.

Дальше нам необходимо конвертировать raw в pcm с помощью VoiceAge.

Открываем командную строку и в ней переходим в распакованную папку.

1580926289589.png

Синтаксис декодера для преобразования raw в pcm выглядит следующим образом.

В нашем случае декодируем два наших файла raw в pcm:

Код:
cp_g729_decoder.exe test-f.raw test-f.pcm
cp_g729_decoder.exe test-r.raw test-r.pcm
1580926384364.png

После декодирования открываем программу Audacity.

Далее Файл –> Импортировать –> Звуковой файл без заголовка (Raw) и выбираем test-f.pcm.

1580926471842.png

Далее нужно сделать так, как показано на рисунке ниже, и повторить эту процедуру со вторым нашем файлом (test-r.pcm).

1580926502697.png

После всего проделанного можно послушать оба потока и сохранить в удобном для вас формате, например mp3.

C MVTS, пока закончим, дальше я расскажу немного про РТУ и покажу как он работает, на паре примеров.

1580926527476.png

РТУ (Российский телефонный узел, на зарубежном рынке — Retail and Transit Unit) — модульный продукт, программный телефонный коммутатор или NGN-софтсвич для операторов связи и крупных компаний. Продукт был разработан и развивался c 2007 года компанией МФИ Софт. В период с 2013 по 2016 год, софтсвичи под брендом РТУ — РТУ МТТ, РТУ МОА и РТУ-комплекс развивались компанией SwitchRay (из США с офисом разработки в России), на зарубежном рынке им соответствовали продукты SR-S4000, SR-S5000 и SR-S6000.

В России с октября 2016 года развитием и поддержкой продукта под названием «Платформа РТУ» занимается компания САТЕЛ ПрО, входящая в холдинг системного интегратора САТЕЛ САТЕЛ ПрО также владеет интеллектуальными правами на товарный знак «РТУ Российский Телефонный Узел».

С точки зрения технологий, РТУ выступает в роли телефонного коммутатора и сервера IP-телефонии — контроллер зоны H.323, SIP-сервер (регистрар и B2BUA). Дополнительно, с точки зрения протокола SIP, софтсвитч РТУ может выступать прокси-сервером без сохранения состояний вызовов (call stateless, как это описано в RFC 3261, секция 16.11). Поддерживается работа с транзитным сигнальным трафиком традиционной телефонной сети — ОКС-7 (посредством шлюзов с поддержкой SIGTRAN / ISUP или SIP-T / SIP-I). Софтсвич позволяет не только объединять сети с разнородной сигнализацией (VoIP / TDM - ТФОП), но и выполнять нормализацию сигнальных протоколов, обеспечивая сопряжения с телефонным оборудованием различных производителей.

Для голосовых и видео-вызовов, реализована полноценная поддержка протоколов RTP/RTCP, опциональное и настраиваемое проксирование медиа-трафика, а также приём, анализ и передача тональных сигналов (RFC 2833, сигнальные сообщения SIP INFO и H.245 Digits, G.711-inband) и факсимильных сообщений (T.38, G.711-inband). Кроме традиционного способа передачи оцифрованного голоса, посредством технологии G.711 (PCM), в стандартной поставке, без дополнительных лицензионных соглашений и платы поддерживается работа с очень большим набором популярных узкополосных голосовых кодеков: G.729, G.723.1, Speex, iLBC, G.726, GSM-FR и высококачественных HD-кодеков, таких как различные варианты G.722 / AMR-WB или OPUS. При прохождении голосового трафика через софтсвитч (медиа-проксировании), РТУ может выполнять переконвертацию из любого поддерживаемого кодека в любой другой, то есть транскодинг. Для видео-вызовов поддерживаются распространённые кодеки H.264, H.261 и H.263.

Так выглядит РТУ в консоли:

1580926573690.png

А так из web-интерфейса:

1580927043024.png

Ниже, несколько примеров работы с РТУ:

Пример 1: Конфигурирование шлюза ОКС7.

Поскольку работа любого шлюза ОКС7 главным образом определяется соединением ISUP, конфигурирование шлюза.

ОКС7 заключается в добавлении соединения ISUP, у которого в раскрывающемся списке Национальный стандарт ISUP выбрано значение FICORA, на модуле обработки вызовов ОКС7.

1580927066321.png

Пример 2: Диагностика неполадок и устранение проблем.

Все файлы журналов хранятся в каталоге /var/log/mvts3g/.

Весь жизненный цикл подсистемы коммутации протоколируется в файл /var/log/mvts3g/phoenix.log. В случае возникновения проблем, информацию о возможных причинах можно получить из этого файла. Для протоколирования используется утилита syslog.

Для более подробной информации об утилите syslog используйте команду:

Код:
man syslogd
Файлы rtinfo содержат информацию о функционировании конкретных модулей ПКомм. Для получения файла, необходимо выполнить команду.

Код:
kill -USR1 <node_pid>, где <node_pid> – идентификатор процесса интересующего вас модуля ПКомм.
1580927137232.png

Код:
kill -USR1 3864
Полученный файл с именем rtinfo-SIGUSR1-<node name>-<node pid>.log будет содержать информацию о последних пакетах, проходивших через модуль, в двоичном представлении, а также расширенные сообщения о возникших ошибках. Запись файла также может происходить автоматически, например, при программных сбоях в модуле. В общем случае, полученный файл будет иметь наименование rtinfo-<SIGNAL>-<имя модуля>-<pid модуля>-<pid> дополнительного процесса для сброса <rtinfo>.log.

Все файлы rtinfo сохраняются в каталоге /var/log/mvts3g/. Найти интересующий вас файл можно по идентификатору процесса модуля ПКомм.

В этой статье я описал, все, что планировал, в следующем выпуске, мы рассмотрим работу с FreePBX и Asterisk. Их интеграцию в сеть VoIP оператора и способы мошенничества в сетях VoIP.

Спасибо за внимание, материал подготовлен специально для protey.net.​
 
Последнее редактирование:
Верх Низ