Анализ звонков VoIP в Wireshark

    В преддверии подкаста про VoIP внезапно родилась небольшая заметка.

    Иногда приходится сталкиваться с проблемой установки голосового вызова. По неизвестной изначально причине, звонок просто рвётся.

    Что делать, если методы влоб уже использованы?

    Дамп.
    А что сейчас неразрывно связано с дампами? Wireshark.

    Пару лет назад у нас уже была статейка о работе в этом воистину магическом инструменте сетевика.
    Не грех же и повторить?


    Процесс обмена сообщениями SIP


    Самым показательным будет, конечно, обмен сигнальными сообщениями и трафиком.
    Telephony→SIP Flows

    Здесь вы увидите все звонки данного дампа.


    Возьмём второй звонок в качестве примера – в нём 27 пакетов – должно быть интересно. Нажмите Flow.



    Для данного отвергнутого и оскорблённого звонка вы можете видеть сообщение PRACK, которое отчаянно посылает SIP-сервер (10.8.156.201) голосовому шлюзу (10.12.5.6), на что последний отвечает скудным “100 Trying. Это ненормально – должно быть 200.
    Ну и наконец звонок завершается сообщением “500 Server Internal Error.

    Неплохо!

    Анализ сообщений SIP


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



    Но в действительности гораздо более удобно было бы открыть все сообщения в одном окне как текст.
    Analyze→Follow UDP Stream



    Голос из дампа


    Хотелось бы подслушать о чём говорят в собранном дампе телефонного звонка? Нет ничего проще… А нет, много что гораздо проще этого. Даже содержать хаски проще, чем собрать и прослушать дамп.
    В общем в предыдущем окне нужно кликнуть Player.
    Потом Decode.

    В следующем окне вы увидите спектрограмму вызова.

    Чёрные прямоугольники – КПВ.



    Окно разделено на два трека – голоса в разных направлениях.
    Выбираем оба трэка и нажимаем Play.
    Хотелось бы экспортнуть аудиофайл и расшарить его с друзьями? Вам в следующую секцию.

    Анализ содержимого RTP-потока


    Для всего RTP_потока можно проверить важнейшие параметры – потери, задержки, вариация задержки.
    TelephonyRTPStream Analysis.


    Если таки приспичило нарушить тайну переговоров и экспортировать голос во внешний файл, следует нажать Save payload

    На следующем экране выбираете формат .au (впоследствии может быть открыт Windows Media Player или Audacity, чтобы конвертировать потом в mp3/wav). Both означает, что сохраняем оба направления голоса.



    Ну всё – вы мастер VoIP.
    • +16
    • 26,8k
    • 9
    Поделиться публикацией
    Комментарии 9
      +1
      Хорошее начало цикла статей о поиске проблем в SIP связи, и примеры их решения. Чтобы можно было вот так вот по шагам и искать проблемные точки, и на что обращать внимание…
        0
        У нас есть один хороший, но ооочень занятой человек, который хотел бы написать про VoIP статью для цикла СДСМ.
        0
        Не все так просто с голосом. Бывает, RTP не проходит через узлы, обрабатывающие сигналку, в таком случае облом. Но обмен да, какой-то нездоровый. Интересно, что происходило на 10.12.5.6, если там есть какие-то логи.
          0
          Конкретно по этой проблеме всё упиралось в невозможность шлюза обработать сообщение Progress от АТС.
            0
            Так а как решили проблему AR1220 с Progress? Какую там опцию надо крутить?
              0
              Так вот она — пока живая.
              Воркэарунд — отключить Progress на АТС.
              Постоянное — патч или новая версия.

              Был и другой вариант, но там надо софтсвитч крутить.
                0
                Ну прогресс на АТС отключать не очень хорошо, так как таких шлюзов по стране довольно много, надо каждому Заказчику говорить, чтобы он отключал.

                Я правильно понимаю, что данная ситуация проявляется только тогда, когда АТС транзитная, то есть к ней подключается еще одна АТС, к которой уже подключены телефоны?

                Постоянное — патч или новая версия.

                Уже есть патч или прошивка? V200R007 не прокатила.

          +1
          Коллеги, и еще обращаем внимание на jitter (джиттер) норма в границах до 50 ms, после уже будут проблемы с понимание оппонента.
            0
            Я бы ещё добавил, что хорошо с этим помогает бороться jitter buffer, и иногда может помочь перебор кодеков.

          Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

          Самое читаемое