Протокол RTCP используется для текущего контроля RTP-сессии и сбора статистической информации по качеству передачиинформации (qualityoftransmission) в сети. Это осуществляется засчет организации обратной связи между источником и получателями информации. Также протокол RTCP поддерживает устойчивый идентификатор источника данных RTP на транспортномуровне, называемый «каноническим именем» (CNAME –
canonicalname). Так как идентификатор SSRC может изменяться,если обнаружен конфликт или перезапущена программа, то получателям для отслеживания каждого участника требуется каноническое имя CNAME. Получатели также требуют CNAME для отображения множества потоков информации от данного участникана множество связанных сеансов RTP.
Например, для синхронизации звукового и видеосигнала. Каждый участник телеконференциипри посылке управляющих пакетов всем остальным участникам,может независимо от других оценивать общее число участников.
Это число используется при вычислении частоты отправления па-
кетов RTCP.
Пакеты RTCP передаются вместе с потоком данных RTP только на значительно меньшей скорости. Обычно под RTCP трафикотводится до 5% всего диапазона для передачи потоковых данных.
Даже в самых быстрых сессиях пакеты RTCP передаются не чаще,
чем раз в пять секунд.
Существует различные типы пакетов RTCP несущие разнуюинформацию:
- SR (SenderReports – рапорт источника) – содержит статистическую информацию отправителя и информацию получателей;
- RR (Receiver Reports – рапорт приемника) – содержит статистическую информацию получателей;
- SDES (SourceDEScription) – содержит описание различныхпараметров источника, включая CNAME (имя пользователя);
- BYE (запрос разъединения) – это последний пакет, которыйпосылает участник конференции, когда хочет её покинуть;
- APP (application – приложение) – содержание приложения, которое определяется самим приложением.
В один пакет транспортного уровня укладывается, как правило, несколько пакетов RTCP. При этом общий заголовок отсутствует. Например, типичный пакет транспортного уровня, посылаемый активным участником сессии, содержит следующие пакетыRTCP: пакет SR (содержит информацию об отправленный пакетах), пакет RR (содержит информацию о принятых пакетах), пакетSDES (содержит описание источника).
На рис. 1.10 представлен формат рапорта приемника RR. В поле V (2 бит) указывается версия протокола RTCP, в поле Р (1 бит)помещается признак наличия заполнения (Padding), в поле RC (5бит) записывается число блоков источников, представленных вданном рапорте. В поле тип нагрузки (8 бит) записан PT=201, чтопоказывает тип пакета RR. В поле длина (16 бит) записываетсядлина пакета (Length) в 32-битных словах за исключением заго-
ловка и заполнителя. В поле, следующим за заголовком указываетсяидентификатор источника синхронизации, сформировавшегоданное сообщение.
Рисунок 1.10 Формат пакета рапорта приемника
На рис. 1.11 представлен формат блока отчётных данных (Report
block).
Рисунок 1.11 Формат блока отчётных данных поисточнику (Report Block)
В сообщениях SR и RR каждый источник описывается блоком(рис. 1.11), содержащим следующие данные:
- SSRC – идентификатор источника синхронизации (идентификатор источника);
- FractionLost (8 бит) – доля потерянных пакетов данного источника относительно общего числа пакетов;
- Packet Lost (24 бит) – общее число потерянных пакетов данного источника;
- Highest Sequence Number – максимальный номер пакета, полученного от данного источника;
- LSR – старшая часть последнего значения метки времени NTP(Network Time Protocol) TimeStamp, полученного от данногоисточника;
- DLSR – задержка времени от получения последнего сообщенияот данного источника до формирования данного блока.
Если SR (SenderReport) посылается источником, который работает, как микшер (т.е. сам получает информацию из несколькихисточников и объединяет ее в один поток), то пакет SR содержитследующие части (рис. 1.12):
- Header (заголовок) его структура показана более подробно нарис. 1.13.
Рисунок 1.12 Формирование общего рапорта отправителя для микшера
Далее следует информация о приеме данных от источников иданные, которые используются для формирования передаваемогопотока. Каждый такой источник описывается блоком данных. Каждый блок начинается с SCRC источника.
Рисунок 1.13. Формат пакета отчётных данных отправителя(SenderReport)
На рис. 1.13 представлен формат пакета SR (SenderReport). Онсодержит заголовок пакета, статистическую информацию отправителя и собранную статистическую информацию получателя (илигруппы получателей, если это конференция).
Рассмотрим назначение полей этого пакета:
- V, P – имеют тоже значение, что и в пакетах протокола RTP(рис. 1.10);
- RC (ReportCount) – указывает на число рапортов получателей,которые включены в данный пакет;
- PT – для пакета рапорта отправителя равно SR = 200;
- Length – определяет общую длина данного пакета SR, невключая заголовок и заполнение;
- NTP timestamp (64 бита) – значение абсолютной метки временив формате протокола NTP. Значение этого поля вместе с временной меткой в пакете отправителя может быть использованодля расчета RTT;
- RTP timestamp – содержит метку относительного времени, сгенерированную протоколом RTP;
- Sender packet count – содержит число отправленных пакетов сначала текущей сессии;
- Senderoctetcount – содержит общее число октетов, отправленных с начала сессии;
- SSRC 1 – содержит идентификатор 1-го источника синхронизации;
- Reportblock 1 – информация блока данных по 1-му источнику;
- SSRC 2 – содержит идентификатор 2-го источника синхронизации;
- Reportblock 2 – информация блока данных по 2-му источнику.
За счет пересылки рапортов RR и SR осуществляется обратнаясвязь между получателем и источником. На основе статистическихданных этих рапортов отправитель (источник) может приниматьрешение об изменении текущих параметров сессии. Например,запросить большую полосу пропускания.
Рисунок 1.14. Формат пакета SDES (SourceDescription)
Пакет описание источника SDES (рис. 1.14) начинается с заголовка, в котором представлена версия протокола V=2, биты заполнения P, значение числа блоков источников (chunk) RC в данномрапорте, идентификатор типа пакета SDES = 202, общая длина пакета. Далее следуют блоки описания источников.
Рисунок 1.15 Формат блока описания источника
Блок описания источника Source Descriptor Block (рис. 1.15)начинается с SSRC источника. Далее следуют элементы описанияисточников (SDES Item). Каждый блок находится на границедвойного слова. Каждый элемент описания источника начинаетсяс заголовка, состоящего из типа TYPE (1 байт) (см. табл. 1.3), длины в байтах Length (1 байт), далее следует текст элемента. Длинаотносится к тексту.
Обычно CNAME имеет следующий формат: user@host, где user
– имя пользователя, host – идентификатор хоста (доменное имяили IP-адрес в стандартном ASCII-представлении). Если по каким-либо причинам имя пользователя оказывается недоступным, тоиспользуется CNAME в формате host.
Пример:dwarf@sleepy.beauty.com или dwarf@192.166.148.9. CNAME явля-
ется единственным обязательным элементом описания источника.
Таблица 1.3. Типы кодов описаний источника
Рисунок 1.16. Формат пакета завершения сессии BYE
Пакет BYE (рис. 1.16) передается в том случае, если один изучастников покидает сессию. Если пакет BYE получен смесителем, он передает этот пакет с идентификатором SSRC или CSRCбез изменений. Если смеситель отключается сам, то он должен послать пакет BYE, перечислив все источники, вносившие вклад впоток, с которым он работал, а также свой идентификатор SSRC.
Пакет BYE может также содержать 8-битовое число октетов, закоторым следует текст соответствующей длины, поясняющийпричину отключения. Например, «камера не работает» («cameramalfunction»).
В настоящее время разработана расширенная версия протоколаRTCP XR, описанная в RFC 3611. В ней увеличено число параметров, по которым собираются статистические данные.
Наиболеезначимыми дополнительными параметрами являются:
- доля сброшенных пакетов из-за переполнения буфера (DiscardRate);
- интенсивность и длительность вспышки трафика (Burstdensity/duration);
- интенсивность и продолжительность пауз (низкого уровняпоступления пакетов Gap density/duration);
- задержка передачи пакета «туда и обратно» (RoundTripDelay);
- уровень сигнала (Signal Level) и уровень шума (NoiseLevel);
- экспертнаяоценкакачестваслушающим MOS-LQ (Estimated Mean Opinion Score for Listening Quality);
- экспертнаяоценкакачестватракта MOS-CQ (Estimated Mean Opinion Score for Conversational Quality);
- номинальная задержка в анти-джиттерном буфере (JitterBuffer NominalDelay);
- максимальная задержка в анти-джиттерном буфере (зафиксированная) (Jitter Buffer Maximum).
Таким образом, расширенная версия протокола RTCP позволяет получить значительно больший перечень характеристик качества передачи в текущей сессии.
Протоколы RTP/RTCP являются универсальным механизмомпередачи аудио- и видеоинформации через IP-сети. Для установления RTP-сессий используются протоколы сигнализации Н.323 иSIP.