RTCP (Real-time Transport Control Protocol)

Материал из Национальной библиотеки им. Н. Э. Баумана
Последнее изменение этой страницы: 17:41, 7 декабря 2017.
Real-time Transport Control Protocol
RTCPзкщещсщд.jpg
Уровень (по модели OSI): Транспортный
Семейство: стек протоколов TCP/IP (Transmission Control Protocol/Internet Protocol)
Порт/ID: нечетные номера UDP портов из диапазона 16384-32767
Спецификация: RFC 3550, RFC 2326, RFC 1889 (устаревший с момента выхода RFS в 2003 году)
Основные реализации: Linux
Основные реализации (клиенты): Проигрыватель Windows Media[1],
QuickTime[2],
Skype,
RealPlayer[3],
Медиапроигрыватель VLC,
Media Player Classic[4],
MPlayer[5],
Winamp[6] (только некоторые версии протокола),
MPEG4IP[7]
Вступил в силу с: 1998 года

RTCP (Real-Time Control Protocol)(от англ. Real-Time Transport Control Protocol — протокол управления передачей в реальном времени) — протокол управления передачей данных в реальном масштабе времени. Он выполняет функцию подсчета переданных пакетов, учета задержек при передаче, учета потерянных пакетов, jitter[8] (значения флуктуации задержек).[Источник 1] RTSP не выполняет сжатие, а также не определяет метод инкапсуляции мультимедийных данных и транспортные протоколы. Передача потоковых данных сама по себе не является частью протокола RTSP. Большинство серверов RTSP используют для этого стандартный транспортный протокол реального времени, осуществляющий передачу аудио- и видеоданных. Пример трафика:

# Real-time Transport Control Protocol (Sender Report)
    [Stream setup by H245 (frame 51)]
        [Setup frame: 51]
        [Setup Method: H245]
    10.. .... = Version: RFC 1889 Version (2)
    ..0. .... = Padding: False
    ...0 0001 = Reception report count: 1
    Packet type: Sender Report (200)
    Length: 12 (52 bytes)
    Sender SSRC: 0xbcdc0094 (3168534676)
    Timestamp, MSW: 11 (0x0000000b)
    Timestamp, LSW: 22544384 (0x01580000)
    [MSW and LSW as NTP timestamp: Feb  7, 2036 06:28:27,0052 UTC]
    RTP timestamp: 49823528
    Sender's packet count: 166
    Sender's octet count: 9960
    Source 1
        Identifier: 0xf5e33db0 (4125310384)
        SSRC contents
            Fraction lost: 0 / 256
            Cumulative number of packets lost: 0
        Extended highest sequence number received: 28620
            Sequence number cycles count: 0
            Highest sequence number received: 28620
        Interarrival jitter: 0
        Last SR timestamp: 0 (0x00000000)
        Delay since last SR timestamp: 0 (0 milliseconds)
Real-time Transport Control Protocol (Source description)
    [Stream setup by H245 (frame 51)]
        [Setup frame: 51]
        [Setup Method: H245]
    10.. .... = Version: RFC 1889 Version (2)
    ..0. .... = Padding: False
    ...0 0001 = Source count: 1
    Packet type: Source description (202)
    Length: 11 (48 bytes)
    Chunk 1, SSRC/CSRC 0xBCDC0094
        Identifier: 0xbcdc0094 (3168534676)
        SDES items
            Type: CNAME (user and domain) (1)
            Length: 14
            Text: IP200A@0.0.0.0
            Type: NAME (common name) (2)
            Length: 6
            Text: IP200A
            Type: TOOL (name/version of source app) (6)
            Length: 11
            Text: innovaphone
            Type: END (0)
[RTCP frame length check: OK - 100 bytes] ##!i##

Общая характеристика

По синтаксису и операциям протокол похож на HTTP (Hypertext Transfer Protocol). Однако между протоколами RTSP и HTTP есть ряд существенных различий. Одно из основных заключается в том, что в первом и сервер, и клиент способны генерировать запросы. Например, видеосервер может послать запрос для установки параметров воспроизведения определенного видеопотока. Также протоколом RTSP предусматривается, что управление состоянием или связью должен осуществлять сервер, тогда как HTTP вообще никакого отношения к этому не имеет. Наконец, в RTSP данные могут передаваться вне основной полосы (англ. out of band) другими протоколами, напримерRTP (Real-time Transport Protocol), что невозможно в случае HTTP. RTSP-сообщения посылаются отдельно от мультимедийного потока. Для них используется соединение по специальному порту, по умолчанию с номером 554. Запрос на сервер посылается в текстовом виде в формате: метод <абсолютный_адрес>[/медиасодержимое] <версия_протокола>. Вместе с запросом могут быть переданы дополнительные служебные поля (на новых строках запроса).

Методы протокола:
КЕСЗ.jpg
  • describe — запрос описания содержимого, например, в формате SDP (Software-defined Protection);
  • options — запрос поддерживаемых методов;
  • play — запрос начала вещания содержимого;
  • pause — запрос временной остановки вещания;
  • record — запрос на записывание содержимого сервером;
  • redirect — перенаправление на другое содержимое;
  • setup — запрос установки транспортного механизма для содержимого;
  • announce — обновление данных описания содержимого;
  • get_parameter — запрос указанных параметров у сервера;
  • set_parameter — установка параметров сервера;
  • teardown — остановка потока и освобождение ресурсов.[Источник 2]

Пример запроса: PLAY rtsp://example.com/video/test.mpg/streamid=0 RTSP/1.0 Протокол RTP переносит в своём заголовке данные, необходимые для восстановления аудиоданных или видеоизображения в приёмном узле, а также данные о типе кодирования информации (JPEG, MPEG и т. п.). В заголовке данного протокола, в частности, передаются временная метка и номер пакета. Эти параметры позволяют при минимальных задержках определить порядок и момент декодирования каждого пакета, а также интерполировать потерянные пакеты. RTP не имеет стандартного зарезервированного номера порта. Единственное ограничение состоит в том, что соединение проходит с использованием чётного номера, а следующий нечётный номер используется для связи по протоколу RTCP. Тот факт, что RTP (Real-time Transport Protocol) использует динамически назначаемые адреса портов, создаёт ему трудности для прохождения межсетевых экранов, для обхода этой проблемы, как правило, используется STUN-сервер[9]. Установление и разрыв соединения не входит в список возможностей RTP, такие действия выполняются сигнальным протоколом (например, RTSP или SIP (Session Initiation Protocol) протоколом). RTP был разработан как протокол реального времени, из конца в конец (end-to-end), для передачи потоковых данных. В протокол заложена возможность компенсации джиттера и обнаружения нарушения последовательности пакетов данных — типичных событий при передаче через IP-сети. RTP поддерживает передачу данных для нескольких адресатов через Multicast. RTP рассматривается как основной стандарт для передачи голоса и видео в IP-сетях и совместно с кодеками. Приложения, формирующие потоки реального времени, требуют своевременной доставки информации и для достижения этой цели могут допустить некоторую потерю пакетов. Например, потеря пакета в аудио-приложении может привести к доле секунды тишины, которая может быть незаметна при использовании подходящих алгоритмов скрытия ошибок. Протокол TCP (Transmission Control Protocol), хотя и стандартизирован для передачи RTP, как правило не используется в RTP-приложениях, так как надежность передачи в TCP формирует временные задержки. Вместо этого, большинство реализаций RTP базируется на UDP. Кроме этого, существуют другие спецификации для транспортных протоколов SCTP (Stream Control Transmission Protocol)t и DCCP (Datagram Congestion Control Protocol), но они мало распространены.

Компоненты протокола

Структура RTCP

Спецификация RTP описывает два подпротокола:

  1. Протокол передачи данных, RTP, который взаимодействует с передачей данных реального времени. Информация, предоставляемая посредством этого протокола, включает в себя отметку времени(для синхронизации), последовательный номер (для детектирования потери и дублирования пакетов) и формат полезной нагрузки, который определяет формат кодирования данных.
  2. Протокол контроля, RTCP, используемый для определения качества обслуживания (QOS), обратной связи и синхронизации между медиа-потоками. Занимаемая полоса пропускания RTCP мала в сравнении с RTP, обычно около 5 %.

Управляющий сигнальный протокол, такой как SIP, H.323, MGCP (Media Gateway Control Protocol) или H.248. Сигнальные протоколы управляют открытием, модификацией и закрытием RTP-сессий между устройствами и приложениями реального времени. Управляющий протокол описания медиа, такой как Session Description Protocol.

Сессии

RTP-сессия устанавливается для каждого потока мультимедиа. Сессия состоит из IP-адреса и пары портов для RTP и RTCP. Например, аудио и видео потоки будут иметь различные RTP-сессии, позволяющие приемнику для этого выделить конкретный поток. Порты, которые образуют сессию, связываются друг с другом средствами других протоколов, таких как SIP (содержащий в своих сообщениях протокол SDP (Software-defined Protection)) и RTCP (используя SDP в методе Setup). В соответствии со спецификацией, RTP не имеет стандартного зарезервированного номера порта. Единственное ограничение состоит в том, что соединение проходит с использованием чётного номера, а следующий нечётный номер используется для связи по протоколу RTCP. RTP и RTCP обычно используют непривилегированные UDP-порты (16k-32k), но могут использовать и другие протоколы, поскольку сам протокол RTP независим от транспортного уровня.[Источник 3]

Структура пакета

+ Биты 0-1 2 3 4-7 8 9-15 16-31
0 Ver. P X CC M PT Порядковый номер
32 Метка времени
64 SSRC-идентификатор
96, если CC>0 CSRC-идентификаторы
96+(CC×32),
если X=1
Заголовок расширения — определённое профилем значение Заголовок расширения — количество блоков данных по 32 бита (EHL)
96+(CC×32)+32 Заголовок расширения — блоки данных
96+(CC×32)
+X*(32+32×EHL)
 
Данные
 
если P=1 Заполнение (Padding data) L

0-1 — Ver. (2 бита) указывает версию протокола. Текущая версия — 2.
2 — P (один бит) используется в случаях, когда RTP-пакет дополняется пустыми байтами на конце.
3 — X (один бит) используется для указания расширений протокола, задействованных в пакете.
4-7 — CC (4 бита) содержит количество CSRC-идентификаторов, следующих за постоянным заголовком.
8 — M (один бит) используется на уровне приложения и определяется профилем. Если это поле установлено, то данные пакета имеют какое-то особое значение для приложения.
9-15 — PT (7 бит) указывает формат полезной нагрузки и определяет её интерпретацию приложением.
64-95 — SSRC указывает источник синхронизации.
EHL (Extension Header Length) — количество 32-битных слов в блоке данных расширения заголовка.
L — последний байт в пакете, определяющий длину области заполнения в байтах (используется для выравнивания в последнем пакете).

RTCP как инструмент администратора телефонии

Протокол RTCP используется для передачи информации о задержках и потерях медиа-пакетов, джиттер-буфере, уровне звукового сигнала. Также передаются метрика качества сигнала (Call Quality Metrics[10]) и Echo Return Loss[11](увеличение затухания обратного эха). Для устранения неполадок плохой связи потребуется Asterisk[12] старше 11 версии. Начиная с 11 версии, астериск через AMI присылает событие RTCPReceived и RTCPSent. Наиболее интересно для нас RTCPReceived, поскольку оно несет важную для нас информацию. Выглядит оно так:

#  Event: RTCPReceived
privilege: reporting,all
sequencenumber: 23177
file: manager.c
line: 1696
func: manager_default_msg_cb
channel: SIP/MainAsterisk-0000113f
channelstate: 6
channelstatedesc: Up
calleridnum: 79914099
calleridname: RC
connectedlinenum: unknown
connectedlinename: unknown
language: ru
context: TO_REGION
exten: 680000130
priority: 1
uniqueid: 1481711487.11714
linkedid: 1481711487.11714
to: Адрес астериска:12611
from: Адрес пира:14555
rtt: 0.0272
ssrc: 0x73f52b22
pt: 200(SR)
reportcount: 1
sentntp: 1481712636.17532474232832
sentrtp: 9159680
sentpackets: 57246
sentoctets: 9159360
report0sourcessrc: 0x3098e4b3
report0fractionlost: 0
report0cumulativelost: 0
report0highestsequence: 7177
report0sequencenumbercycles: 1
report0iajitter: 3
report0lsr: 2726085614
report0dlsr: 0.0590 ##!i##

Интересные для нас поля:

  1. channel — имя ассоциированного канала.
  2. from — IP удаленного пира.
  3. rtt — «задержка», точнее круговая задержка.
  4. sentpackets — колличество отправленых пакетов.
  5. sentoctets — колличество байт отправленых.
  6. report0cumulativelost — количество потерянных пакетов, с начала сессии.
Схема хождения пакетов RTCP

Рассчет R-Фактора lite

Конечно, интересно получить итоговое качество канала в виде %. Для этого есть два параметра: R-фактор и MOS. Более подробно ознакомиться сними можно здесь: https://www.tamos.ru/htmlhelp/voip-analysis/mos_rfactor.htm Общий алгоритм (lite-версия) вычисления может выглядеть так:

  1. Считаем максимальную задержку (RTT) на всех плечах и берем за аксиому, что проблемы со слышимостью начинаются при 1000 мс.
  2. Считаем процент потерь (максимальный) и берем за аксиому, что при 40 процентах качество связи не приемлемое.

Итого, вычисление R-фактора может выглядеть так: R=100-(MaxRTT/10+2*MaxLostPackets) Оценка по шкале %:
80-100% — хорошее качество звука
60-79% — удовлетворительно
менее 60% — качество звука ужасное[Источник 4]

Настройки RTCP по предпочтению

Существует четыре настройки предпочтений, влияющих на RTCP.

  • Показать информацию о настройке потока (по умолчанию включен).
  • Попробуйте расшифровать протокол rtcp за пределами беседы (по умолчанию выключен).
  • Показать относительный расчет туда и обратно (по умолчанию выключен).
  • Минимальные расчеты туда и обратно, чтобы сообщить(мс) (по умолчанию -10).[Источник 5]


Функции протокола RTCP

RTCP выполняет несколько функций:

  1. Обеспечение и контроль качества услуг и обратная связь в случае перегрузки. Так как RTCP-пакеты являются многоадресными, все участники сеанса могут оценить, насколько хороши работа и прием других участников. Сообщения отправителя позволяют получателям оценить скорость данных и качество передачи. Сообщения получателей содержат информацию о проблемах, с которыми они сталкиваются, включая утерю пакетов и избыточную неравномерность передачи. Обратная связь с получателями важна также для диагностирования ошибок при распространении. Анализируя сообщения всех участников сеанса, администратор сети может определить, касается данная проблема одного участника или носит общий характер. Если приложение-отправитель приходит к выводу, что проблема характерна для системы в целом, например, по причине отказа одного из каналов связи, то оно может увеличить степень сжатия данных за счет снижения качества или вообще отказаться от передачи видео — это позволяет передавать данные по соединению низкой емкости.
  2. Идентификация отправителя. Пакеты RTCP содержат стандартное текстовое описание отправителя. Они предоставляют больше информации об отправителе пакетов данных, чем случайным образом выбранный идентификатор источника синхронизации. Кроме того, они помогают пользователю идентифицировать потоки, относящиеся к различным сеансам.
  3. Оценка размеров сеанса и масштабирование. Для обеспечения качества услуг и обратной связи с целью управления загруженностью, а также с целью идентификации отправителя, все участники периодически посылают пакеты RTCP. Частота передачи этих пакетов снижается с ростом числа участников. При небольшом числе участников один пакет RTCP посылается максимум каждые 5 секунд. RFC-1889 описывает алгоритм, согласно которому участники ограничивают частоту RTCP-пакетов в зависимости от общего числа участников. Цель состоит в том, чтобы трафик RTCP не превышал 5% от общего трафика сеанса.[Источник 6]

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

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

5c3c1109403543e57b78508213f91e26.png
F3be7c2871072f275eda6bedf192ad61.png
Ac84724c3c7850c31f66051ee980efaa.png

Примечания

  1. Стандартный проигрыватель Windows Media (Windows Media Player, сокращённо WMP) звуковых и видеофайлов для операционных систем семейства Windows https://ru.wikipedia.org/wiki/%D0%9F%D1%80%D0%BE%D0%B8%D0%B3%D1%80%D1%8B%D0%B2%D0%B0%D1%82%D0%B5%D0%BB%D1%8C_Windows_Media
  2. Технология проигрывания QuickTime (от англ. строевой шаг) звуковых и видео-файлов Apple Inc.https://ru.wikipedia.org/wiki/QuickTime
  3. Кроссплатформенный медиапроигрыватель RealPlayer https://ru.wikipedia.org/wiki/RealPlayer
  4. Свободный видео- и аудио- проигрыватель для windows Media Player Classic (MPC) (проект guliverkli) https://ru.wikipedia.org/wiki/Media_Player_Classic
  5. Свободный и медиаплеер MPlayer https://ru.wikipedia.org/wiki/MPlayer
  6. Универсальный медиапроигрыватель компании Nullsoft Winamp https://ru.wikipedia.org/wiki/Winamp
  7. Открытый опенсорсный MPEG 4 формата https://wiki.videolan.org/MPEG4IP/
  8. Джи́ттер (англ. jitter — дрожание) или фазовое дрожание цифрового сигнала данных https://ru.wikipedia.org/wiki/%D0%94%D0%B6%D0%B8%D1%82%D1%82%D0%B5%D1%80
  9. Сетевой протокол STUN (сокр. от англ. Session Traversal Utilities for NAT, Утилиты прохождения сессий для NAT, ранее англ. Simple Traversal of UDP through NATs, Простое прохождение UDP через серверы NAT) https://ru.wikipedia.org/wiki/STUN
  10. Стандарт каачества телефонного сигнала Call Quality Metrics https://www.voip-info.org/wiki/view/Call+Quality+Metrics
  11. Echo Return Loss(увеличение затухания обратного эха) https://www.multitran.ru/c/m.exe?t=6652164_1_2&s1=Echo%20Return%20Loss%20Enhancement
  12. Решение компьютерной телефонии Asterisk https://ru.wikipedia.org/wiki/Asterisk
  13. Технология VoIP представляет все возможные варианты передачи голоса через IP https://en.wikipedia.org/wiki/Voice_over_IP

Источники

  1. REAL-TIME TRANSPORT PROTOCOL (RTP) // Privilege15. [2009-2012]. Дата обновления: 02.03.2012. URL: http://telecombook.ru/archive/voip/cisco/directory/143-rtp (дата обращения:17.11.2017)
  2. Потоковый протокол реального времени (англ. real time streaming protocol, сокр. RTSP) // Wikipedia. [2006-2017]. Дата обновления: 24.08.2015. URL: https://ru.wikipedia.org/wiki/RTSP (дата обращения:06.12.2017)
  3. Real-time Transport Protocol // Wikipedia. [2006-2017]. Дата обновления: 15.11.2014. URL: https://ru.wikipedia.org/wiki/Real-time_Transport_Protocol (дата обращения:06.12.2017)
  4. RTCP как инструмент администратора телефонии // Habrahabr. [2006-2017]. Дата обновления: 16.12.2016. URL: https://habrahabr.ru/post/317746/ (дата обращения:06.12.2017)
  5. Real-time Control Protocol (RTCP) // Wiki. [2006-2017]. Дата обновления: 08.04.2012. URL: https://wiki.wireshark.org/RTCP (дата обращения:06.12.2017)
  6. Протоколы RTP и RTCP // Opds. [2009-2012]. Дата обновления: 02.03.2012. URL: http://opds.sut.ru/old/electronic_manuals/videoconf/protocols/rtp.htm (дата обращения:06.12.2017)
  7. Wireshark — приручение акулы // Habrahabr.. [2006-2017]. Дата обновления: 02.12.2013. URL: https://habrahabr.ru/company/pentestit/blog/204274/ (дата обращения:06.12.2017)