Качество обслуживания (QoS) : Протокол RTP

Дешифруйте поток RTP для анализа потери пакета в Wireshark для голосовых вызовов и видеовызовов

5 апреля 2016 - Машинный перевод
Другие версии: PDF-версия:pdf | Английский (23 апреля 2015) | Отзыв

Содержание
          Введение
          

Проблема
          Решение

Введение

Этот документ описывает процесс того, как дешифровать Потоковую передачу в режиме реального времени (RTP) поток для анализа потери пакета в Wireshark для голосовых вызовов и видеовызовов. Можно использовать фильтры Wireshark для анализа одновременных захватов пакета, взятых в или близко к источнику и назначению вызова. Это полезно, когда необходимо устранить неполадки аудио и проблем качества видеосигнала, когда подозреваются сетевые потери.

Внесенный Shyam Venkatesh, специалистом службы технической поддержки Cisco.

Проблема

Данный пример использует этот поток вызовов:

IP-телефон (центральный siteA)> 2960 Маршрутизаторов глобальной сети Router> switch> (Центральный узел)> IPWAN> Маршрутизатор глобальной сети (сайт B)> Router> 2960> IP-телефон B

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

Посмотрите потерянные пакеты получателя в статистике потоковой передачи IP-телефона ответвления:

Решение

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

IP addressing scheme
Central IP phone: 192.168.10.146
Central Gateway: 192.168.10.253
Central WAN router: 192.168.10.254
Branch WAN router: 192.168.206.210
Branch Gateway: 192.168.206.253
Branch IP phone: 192.168.207.231

Захваты пакета взяты на Центральном Маршрутизаторе глобальной сети и Маршрутизаторе глобальной сети Ответвления, и глобальная сеть (WAN) отбрасывает эти пакеты. Внимание на поток RTP от центрального IP-телефона (192.168.10.146) для ветвления IP-телефона (192.168.207.231). Если глобальная сеть (WAN) отбрасывает пакеты на потоке от центрального Маршрутизатора глобальной сети для ветвления Маршрутизатора глобальной сети, этот поток пропускает пакеты на Маршрутизаторе глобальной сети ответвления. Используйте параметры фильтрации в wireshark для изоляции проблемы:

  1. Откройте перехват в wireshark.

  2. Используйте фильтр ip.src == 192.168.10.146 && ip.dst == 192.168.207.231. Это отфильтровывает все потоки UDP от центрального IP-телефона для ветвления IP-телефона.

  3. Выполните анализ стороны ответвления перехватывают только, но обращают внимание, что необходимо выполнить эти шаги для центрального перехвата также.

  4. В этом снимке экрана поток UDP фильтрован между источником и IP - адресами назначения и содержит два потока UDP (дифференцируемый Номерами порта UDP). Это - видеовызов, таким образом, существует два потока: аудио и видео. В данном примере эти два потока:

    • Поток 1: исходный порт UDP: 20560, порт назначения: 20800

    • Поток 2: исходный порт UDP: 20561, порт назначения: 20801



  5. Выберите пакет от одного из потоков и щелкните правой кнопкой мыши по пакету.

  6. Выберите Decode As... и введите RTP.

  7. Нажмите кнопку Принять и Ok для декодирования потока как RTP.



    Вас оставляют с одним потоком, декодируемым как RTP и другой как недекодируемый UDP.



  8. Выберите пакет от недекодируемого потока и декодируйте его как RTP. Это декодирует и аудио и видеопотки в RTP.

    Примечание: Аудиопоток находится в формате кодека G.722, и тип полезных данных Dynamic-RTP-97 указывает на видео поток RTP.





    Проблема теперь только с качеством видеосигнала. Внимание на видео поток RTP и использование Номера порта UDP для этого потока для отфильтровывания других потоков.

  9. Просмотрите номер порта путем выбора одного из пакетов, который отображает сведения о портах UDP на нижней области в утилите Wireshark. В предыдущем снимке экрана выбран один из пакетов от видеопотка, и вы видите порт src (20568) и порт Dst (20808) информация о нижней области.

    Совет: Используйте этот фильтр: (ip.src == 192.168.10.146 && ip.dst == 192.168.207.231) && (udp.port eq 20568 и udp.port eq 20808). Вы будете только видеть видео поток RTP, показанный в этом снимке экрана.



    Примечание: Запишите первое и последние порядковые номера RTP для этого потока.







    Первый порядковый номер RTP 45514, последнее 50449 для отфильтрованного видео потока RTP.

  10. Удостоверьтесь, что первое и последние пакеты порядкового номера RTP присутствуют и в captures.for примере, центральном и в перехватах ответвления), и обратите внимание, что SSRC для поток был бы тем же на обоих перехваты.
  11. Совершенствуйте фильтр для соответствия только с пакетами между первым и последними потоками RTP. 

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

    Примечание: Возможно, что узел филиала мог бы запустить некоторые порядковые номера после 45514.



  12. Выберите запуск и закончите порядковый номер. Эти пакеты присутствуют в обоих перехваты и совершенствовали фильтр для показа только тех пакетов между запуском и конечными порядковыми номерами RTP. Фильтр для этого:

    (ip.src==192.168.10.146 && ip.dst==192.168.207.231) && (udp.port eq 20568 
    and udp.port eq 20808) && ( rtp.seq>=44514 && rtp.seq<=50449 )


    When captures are simultaneously taken, no packets are missed at the start or end on both captures. If you see that one of the captures does not include a few packets at the start/end, use the first sequence number or the last sequence number in the capture missed in both packets to refine the filter for both the captures. Observe the packets that captured at both points between the same sequence numbers (RTP sequence number range).

    When you apply the filter, you see this at the central site and the branch site:

    Central Site :



    Branch site :



    Note the filtered packet count at the bottom pane on the Wireshark utility on both captures. The Displayed count indicates the number of packets matching the desired filter criteria.

    The central site has 4,936 packets that match the desired filter criteria between the start (45514) and end (50449) RTP sequence numbers while at the branch site there are only 4,737 packets. This indicates a loss of 199 packets. Note that these 199 packets match the "Rcvr Lost Pkts" count of 199 which was seen in the streaming statistics of the branch side IP phone shown at the start of this document.

    This confirms that all the Rcvr Lost Packets were actually network losses dropped across the WAN. This is how the point of packet loss in the network is isolated while audio/video quality issues are handled involving suspected network drops.

Связанные обсуждения сообщества поддержки Cisco

В рамках сообщества поддержки Cisco можно задавать и отвечать на вопросы, обмениваться рекомендациями и совместно работать со своими коллегами.


Document ID: 117881