Протокол управления RTCP (RTP Control Protocol)

Протокол RTCP употребляется для текущего контроля RTP-сессии и сбора статистической инфы по качеству передачиинформации (qualityoftransmission) в сети. Это осуществляется засчет организации оборотной связи меж источником и получателями инфы. Также протокол RTCP поддерживает устойчивый идентификатор источника данных RTP на транспортномуровне, именуемый «каноническим именем» (CNAME –

canonicalname). Потому что идентификатор SSRC Протокол управления RTCP (RTP Control Protocol) может изменяться,если найден конфликт либо перезапущена программка, то получателям для отслеживания каждого участника требуется каноническое имя CNAME. Получатели также требуют CNAME для отображения огромного количества потоков инфы от данного участникана огромное количество связанных сеансов RTP.

К примеру, для синхронизации звукового и видеосигнала. Каждый участник телеконференциипри посылке управляющих пакетов всем остальным Протокол управления RTCP (RTP Control Protocol) участникам,может независимо от других оценивать общее число участников.

Это число применяется при вычислении частоты отправления па-

кетов RTCP.

Пакеты RTCP передаются совместно с потоком данных RTP лишь на существенно наименьшей скорости. Обычно под RTCP трафикотводится до 5% всего спектра для передачи потоковых данных.

Даже в самых стремительных Протокол управления RTCP (RTP Control Protocol) сессиях пакеты RTCP передаются не почаще,

чем раз в 5 секунд.

Существует разные типы пакетов RTCP несущие разнуюинформацию:

-SR (SenderReports – рапорт источника) – содержит статистическую информацию отправителя и информацию получателей;

-RR (Receiver Reports – рапорт приемника) – содержит статистическую информацию получателей;

-SDES (SourceDEScription) – содержит описание различныхпараметров источника, включая CNAME (имя юзера);

-BYE (запрос разъединения) – это последний Протокол управления RTCP (RTP Control Protocol) пакет, которыйпосылает участник конференции, когда желает её покинуть;

-APP (application – приложение) – содержание приложения, которое определяется самим приложением.

В один пакет транспортного уровня укладывается, обычно, несколько пакетов RTCP. При всем этом общий заголовок отсутствует. К примеру, обычный пакет транспортного уровня, посылаемый активным участником сессии, содержит последующие пакетыRTCP: пакет SR (содержит Протокол управления RTCP (RTP Control Protocol) информацию об отправленный пакетах), пакет RR (содержит информацию о принятых пакетах), пакетSDES (содержит описание источника).

На рис. 1.10 представлен формат рапорта приемника RR. В поле V (2 бит) указывается версия протокола RTCP, в поле Р (1 бит)помещается признак наличия наполнения (Padding), в поле RC (5бит) записывается число блоков Протокол управления RTCP (RTP Control Protocol) источников, представленных вданном рапорте. В поле тип нагрузки (8 бит) записан PT=201, чтопоказывает тип пакета RR. В поле длина (16 бит) записываетсядлина пакета (Length) в 32-битных словах кроме заго-

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

Набросок 1.10 Формат пакета рапорта приемника

На рис. 1.11 представлен формат блока Протокол управления RTCP (RTP Control Protocol) отчётных данных (Report

block).

Набросок 1.11 Формат блока отчётных данных поисточнику (Report Block)

В сообщениях SR и RR каждый источник описывается блоком(рис. 1.11), содержащим последующие данные:

-SSRC – идентификатор источника синхронизации (идентификатор источника);

-FractionLost(8 бит) – толика потерянных пакетов данного источника относительно общего числа пакетов;

-Packet Lost(24 бит) – общее число потерянных пакетов данного источника Протокол управления RTCP (RTP Control Protocol);

-Highest Sequence Number – наибольший номер пакета, приобретенного от данного источника;

-LSR – старшая часть последнего значения метки времени NTP(Network Time Protocol) TimeStamp, приобретенного от данногоисточника;

-DLSR – задержка времени от получения последнего сообщенияот данного источника до формирования данного блока.

Если SR (SenderReport) посылается источником, который работает, как микшер (т.е. сам Протокол управления RTCP (RTP Control Protocol) получает информацию из несколькихисточников и соединяет воединыжды ее в один поток), то пакет SR содержитследующие части (рис. 1.12):

-Header(заголовок) его структура показана более тщательно нарис. 1.13.

Набросок 1.12 Формирование общего рапорта отправителя для микшера

Дальше следует информация о приеме данных от источников иданные, которые употребляются для формирования передаваемогопотока. Каждый таковой источник описывается блоком Протокол управления RTCP (RTP Control Protocol) данных. Каждый блок начинается с SCRC источника.

Набросок 1.13. Формат пакета отчётных данных отправителя(SenderReport)

На рис. 1.13 представлен формат пакета SR (SenderReport). Онсодержит заголовок пакета, статистическую информацию отправителя и собранную статистическую информацию получателя (илигруппы получателей, если это конференция).

Разглядим предназначение полей этого пакета:

-V, P – имеют тоже значение, что Протокол управления RTCP (RTP Control Protocol) и в пакетах протокола RTP(рис. 1.10);

-RC (ReportCount) – показывает на число рапортов получателей,которые включены в данный пакет;

-PT – для пакета рапорта отправителя равно SR = 200;

-Length – определяет общую длина данного пакета SR, невключая заголовок и наполнение;

-NTP timestamp(64 бита) – значение абсолютной метки временив формате протокола NTP. Значение этого Протокол управления RTCP (RTP Control Protocol) поля совместно с временной меткой в пакете отправителя может быть использованодля расчета RTT;

-RTP timestamp – содержит метку относительного времени, сгенерированную протоколом RTP;

-Sender packet count– содержит число отправленных пакетов поначалу текущей сессии;

-Senderoctetcount– содержит общее число октетов, отправленных с начала сессии;

-SSRC 1 – содержит идентификатор 1-го источника синхронизации;

-Reportblock 1 – информация Протокол управления RTCP (RTP Control Protocol) блока данных по 1-му источнику;

-SSRC 2 – содержит идентификатор 2-го источника синхронизации;

-Reportblock 2 – информация блока данных по 2-му источнику.

За счет пересылки рапортов RR и SR осуществляется обратнаясвязь меж получателем и источником. На базе статистическихданных этих рапортов отправитель (источник) может приниматьрешение об изменении текущих характеристик сессии. К примеру,запросить огромную Протокол управления RTCP (RTP Control Protocol) полосу пропускания.

Набросок 1.14. Формат пакета SDES (SourceDescription)

Пакет описание источника SDES (рис. 1.14) начинается с заголовка, в каком представлена версия протокола V=2, биты наполнения P, значение числа блоков источников (chunk) RC в данномрапорте, идентификатор типа пакета SDES = 202, общая длина пакета. Дальше следуют блоки описания источников.

Набросок 1.15 Формат блока описания Протокол управления RTCP (RTP Control Protocol) источника

Блок описания источника Source Descriptor Block (рис. 1.15)начинается с SSRC источника. Дальше следуют элементы описанияисточников (SDES Item). Каждый блок находится на границедвойного слова. Каждый элемент описания источника начинаетсяс заголовка, состоящего из типа TYPE (1 б) (см. табл. 1.3), длины в б Length (1 б), дальше следует текст элемента. Длинаотносится к тексту.

Обычно CNAME Протокол управления RTCP (RTP Control Protocol) имеет последующий формат: user@host, где user

– имя юзера, host – идентификатор хоста (доменное имяили Айпишник в стандартном ASCII-представлении). Если по любым причинам имя юзера оказывается труднодоступным, тоиспользуется CNAME в формате host.

Пример:dwarf@sleepy.beauty.com либо dwarf@192.166.148.9. CNAME явля-

ется единственным неотклонимым элементом описания источника.

Таблица 1.3. Типы кодов описаний источника

Набросок Протокол управления RTCP (RTP Control Protocol) 1.16. Формат пакета окончания сессии BYE

Пакет BYE (рис. 1.16) передается в этом случае, если один изучастников покидает сессию. Если пакет BYE получен смесителем, он передает этот пакет с идентификатором SSRC либо CSRCбез конфигураций. Если смеситель отключается сам, то он должен отправить пакет BYE, перечислив все источники, вносившие вклад впоток, с Протокол управления RTCP (RTP Control Protocol) которым он работал, также собственный идентификатор SSRC.

Пакет BYE может также содержать 8-битовое число октетов, закоторым следует текст соответственной длины, поясняющийпричину отключения. К примеру, «камера не работает» («cameramalfunction»).

В текущее время разработана расширенная версия протоколаRTCP XR, описанная в RFC 3611. В ней увеличено число характеристик, по которым собираются Протокол управления RTCP (RTP Control Protocol) статистические данные.

Наиболеезначимыми дополнительными параметрами являются:

- толика сброшенных пакетов из-за переполнения буфера (DiscardRate);

- интенсивность и продолжительность вспышки трафика (Burstdensity/duration);

- интенсивность и длительность пауз (низкого уровняпоступления пакетов Gap density/duration);

- задержка передачи пакета «туда и обратно» (RoundTripDelay);

- уровень сигнала (Signal Level) и уровень шума (NoiseLevel);

- экспертнаяоценкакачестваслушающим MOS-LQ (Estimated Mean Opinion Протокол управления RTCP (RTP Control Protocol) Score for Listening Quality);

- экспертнаяоценкакачестватракта MOS-CQ (Estimated Mean Opinion Score for Conversational Quality);

- номинальная задержка в анти-джиттерном буфере (JitterBuffer NominalDelay);

- наибольшая задержка в анти-джиттерном буфере (зафиксированная) (Jitter Buffer Maximum).

Таким макаром, расширенная версия протокола RTCP позволяет получить существенно больший список черт свойства передачи Протокол управления RTCP (RTP Control Protocol) в текущей сессии.

Протоколы RTP/RTCP являются универсальным механизмомпередачи аудио- и видеоинформации через IP-сети. Для установления RTP-сессий употребляются протоколы сигнализации Н.323 иSIP.


protivorechiya-v-ryadah-antanti.html
protivostoyanie-aleksandru-bloku-v-tvorchestve-nikolaya-gumileva-sochinenie.html
protivostoyanie-priroda-protiv-hirurgii-nauchno-obosnovannih.html