Приветствую уважаемую аудиторию форума Codeby.net! Спустя некоторое время (месяцев 9, так навскидку), я решил все же, вернуться к теме VoIP.
Я не могу оставить ее незаконченной, к тому же, есть предпосылки, что в скором времени придется менять сферу деятельности, и нужно как можно больше успеть, Вам рассказать.
Возможно, завершительной статьи я не напишу, но буду выкладывать, все, что знаю и с чем работаю, как можно в большем объёме.
Вот, что было в предыдущих сериях:
Softswitch (программный коммутатор) — гибкий программный коммутатор, один из основных элементов сети связи следующего поколения NGN.
Softswitch — это устройство управления сетью NGN, призванное отделить функции управления соединениями от функций коммутации, способное обслуживать большое число абонентов и взаимодействовать с серверами приложений, поддерживая открытые стандарты.
Softswitch является носителем интеллектуальных возможностей IP-сети, он координирует управление обслуживанием вызовов, сигнализацию и функции, обеспечивающие установление соединения через одну или несколько сетей.
Схематично работу софтсвитча, можно представить так:
Я прекрасно понимаю, что для неподготовленного читателя, это кажется полной ахинеей… но, без сухой теории никак, хоть немного ее должно присутствовать.
Теперь, переведем это на человеческий язык.
Софтсвитч – это, один из главных функциональных модулей в структуре VoIP-оператора.
Там, инженер настраивает новые подключения (транки с новыми компаниями), контролирует емкость маршрутов, таблицу маршрутизации для клиентов, обсчет траффика и вообще биллинг, тоже ложится на плечи софтсвитча.
В нем осуществляются тонкие настройки сигнализации, передачи тех или иных сообщений по различным протоколам, так как, немаловажная способность софтсвитча, это конвертация протоколов, например H.323, SIP, SS7.
Для транзитного оператора, хороший софтсвитч – залог крепкого психического здоровья коллектива. Ну и про стабильность в работе и доходы, я думаю понятно.
Теперь, когда стало немного понятно, что это такое, можно рассмотреть работу нескольких свитчей, которые используют, крупные и средние VoIP операторы.
Начнем с SR-S4500 от SwitchRay, насколько мне известно, эта компания уже таковой не является, но их продуктом MERA VoIP Transit Softswitch (MVTS), многие, в том числе и мы, пользуются до сих пор.
SR-S4500 – система управления транзитным VoIP-трафиком. Предназначена для эффективной обработки большого количества одновременных вызовов за счет применения гибких схем авторизации и маршрутизации.
Функционально SR-S4500 состоит из двух основных подсистем:
А так выглядит интерфейс управления свитчом из консоли:
А так из web-интерфейса:
В сети есть мануал на 300 страниц, а в этой статье я ограничусь краткими вводными данными и несколькими примерами работы с MVTS.
Пример 1: Аутентификация.
Процедура аутентификации пользователя состоит из следующих этапов:
Т.е. получить несанкционированный доступ к MVTS – это даже не половина дела, нужно иметь представление о том, как она работает, чтобы в дальнейшем обеспечить себя всеми возможностями управления и связью, так, чтобы это было максимально незаметно для администраторов.
Пример 2: Подмена номера.
В MVTS есть правила трансляции (преобразования) номеров.
Придумаем номер, с которого будем звонить, возьмем какой-то беспалевный:
Заходим на MVTS в раздел аутентификации, для зарегистрированного пользователя (в данном случае, меня) и указываем этот номер в поле SRC translate:
Набираем через софтфон свой реальный номер и получаем такой результат, звонок пришел с номера, который мы указали:
Ну и немного дампа, чтобы было понятно, как это происходит:
Пример 3. Прослушивание звонков.
Для выполнения данного трюка, уже необходимо иметь консольный доступ на правах root на подсистему коммутации Traffic Switch.
Определяемся, что именно будем слушать, к примеру, определенный IP, т.к. дампить весь трафик ресурсоемко и заметно.
А декодировать мы будем только 729 кодек, усложним себе задачу, т.к. он имеет большую степень сжатия, и в Wireshark его не послушаешь, так как 711.
Выполняем следующую команду на Traffic Switch:
Ждем некоторое время, если активных звонков много – то пары минут достаточно, или мы ждем звонок с определенного номера, для этого надо еще и параллельно следить за поступающими звонками.
Выключаем дамп и копируем этот файл себе, для последующего анализа.
Дальше работаем по этой инструкции:
Первое, что нам предстоит сделать, это открыть .pcap файл, содержащий RTP пакеты, который будем декодировать. Щелкните по одному из RTP и перейдите в меню Telephony –> RTP –> Stream Analysis.
В открывшимся окне выбираем любой пакет (обратите внимание, что Wireshark будет отображать полезную информацию о потоке, включая джиттер, количество потерянных пакетов и продолжительность потока) и нажимаем “Save Payload…”
В открывшемся окне выбираем Format=.raw, Channel=forward и называем файл test-f.raw.
Если требуется декодировать два потока, то повторяем процедуру, изменив Channel=reverse и поменяв название файла.
Нажимаем на кнопку “Save payload” и далее выбираем Format:.raw, даем название файлу и место, куда сохранить.
После того как raw файл был извлечен из RTP потока, Wireshark нам больше не понадобится.
Дальше нам необходимо конвертировать raw в pcm с помощью VoiceAge.
Открываем командную строку и в ней переходим в распакованную папку.
Синтаксис декодера для преобразования raw в pcm выглядит следующим образом.
В нашем случае декодируем два наших файла raw в pcm:
После декодирования открываем программу Audacity.
Далее Файл –> Импортировать –> Звуковой файл без заголовка (Raw) и выбираем test-f.pcm.
Далее нужно сделать так, как показано на рисунке ниже, и повторить эту процедуру со вторым нашем файлом (test-r.pcm).
После всего проделанного можно послушать оба потока и сохранить в удобном для вас формате, например mp3.
C MVTS, пока закончим, дальше я расскажу немного про РТУ и покажу как он работает, на паре примеров.
РТУ (Российский телефонный узел, на зарубежном рынке — 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.
Так выглядит РТУ в консоли:
А так из web-интерфейса:
Ниже, несколько примеров работы с РТУ:
Пример 1: Конфигурирование шлюза ОКС7.
Поскольку работа любого шлюза ОКС7 главным образом определяется соединением ISUP, конфигурирование шлюза ОКС7 заключается в добавлении соединения ISUP, у которого в раскрывающемся списке Национальный стандарт ISUP выбрано значение FICORA, на модуле обработки вызовов ОКС7.
Пример 2: Диагностика неполадок и устранение проблем.
Все файлы журналов хранятся в каталоге /var/log/mvts3g/.
Весь жизненный цикл подсистемы коммутации протоколируется в файл /var/log/mvts3g/phoenix.log. В случае возникновения проблем, информацию о возможных причинах можно получить из этого файла. Для протоколирования используется утилита syslog.
Для более подробной информации об утилите syslog используйте команду:
Файлы rtinfo содержат информацию о функционировании конкретных модулей ПКомм. Для получения файла, необходимо выполнить команду.
Это идентификатор процесса интересующего вас модуля ПКомм.
Полученный файл с именем rtinfo-SIGUSR1-<node name>-<node pid>.log будет содержать информацию о последних пакетах, проходивших через модуль, в двоичном представлении, а также расширенные сообщения о возникших ошибках. Запись файла также может происходить автоматически, например, при программных сбоях в модуле. В общем случае, полученный файл будет иметь наименование rtinfo-<SIGNAL>-<имя модуля>-<pid модуля>-<pid> дополнительного процесса для сброса <rtinfo>.log.
Все файлы rtinfo сохраняются в каталоге /var/log/mvts3g/. Найти интересующий вас файл можно по идентификатору процесса модуля ПКомм.
В этой статье я описал, все, что планировал, в следующем выпуске, мы рассмотрим работу с FreePBX и Asterisk. Их интеграцию в сеть VoIP оператора и способы мошенничества в сетях VoIP.
Спасибо за внимание, специально для Codeby.net.
Я не могу оставить ее незаконченной, к тому же, есть предпосылки, что в скором времени придется менять сферу деятельности, и нужно как можно больше успеть, Вам рассказать.
Возможно, завершительной статьи я не напишу, но буду выкладывать, все, что знаю и с чем работаю, как можно в большем объёме.
Вот, что было в предыдущих сериях:
- [0] VoIP Введение. SIP, H.323, T.38
- [1] VoIP. Транспорт и кодирование голоса
- [2] VoIP. Мониторинг эффективности сети
- [3] VoIP. Система сигнализации SS7 (ОКС-7)
Softswitch (программный коммутатор) — гибкий программный коммутатор, один из основных элементов сети связи следующего поколения NGN.
Softswitch — это устройство управления сетью NGN, призванное отделить функции управления соединениями от функций коммутации, способное обслуживать большое число абонентов и взаимодействовать с серверами приложений, поддерживая открытые стандарты.
Softswitch является носителем интеллектуальных возможностей IP-сети, он координирует управление обслуживанием вызовов, сигнализацию и функции, обеспечивающие установление соединения через одну или несколько сетей.
Схематично работу софтсвитча, можно представить так:
Я прекрасно понимаю, что для неподготовленного читателя, это кажется полной ахинеей… но, без сухой теории никак, хоть немного ее должно присутствовать.
Теперь, переведем это на человеческий язык.
Софтсвитч – это, один из главных функциональных модулей в структуре VoIP-оператора.
Там, инженер настраивает новые подключения (транки с новыми компаниями), контролирует емкость маршрутов, таблицу маршрутизации для клиентов, обсчет траффика и вообще биллинг, тоже ложится на плечи софтсвитча.
В нем осуществляются тонкие настройки сигнализации, передачи тех или иных сообщений по различным протоколам, так как, немаловажная способность софтсвитча, это конвертация протоколов, например H.323, SIP, SS7.
Для транзитного оператора, хороший софтсвитч – залог крепкого психического здоровья коллектива. Ну и про стабильность в работе и доходы, я думаю понятно.
Теперь, когда стало немного понятно, что это такое, можно рассмотреть работу нескольких свитчей, которые используют, крупные и средние VoIP операторы.
Начнем с SR-S4500 от SwitchRay, насколько мне известно, эта компания уже таковой не является, но их продуктом MERA VoIP Transit Softswitch (MVTS), многие, в том числе и мы, пользуются до сих пор.
SR-S4500 – система управления транзитным VoIP-трафиком. Предназначена для эффективной обработки большого количества одновременных вызовов за счет применения гибких схем авторизации и маршрутизации.
Функционально SR-S4500 состоит из двух основных подсистем:
- Коммутации (Traffic Switch)
- Управления (Traffic Manager)
А так выглядит интерфейс управления свитчом из консоли:
А так из web-интерфейса:
В сети есть мануал на 300 страниц, а в этой статье я ограничусь краткими вводными данными и несколькими примерами работы с MVTS.
Пример 1: Аутентификация.
Процедура аутентификации пользователя состоит из следующих этапов:
- Поиск аутентификационной записи клиента. При получении запроса от подсистемы коммутации TMngr аутентифицирует пользователя. Возможна авторизация по паре логин-пароль, IP-адрес.
- Преобразование номеров. Если пользователь идентифицирован, и его учетная запись не блокирована, TMngr производит преобразование номеров вызывающего и вызываемого абонентов в соответствии с правилами преобразования, заданными в учетной записи оборудования и/или аутентификационной записи оборудования.
- Выбор тарифного плана. По аутентификационной записи инициирующего оборудования TMngr определяет тарифный план, используемый пользователем.
- Выбор плана маршрутизации. Система определяет план маршрутизации, к которой принадлежит данный пользователь. План маршрутизации – это совокупность маршрутов, в которой поиск маршрута выполняется в первую очередь. Если маршрут в плане найти не удалось, TMngr продолжает поиск вариантов среди маршрутов, не входящих в план.
- Определение уровня протоколирования. TMngr определяет уровень детализации отладочного протокола и переходит к процедуре авторизации. Неудачные попытки аутентификации записываются в CDR.
Т.е. получить несанкционированный доступ к MVTS – это даже не половина дела, нужно иметь представление о том, как она работает, чтобы в дальнейшем обеспечить себя всеми возможностями управления и связью, так, чтобы это было максимально незаметно для администраторов.
Пример 2: Подмена номера.
В MVTS есть правила трансляции (преобразования) номеров.
- In SRC преобразование – правило преобразования номера вызывающего абонента для случаев, когда устройство выступает в качестве инициатора.
- In DST преобразование – правило преобразования номера вызываемого абонента для случаев, когда устройство выступает в качестве инициатора вызова.
- Out SRC преобразование – правило преобразования номера вызывающего абонента для случаев, когда устройство выступает в качестве терминирующего.
- Out DST преобразование – правило преобразования номера вызываемого абонента для случаев, когда устройство выступает в качестве терминирующего.
Придумаем номер, с которого будем звонить, возьмем какой-то беспалевный:
Заходим на MVTS в раздел аутентификации, для зарегистрированного пользователя (в данном случае, меня) и указываем этот номер в поле SRC translate:
Набираем через софтфон свой реальный номер и получаем такой результат, звонок пришел с номера, который мы указали:
Ну и немного дампа, чтобы было понятно, как это происходит:
Пример 3. Прослушивание звонков.
Для выполнения данного трюка, уже необходимо иметь консольный доступ на правах root на подсистему коммутации Traffic Switch.
Определяемся, что именно будем слушать, к примеру, определенный IP, т.к. дампить весь трафик ресурсоемко и заметно.
А декодировать мы будем только 729 кодек, усложним себе задачу, т.к. он имеет большую степень сжатия, и в Wireshark его не послушаешь, так как 711.
Выполняем следующую команду на Traffic Switch:
Код:
tcpdump -i any -s 65535 -w capital.pcap host 194.58.156.11Ждем некоторое время, если активных звонков много – то пары минут достаточно, или мы ждем звонок с определенного номера, для этого надо еще и параллельно следить за поступающими звонками.
Выключаем дамп и копируем этот файл себе, для последующего анализа.
Дальше работаем по этой инструкции:
Первое, что нам предстоит сделать, это открыть .pcap файл, содержащий RTP пакеты, который будем декодировать. Щелкните по одному из RTP и перейдите в меню Telephony –> RTP –> Stream Analysis.
В открывшимся окне выбираем любой пакет (обратите внимание, что Wireshark будет отображать полезную информацию о потоке, включая джиттер, количество потерянных пакетов и продолжительность потока) и нажимаем “Save Payload…”
В открывшемся окне выбираем Format=.raw, Channel=forward и называем файл test-f.raw.
Если требуется декодировать два потока, то повторяем процедуру, изменив Channel=reverse и поменяв название файла.
Нажимаем на кнопку “Save payload” и далее выбираем Format:.raw, даем название файлу и место, куда сохранить.
После того как raw файл был извлечен из RTP потока, Wireshark нам больше не понадобится.
Дальше нам необходимо конвертировать raw в pcm с помощью VoiceAge.
Открываем командную строку и в ней переходим в распакованную папку.
Синтаксис декодера для преобразования raw в pcm выглядит следующим образом.
В нашем случае декодируем два наших файла raw в pcm:
Код:
cp_g729_decoder.exe test-f.raw test-f.pcm
cp_g729_decoder.exe test-r.raw test-r.pcmПосле декодирования открываем программу Audacity.
Далее Файл –> Импортировать –> Звуковой файл без заголовка (Raw) и выбираем test-f.pcm.
Далее нужно сделать так, как показано на рисунке ниже, и повторить эту процедуру со вторым нашем файлом (test-r.pcm).
После всего проделанного можно послушать оба потока и сохранить в удобном для вас формате, например mp3.
C MVTS, пока закончим, дальше я расскажу немного про РТУ и покажу как он работает, на паре примеров.
РТУ (Российский телефонный узел, на зарубежном рынке — 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.
Так выглядит РТУ в консоли:
А так из web-интерфейса:
Ниже, несколько примеров работы с РТУ:
Пример 1: Конфигурирование шлюза ОКС7.
Поскольку работа любого шлюза ОКС7 главным образом определяется соединением ISUP, конфигурирование шлюза ОКС7 заключается в добавлении соединения ISUP, у которого в раскрывающемся списке Национальный стандарт ISUP выбрано значение FICORA, на модуле обработки вызовов ОКС7.
Пример 2: Диагностика неполадок и устранение проблем.
Все файлы журналов хранятся в каталоге /var/log/mvts3g/.
Весь жизненный цикл подсистемы коммутации протоколируется в файл /var/log/mvts3g/phoenix.log. В случае возникновения проблем, информацию о возможных причинах можно получить из этого файла. Для протоколирования используется утилита syslog.
Для более подробной информации об утилите syslog используйте команду:
Код:
man syslogdФайлы rtinfo содержат информацию о функционировании конкретных модулей ПКомм. Для получения файла, необходимо выполнить команду.
Код:
kill -USR1 <node_pid>, где <node_pid>
Код:
kill -USR1 3864Полученный файл с именем rtinfo-SIGUSR1-<node name>-<node pid>.log будет содержать информацию о последних пакетах, проходивших через модуль, в двоичном представлении, а также расширенные сообщения о возникших ошибках. Запись файла также может происходить автоматически, например, при программных сбоях в модуле. В общем случае, полученный файл будет иметь наименование rtinfo-<SIGNAL>-<имя модуля>-<pid модуля>-<pid> дополнительного процесса для сброса <rtinfo>.log.
Все файлы rtinfo сохраняются в каталоге /var/log/mvts3g/. Найти интересующий вас файл можно по идентификатору процесса модуля ПКомм.
В этой статье я описал, все, что планировал, в следующем выпуске, мы рассмотрим работу с FreePBX и Asterisk. Их интеграцию в сеть VoIP оператора и способы мошенничества в сетях VoIP.
Спасибо за внимание, специально для Codeby.net.
Последнее редактирование:
