Wireshark — анализ RTP трафика. Тишина в RTP канале.

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

Содержание:

1.Тишина в RTP-канале.

2.Краткий бриф.

3.Анализ дампа.

4.Подведение итогов.

1.Тишина в RTP-канале.

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

2.Краткий бриф.

Операторы Call-центра станции жалуются на то, что не слышно некоторых клиентов. Они несколько раз повторяют приветствие, а затем кладут трубку. Необходимо провести траблшутинг, чем мы сейчас и займёмся. Прежде чем приступить к анализу, предлагаю скачать дамп, чтобы была возможность разбирать всё на реальном примере.

3.Анализ дампа.

1.Открываем дамп.

Если Вас интересует как отлавливать трафик в Wireshark в реальном времени, ознакомьтесь со статьёй на нашем сайте.

2.Идём в Telephony -> VoIP Calls.

 
Если Вам необходимо получить конкретный вызов или же их пул, ознакомьтесь со статьёй на нашем сайте.

Как Вы уже заметили, в данном дампе всего 1 вызов, но нам больше и не нужно, почему – поймёте дальше. С виду, звонок выглядит корректно, но информации недостаточно, чтобы произвести оценку ситуации, мы, ведь, знаем, что проблема точно есть, посему будем копать глубже.

Снизу в центре необходимо нажать кнопку Flow Sequence (секвенция потока).

После перехода мы увидим следующую картину:

Судя по данной Call-Flow диаграмме, вызов так же выглядит корректным, потому что от начала до конца секвенции, мы наблюдаем всё то же самое, что и при любом другом корректном вызове: инвайт от провайдера, подтверждение со стороны нашего сервера (200 ОК), 2 потока RTP (к нам и от нас), завершение вызова (BYE) с нашей стороны (ведь, это оператор Call-центра трубку положил), ответ от оператора связи (200 ОК). Всё замечательно, но где же тогда проблема? Давайте копнём глубже.

Закроем Call-Flow. Ткнув на кнопку Play Streams, перейдём к прослушиванию потоков.

 
Может возникнуть не очень приятная ситуация, если RTP зашифрован. В такой ситуации рекомендую ознакомиться со статьёй на нашем сайте.

Перейдя к окну прослушивания, увидим следующее:

Кажется, что всё сразу стало понятным, правда? Но не будем делать поспешных выводов и прослушаем вызов от начала и до конца. Для этого необходимо нажать Play на панели проигрывания, а так же выбрать устройство вывода звука (Output Device).

После прослушивания дампа становится понятно, что в канале клиента есть RTP пакеты, несущие в себе тишину. Теперь мы знаем, что проблема в голосовом потоке со стороны оператора связи, а не нашего сервера. Давайте в этом убедимся:

Не путайте это понятие с не установленным соединением. Если бы клиентский поток не был бы установлен, то линия клиента бы вовсе не отобразилась. Т.е. тишина не является отсутствием RTP-пакетов.

Давайте проведём дополнительный сбор информации для вынесения окончательного вердикта. Продолжать сбор информации мы будем во вкладке Telephony -> RTP -> RTP Streams.

После перехода мы увидим следующее окно:

Данное окно предназначено для вывода более детальной информации о голосовых потоках открытого дампа.

Теперь нам необходимо сравнить 2 потока как Forward и Reverse. Для этого выделяем вначале первый поток, затем второй, нажимаем Analyze.

Увидим следующий вывод:

Здесь нас интересует конкретный блок вывода, в котором мы производим сравнение двух потоков:

Здесь и подтверждается наше предположение. Мы видим, что RTP пакеты присутствуют с обеих сторон. RTP Packets – количество RTP-пакетов. Expected – ожидаемое количество пакетов. Lost – потери пакетов в процентном и количественном соотношении. Фактически, потеря 0,12% пакетов со стороны оператора не могла повлиять на то, что в канале клиента не осталось ничего, кроме тишины.

4.Подведение итогов.

Таким образом, мы получаем, что тишина образовалась в канале клиента из-за проблем на стороне оператора связи. Для выяснения данного вопроса необходимо направить этот дамп оператору связи, что я и сделал. Надеюсь, данная статья поможет Вам быть ближе к пониманию процесса траблшутинга на своей виртуальной IP-АТС.