Поток rtp пустили кодек не поддерживается wireshark
Обновлено: 05.07.2024
На наших страницах не один раз появлялись материалы о том, как можно осуществлять аппаратный перехват трафика в сети. В тех случаях, когда перехват осуществляется с помощью SOHO-маршрутизаторов, у администратора нет возможности сохранять большие объёмы данных, либо делать перехват с большой скоростью. Казалось бы, для современных сетей это теряет актуальность, однако сегодня мы хотим представить одну ситуацию, в которой возможностей существующих продуктов будет достаточно. Речь идёт о перехвате голосового трафика для его последующего анализа и восстановления аудиоданных с помощью утилиты Wireshark.
Кроме описанных уже на нашем сайте способов аппаратного перехвата трафика существует и традиционный перехват с помощью самого же Wireshark, но для этого требуется, чтобы все необходимые потоки попадали и на компьютер со снифером. Этого можно достичь подключением всех узлов к концентратору, что, к сожалению, приведёт к падению производительности всей сети, поэтому такой вариант считаем неприемлемым. Ещё одним вариантом является возможность зеркалирования проходящих данных в специальный порт. Так, например, коммутаторы Catalyst 2950 компании Cisco Systems позволяют выделить отдельный интерфейс, в который будут перенаправляться интересующие потоки. В приведённой ниже конфигурации передаваемые через порт Fa0/5 данные будут копироваться в порт Fa0/10.
Недостатком такой схемы будет невозможность обычной работы хоста, подключённого к порту Fa0/10. Другими словами узел, подключённый к интерфейсу Fa0/10 сможет только получать зеркалированные данные, но не сможет отправлять и получать свои собственные фреймы.
В проводных маршрутизаторах Linksys RVS4000 указанная выше проблема отсутствует, однако существует другая – администратор может получить только входящие данные, но не исходящие из порта. Конечно же, можно было бы зеркалировать все порты, но использование IPSec с WAN-порта может существенно усложнить задачу, если за RVS4000 расположен только один из собеседников, и телефонный трафик шифруется при передаче через интернет с помощью IPSec. Мы обращались в Linksys с этой проблемой несколько раз, но, к сожалению, не смогли получить никакого вразумительного ответа или обещания решить указанную проблему в будущих прошивках. Настроить зеркалирование входящего потока данных можно в пункте Port Mirroring меню L2 Switch.
Маршрутизатор ASUS RX3042H позволяет отдельно указать какие потоки и из каких портов необходимо зеркалировать. Увы, среди этих портов нет WAN-интерфейса. Настройка обсуждаемой возможности в данной модели производится с помощью пункта Port Mirroring меню Router Setup.
Предположим, что каким-то образом нам всё-таки удалось перехватить заветные пакеты и сохранить их. Откроем этот файл в Wireshark. В случае, когда пакеты RTP теряются среди огромного количества других данных, можно настроить фильтр, указав rtp в соответствующем поле.
Выберем один RTP-пакет из разговора и обратимся к меню Telephony-RTP-Stream Analysis.
Изучение статистической информации о перехваченном голосовом потоке не входит в наши планы, поэтому мы сразу перейдём к сохранению аудиоданных, для чего необходимо нажать кнопку Save payload…
В окне сохранения аудио-файла требуется указать его имя и местоположение, формат, а также выбрать сохраняемый канал-направление. К сожалению, в Wireshark с сохранением аудио-файла тоже не всё хорошо, вам придётся установить самую последнюю версию (хотя бы новее версии 1.2.4, в которой исправлена ошибка 4120) для того, чтобы иметь возможность сохранять в один файл оба направления.
Кроме непосредственного сохранения перехваченного телефонного разговора может возникнуть необходимость предварительного прослушивания записи. Для решения указанной проблемы требуется обратиться к меню Telephony-VoIP Calls, в котором будут представлены все перехваченные разговоры.
Далее требуется выбрать нужный разговор и нажать кнопку Player. В появившемся окне следует нажать кнопку Decode. Опция Use RTP timestamp позволяет использовать встроенные в RTP отметки времени вместо того, чтобы ориентироваться на время прибытия пакетов. Изменение параметра Jitter buffer [ms] позволяет эмулировать воспроизведение реального голосового потока с конкретного устройства с фиксированным объёмом входного буфера.
Сразу же после декодирования появляется возможность прослушивания перехваченного потока аудио-данных с помощью кнопок Play, Pause и Stop.
Краткий обзор голосовых возможностей Wireshark на этом завершается. В заключении добавим, что по похожему принципу строятся офисные системы записи телефонных переговоров: перехватывается весь поток данных SIP или H.323 сервера, а также трафик с самих телефонных аппаратов для последующего детального анализа. Задача существенно упрощается в том случае, когда под телефонию выделяется отдельный VLAN.
В преддверии подкаста про VoIP внезапно родилась небольшая заметка.
Иногда приходится сталкиваться с проблемой установки голосового вызова. По неизвестной изначально причине, звонок просто рвётся.
Что делать, если методы влоб уже использованы?
Дамп.
А что сейчас неразрывно связано с дампами? Wireshark.
Пару лет назад у нас уже была статейка о работе в этом воистину магическом инструменте сетевика.
Не грех же и повторить?
Здесь вы увидите все звонки данного дампа.
Возьмём второй звонок в качестве примера – в нём 27 пакетов – должно быть интересно. Нажмите Flow.
Голос из дампа
Хотелось бы подслушать о чём говорят в собранном дампе телефонного звонка? Нет ничего проще… А нет, много что гораздо проще этого. Даже содержать хаски проще, чем собрать и прослушать дамп.
В общем в предыдущем окне нужно кликнуть Player.
Потом Decode.
В следующем окне вы увидите спектрограмму вызова.
Окно разделено на два трека – голоса в разных направлениях.
Выбираем оба трэка и нажимаем Play.
Хотелось бы экспортнуть аудиофайл и расшарить его с друзьями? Вам в следующую секцию.
Анализ содержимого RTP-потока
Для всего RTP_потока можно проверить важнейшие параметры – потери, задержки, вариация задержки.
Telephony→RTP→Stream Analysis.
Если таки приспичило нарушить тайну переговоров и экспортировать голос во внешний файл, следует нажать Save payload…
На следующем экране выбираете формат .au (впоследствии может быть открыт Windows Media Player или Audacity, чтобы конвертировать потом в mp3/wav). Both означает, что сохраняем оба направления голоса.
ВВЕДЕНИЕ Многие сталкивались с ситуацией, когда из логов астериска не понятно что происходит с вызовом. Или кто-то из фирмы жалуется на плохое качество связи, заикания прерывания, треск и т.д. В этой статье будет рассказано, как с помощью дампа в wireshark сохранить запись, если она была случайно утеряна с АТС, а также выяснить проблему прохождения голоса. […]
ВВЕДЕНИЕ
Многие сталкивались с ситуацией, когда из логов астериска не понятно что происходит с вызовом. Или кто-то из фирмы жалуется на плохое качество связи, заикания прерывания, треск и т.д. В этой статье будет рассказано, как с помощью дампа в wireshark сохранить запись, если она была случайно утеряна с АТС, а также выяснить проблему прохождения голоса.
Сохранение звуковых потоков RTP
Сохранить аудио поток можно, только если использовались кодеки a-law или mu-law Далее работа будет вестись с .pcap файлом, где наблюдались проблемы с голосомДля сохранения аудио потока из wireshark необходимо зайти в раздел Телефония → RTP → RTP Streams.
- Выбираем нужный нам вызов
- с помощью кнопки Find Reverse находим соответствующий ему поток
- Кнопкой Analyze показываем аналитику RTP потока данного звонка.
Далее Нажимаем кнопку «Сохранить», появится всплывающее окно, где можно сохранить Отдельно потоки (Forward – первичный канал, Reverse – вторичный канал) и весь поток (Оба потока вместе).
Анализ потока RTP
Есть 2 способа перейти в аналитику RTP потока:
- Telephony → RTP → RTP Streams и выбрать необходимый поток
- Из списка пакетов выбрать RTP пакет, затем меню Telephony → RTP → Stream Analysis
В этом меню мы можете получить задержку в мс, максимальный джиттер, минимальный джиттер, процент потери пакетов на канале.
RTP Streams
Для детального рассмотрения RTP канала выберем интересующий нас и нажмем кнопку Analyze
В этом разделе детально показывается информация по каналу:
- Максимальная задержка RTP
- Максимальный джиттер
- Минимальный джиттер
- Принятых RTP пакетов
- Ожидаемых RTP пакетов
- Потерянных пакетов
- Колличество ошибочных пакетов
- Продолжительность разговора
- Тактовая частота аудио в канале
На вкладке Graph можно посмотреть график приведенных выше данных
RTP Graph
Расчет джиттера
В Wireshark расчет джиттера ведется согласно RFC3550.
Пусть Si – это время отправки i пакета, а Ri – это расчетное время получения пакета. Тогда для двух пакетов i и j. Среднее время D(i,j) будет высчитываться по формуле:
Таким образом средний показатель джиттера ДОЛЖЕН вычислятся каждый раз, когда пришел пакет i от источника SSRC_n используя показатель D для этого пакета и пакета i-1 в порядке прибытия пакета (необязательно в строгой последовательности). Из этого вытекает следующая формула:
RTP timestamp основывается на тактовой частоте кодека. Обычно это 8000 для аудиокодеков и 90000 для видеокодеков.
Операторы Call-центра периодически сообщают о том, что собеседник "пропадает" во время разговора. В такой ситуации необходимо в первую очередь выяснить где происходит потеря голосовых rtp-пакетов. Для этого надо выгрузить файл записи из Oktell и прослушать его.
- Если в файле записи также наблюдаются "пропадание" голоса, это обозначает что в Oktell RTP-пакеты уже приходят с потерями, а значит проблему нужно искать в интернет соединении.
- Если в файле записи никаких "пропаданий" не наблюдается, но оператор плохо слышит собеседника, значит проблему нужно искать в локальной сети между телефоном и сервером Oktell.
В данной статье рассматривается проблема в интернет соединении от провайдера. Далее рассказывается методика определения количества потерь rtp пакетов с помощью программы wireshark. Wireshark - программный инструмент для анализа сетевого трафика. С его помощью можно проанализировать RTP-пакеты, просмотреть работу SIP протокола, а также многое другое.
Содержание
Шаг. Запуск Wireshark.
Запустим wireshark, чтобы он сохранил все исходящие и входящие пакеты во время разговора. В главном окне необходимо выбрать раздел Interface List и выделить необходимый интерфейс. Далее нажмите на Options.
Раздел Capture Filter - называется фильтром захвата. Wireshark будет захватывать только те пакеты, которые указаны в этом фильтре. Если нажать непосредственно на саму кнопку Capture Filter вам будут показаны различные предустановленные варианты захвата. Нам понадобиться UDP-протокол, введите его в поле ввода.
В этом окне также вы можете нажать Capture Files и выбрать в какой файл будут сохраняться результаты. Если поставить галочку Use multiple files, то можно выбрать кольцевую схему сохранения, дробление файлов (например, по 200 мегабайт) и условие окончания захвата (например, после 1 гигабайта информации). После выбранных настроек нажмите кнопку Start.
Шаг. Поиск Call-ID.
Получив сведения о том, что во время звонка были "пропадания" голоса, подождите когда он завершится и отключите Wireshark. Теперь задача заключается в том, чтобы найти этот разговор в программе. Для этого нам нужен Call-id (идентификатор коммутации). Получить его мы сможем, зная время, номер линии или зная телефон собеседника. Для этого мы воспользуемся канальным логом /server/Log/Hardware/Sip/текущая_дата/Номер_линии. Также нам понадобится лог SIP-транзакций /server/Log/Hardware/Sip/trn_текущая_дата.
Зная время и номер мы можем найти в канальном логе следующую строчку, содержащую INVITE, копируем ее с помощью Ctrl+c. Также ниже мы можем увидеть на какой порт пришел запрос.
Откройте лог trn и с помощью поиска Ctrl+F (вставьте скопированное с помощью Ctrl+v) найдите данный запрос (убедитесь, что время совпадает). Скопируйте значение Call-id.
Шаг. Поиск разговора в Wireshark.
Найдите разговор в wireshark. Для этого воспользуемся еще одним типом фильтра - фильтром отображения. Распологается он в верхней части программы, рядом находится подпись "Filter". Введите следующее (используйте ранее скопированный Call-ID)
Далее нажмите Enter или кнопку Apply. Вам выведутся все SIP-транзакции, относящиеся к выбранной коммутации. Найдите пакет INVITE, и запишите время получения\отправки пакета. Оно находится во втором столбце Time и обозначает время, которое прошло после начала захвата. Вы всегда можете поменять его во вкладке View->Time Display Format. По умолчанию, в программе используется значение Seconds since Beginning of Capture (время, которое прошло после начала захвата)
Выберите в верхнем горизонтальном меню пункт Telephony -> VoIP Calls.
Найдите нужную коммутацию в выведенном списке, нажмите кнопку Prepare Filter. Это подготовит необходимый фильтр отображения и сразу вставит его в поле ввода в wireshark (желательно, предварительно очистить поле ввода от предыдущих запросов).
После этого wireshark отфильтрует весь массив данных, согласно данному запросу.
Далее выберите RTP пакеты и найдите SSRC пакета. Скопируйте это значение, нажав правой кнопкой мыши -> copy -> value. Вам понадобится найти еще один SSRC, участвующий в коммутации. Составьте на основе этих данных (Call-ID, и двух SSRC) следующий запрос.
Сохраните выведенные (displayed) данные в отдельный файл. А затем откройте его.
Шаг. Анализ RTP-трафика
Анализ rtp пакетов. Получив только выборку, связанную с коммутацией, нажмите в верхнем меню telephony-> rtp-> show all streams. Проверьте что у вас будут две строки, а один из портов будет совпадать с тем, что мы нашли в канальном логе на шаге 1. В столбце Lost будут определены потери RTP пакетов. Потери до 5% считаются допустимыми. С помощью этой информации вы можете определить в какую сторону у вас идут потери - на входящий или исходящий трафик.
Пожалуй, нет более мощного средства для дебага проблем с RTP-трафиком, чем Wireshark. Если вы когда-либо сталкивались с проблемами типа: односторонняя слышимость, сетевые потери и так далее, то Вам будет полезна данная статья. В данной статье будет подробно рассмотрена одна из возможных проблемных ситуаций.
Содержание:
1.Тишина в RTP-канале.
Это сильно плавающая проблема, которая никогда не может быть однозначной. Практически каждый случай уникален в своём роде. Рассмотрим одну из наиболее часто встречающихся проблемных ситуаций – тишина в канале.
2.Краткий бриф.
Операторы Call-центра станции жалуются на то, что не слышно некоторых клиентов. Они несколько раз повторяют приветствие, а затем кладут трубку. Необходимо провести траблшутинг, чем мы сейчас и займёмся. Прежде чем приступить к анализу, предлагаю скачать дамп, чтобы была возможность разбирать всё на реальном примере.
3.Анализ дампа.
Если Вас интересует как отлавливать трафик в 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.Подведение итогов.
Читайте также: