1. Введение

Одной из характерных особенностей, свойственных в настоящее время телекоммуникационным системам передачи информации, является широкое использование принципов пакетной передачи данных на основе IP технологий [1], [2], [3]. Данный вариант телекоммуникационных систем позволяет осуществлять передачу мультисервисного трафика с высокими скоростями, широко доступен и обладает всеми наиболее характерными свойствами, которые присущи пакетным системам передачи информации.Технологические тенденции таковы, что пакетная передача становится общей основой сетевой инфраструктуры как для стационарных, так и для подвижных сетей.

Взаимодействие плезиохронных (PDH) и пакетных (IP/MPLS, Ethernet) фрагментов в современных телекоммуникационных системах, как правило, строится на принципах конвергенции разнородного характера трафика и возможных вариантов инфраструктуры, в которых устаревающие, но надежные синхронные каналы связи сопрягаются с гибкими пакетными сетями

2. Методы и принципы исследования

Анализ технологий организации взаимодействия плезиохронных и пакетных компонент осуществлялся с использованием схемы организации связи, представленной на рисунке 1, приведенном далее.

[4][5][6][7][8][9][10][11][12][13][14]

Выбор оборудования, использованного в составе экспериментальной системы не случаен. Несмотря на значительные изменения в приоритетах телекоммуникаций, SSW Asterisk продолжает оставаться весьма универсальной технологической платформой. Есть достаточно оснований полагать

[7][8][15][17]

Изначально проведенный анализ всегда исходил из того, что абонент А, с номером NNNN, звонил абоненту В, с номером MMMM. При этом анализ номера NNNN для выбора направления маршрутизации вызова будем называть А-анализом, а аналогичные действия в отношении ММММ В-анализом.

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

[3]

При проведении анализа активно использовалось инструментальное программное обеспечение sngrep [18] полезный инструмент, для захвата и анализа SIP трафика, построения трейсов и фильтров SIP сообщений [16], [17]. Основной задачей данного инструмента, являлась визуализация процесса отладки SIP протокола, что позволило сделать процесс отладки проще и понятнее. Sngrep отображает потоки SIP вызовов (sip flow) прямо в консоли сервера, на котором развернут SoftSwitch. Кроме этого sngrep показывает SIP обмен сообщениями в удобной и читаемой форме. И, как показывает практика, данная утилита является одним из предпочтительных инструментов VoIP- инженеров, использующих ее для диагностики систем пакетной телефонии.

К особенностям sngrep можно отнести:

—

захват SIP пакетов от устройств или чтение из PCAP файла;

—

поддержка транспортов UDP, TCP и частично TLS;

—

возможность использования фильтрации BPF (Berkeley Packet Filter) пакетов;

—

функции сохранения перехваченных пакетов в файле PCAP.

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

[14]

3. Основные результаты

Исходя из ранее высказанных предположений основным вариантом организации взаимодействия между отдельными самостоятельными компонентами в составе пакетных сетей являются sip-транки. Форма для внесения общих настроек sip-транка для пакетного коммутатора Asterisk [8], [9] имеет следующий вид (рисунок 2):

В свою очередь регистрация на Asterisk и обработка входящего вызова осуществляется транком шлюза Alvis со следующей конфигурацией (рисунок 4):

пункт меню Registration в левом столбце на рисунке 4, указывает на необходимость регистрации транка alvis на удаленном устройствепункт меню Host определяет адрес этого устройства. В формах, приведенных на рисунках 3 и 4 явным образом присутствует возможность ограничения количества одновременных вызовов, которые могут быть одновременно направлены по данному транку. В рассматриваемом примере со стороны шлюза таких ограничений не введено (No limit), а со стороны SSW Asterisk установлено ограничение в 10 одновременных вызовов.

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

Регистрация интерфейса Asterisk осуществляется следующими средствами (рисунок 5):

Регистрация Asterisk производится на транке шлюза, конфигурация которого приведена на рисунке 6.

В этом случае пункт меню Registration в левом столбце на рисунке 6, указывает на необходимость регистрации транка на данном устройстве, а пункт меню Host попросту отсутствует.

При настройке взаимодействия sip-устройств особое внимание необходимо уделить маршрутизации входящих вызовов для Asterisk, которые определяются содержанием экранной формы FreePBX —

Маршрутизация входящих вызовов, пришедших из транка, как правило, сводится к направлению вызова либо на абонентское окончание, либо в другой транк для дальнейшей маршрутизации. Направление вызова на абонентское окончание может производиться в форме представленной на рисунке 7. В этой форме сразу после произвольного описания указывается ожидаемый номер (номер DID), а в пункте Установить направление выбирается назначение Внутренние номера, после чего выбирается одно из существующих на данный момент абонентских окончаний.

Так, в примере, приведенном на рисунке, в качестве направления для окончательной обработки входящего вызова, который предназначен для DID 333, выбрано абонентское окончание с номером 333 последняя строка на рисунке 7. При большом количестве абонентских окончаний, способных принимать входящие вызовы, приходящие с транка, число строк, в которых должны быть прописаны прямые соответствия для каждого из приходящих DID может оказаться достаточно большим, что безусловно трудоемко и затянет обработку входящего вызова. Поэтому крайне целесообразно использовать единую маску, которая устанавливает соответствие между DID входящих вызовов и номерами абонентских окончаний. Такая маска начинается с символа подчеркивание, за которым следуют постоянные цифры, входящие в ожидаемый DID и символы Х, которые обозначают, что на их месте могут присутствовать любые цифры ∈{0, ….9}. Так, в примере приведенном на рисунке 8 указана маска _71ХХ, которая показывает, что входящий DID четырехзначный и начинается с 71, т.е. ожидаемые DID ∈{7100, 7101,…, 7199}.

[6][7][8]

При обработке входящего вызова может возникнуть ситуация, когда данный вызов необходимо сразу перенаправить в другой транк. Так на рисунке 10 представлена конфигурация sip-транка Asterisk предназначенного для маршрутизации вызова в sip-транк АТС Panasonic KX DTE-100 [19].

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

Состояние транков, приведенное на рисунке 13, позволяет осуществлять маршрутизацию трафика телефонных вызовов с использованием протокола sip.

4. Обсуждение

Приведенные и описанные конфигурации sip-транков были протестированы за счет выполнения телефонных вызовов между абонентами, подключенными к различным фрагментам телекоммуникационной сети, представленной на рисунке 1, средствами пакетной сети (S1-S2), цифровыми интерфейсами классической телефонной сети сторонней АТС (Т1-Т3), а также в качестве sip-клиентов, зарегистрированных непосредственно на шлюзе Alvis.

В качестве отправной точки рассмотрим sip flow поток (сценарий, диаграмму) sip–вызова внутренним абонентом Asterisk S1 с номером А 7120, абонента В с номером 7119, использующего традиционный для PDH сетей кодек аlaw, и приведенный далее на рисунке 14.

приведен результат мониторинга трафика на сетевом интерфейсе ВМ в ситуации, когда рассматриваемый вызов является единственным вызовом, обрабатываемым ресурсами SSW Asterisk. При этом интенсивность трафика с учетом всех накладных расходов составляет ~160 кбит/сек в каждом из двух направлений. В правой части рисунка 14 приведена sip flow диаграмма данного вызова и подробно содержимое сообщения INVITE. Ранее упомянутая утилита sngrep, использованная для детализации данного вызова, позволяет получить подробное содержание всех sip сообщений, которыми обмениваются абоненты при его организации и завершении. Незначительная разница во времени для мониторинга событий на сетевом интерфейсе гипервизора и на sip flow диаграмме утилиты sngrep обусловлена рассинхронизацией временных шкал, задействованных инструментальных средств. В ходе анализа Call flow, приведенного на рисунке 14 с использованием утилиты sngrep после нажатия на клавишу F4 на экране появляется информация о варианте кодека, использованного при формировании RTP-пакетов (alaw g.711) и номерах портов со стороны абонентов А и В.

В наиболее общем случае приоритет использования аудиокодеков для Asterisk определяется в пункте главного меню FreePBX Настройки -> Установки Asterisk для sip. Так, при назначении кодека g.729 в качестве приоритетного и с учетом возможности его использования для каждого из используемых телефонных аппаратов был выполнен тестовый вызов теперь уже внутреннего sip-абонента Asterisk. Результаты мониторинга сетевого трафика ВМ и диаграмма вызова внутреннего sip-абонента SSW Asterisk с использованием кодека g.729 приведена на рисунке 15.

Рассмотрим результат мониторинга вызова абонента B (T1 — см. рисунок 1), расположенного в сети PDH — рисунок 16. В этом случае в промежутке SSW Asterisk — классическая цифровая УПАТС неотъемлемым компонентом является шлюз ALVIS-GW-2E1.

Продолжим сравнивать результаты мониторинга вызовов между внутренними абонентами SSW Asterisk с использованием кодеков различного типа, с вызовами сторонних абонентов. Рассмотрим call flow вызова абонентом с номером 5503 внутреннего абонента В SSW Asterisk с номером 7120, который представлен на рисунке 17. При его организации был использован кодек g.723.

Результат мониторинга данного вызова (рисунок 17) показывает, что при использовании кодека g.723 интенсивность трафика в каждом из направлений с учетом накладных расходов составляет порядка 40 кбит/сек, что в 1.25 раза меньше чем для кодека g.729 и в четыре раза меньше чем для кодека alaw — фактически обязательного при вызове абонентов расположенных в сети PDH.

5. Заключение

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

Анализ возможностей конвергенции в рамках комбинированной схемы организации связи (см. рисунок 1) подтверждает, что программный коммутатор (SSW) Asterisk является гибким и эффективным инструментом для реализации подобных технических решений. Примечательно, что внутренняя структура используемого шлюза Alvis [4], [5] также базируется на кастомизированной и облегченной версии Asterisk. Если в процессе эксплуатации потребуется расширение функционала, целесообразно перейти на более производительное оборудование — например, транковый IP-шлюз SMG-2016 [20].

Таким образом, применение SSW Asterisk для формирования, обработки и маршрутизации речевых сообщений открывает широкие возможности, как минимум на этапе предпроектного анализа потребностей потенциальных клиентов. При этом аппаратные ограничения, связанные с пропускной способностью сетевого интерфейса виртуальной машины, в большинстве сценариев не критичны. Даже при использовании ресурсоемкого кодека G.711 alaw (с полосой около 80 Кбит/с на канал и суммарным сетевым трафиком порядка 0,33 Мбит/с для сигнально-медийного потока) стандартный интерфейс 1 Гбит/с способен одновременно обслуживать более 3 000 абонентов. Стоит подчеркнуть, что данная оценка является консервативной, так как не учитывает возможность прямой коммутации RTP-трафика между абонентами внутри одного узла.

The additional file for this article can be found as follows: