Real-time transport protocol

RTCP Control Packet Types (PT)

Expert(s)

Steve Casner, Magnus Westerlund

Reference

Note

The RFC "RTP: A Transport Protocol for Real-Time Applications"
 specifies an initial set of "control packet types" for
RTCP.  This list maintains and extends that list.
    

Available Formats

Описание протокола

RTP был разработан как протокол реального времени, из конца в конец (end-to-end), для передачи потоковых данных. В протокол заложена возможность компенсации джиттера и обнаружения нарушения последовательности пакетов данных — типичных событий при передаче через IP-сети. RTP поддерживает передачу данных для нескольких адресатов через Multicast. RTP рассматривается как основной стандарт для передачи голоса и видео в IP-сетях и совместно с кодеками.

Приложения, формирующие потоки реального времени, требуют своевременной доставки информации и для достижения этой цели могут допустить некоторую потерю пакетов. Например, потеря пакета в аудио-приложении может привести к доле секунды тишины, которая может быть незаметна при использовании подходящих алгоритмов скрытия ошибок. Протокол TCP, хотя и стандартизирован для передачи RTP, как правило не используется в RTP-приложениях, так как надежность передачи в TCP формирует временные задержки. Вместо этого, большинство реализаций RTP базируется на UDP. Кроме этого, существуют другие спецификации для транспортных протоколов SCTP и DCCP, но они мало распространены.

TCP

TCP — это протокол с гарантией доставки и сохранения порядка следования пакетов. В исходном варианте протокола передающая сторона отправляет порцию данных и ждет подтверждения их получения от приемной стороны. Такая система сильно замедляет передачу данных, поэтому в более поздних версиях протокола они стали передаваться сериями, а приемное устройство — отправлять кумулятивные подтверждения о получении всей серии или ее части, если какие-то пакеты были потеряны.

Во времена расцвета RTMP/Flash, 12—15 лет назад, технологии на базе HTTP вообще не могли обеспечить полноценный стриминг, а только загрузку видео последовательными фрагментами с началом проигрывания после получения определенного количества фрагментов. Сегодняшние протоколы на базе HTTP, по сути, работают по тому же принципу, с той лишь разницей, что после множества оптимизаций это практически перестало быть заметно конечным пользователям. В хорошо отлаженных коммерческих сетях, использующих CDN в комбинации с небольшими кластерами доступа, видео доставляется с минимальными колебаниями качества. Поэтому современные технологии доставки видео на базе HTTP — HLS и MPEG-DASH — имеют полное право считаться стриминговыми.

Оптимизация проводилась по нескольким направлениям. Первое — сокращение цикла отправка/подтверждение за счет появления и оптимизации режима скользящего окна в протоколе TCP. Второе — введение адаптивной передачи. На уровне HTTP адаптивность реализована добавлением в клиентские устройства постоянного мониторинга качества видеопотока и возможности на лету запрашивать другой профиль видео. Этому способствует и совершенствование систем компрессии, в том числе появление новых ABR-кодеров, в которых профили видео формируются не по формальным параметрам потока, а по уровню качества картинки.

Последнее направление оптимизации, на котором сейчас сфокусированы усилия разработчиков, — сокращение времени от запроса услуги до начала воспроизведения видео. Этот вопрос сейчас решается в рамках стандарта CMAF, процесс подробно описан в статье
. Цель разработчиков — довести стартовую задержку до 3 секунд, что сопоставимо с задержкой в вещательных сетях. Сегодня она может составлять 40 секунд и более. Отметим, что проблема связана именно со спецификой стандарта HTTP. В RTMP/Flash стартовая задержка на уровне вещательных сетей обеспечивалась без дополнительных усилий.

Активные методы

Перезапросы пакетов и ключевых кадров

1. Перезапрос пакета (NACK — negative acknowledgement). Потеряли пакет – попросили его ещё раз – получили – декодировали.
2. Запрос ключевого кадра (FIR — full intra-frame request). Если декодер понимает, что всё пошло плохо и достаточно давно, можно сразу просить ключевой кадр, который сотрёт всю историю и можно будет начать декодирование с чистого листа.
3. Запрос обновления определённой области кадра. Декодер может сообщить енкодеру, что какой-то пакет потерян. На основе этой информации енкодер вычисляет, как далеко распространилась ошибка по кадру и обновляет тем или иным способом повреждённый регион. Как это реализовать понятно только теоретически, практических реализаций я не встречал.

• RFC 2032. На самом деле это стандарт упаковки потока кодека H.261 в RTP пакеты. Но этим стандартом предусмотрены и перезапросы первых двух типов. Этот стандарт устарел и заменён на RFC 4587, в котором предлагается такие пакеты игнорировать.
• RFC 4585. Действующий стандарт. Предусматривает все три варианта и даже больше. По на практике используется именно NACK и FIR.
• RFC 5104. Тоже действующий стандарт. Частично дублирует RFC 4585 (но не совместим с ним) плюс куча другой фунциональности.

Пример зависания видео после 3х секундного разрыва связи при наивной реализации перезапросов.TCP

Техническая информация

RIP — так называемый протокол дистанционно-векторной маршрутизации, который оперирует транзитными участками (хоп, hop) в качестве метрики маршрутизации. Максимальное количество транзитных участков, разрешенное в RIP — 15 (метрика 16 означает «бесконечно большую метрику»). Каждый RIP-маршрутизатор по умолчанию вещает в сеть свою полную таблицу маршрутизации раз в 30 секунд, довольно сильно нагружая низкоскоростные линии связи. RIP работает в сетях TCP/IP, используя UDP порт 520.

В современных сетевых средах RIP — не самое лучшее решение для выбора в качестве протокола маршрутизации, так как его возможности уступают более современным протоколам, таким как EIGRP, OSPF. Ограничение на 15 транзитных участков не дает применять его в больших сетях. Преимущество этого протокола — простота конфигурирования.

Формат RIP пакета

• Command — команда, определяет назначение датаграммы (1 — request; 2 — response)
• Version — номер версии, в зависимости от версии, определяется формат пакета
• Routing Domain — идентификатор RIP-системы, к которой принадлежит данное сообщение; часто — номер автономной системы. Используется, когда к одному физическому каналу подключены маршрутизаторы из нескольких автономных систем, в каждой автономной системе поддерживается своя таблица маршрутов. Поскольку сообщения RIP рассылаются всем маршрутизаторам, подключенным к сети, требуется различать сообщения, относящиеся к «своей» и «чужой» автономным системам. Поле использовалось короткое время в версии протокола RIP-2. В протоколе RIP-1 и в текущей версии RIP-2 не используется.
• RIP Entry (RTE) — запись маршрутной информации RIP. RIP пакет может содержать от 1 до 25 записей RIP Entry.

Формат RIP Entry для протокола RIP-1

Поле Version = 1.

• Address family identifier (AFI) — тип адреса, обычно поддерживается только запись AF_INET, которое равно 2 (т. е. используется для протокола IP).
• Must be zero — должно быть нулём.
• IPv4 address — IP адрес места назначения (хост или сеть)
• Metric — метрика маршрута

Формат RIP Entry для протокола RIP-2

Поле Version = 2.

• Address Family Identifier (AFI) — тип адреса, обычно поддерживается только запись AF_INET, которое равно 2 (т.е. используется для протокола IP).
• Route Tag (RT) — тег маршрута. Предназначен для разделения «внутренних» маршрутов от «внешних», взятых, например, из другого IGP или EGP.
• IP Address — IP адрес места назначения.
• Subnet Mask — маска подсети
• Next Hop — следующий хоп. Содержит IP адрес маршрутизатора к месту назначения. Значение 0.0.0.0 — хопом к месту назначения является отправитель пакета. Необходимо, если протокол RIP не может быть запущен на всех маршрутизаторах.
• Metric — метрика маршрута.

Аутентификация

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

Сравнение IAX2 и SIP

Полоса пропускания (bandwidth)

IAX использует меньшую полосу пропускания, т.к. осуществляется передача бинарных данных, в отличии от пересылки текстовых данных, используемых в SIP. Кроме того, IAX сжимает и заголовки сообщений. Преимущество IAX выражается от 2,4к для одного звонка до трёхкратного превышения количества одновременных звонков на 1 мегабит при использовании G.729, в сравнении с SIP.

NAT

Основная статья: NAT (Network Address Translation)

В IAX служебные данные и сам разговор передаются вместе, что позволяет избежать проблем с NAT, присущих SIP. Для установки соединения и передачи данных в SIP используются различные протоколы, почему и возникают проблемы с NAT. Аудио поток должен проходить через фаерволы и роутеры. Для Устранения проблем с NAT, SIP протоколу обычно приходится пользоваться STUN сервером.

Стандартизация и использование

SIP — это протокол, который давно стандартизирован IETF, широко используется производителями программного обеспечения и оборудования. IAX же ещё только ожидается стандартизация. Этим обусловлена причина, почему он пока не нашёл широкого распространения.

Используемые порты

IAX использует только один порт (UDP 4569) для установки соединения и передачи данных всех звонков. Для осуществления этого, IAX использует так называемые транки (trunking system). Вся служебная информация, а так же аудиопотоки всех звонков передаются через один User Datagram Protocol (UDP). SIP, наоборот, использует один TCP порт (5060) для соединения и 2 RTP порта для каждого аудио соединения (всего как минимум 3 порта). Например, если у вас есть 100 одновременных звонков, для их осуществления мы должны использовать 200 RTP портов и один порт для соединения (5060). IAX использует только один порт для всего (UDP 4569).

Когда аудио поток использует сервер

В SIP установка соединения осуществляется всегда через сервер, а вот аудиопоток (RTP flow) может идти от пользователя к пользователю, минуя сервер. В IAX соединение и передача данных всегда происходят через IAX сервер. Это увеличивает требования к Internet каналам для IAX серверов во время множества одновременных звонков.

Описание профиля и формата трафика

Как отмечалось выше (см. ), для полного описания протокола RTP для
конкретного приложения требуются дополнительные документы двух типов: описание
профиля и формата трафика.

RTP может использоваться для многих классов приложений со значительно различающимися
требованиями. Гибкость адаптации к этим требованиям обеспечивается использованием
различных профилей (см. ). Обычно приложение
использует только один профиль, и никакой явной индикации того, какой профиль
находится в данный момент в использовании, — нет.

Дополнительный документ второго типа — спецификация формата трафика — определяет,
как конкретный вид трафика (например, видеосигнал, кодированный согласно H.261)
должен передаваться в соответствии с RTP. Один и тот же формат трафика может
использоваться для множества профилей и может, следовательно, быть определен
независимо от профиля. Документы профиля отвечают лишь за соответствие этого
формата и значения PT.

В описании профиля могут определяться следующие пункты, но этот список не является
исчерпывающим.

Заголовок пакета данных RTP. Октет в заголовке пакета данных RTP, который
содержит бит маркера и поле типа трафика, может быть переопределен в соответствии
с профилем для удовлетворения различным требованиям, например, для обеспечения
большего или меньшего количества битов маркера (раздел 3.3).

Типы трафика. Профиль обычно определяет множество форматов трафика
(например, алгоритмов кодирования мультимедийных данных) и заданное по умолчанию
статическое соответствие этих форматов и значений РТ. Некоторые из форматов
трафика могут быть определены ссылкой на отдельные описания формата трафика.
Для каждого определенного типа трафика профиль должен задать необходимую для
использования тактовую частоту временной метки RTP (раздел 3.1).

Дополнения заголовка пакета данных RTP. Если требуются некоторые дополнительные
функциональные возможности в рамках класса приложений профиля, не зависящих
от типа трафика, то к фиксированному заголовку пакета данных RTP могут быть
присоединены дополнительные поля.

Расширения заголовка пакета данных RTP. Должно быть определено содержимое
первых 16 битов структуры расширения заголовка пакета данных RTP, если использование
этого механизма позволено профилем.

Типы пакетов RTCP. Могут быть определены (и зарегистрированы IANA)
новые, зависящие от класса приложения типы пакетов RTCP.

Интервал отчетности RTCP. Профиль должен определить величины, используемые
при вычислении интервала отчетности RTCP: часть полосы пропускания сеанса RTCP,
минимальный интервал отчетности и разделение полосы пропускания между отправителями
и получателями.

Расширение пакета SR/RR. Если имеется дополнительная информация об
отправителе или получателе, которая должна регулярно передаваться, то для пакетов
SR и RR протокола RTCP может быть определен раздел расширения.

Использование SDES. Профиль может определять относительные приоритеты
для пунктов SDES протокола RTCP, которые будут переданы или исключены (см. ); альтернативный синтаксис или семантику для пункта CNAME (раздел 4.4.1);
формат пункта LOC (раздел 4.4.5); семантику и использование пункта NOTE (раздел
4.4.7) и новые пункты SDES, которые должны регистрироваться в IANA.

Безопасность. Профиль может определять, какие услуги по обеспечению
безопасности и алгоритмы нужно использовать приложениям, и может обеспечивать
управление их использованием (раздел 7).

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

Протокол нижележащего уровня. Для передачи пакетов RTP может требоваться
использование конкретной нижележащей сети или протокола транспортного уровня.

Транспортное соответствие. Может быть определено иное, чем указанное
в разделе 8 стандартное соответствие RTP и RTCP адресам транспортного уровня,
например, портам UDP.

Инкапсуляция. Формирование пакетов RTP может быть определено так, чтобы
позволить передавать множество информационных пакетов RTP в одном блоке данных
протокола нижележащего уровня (раздел 8).

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

Протокол RIST

Через год после появления Альянса SRT компании, имеющие корпоративные решения в области IP-доставки, создали еще один альянс для разработки более продвинутой технологии. Новый протокол получил название Reliable Internet Stream Transport (RIST), как и сам альянс. Он организован в рамках консорциума Video Services Forum, занимающегося разработкой и стандартизацией сетевых технологий для передачи медиа. К слову, в этот альянс в качестве ключевого участника
и Haivision.

RIST задуман как многопрофильный стандарт, однако пока выпущен только базовый профиль. По функциональности он уступает SRT. В частности, не поддерживает мультиплексирование каналов на одном UDP-порту и имеет только один режим установления соединения (Push). В результате для передачи каждого потока приходится открывать по UDP-порту на приемнике и на передатчике. Кроме того, в отличие от SRT, базовый профиль RIST не поддерживает шифрование и файловую передачу. В то же время в протокол заложена передача множественных каналов. Она реализована в двух режимах. Один поддерживает разбиение логического канала на несколько физических, отправляемых разными маршрутами. Второй обеспечивает резервирование потоков и бесшовное переключение с одного на другой.

А схожи SRT и базовая версия RIST в том, что оба используют ARQ с настраиваемым соотношением между задержкой и защищенностью. Кроме того, они практически одинаковы в плане мониторинга потоков и сбора статистики. Однако у RIST есть все шансы опередить конкурента. Уже подготовлен основной профиль протокола, и живую демонстрацию его работы можно было увидеть на IBC-2019. При разработке профиля учитывались разные сценарии его применения, в том числе дистанционные интервью, сбор новостей из удаленных точек, передача видео в облако и передача мультикастовых трансляций.

Перечислим основные усовершенствования, появившиеся в этом профиле. Во-первых, добавилась поддержка мультиплексирования потоков на одном UDP-порту. Во-вторых, реализовано GRE-туннелированние (Generic Routing Encapsulation). GRE-шлюзы могут использоваться для организации двухстороннего обмена между RIST-устройствами базовой версии, умеющими взаимодействовать только в режиме Push. Шлюзы также могут применяться для передачи управляющих данных, например SNMP, для туннелирования мультикастового трафика и решения других задач. В-третьих, добавлены механизмы скремблирования, авторизации и аутентификации. Для скремблирования и авторизации выбран протокол DTLS, другими словами, версия TLS для UDP-протокола. Она адаптирована для приложений, чувствительных к временным задержкам. В рамках TLS могут использоваться разные алгоритмы шифрования, но в качестве основных для RIST предложены AES 128/256 бит.

Из других улучшений отметим оптимизацию транспортной полосы за счет исключения нулевых пакетов. Они не несут информации, но нужны для сохранения синхронизации. Поэтому перед передачей они заменяются метками и восстанавливаются на приемной стороне. Кроме того, добавлена возможность расширить заголовок RTP для увеличения цикла нумерации пакетов. Эта нумерация используется в ARQ при запросе потерянных пакетов, а при высокой скорости передачи стандартного цикла может не хватить.

Перспективы сосуществования SRT и RIST пока непонятны. С учетом того, что Haivision оказался одним из основных участников RIST, не исключен вариант слияния протоколов. Но может быть, каждый из них найдет свою нишу. Ясно одно — транспортные технологии для передачи видео через IP-сети с негарантированным качеством будут и дальше активно развиваться, а их доля во всех сегментах передачи медиа будет расти.

Использование технологии Wareshark для протокола RTCP

Также поддержка протокола RTCP, также как и других голосовых пакетов SIP, SDP, RTSP, H.323, SRTP и др., предусматривается технологией Wireshark (ранее — Ethereal), которая представляет собой программу-анализатор трафика для компьютерных сетей Ethernet и некоторых других. Wireshark умеет перехватывать и сохранять голосовой трафик для дальнейшего прослушивания.Этот функционал как нельзя лучше подойдет для траблшутинга в сетях Voice over IP. Траблшутинг представляет собой поиск и исправление багов и логов в какой-то инфраструктуре.
Меню Statistics — Flow Graph покажет наглядную картину, как происходил весь обмен пакетами.
А вообще целое меню Telephony отведено для работы с голосовым трафиком. Например, Telephony – RTP – Show All Streams покажет подробно, что происходило с RTP, в частности jitter (параметр, который, вероятно, самый важный в голосе), что иногда сразу скажет о наличии проблем.Нажав на кнопку “Analyze”, можно открыть окно RTP stream Analysis – и, выбрав там поток, можно его даже проиграть, используя кнопку player.Сначала отроется окно проигрывателя, в котором вначале нужно установить подходящее значение jitter и использовать кнопку decode.

Резюме файла RTP

Расширение файла RTP включает в себя два основных типов файлов и его можно открыть с помощью Gromacs (разработчик — KTH Royal Institute of Technology). В общей сложности с этим форматом связано всего пять программное (-ых) обеспечение (-я). Чаще всего они имеют тип формата Gromacs Residue Topology Parameter File.
Расширение файла RTP указано преимущественно в категории Data Files. В менее распространенных приложениях они также могут откноситься к Uncommon Files.

Файлы с расширением RTP были идентифицированы на настольных компьютерах (и некоторых мобильных устройствах). Они полностью или частично поддерживаются Windows, Linux и Mac.

Рейтинг популярности файлов RTP составляет «Низкий», что означает, что данные файлы встречаются редко.

Команда AuditEndpoint (AUEP)

Агент вызова может использовать команду AuditEndpoint для определения состояния конечной точки. Обычно это происходит при инициализации агента вызова при поиске состояния всех конечных точек, которыми он управляет. Этот запрос содержит параметр идентификатор конечной точки (Endpoint ID), который идентифицирует контролируемую конечную точку, и параметр запрошенная информация (Requested Information), содержащий следующие внутренние параметры:

• Список конечных точек (endpoint list). Идентифицирует контролируемую конечную точку. Чтобы указать все конечные точки, соответствующие определенной схеме, можно использовать шаблон.
• Уведомляемый объект (Notified Entity— N). Объект, уведомляемый об активных запросах.
• Запрошенные события (Requested Events — R). Список событий, запрошенных в настоящий момент.
• Цифровая карта (digit map). Текущая цифровая карта конечной точки.
• Требуемые сигналы (Signal Requests — S). Список сигналов, которые в настоящее время применяются на конечной точке.
• Идентификатор запроса (Request Identifier— X). Идентификатор последней команды Notif icationRequest, полученной конечной точкой.
• Идентификаторы соединения (Connection Identifiers — I). Список текущих соединений, поддерживаемых определенной конечной точки.
• События поиска (Detect Events — Т). Список событий, которые в настоящее время обнаруживаются в режиме карантина.
• Параметры локального соединения (Local Connection Options — L). Список всех текущих значений, например период пакетирования и кодек. Этот параметр можно использовать для запроса пакета текущих событий, которые поддерживаются определенной конечной точкой.

Ответ шлюза для команды AUEP будет содержать информацию о каждом из элементов, для которых был запрошен контроль информации.

Используем TShark для анализа RTP-пакетов

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

В этой статье мы продолжаем изучать передачу звукового сигнала с помощью RTP-протокола. Сначала разделим наше тестовое приложение на передатчик и приемник и научимся исследовать RTP-поток с помощью анализатора сетевого трафика.

Итак, чтобы нам более ясно было видно какие элементы программы отвечают за передачу RTP, а какие за прием, мы разделяем наш файл mstest6.c на две самостоятельные программы передатчика и приемника, общие функции, которые используют и тот и другой мы вынесем в третий файл, который назовем mstest_common.c, он будет подключаться передатчиком и приемником с помощью директивы include:

Теперь файл обособленного передатчика:

И наконец, файл приемника:

Компилируем, передатчик и приемник, затем запускаем каждый в своей консоли. Далее должно работать как прежде — только ввод чисел от 1 до 6 мы должны делать в консоли передатчика, а отклик на них должен появляться в консоли приемника. В динамике должны прослушиваться тоны. Если все так, то между приемником и передатчиком у нас установлена связь — происходит непрерывная передача RTP-пакетов от передатчика к приемнику.

Теперь самое время установить анализатор трафика, для этого мы установим консольную версию отличной программы Wireshark — она называется TShark. Я выбрал TShark для дальнейшего изложения для того, чтобы облегчить описание управления программой. С Wireshark мне бы потребовалось море скриншотов, которые могут быстро устареть с выпуском новой версии Wireshark.

Если вы умеете пользоваться Wireshark, то можете его использовать для изучения наших примеров. Но и в этом случае я вам рекомендую освоить TShark, так как вам это поможет автоматизировать тестирование ваших VoIP приложений, а также выполнять захват удаленно .

Устанавливаем TShark командой:

Традиционно, проверяем результат установки запрашивая версию программы:

Если получен адекватный ответ продолжаем далее.

Поскольку наши пакеты ходят пока только внутри компьютера, мы можем сказать tshark показывать только такие пакеты. Для этого нужно выбрать захват пакетов с интерфейса loopback (обратная петля), передав TShark опцию -i lo:

В консоль сразу начнут сыпаться сообщения о пакетах отправляемых нашим передатчиком (непрерывно, независимо от того, нажимали мы кнопку на пульте или нет). Возможно, на вашем компьютере есть программы которые тоже отправляют пакеты по локальной петле, в этом случае мы получим смесь наших и чужих пакетов. Чтобы быть уверенными, что в списке мы видим только пакеты отправленные нашим пультом, мы добавим фильтр по номеру порта. Нажатием Ctrl-C останавливаем анализатор и вводим фильтр на номер порта который использует на пульт как порт назначения для своей передачи (8010): -f «udp port 8010». Теперь наша командная строка будет выглядеть так:

В консоли появиться вывод следующего вида (первые 10 строк):

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

Номер события.
Время его возникновения.
IP-адрес источника пакета и IP-адрес приемника пакета.
Протокол пакета, показан как UDP, поскольку RTP-пакеты передаются как полезная нагрузка внутри UDP-пакетов.
Размер пакета в байтах.
Номер порта источника пакета и номер порта приемника пакета.
Размер полезной нагрузки пакета, отсюда можно сделать вывод, что наш передатчик формирует RTP-пакеты размером 172 байта, который, как утка в сундуке, находится внутри UDP-пакета размером 214 байт.
Теперь пришло время заглянуть внутрь UDP-пакетов, для этого мы запустим TShark с дополненным набором ключей:

В результате, вывод программы обогатится — к каждому событию добавится расшифровка внутреннего содержимого пакета, который его вызвал. Чтобы лучше рассмотреть данные вывода вы можете либо остановить TShark нажатием Ctrl-C, либо продублировать его вывод в файл, добавив к команде запуска конвейер к программе tee с указанием имени файла, tee <имя_файла>:

Теперь посмотрим на то, что мы получили в файле, вот первый пакет из него:

Следующую статью мы посвятим разбору информации, которая содержится в этом листинге и неизбежно поговорим о внутренней структуре RTP-пакета.