Заголовок пакета RTP

Первые 12 октетов присутствуют во всех RTP-пакетах. Список CSRC-идентификаторов присутствует только тогда, когда пакет формируется смесителем.

V (2 бита) - поле версии протокола RTP. Текущая версия — вторая.

P (1 бит) - поле заполнения. Если Р=1, пакет содержит один или более дополнительных октетов-заполнителей в конце поля данных (заполнители не являются частью поля данных). Последний октет заполнителя содержит число октетов, которые должны игнорироваться. Заполнитель нужен при использовании некоторых алгоритмов шифрования при фиксированном размере блоков или при укладке нескольких RTP-пакетов в один UDP.

X (1 бит) поле расширения заголовка. Если Х=1, то за основным заголовком следует еще один дополнительный, используемый в экспериментальных расширениях RTP.

CC (CSRC count – число CSRC, 4 бита). Это поле содержит количество идентификаторов отправителей, чьи данные находятся в пакете, причем сами идентификаторы следуют за основным заголовком.

M (1 бит) поле маркера. Интерпретация маркера определяется профайлом. Например, предполагается разрешить выделять в потоке пакетов существенные события, такие как границы кадра в случае видео, или в случае голоса выделять начало речи после периода молчания.

PT (7 битов) - поле типа полезной нагрузки. Идентифицирует тип полезной нагрузки и формат данных RTP-пакета, включая сжатие и шифрование данных и определяет интерпретацию поля данных приложением.

Порядковый номер пакета (Sequence Number, 16 битов). Каждый источник начинает нумеровать пакеты с произвольного номера, увеличиваемого затем на единицу с каждым посланным пакетом данных RTP. Это позволяет обнаружить потерю пакетов и определить порядок пакетов с одинаковой отметкой о времени. Несколько последовательных пакетов могут иметь одну и ту же отметку о времени, если логически они порождены в один и тот же момент, как, например, пакеты, принадлежащие к одному и тому же видеокадру.

Временная метка (Timestamp, 32 бита). Поле отметки о времени. Это поле содержит момент времени, в который первый октет данных полезной нагрузки был создан. Единицы, в которых время указывается в этом поле, зависят от типа полезной нагрузки. Значение определяется по локальным часам отправителя. Начальное значение временной метки является случайным. Несколько последовательных RTP-пакетов могут иметь идентичные временные метки, если логически они генерируются одновременно (например, относятся к одному и тому же видеокадру).

SSRC (Synchronization Source Identifier, 32 бита). Поле SSRC идентифицирует источник синхронизации. Этот идентификатор выбирается случайным образом, так чтобы в пределах одной RTP-сессии не было двух равных SSRC-кодов, и не зависит от сетевого адреса. Все приложения должны быть способны выявлять случаи равенства SSRC-кодов. Если отправитель изменяет свой транспортный адрес, он должен также сменить и SSRC-идентификатор.

CSRC-список (Contributing source Identifier, 32 бита). Список полей идентификаторов источников, "подмешанных" в основной поток, например, с помощью смесителя. Количество элементов в списке: от 0 до 15. Число идентификаторов задается полем CC. Примером может служить аудио-конференция, в RTP-пакеты которой собраны речи всех участников, каждый со своим CSRC — они-то и образуют список CSRC. При этом вся конференция имеет общий SSRC.

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

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

Оконечная система генерирует или воспринимает данные, посылаемые в виде RTP-пакетов. Алгоритмы работы отправителя и получателя RTP-пакетов описаны в RFC 1889.

Смеситель принимает потоки RTP-данных от одного или нескольких источников и формирует из них один общий поток. Так как объединяемые потоки не синхронизованы, смеситель производит синхронизацию потоков и формирует свою собственную временную шкалу для исходящего потока. Таким образом, все пакеты данных, переадресованные смесителем, будут помечены SSRC-идентификатором смесителя. Для того чтобы сохранить информацию об источниках исходных данных, смеситель должен внести SSRC-идентификаторы из заголовков входящих RTP-пакетов в список CSRC-идентификаторов формируемого исходящего пакета, а также должен включить свой собственный SSRC-идентификатор в CSRC-список для данного пакета.

Например, запись "M1:13(1,17)" обозначает пакет, отправленный смесителем MUX1, который идентифицируется случайным значением SSRC 13 и двумя CSRC-идентификаторами 1 и 17, скопированными с SSRC-идентификаторов пакетов оконечных систем ES1 и ES2

Транслятор переадресует RTP-пакеты, не изменяя их SSRC-идентификаторы. Некоторые типы трансляторов передают данные без изменений, другие кодируют данные и соответственно изменяют коды типа данных и временные метки.

В RTP-сессии могут быть задействованы несколько смесителей и трансляторов. Если два смесителя включены последовательно, как MUX2 и MUX3, то пакеты, полученные смесителем, могут быть уже объединены и включать CSRC-список со многими идентификаторами. Смеситель (MUX3) должен формировать CSRC-список для исходящих пакетов, используя CSRC-идентификаторы уже смешанных входных пакетов (выход MUX2) и SSRC-идентификаторы несмешанных входных пакетов, поступивших от ES9 (E:36). Это отмечено на рисунке для выходных пакетов смесителя MUX3 как M3:99(9,11,36).

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