Контроль за состоянием сигнальной сети VoIP является одним из важных условий, позволяющих UCaaS-провайдеру предоставлять клиентам гарантированный уровень качества таких услуг как аудио- и видеовызовы, приём и передача факсов. Обычно такой контроль осуществляется с помощью различных систем мониторинга, сбора и анализа трафика, анализа CDR. Некоторые из параметров сигнальной сети достаточно трудно, а часто и невозможно оценить указанными способами.
Возможным источником важной информации о состоянии сигнальной сети VoIP является SIP-сервер приложений (SIP AS) — один из основных элементов, участвующих в обработке вызовов в VoIP-сети. Лог-файлы SIP AS позволяют, среди прочего, оценить следующие параметры сигнальной сети VoIP:
- Длина SIP-диалогов
- Промежуток времени между посылкой запроса и получением финального ответа (request-response time, RRT) для различных типов SIP-запросов
- Количество повторных передач сообщений (retransmits, RTR) для разных типов SIP-сообщений
Важны не только значения указанных параметров, но и распределение этих параметров, а также их изменения во времени. Информация об изменении значений параметров во времени позволяет прогнозировать возможные проблемы в VoIP-сети. Эта информация также может послужить одним из источников данных для различных алгоритмов машинного обучения (machine learning, ML), которые позволят спрогнозировать изменения параметров не только в зависимости от времени, но и от других факторов.
В зависимости от сигнальной нагрузки SIP AS может сгенерировать лог-файлы в текстовом формате объёмом до нескольких десятков Гб в сутки. Анализ текстовых файлов такого объёма — это ресурсоёмкая задача. Как один из возможных вариантов, для такого анализа могут быть использованы различные средства языка Python. Например, библиотека Pandas предоставляет достаточно удобные инструменты для обработки и анализа различных данных, в частности, датафреймы (data frames, DF). Код, использованный в данной статье, доступен здесь.
Предлагается следующая последовательность шагов для анализа лог-файлов SIP AS:
- Открыть лог-файл на чтение. Если SIP AS создал несколько лог-файлов, то их следует открывать в том же порядке, в котором они были созданы
- Считывать данные построчно. Это необходимо для экономии оперативной памяти в случае работы с файлами объёмом в единицы-десятки Гб
- Выделить сообщения протокола SIP, расположенные между определёнными последовательностями символов – разделителями (delimiters)
- Создать список, состоящий из словарей. Каждый из словарей, в свою очередь, состоит из временнОй метки (key) и собственно SIP-сообщения (value) в форме списка
- Сохранить этот список на диск или сетевое хранилище в виде, например, pickle-файла. Этот файл в дальнейшем будет использован для создания различных DF
- Создать DF из сохранённого pickle-файла, содержащий необходимую для дальнейшего анализа информацию (SIP DF)
В данном конкретном случае был создан SIP DF, содержащий следующие колонки:
- Timestamp — временнАя метка, добавляемая SIP AS
- Call-ID – Call-ID SIP-диалога
- CSeq_num, CSeq_meth – данные из SIP-заголовка ‘CSeq’
- Direction – сообщение принято (Rx<-) или отправлено (Tx->), добавляется SIP AS
- SIP method – SIP-метод из SIP Request-Line
- Src Dst IP – IP-адрес, с которого отправлено или принято сообщение
Рис. 1. Параметры SIP DF, полученного из pickle-файла размером около 3 Гб
Рис. 2. Содержимое SIP DF
Имея подобный SIP DF, можно оценить различные параметры сигнальной VoIP-сети. Все приведённые ниже примеры взяты с действующей VoIP-сети. IP-адреса и прочие данные, могущие дать какую-либо информацию об указанной сети, изменены.
1. Длина SIP-диалога
Рис. 3. DF и длина SIP-диалога
Для каждого случая длинного SIP-диалога по значению Call-ID можно найти вызов и далее, по текстовым логам, проанализировать сценарий этого вызова. Несмотря на достаточно малое число вызовов, для которых длина SIP-диалога составляет десятки-сотни сообщений, сценарии этих вызовов необходимо исследовать. Исследование таких вызовов позволило выявить следующие источники длинных SIP-диалогов:
- Передача нескольких десятков групп определённой структуры, состоящих из DTMF-символов, после установления голосовой сессии. Это сценарий голосового вызова, в ходе которого происходит аутентификация, авторизация и обмен информацией между вызывающим и вызываемым абонентами.
- Видеовызовы, в ходе которых отмечено очень большое число Full Intra-Frame Request-запросов (FIR). Это, в частности, указывает на проблему ПО телефонов или на потери RTP-пакетов в ходе видеовызовов
Длинные SIP-диалоги также могут появляться из-за неисправности VoIP-оборудования, попыток подбора PIN-кодов через IVR-меню (посылка большого числа DTMF-последовательностей). В любом случае необходимо следить за количеством длинных SIP-диалогов, т. к. с ростом числа таких диалогов может появляться бесполезная дополнительная сигнальная нагрузка на элементы VoIP-сети.
2. RRT
Вычисляется отдельно для принятых и отправленных INFO- и INVITE-запросов. Следует учитывать, что при обработке большого числа вызовов могут встречаться одинаковые значения CSeq для разных диалогов. Можно предположить, что распределение величин RRT должно примерно совпадать для отправленных запросов, абсолютные значения должны отличаться в силу разного размера и содержимого INFO- и INVITE-запросов и, как следствие, разного времени обработки этих запросов элементами сети.
Рис. 3. RRT для INFO-запросов, принятых SIP AS
Рост значений RRT в данном случае указывает на возможные проблемы с виртуализацией, увеличением нагрузки на SIP AS. Call-ID и CSeq_num позволяют исследовать значения RRT для каждого конкретного случая.
Рис. 4. RRT для INFO-запросов, отправленных SIP AS. RRT на графике ограничено значением 500 мс, которое является значением по умолчанию для таймера SIP T1.
Рис. 5. RRT для INVITE-запросов, отправленных SIP AS. Как и предполагалось, распределение примерно совпадает с таким же для INFO-запросов.
3. RTR
Важный параметр, характеризующий состояние сигнальной VoIP-сети.
Рис. 6. Процент повторной передачи INFO- и INVITE-запросов соответственно. Учитываются RTR, случившиеся один и более раз.
В дополнение к описанным примерам, с помощью DF могут быть получены и другие данные, например:
- Корректность распределения нагрузки SIP AS для исходящих сообщений. Для этого необходимо посчитать количество отправленных сообщений (Tx) на разные IP-адреса (SrcDst IP) с помощью groupby().count() — по аналогии с функцией retransmits_counter_tx(). Разница в количествах сообщений более 15-20% говорит о некорректном разделении нагрузки
- Количество неуспешных переводов вызова (call transfers). Для этого можно сформировать отдельный DF, содержащий только REFER-диалоги, а также необходимые заголовки и поля из сообщений этих диалогов
- Зависимость параметров от времени. Если собирать среднее значение одного из параметров, например, RRT, в течение нескольких месяцев, то на основании полученных данных можно построить временной ряд (time series, TS). Применив различные библиотеки для анализа TS, например, statsmodels, можно определить тренд, сезонность (trend, seasonality) и другие параметры TS. Данные этого прогноза могут быть использованы для корректировки архитектуры VoIP-сети
Заключение
Текстовые лог-файлы SIP AS — это важный источник информации о текущем состоянии VoIP-сети. Кроме того, данные, полученные после соответствующей обработки этой информации, могут быть использованы при прогнозировании состояния VoIP-сети, в частности, методами ML.
