Алгоритмы мультимедиа

Определения

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

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

Пакет RTCP. Управляющий пакет, который содержит фиксированный заголовок, сходный с RTP, и за ним следуют структурные элементы, зависящие от типа RTCP-пакета. Обычно несколько RTCP-пакетов посылаются как составной RTCP-пакет, вложенный в дейтограмму нижележащего уровня.

Транспортный адрес. Комбинация сетевого адреса и порта, которая идентифицирует конечную точку канала (например, IP-адрес и UDP-порт). Пакеты следуют от транспортного адреса отправителя к транспортному адресу получателя.

Сессия RTP. Период с момента формирования группы участников RTP-обмена до ее исчезновения. Для каждого из участников сессия определяется конкретной парой транспортных адресов (сетевой адрес и номера портов для RTP и RTCP). Транспортный адрес места назначения может быть общим для всех участников сессии. Допускается реализация нескольких сессий для каждого из участников одновременно.

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

Информационный источник CSRC (contributing source). Источник потока RTP-пакетов, который вносит вклад в общий поток, формируемый RTP-смесителем. Смеситель вставляет список SSRC-идентификаторов, которые идентифицируют парциальные источники, в заголовок RTP-пакетов. Этот список называется CSRC-списком. Примером приложения может быть аудиоконференция, где смеситель отмечает всех говорящих, чей голос порождает исходящие пакеты. Это позволяет принимающей стороне идентифицировать говорящего, хотя все пакеты имеют один и тот же SSRC-идентификатор.

Оконечная система. Приложение, которое генерирует или воспринимает данные, посылаемые в виде RTP-пакетов. Оконечная система может выступать в качестве одного или нескольких источников синхронизации для конкретной сессии.

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

Транслятор. Промежуточная система, которая переадресует RTP-пакеты, не изменяя их идентификаторы источника синхронизации. Такие устройства используются для преобразования системы кодирования, перехода от мультикастинг- к традиционной уникаст-адресации или при работе с Firewall.

Монитор. Приложение, которое получает RTCP-пакеты, посланные участниками RTP-сессии, в частности, диагностические сообщения, производит оценку состояния связи, копит долгосрочную статистику обмена.

Все целочисленные поля передаются в соответствии c сетевым порядком, т.е. старший байт следует первым (big-endian). Порядок передачи описан подробно в работе [10.3]. Если не оговорено обратного, все цифровые константы являются десятичными. Все поля заголовка выравниваются по их естественным границам, т.е. 16-битовые поля имеют четное смещение, а 32-битные имеют адрес, кратный 4. Октеты-заполнители содержат нули.

Абсолютное время представляется с помощью временных меток в соответствии с форматом NTP (network time protocol), который характеризует время в секундах от начала суток (UTC) 1 января 1900 года [10.4]. Полное разрешение временной метки NTP определяется 64-битовым числом с фиксированной запятой без знака. Целочисленная часть задается первыми 32 битами, а дробная часть — последними. В некоторых полях, где допустимо более компактное представление, используются только средние 32 бита (16 бит — целочисленная часть и 16 бит — дробная). Заголовок RTP-пакета имеет следующий формат (см. рис. 10.4).

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

Рис. 10.4. Заголовок пакета RTP

V (Версия): 2 бита

Это поле идентифицирует версию протокола RTP. В настоящее время в это поле записывается код 2. Значение 1 использовалось в опытной версии RTP, а код 0 — в аудиоприложении vat.

p (Заполнитель): 1 бит

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

x (Расширение): 1 бит

Если бит Х=1, далее следует фиксированный заголовок, за которым размещается одно расширение заголовка.

CC (CSRC count — число CSRC): 4 бита

Число CSRC содержит код количества CSRC-идентификаторов, которые записаны в пакете.

M (маркер): 1 бит

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

PT (Тип данных): 7 бит

Это поле идентифицирует формат поля данных RTP-пакета и определяет его интерпретацию приложением. Могут быть определены дополнительные коды типа данных. Исходный набор кодов по умолчанию для аудио и видео задан в профайле Internet-draft и может быть расширен в следующих редакциях стандарта (RFC-1700) [10.5].

Номер по порядку: 16 бит

Номер по порядку инкрементируется на 1 при посылке очередного RTP-пакета данных, этот код может использоваться получателем для регистрации потерь пакетов и для восстановления истинного порядка присланных фрагментов. Начальное значение кода является случайным. Алгоритм генерации таких кодов рассмотрен в [10.6].

Временная метка: 32 бита

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

Начальное значение временной метки является случайным. Несколько последовательных RTP-пакетов могут иметь идентичные временные метки, если логически они генерируются одновременно (например, относятся к одному и тому же видео кадру).

SSRC: 32 бита

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

CSRC-список: от 0 до 15 элементов, по 32 бита каждый

CSRC-список идентифицирует источники информации, которые внесли свой вклад в поле данных пакета. Число идентификаторов задается полем CC. Если число источников больше 15, только 15 из них могут быть идентифицированы.

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

1. если один из типов данных будет изменен в ходе сессии, нет универсальных средств для определения, какое из старых значений следует заменить на новое;
2. SSRC определено для идентификации одного пространства номеров и временных меток. Совместное использование нескольких типов данных в общем потоке может потребовать разных средств синхронизации и разной нумерации, чтобы определять, какой из типов пакетов потерян;
3. RTCP-сообщения отправителя и получателя могут описать только одно пространство номеров и временных меток для каждого SSRC и не имеют поля типа данных;
4. RTP-смеситель не сможет объединять перекрывающиеся потоки при условии их несовместимости;
5. работа со многими средами в пределах одной RTP-сессии предполагает использование различных сетевых путей или разного размещения сетевых ресурсов; и прием только одного субнабора, например аудио, когда видео недоступно из-за недостатка широкополосности.

Первые три из этих проблем вполне устранимы, если использовать различные SSRC для каждого вида среды при посылке их в пределах одной RTP-сессии.

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

• Бит маркера и поле типа данных содержат информацию, задаваемую профайлом, но они размещаются в стандартном заголовке, так как нужны многим приложениям. Октет, где размещаются эти поля, может быть переопределен профайлом. При любом числе маркерных битов один должен размещаться в старшем разряде октета, поскольку это необходимо для мониторирования потока.
• Дополнительная информация, которая требуется для конкретного формата поля данных, такая, как тип видеокодирования, должна транспортироваться в поле данных пакета. Это может быть заголовок, присутствующий в начале поля данных.
• Если конкретное приложение нуждается в дополнительных возможностях, которые не зависят от содержимого поля данных, профайл данного приложения должен определить дополнительные фиксированные поля, следующие непосредственно после поля SSRC существующего заголовка пакета. Эти приложения смогут получить доступ к таким дополнительным полям, при этом сохраняются все стандартные средства контроля и мониторинга, так как они базируются на первых 12 октетах заголовка.

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

Расширения заголовка предназначены для ограниченного использования — и многие приложения лучше реализовать, используя профайл. Формат реализации расширений показан на рис. 10.5.

Рис. 10.5. Формат расширения заголовка

Если бит x в RTP-заголовке равен 1, то к заголовку добавлено расширение переменной длины, за которым может следовать список CSRC. Расширение заголовка содержит 16-битовое поле длины, определяющее число 32-битных слов в расширении, исключая 4-октета заголовка расширения (т.о. значения поля длина, равное нулю, вполне допустимо). Информационный заголовок RTP может иметь только одно расширение. Чтобы обеспечить работу различных приложений с различными расширениями заголовка или чтобы обеспечить работу с более чем одним типом расширений, первые 16 бит расширения заголовка остаются свободными для выбора идентификаторов или параметров. Формат этих 16 бит определяется спецификацией профайла, с которым работает приложение.

Кроме оконечных систем, RTP поддерживает трансляторы и смесители, которые рассматриваются как промежуточные системы на уровне RTP.

RTP транслятор/смеситель соединяет две или более области на транспортном уровне. Обычно каждая область определяется сетью и транспортным протоколом (например, IP/UDP), мультикаст-адресом или парой уникаст-адресов, а также портом назначения транспортного уровня. Одна система может служить транслятором или смесителем для нескольких RTP сессий.

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

• Каждая из областей, соединенных транслятором или смесителем и участвующих в одной RTP-сессии, должна отличаться от всех других, по крайней мере, одним параметром (протоколом, адресом, портом) или должна быть изолирована от других на сетевом уровне.
• Следствием первого правила является то, что области не должны быть соединены более чем одним смесителем или транслятором.

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

Различие между смесителями и трансляторами заключается в том, что последние пропускают через себя потоки данных, при необходимости их преобразуя, а смесители просто объединяют несколько потоков в один.

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

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

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

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

Рис. 10.6. Пример RTP сети с оконечными системами, смесителями и трансляторами

Некоторый набор смесителей и трансляторов представлен на рис. 10.6. Здесь показано их влияние на SSRC и CSRC-идентификаторы. Оконечные системы обозначены символами ES и выделены цветом. Трансляторы обозначены буквами TRS (на рисунке — овалы), и смесители обозначены как MUX (прямоугольники). Запись M1:13(1,17 ) обозначает пакет, отправленный смесителем MUX1, который идентифицируется случайным значением SSRC 13 и двумя CSRC-идентификаторами 1 и 17, скопированными с SSRC-идентификаторов пакетов оконечных систем ES1 и ES2.

Последовательное включение смесителей

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

SSRC-идентификаторы в RTP-заголовках и в различных полях RTCP-пакетов являются случайными 32-битовыми числами, которые должны быть уникальными в рамках RTP-сессии. Очень важно, чтобы одни и те же числа не были использованы несколькими участниками сессии.

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

Неприемлемо также получать идентификаторы SSRC путем простого обращения к функции random() без тщательной инициализации.

Так как идентификаторы выбраны случайным образом, существует малая, но конечная вероятность того, что два или более источников выберут одно и то же число. Столкновение более вероятно, если все источники стартуют одновременно. Если N — число источников, а L — длина идентификатора (в нашем случае 32 бита), вероятность того, что два источника независимо выберут одно и то же значение (для больших N [10.8]), составляет 1-exp(-N² /2^(L+1)). Для N=1000 вероятность примерно равна 10^-4.

Типовое значение вероятности столкновения много меньше худшего случая, рассмотренного выше. Возьмем случай, когда новый источник подключается к RTP-сессии, в которой все остальные источники уже имеют уникальные идентификаторы. Если N равно числу источников, а L — длина идентификатора, вероятность столкновения равна N/2^L. Для N=1000 вероятность составит около 2*10^-7.

Вероятность столкновения уменьшается еще больше в случае, когда новый источник получает пакеты других участников до того, как передаст свой первый пакет. Если новый источник отслеживает идентификаторы других участников, он легко может устранить вероятность конфликта.

Преодоление столкновений и детектирование петель

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

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

• Транслятор может некорректно переадресовать пакет некоторой мультикастинг-группе, откуда этот пакет получен. Это может быть сделано непосредственно или через цепочку трансляторов. В таком случае один и тот же пакет появится несколько раз, приходя от разных сетевых источников.
• Два транслятора, некорректно поставленные в параллель, т.е. с одними и теми же мультикастными группами на обеих сторонах, будут направлять пакеты от одной мультикастной группы к другой. Однонаправленные трансляторы могут создать две копии; двунаправленные трансляторы могут образовать петлю.
• Смеситель может замкнуть петлю путем посылки пакета по адресу, откуда он был получен. Это может быть выполнено непосредственно, через смеситель или через транслятор.

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

Оба вида петель и столкновения приводят к тому, что пакеты приходят с тем же самым SSRC-идентификатором, но с разными транспортными адресами, которые могут принадлежать оконечной или какой-то промежуточной системе. Следовательно, если источник меняет свой транспортный адрес, он должен также выбрать новый SSRC-идентификатор, чтобы ситуация не была интерпретирована как зацикливание. Петли или столкновения, происходящие на дальней стороне транслятора или смесителя, не могут быть детектированы с использованием транспортного адреса источника, если все копии пакетов идут через транслятор или смеситель. Однако столкновения могут быть детектированы, когда фрагменты двух RTCP SDES пакетов содержат равные SSRC-идентификаторы, но разные коды CNAME (см. описание протокола RTCP).

Чтобы детектировать и устранять конфликты, реализации RTP должны содержать алгоритм, аналогичный описанному ниже. Он игнорирует пакеты от нового источника, которые входят в противоречие с работающим источником. Алгоритм разрешает конфликты с SSRC-идентификаторами участников путем выбора нового идентификатора и посылки RTCP BYE для старого. Однако когда столкновение вызвано зацикливанием собственных пакетов участников сессии, алгоритм выбирает новый идентификатор только раз и после этого игнорирует пакеты от транспортного адреса, вызвавшего зацикливание. Это нужно, чтобы избежать потока пакетов BYE.

Этот алгоритм зависит от равенства транспортных адресов для RTP и RTCP пакетов источника. Алгоритм требует модификации приложений, которые не отвечают этому ограничению.

Данный алгоритм требует наличия таблицы транспортных адресов источников, упорядоченных по их идентификаторам. В таблицу заносятся адреса, откуда данный идентификатор был впервые получен. Каждый SSRC- или CSRC-идентификатор, полученный с информационным или управляющим пакетом, отыскивается в этой таблице, чтобы корректно обработать полученные данные. Для управляющих пакетов каждый элемент с его собственным SSRC, например, фрагмент SDES, требует отдельного просмотра. SSRC в сообщениях-отчетах составляют исключение. Если SSRC или CSRC не найдены, создается новая запись в таблице. Эти записи в таблице удаляются, когда приходит пакет RTCP BYE с соответствующим кодом SSRC или когда достаточно долго не приходит вообще никаких пакетов.

Чтобы отслеживать зацикливание собственных пакетов участников, необходимо также завести отдельный список транспортных адресов источников, которые считаются конфликтными. Заметим, что это должен быть короткий список, обычно пустой. Каждый элемент этого списка хранит адрес источника и время, когда был получен последний конфликтный пакет. Элемент может быть удален из списка, если за время 10 периодов посылки RTCP сообщений-отчетов не прибыло ни одного конфликтного пакета.

Предполагается, что собственные идентификаторы и состояния участников записаны в таблицу идентификаторов источников.

Алгоритм:

IF SSRC или CSRC-идентификатор не найден в таблице идентификаторов источников:
THEN создать новую запись и внести туда транспортный адрес источника и SSRC или
CSRC вместе с кодом состояния.
CONTINUE (продолжить) обычную процедуру обработки.
Идентификатор найден в таблице
IF транспортный адрес источника из пакета совпадает с одним из записанных в таблице:
THEN CONTINUE Продолжить обычную процедуру обработки.
Обнаружено столкновение идентификаторов или зацикливание
IF идентификатор источника не совпадает с собственным идентификатором участника:
THEN IF идентификатор источника совпадает с тем, что содержится в фрагменте RTCP SDES, содержащем элемент CNAME, который отличается от CNAME из рекорда таблицы:
THEN (опционно) Случилось столкновение посторонних идентификаторов.
ELSE (опционно) Случилось зацикливание.
ABORT Прервать обработку информационного или управляющего пакета.
Столкновение для идентификатора участника или зацикливание его пакетов
IF транспортный адрес найден в списке конфликтных адресов:
THEN IF идентификатор источника не найден во фрагменте RTCP SDES, содержащем CNAME, или если CNAME принадлежит участнику:
THEN (опционно) случилось зацикливание собственного трафика.
Записать текущее время в соответствующую запись таблицы конфликтных адресов.
ABORT (прервать) обработку информационного или управляющего пакета.
Зафиксировать факт столкновения.
Внести новую запись в таблицу конфликтных адресов и зафиксировать время записи.
Послать пакет RTCP BYE с идентификатором SSRC.
Выбрать новый идентификатор.
Внести новую запись в таблицу идентификаторов источников со старым SSRC, транспортным адресом источника обработанного пакета.
CONTINUE Продолжить обычную процедуру обработки.

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

Когда из-за столкновения выбран новый SSRC-идентификатор, кандидат-идентификатор должен быть сверен с содержимым таблицы идентификаторов. Если такой код там уже имеется, должен быть выбран другой кандидат и процедура сверки повторена.

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

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

Алгоритмом шифрования по умолчанию является DES (Data Encryption Standard), работающий в режиме CBC (Cipher Block Chaining), как это описано в RFC-1423 [10.9], за исключением того, что используется заполнение, кратное 8 октетам. Инициализационный вектор равен нулю, так как для RTP-заголовка используются случайные числа. Более подробно о векторах инициализации можно прочесть в [10.10]. Приложения, которые применяют шифрование, должны поддерживать алгоритм DES в режиме CBC. Этот метод выбран потому, что он показал на практике свою эффективность при работе с аудио- и видеоприложениями в Интернет. Возможно применение и других криптографических средств.

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

Для обеспечения демультиплексирования RTP полагается на нижележащий протокольный уровень. Для UDP и сходных с ним протоколов RTP использует четные номера портов, а соответствующие RTCP-потоки — нечетные номера. Если приложению предлагается использовать нечетный номер RTP-порта, этот номер должен быть заменен на ближайший четный меньше исходного.

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

Если RTP-пакеты переносятся посредством протокола, который поддерживает поточный метод передачи, должен быть определен механизм вложения. Механизм вложения должен быть детализован и в случае, когда транспортный протокол использует в поле данных заполнители.

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

Константы, определяющие тип данных (PT) RTP-пакета, задаются профайлом, а не самим протоколом. Однако значение октета RTP-заголовка, который содержит бит(ы) маркера, не должно ни при каких обстоятельствах равняться 200 и 201 (десятичные), чтобы отличить RTP-пакеты от RTCP-пакетов типа SR и RR.

Использование протокола RTP в различных приложениях может предъявлять различные требования. Адаптация протокола к этим требованиям осуществляется путем выбора определенных параметров, применения различных расширений (см. рис. 10.5) или путем вариации формата на основе профайлов. Типовое приложение использует только один профайл. Спецификация формата поля данных определяет то, например, как, закодированный видеосигнал (H.261) должен переноситься RTP-пакетами.

В рамках RTP-стандарта определены следующие элементы поля данных (этот список не следует рассматривать, как окончательный).

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

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

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

Расширения заголовка RTP. Структура содержимого первых 16 бит расширения RTP-заголовка должна быть определена профайлом (см. рис. 10.5).

Безопасность. Профайл может специфицировать, какие услуги и алгоритмы безопасности должно обеспечить приложение.

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

Нижележащий протокол. Определяется нижележащий транспортный протокол, который служит для пересылки RTP-пакетов.

Транспортное соответствие. Соответствие RTP и RTCP адресам транспортного уровня, например, UDP-портам.

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

Не предполагается, что для каждого приложения требуется свой профайл. В пределах одного класса приложений целесообразно использовать расширения одного и того же профайла. Простое расширение, такое, как введение дополнительного типа поля данных или нового типа RTCP-пакета, может быть выполнено путем регистрации их через комитет по стандартным числам Интернет и публикации их описаний в приложении к профайлу.

Алгоритмы работы отправителя и получателя RTP-пакетов определены в RFC-3550 на примере кодов, написанных на языке СИ.

Чтобы посчитать частоту потерь пакетов, нужно знать ожидаемое и реально полученное число пакетов для каждого из источников. Число полученных пакетов определяется простым их подсчетом с учетом возможного дублирования и запаздывания. Ожидаемое число пакетов может быть подсчитано получателем как разность между наибольшим порядковым номером пакета ( s->max_seq ) и номером первого пакета в последовательности ( S->base_seq ). При этом нужно учитывать, что номера имеют 16 бит и по этой причине могут переполниться (число переполнений хранится в переменной s->cycles ).

extended_max = s>cycles + s>max_seq;
expected = extended_max  s>base_seq + 1;

Число потерянных пакетов определяется как разность между ожидаемым и реально полученным числом пакетов:

lost = expected  s>received;

Доля потерянных пакетов за отчетный период (с момента посылки предыдущего SR или RR пакета) вычисляется из разности ожидаемого и реально полученного числа пакетов за отчетный период, где expected_prior и received_prior представляют собой значения, записанные в момент подготовки предыдущего отчета:

expected_interval = expected  s>expected_prior;
s>expected_prior = expected;
received_interval = s>received  s>received_prior;
s>received_prior = s>received;
lost_interval = expected_interval  received_interval;
if (expected_interval == 0 || lost_interval <= 0) fraction = 0;
else fraction = (lost_interval << 8) / expected_interval;

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