Отладка исходящего джиттера¶
Исходящий джиттер - с каким джиттером аудио-поток дошел до пира.
Этот параметр извлекается из пакетов RTCP ReceiverReport, которые приходят от пира.
То есть вычисление параметра джиттера производится пиром, а Smartswitch только отображает значение, которое ему передал пир.
Увидеть его можно в RTP статистике.
Джиттер меньше 50мс обычно незаметен для пользователей.
Если джиттер значительный (выше 50мс), то следует выполнить отладку:
1. Проверить, с каким джиттером получен входящий аудио-поток в связанном CDR.
Если в входящем аудио-потоке связанного CDR от пира А джиттер был незначительный, а в исходящем на пира Б - значительный, то следовательно джиттер появился на пути Smartswitch -> пир Б.
Если же и в связанном CDR от пира А джиттер значительный, то аудио-поток приходит уже с джиттером от пира А.
Внимание! В случае, если установлена опция быстрый прокси для RTP и настройки позволяют быстрое проксирование (нет Перекодировки кодеков, Записи разговора, итп) - Smartswitch не будет выполнять вычисление джиттера для входящего потока (для экономии ресурсов CPU), входящий джиттер в RTP статистике будет постоянно 0.
Таким образом, для проверки входящего джиттера потребуется либо отключить опцию быстрый прокси, либо снять pcap дамп через Захват звонков и посмотреть джиттер входящего потока через Wireshark.
2. Джиттер мог быть внесен на пути следования по сети от Smartswitch к конечному устройству.
В этом случае следует проверить загрузку сетевого оборудования на площадке, где установлен Smartswitch, если это возможно.
Также попробуйте совершить звонок со своего ПК и проверить джиттер.
Если и на вашем звонке будет джиттер - то нехватка сетевых ресурсов на площадке весьма вероятна.
Также эту теорию можно проверить, посмотрев статистику по звонкам от других пиров.
Если у всех одинаковая проблема - то нехватка сетевых ресурсов на площадке весьма вероятна.
3. Джиттер мог быть внесен оборудованием пира, которое отправляет некорректные данные внутри пакетов RTCP Sender/Receiver Report.
Это иногда бывает при использовании недорогих VoIP телефонов или малораспространенных софтфонов.
Эту теорию можно проверить, посмотрев статистику по звонкам от других пиров.
Также эту теорию можно проверить при звонке с вашего ПК как описано в п.2.
4. Джиттер мог возникнуть в результате того, что один из дата-центров на пути следования RTP пакета устанавливает поле DSCP в 0.
DSCP - это поле в IP заголовке, которое по умолчанию Smartswitch для медиа-пакетов устанавливает в значение Expedited Forwarding (ускоренная маршрутизация).
Установка этого поля сигнализирует сетевому оборудованию, что данные пакеты содержат данные, чувствительные к задержкам, и что их нужно доставить в первую очередь.
Однако поскольку эти пакеты становятся более приоритетными для сетевого оборудования дата-центра, чем пакеты от других клиентов этого дата-центра без установленного поля DSCP, то возможны жалобы от других клиентов при нехватке пропускной способности, потому иногда дата-центры сбрасывают значение DSCP в 0 в пакетах от вас, чтоб вы не могли контролировать приоритетность и не могли вытеснять других клиентов.
Вследствие этого, медиа-пакеты обрабатываются с тем же приоритетом, что и обычный трафик, на всем пути следования пакета к конечному узлу, вытесняясь в узких каналах цепочки другим трафиком, и возникает джиттер.
Для проверки этой теории, захватите pcap на сервере Smartswitch и на стороне партнера.
В полученных 2 дампах сравните значения DSCP медиа-пакетов.
Если вы увидите, что в pcap дампе, снятом на сервере, DSCP = Expedited Forwarding, а в pcap дампе, снятом на сервере вашего партнера, DSCP отличается, то значит имеет место описанная проблема.
5. Джиттер мог быть внесен самим Smartswitch.
Это можно проверить, включив Захват звонков, и посмотрев показатель джиттера в исходящем RTP потоке с помошью Wireshark.
Smartswitch может вносить джиттер, если имеет место нехватка CPU для нормального функционирования всех включенных функций.
Попробуйте отключить функции, которые потребляют много ресурсов.
Например:
Если эти функции очень нужны и отключить их не представляется возможным, то следует увеличить аппаратные возможности системы.
Обратитесь к технической поддержке Streamco за более подробной консультацией по этому вопросу.
Отладочная таблица¶
Точный диагноз можно выполнить, включив Захват звонков, и посмотрев показатели джиттера в исходящем/входящем RTP потоке с помощью Wireshark.
См. таблицу ниже по интерпретации результатов.
Внимание! Под входящим и исходящим потоком в таблице ниже имеется в виду один и тот же RTP поток, но захваченный на разных точках системы.
Например, рассмотрим путь следования RTP потока от оригинатора к терминатору (аудио поток от звонящего абонента к набранному)
Путь следования, а соответственно и точки захвата, RTP потока:
1. Входящий поток от оригинатора на сетевой карте сервера: захватывается в pcap, и может быть проверен Wireshark.
2. Входящий поток от оригинатора в CDR оригинатора -> RTP статистика -> входящий джиттер.
3. Исходящий поток на терминатора на сетевой карте сервера: захватывается в pcap, и может быть проверен Wireshark.
4. То, как аудиопоток был доставлен терминатору в CDR терминатора -> RTP статистика -> исходящий джиттер.
Таким образом, у нас есть 4 точки захвата данных.
Сравнивая значения из этих точек, можно более точно определить источник проблем.
| джиттер входящего потока в Wireshark | джиттер входящего потока в RTP статистике | джиттер исходящего потока в Wireshark | джиттер исходящего потока в RTP статистике | диагноз |
| незначительный | незначительный | незначительный | значительный | джиттер вносится уже после того как пакеты покинули сервер с Smartswitch (см. п.1 - п.4) |
| незначительный | любой | значительный | любой | джиттер вносится Smartswitch (см. п.5) |
| значительный | любой | любой | любой | поток приходит к Smartswitch уже с джиттером |