Определяемые профилем изменения заголовка RTP

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

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

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

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

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

Расширение заголовка RTP

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

Если бит X в заголовке RTP установлен в единицу, то к фиксированному заголовку RTP (вслед за списком CSRC, если он есть) присоединяется расширение заголовка с переменной длиной. Заметим, что это расширение заголовка предназначено только для ограниченного использования. Расширение заголовка пакета RTP имеет следующий формат (рис. 3).

Рис. 3 – Расширение заголовка пакета RTP

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

Зацикливания и коллизии

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

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

Вероятность коллизии

Идентификаторы выбираются случайно, поэтому возможно, что два или более источников выберут для него одно и то же значение. Коллизия с наибольшей вероятностью произойдет, если все источники начнут работу одновременно, — например, когда это вызвано автоматически некоторым событием управления сеанса связи. Если N — число источников, а L — длина идентификатора (здесь 32 бита), то вероятность того, что два источника независимо выберут одну и ту же величину, может быть приблизительно рассчитана для больших N по формуле:

1-exp(-N**2/2**(L+1)).

Для N=1000, эта вероятность приблизительно равна 10^-4.

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

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