Самой насущной проблемой все чаще становится нехватка адресного пространства, что требует изменения формата адреса.

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

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

В результате было решено подвергнуть протокол IP модернизации, преследуя следующие основные цели:

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

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

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

Теперь адрес записывается в шестнадцатеричном виде, причем каждые четыре цифры отделяются друг от друга двоеточием, например:

FEDC:0A96:0:0:0:0:7733:567A.

Для сетей, поддерживающих обе версии протокола IPv4 и IPv6 , имеется возможность использовать для младших 4 байтов традиционную десятичную запись, а для старших - шестнадцатеричную:

0:0:0:0:FFFF 194.135.75.104.

В рамках системы адресации IPv6 имеется также выделенное пространство адресов для локального использования, то есть для сетей, не входящих в Интернет. Существует две разновидности локальных адресов : для "плоских" сетей, не разделенных на подсети (Link-Local), и для сетей, разделенных на подсети (Site-Local), которые различаются значением префикса.

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

Основной заголовок дейтаграммы IPv6 длиной 40 байтов имеет следующий формат ( рис. 2.4).

Поле Класс трафика ( Traffic Class) эквивалентно по назначению полю Тип обслуживания (Type Of Service) , а поле Лимит переходов ( Hop Limit) - полю Время жизни (Time To Live) протокола IPv4.

Поле Метка потока (Flow Label) позволяет выделять и особым образом обрабатывать отдельные потоки данных без необходимости анализировать содержимое пакетов. Это очень важно с точки зрения снижения нагрузки на маршрутизаторы.

Поле Следующий заголовок (Next Header) является аналогом поля Протокол (Protocol) IPv4 и определяет тип заголовка, следующего за основным. Каждый следующий дополнительный заголовок также содержит поле Next Header .

2.3.3. Протокол TCP

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

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

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

Логическая структура сетевого программного обеспечения, реализующего протоколы семейства TCP/IP в каждом узле сети Интернет, изображена на рис. 2.5 .

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

Рис. 2.5.

Чтобы установить соединение между двумя процессами на разных компьютерах сети, необходимо знать не только интернет-адреса компьютеров, но и номера тех ТСР-портов (sockets), которые процессы используют на этих компьютерах. Любое TCP-соединение в сети Интернет однозначно идентифицируется двумя IP-адресами и двумя номерами ТСР-портов.

Протокол TCP умеет работать с поврежденными, потерянными, дублированными или поступившими с нарушением порядка следования пакетами. Это достигается благодаря механизму присвоения каждому передаваемому пакету порядкового номера и механизму проверки получения пакетов.

Когда протокол TCP передает сегмент данных, копия этих данных помещается в очередь повтора передачи и запускается таймер ожидания подтверждения.

2.3.4. Протокол UDP

Протокол передачи пользовательских дейтаграмм (User Datagram Protocol - UDP) предназначается для обмена дейтаграммами между процессами компьютеров, расположенных в объединенной системе компьютерных сетей.

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

2.3.5. Протоколы RTP и RTCP

Основные понятия

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

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

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

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

Хотя протокол RTP считается протоколом транспортного уровня, он функционирует обычно поверх другого протокола транспортного уровня UDP (User Datagram Protocol). Оба протокола вносят свои доли в функциональность транспортного уровня. Следует отметить, что RTP и RTCP являются независимыми от нижележащих уровней - транспортного и сетевого, поэтому протоколы RTP / RTCP могут использоваться с другими подходящими транспортными протоколами.

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

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

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

Групповая аудио-конференц-связь

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

Приложение аудио-конференц-связи, используемое каждым участником конференции, посылает звуковые данные малыми порциями, например, продолжительностью 20 мс. Каждой порции звуковых данных предшествует заголовок RTP ; заголовок RTP и данные поочередно формируются (инкапсулируются) в пакет UDP. Заголовок RTP показывает, какой тип кодирования звука (например, ИКМ, АДИКМ или LPC ) применялся при формировании данных в пакете. Это дает возможность изменять тип кодирования в процессе конференции, например, при появлении нового участника, который использует линию связи с низкой полосой пропускания, или при перегрузках сети.

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

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

Видео-конференц-связь

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

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

Понятие о микшерах и трансляторах

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

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

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

Протокол управления RTCP

Все поля пакетов RTP / RTCP передаются по сети байтами (октетами); при этом наиболее значащий байт передается первым. Все данные полей заголовка выравниваются в соответствии с их длиной. Октеты , обозначенные как дополнительные, имеют нулевое значение.

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

1. Главная функция - обеспечение обратной связи для оценки качества распределения данных. Это неотъемлемая функция RTСP как транспортного протокола, она связана с функциями управления потоком и перегрузками других транспортных протоколов. Обратная связь может быть непосредственно полезна для управления адаптивным кодированием, но эксперименты с IP-мультивещанием показали, что обратную связь с получателями также важно иметь для диагностики дефектов при распространении информации. Посылка отчетов обратной связи о приеме данных всем участникам позволяет при наблюдении проблем оценивать, являются они локальными или глобальными. С механизмом распределения IPM для таких объектов, как поставщики услуг сети, можно также получать информацию обратной связи и действовать при диагностике проблем сети как монитор третьей стороны. Эта функция обратной связи обеспечивается отчетами отправителя и приемника RTCP .
2. RTCP поддерживает устойчивый идентификатор источника данных RTP на транспортном уровне, называемый "каноническим именем" (CNAME - canonical name). Так как идентификатор SSRC может изменяться, если обнаружен конфликт или перезапущена программа, то получателям для отслеживания каждого участника требуется каноническое имя CNAME . Получатели также требуют CNAME для отображения множества потоков информации от данного участника на множество связанных сеансов RTP , например, при синхронизации звукового и видеосигнала.
3. Первые две функции требуют, чтобы все участники посылали пакеты RTCP , следовательно, для предоставления возможности масштабирования числа участников протоколом RTP должна регулироваться частота передачи таких пакетов. При посылке каждым участником телеконференции управляющих пакетов всем остальным участникам, каждый может независимо оценивать общее число участников.
4. Четвертая, дополнительная, функция RTCP должна обеспечивать информацию управления сеансом (например, идентификацию участника), которая будет отражена в интерфейсе пользователя. Наиболее вероятно, что это будет полезным в "свободно управляемых" сеансах, где участники вступают в группу и выходят из нее без контроля принадлежности или согласования параметров.

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

Интенсивность передачи пакетов RTCP

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

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

Вычисления полосы пропускания для трафика управления и данных выполняются с учетом нижележащих протоколов транспортного и сетевого уровней (например, UDP и IP). Заголовки уровня звена передачи данных (ЗПД) при вычислениях не учитываются, так как пакет по мере его передачи может инкапсулироваться с различными заголовками уровня ЗПД.

Трафик управления должен быть ограничен малой и известной частью полосы пропускания сеанса: малой настолько, чтобы не пострадала основная функция транспортного протокола - передача данных; известной так, чтобы трафик управления мог быть включен в спецификацию полосы пропускания, данную протоколу резервирования ресурсов , и так, чтобы каждый участник мог независимо вычислить свою долю. Предполагается, что часть полосы пропускания сеанса, выделяемая для RTCP , должна быть установлена равной 5 %. Все участники сеанса должны использовать одинаковую величину полосы пропускания RTCP , так, чтобы вычисленные значения интервала передачи пакетов управления были одинаковыми. Поэтому эти константы должны быть установлены для каждого профиля.

Алгоритм вычисления интервала между посылками составных пакетов RTCP для разделения среди участников полосы пропускания, выделенной для трафика управления, имеет следующие основные характеристики:

• отправители коллективно используют по крайней мере 1/4 полосы пропускания трафика управления так, как в сеансах с большим количеством получателей, но с малым числом отправителей; едва установив соединение, участники в течение короткого интервала времени получают CNAME передающих сайтов;
• требуется, чтобы расчетный интервал между пакетами RTCP , как минимум, превышал 5 секунд, чтобы избежать пачек пакетов RTCP , превышающих дозволенную полосу пропускания, когда число участников мало и трафик не сглаживается согласно закону больших чисел;
• интервал между пакетами RTCP изменяется случайно в пределах от половины до полутора расчетных интервалов во избежание непреднамеренной синхронизации всех участников. Первый пакет RTCP , посланный после вступления в сеанс связи, также задерживается случайным образом (до половины минимума интервала RTCP ) в случае, если приложение начато во множестве сайтов одновременно, например, при объявлении о начале сеанса связи;
• для автоматической адаптации к изменениям в объеме передаваемой информации управления вычисляется динамическая оценка среднего размера составного пакета RTCP с использованием всех полученных и посланных пакетов;
• этот алгоритм может использоваться для сеансов, в которых передача пакетов допустима для всех участников. В этом случае параметр полосы пропускания сеанса - это произведение полосы пропускания индивидуального отправителя на число участников, и полоса пропускания RTP полагается на нижележащий протокол и для обеспечения индикации длины. Максимальная длина пакетов RTP ограничивается только протоколами нижележащих уровней.

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

Стремительный рост Internet предъявляет новые требования к скорости и объемам передачи данных. И для того чтобы удовлетворить все эти запросы, одного увеличения емкости сети недостаточно, необходимы разумные и эффективные методы управления трафиком и загруженностью линий передачи.

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

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

Эту задачу и призван решить новый транспортный протокол реального времени - RTP (Real-Time Transport Protocol), который гарантирует доставку данных одному или более адресатам с задержкой в заданных пределах, т. е. данные могут быть воспроизведены в реальном времени.

Принципы построения протокола RTP

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

Примечание

Для каждого участника RTP сеанс определяется парой транспортных адресов назначения пакетов (один сетевой адрес - IP и пара портов: RTP и RTCP).

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

Примечание

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

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

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

Методы контроля работы

Протокол RTP используется только для передачи пользовательских данных - обычно многоадресной - всем участникам сеанса. Совместно с RTP работает протокол RTCP (Real-time Transport Control Protocol), основная задача которого состоит в обеспечении управления передачей RTP. RTCP использует тот же самый базовый транспортный протокол, что и RTP (обычно UDP), но другой номер порта.

RTCP выполняет несколько функций:

1. Обеспечение и контроль качества услуг и обратная связь в случае перегрузки. Так как RTCP-пакеты являются многоадресными, все участники сеанса могут оценить, насколько хороши работа и прием других участников. Сообщения отправителя позволяют получателям оценить скорость данных и качество передачи. Сообщения получателей содержат информацию о проблемах, с которыми они сталкиваются, включая утерю пакетов и избыточную неравномерность передачи. Обратная связь с получателями важна также для диагностирования ошибок при распространении. Анализируя сообщения всех участников сеанса, администратор сети может определить, касается данная проблема одного участника или носит общий характер. Если приложение-отправитель приходит к выводу, что проблема характерна для системы в целом, например, по причине отказа одного из каналов связи, то оно может увеличить степень сжатия данных за счет снижения качества или вообще отказаться от передачи видео - это позволяет передавать данные по соединению низкой емкости.
2. Идентификация отправителя. Пакеты RTCP содержат стандартное текстовое описание отправителя. Они предоставляют больше информации об отправителе пакетов данных, чем случайным образом выбранный идентификатор источника синхронизации. Кроме того, они помогают пользователю идентифицировать потоки, относящиеся к различным сеансам.
3. Оценка размеров сеанса и масштабирование. Для обеспечения качества услуг и обратной связи с целью управления загруженностью, а также с целью идентификации отправителя, все участники периодически посылают пакеты RTCP. Частота передачи этих пакетов снижается с ростом числа участников. При небольшом числе участников один пакет RTCP посылается максимум каждые 5 секунд. RFC-1889 описывает алгоритм, согласно которому участники ограничивают частоту RTCP-пакетов в зависимости от общего числа участников. Цель состоит в том, чтобы трафик RTCP не превышал 5% от общего трафика сеанса.

Формат заголовка протокола RTP

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

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

Использование TCP в качестве транспортного протокола для этих приложений невозможно по нескольким причинам:

1. Этот протокол позволяет установить соединение только между двумя конечными точками, следовательно, он не подходит для многоадресной передачи.
2. TCP предусматривает повторную передачу потерянных сегментов, прибывающих, когда приложение реального времени уже их не ждет.
3. TCP не имеет удобного механизма привязки информации о синхронизации к сегментам - дополнительное требование приложений реального времени.

Другой широко используемый протокол транспортного уровня - LJDP не имеет части ограничений TCP, но и он не предоставляет критической информации о синхронизации.

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

Эту задачу и призван решить новый транспортный протокол реального времени - RTP (Real-time Transport Protocol), который гарантирует доставку данных одному или более адресатам с задержкой в заданных пределах, т. е. данные могут быть воспроизведены в реальном времени.

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

0

2

3

4

8

16

31

Synchronization Source (SSRC) Identifier
Contributing Source (CSRC) Identifiers

Рис. 1. Фиксированный RTP-заголовок.

V (2 бита). Поле версии. Текущая версия - вторая.
Р (1 бит). Поле заполнения. Это поле сигнализирует о наличии заполняющих октетов в конце полезной нагрузки. Заполнение применяется, когда приложение требует, чтобы размер полезной нагрузки был кратен, например, 32 битам. В этом случае последний октет указывает число заполняющих октетов.
Х (1 бит). Поле расширения заголовка. Когда это поле задано, то за основным заголовком следует еще один дополнительный, используемый в экспериментальных расширениях RTP.
СС (4 бита). Поле числа отправителей. Это поле содержит число идентификаторов отправителей, чьи данные находятся в пакете, причем сами идентификаторы следуют за основным заголовком.
М (1 бит). Поле маркера. Смысл бита маркера зависит от типа полезной нагрузки. Бит маркера используется обычно для указания границ потока данных. В случае видео он задает конец кадра. В случае голоса он задает начало речи после периода молчания.
РТ (7 бит). Поле типа полезной нагрузки. Это поле идентифицирует тип полезной нагрузки и формат данных, включая сжатие и шифрование. В стационарном состоянии отправитель использует только один тип полезной нагрузки в течение сеанса, но он может его изменить в ответ на изменение условий, если об этом сигнализирует протокол управления передачей в реальном времени (Real-Time Transport Control Protocol).
Sequence Number (16 бит). Поле порядкового номера. Каждый источник начинает нумеровать пакеты с произвольного номера, увеличиваемого затем на единицу с каждым посланным пакетом данных RTP. Это позволяет обнаружить потерю пакетов и определить порядок пакетов с одинаковой отметкой о времени. Несколько последовательных пакетов могут иметь одну и ту же отметку о времени, если логически они порождены в один и тот же момент, как, например, пакеты, принадлежащие к одному и тому же видеокадру.
Timestamp (32 бита). Поле отметки о времени. Это поле содержит момент времени, в который первый октет данных полезной нагрузки был создан. Единицы, в которых время указывается в этом поле, зависят от типа полезной нагрузки. Значение определяется по локальным часам отправителя.
Synchronization Source (SSRC) Identifier (32 бита). Поле идентификатора источника синхронизации: генерируемое случайным образом число, уникальным образом идентифицирующее источник в течение сеанса и независимое от сетевого адреса. Это число играет важную роль при обработке поступившей порции данных от одного источника.
Contributing source (CSRC) Identifier (32 бита). Список полей идентификаторов источника, "подмешанных" в основной поток, например, с помощью микшера. Микшер вставляет целый список SSRC идентификаторов источников, которые участвовали в построении данного RTP-пакета. Этот список и называется CSRC. Количество элементов в списке: от 0 до 15. Если число участников более 15 - выбираются первые 15. Примером может служить аудио-конференция, в RTP-пакеты которой собраны речи всех участников, каждый со своим SSRC - они-то и образуют список CSRC. При этом вся конференция имеет общий SSRC.

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

Протокол резервирования ресурсов - RSVP

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

RTP вместе с другими описанными стандартами позволяет с успехом передавать видео и аудио по обычным IP-сетям. RTP/RTCP/RSVP - стандартизованное решение для сетей с передачей данных в реальном времени. Единственным его недостатком является то, что оно предназначено только для IP-сетей. Однако это ограничение временное: сети так или иначе будут развиваться в этом направлении. Данное решение обещает решить проблему передачи чувствительных к задержкам данных по Internet.

Литература

Описание протокола RTP можно найти в RFC-1889.

2. В релятивизме "свет" есть мифическое явление само по себе, а не физическая волна, являющаяся волнением определенной физической среды. Релятивистский "свет" - это волнение ничего в ничем. У него нет среды-носителя колебаний.

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

Протоколы RTP и RTCP в VoIP

RTP является основным транспортным протоколом в сетях IP-телефонии. RTP (Real Time Protocol) - протокол реального времени, был создан для передачи мультимедийной (ауди, видео), закодированной и упакованной в пакеты, информации по IP сетям в строгих временных рамках. Передача сегментов RTP происходит поверх протокола UDP и IP, соответственно на разных уровнях модели OSI. Использования протокола UDP, не гарантирующего доставку, связано со строгими временными рамками передачи мультимедийной информации в реальном времени, а также неспособностью протокола TCP работать в режиме реального времени. Поэтому не смотря на потерю части данных своевременность доставки более важна в данном случае.
В общем виде распределение протоколом по уровням модели OSI выглядит следующим образом:
Транспортный уровень: RTP поверх UDP
Сетевой: IP
Канальный: Ethernet
Физический: Ethernet
При передачи мультимедийной информации с использованием протокола RTP используется инкапсуляция следующего вида:

Минимальным размером RTP сегмента является 12 байт. Первые два бита определяют версию протокола. На сегодняшний день используется RTPv.2 . Следующее поле Р также имеет размер 2 бита и указывает на наличие символов заполнителей в поле данных, при использовании сегментов одинаковой длинны. Поле X определяет используется ли расширенный заголовок. Затем поле СС, состоящее из 4 бит, определяет число CSRC-полей в конце RTP заголовка, т. е. число источников, формирующих поток. Затем идет поле М - маркерный бит, использующийся для выделения важных данных. Следующее поле РТ имеет размер 7 бит. Предназначено для определения типа полезной нагрузки - данные необходимые для приложения. По указанному коду приложение определяет тип мультимедийной информации и способ декодирования.
Остальная часть заголовка состоит из поля порядкового номера (SequenceNumber) - последовательный номер сегмента, который отслеживает порядок пакетов и их потерю; поля метки времени (Time Stamp) - код синхронизации, указывающий на момент времени первой кодированной выборки в полезной нагрузке, данная отметка используется буферами восстановления синхронизации для ликвидации потерь качества, вызванного вариацией задержки; поля источника синхронизации SSRC - произвольное число, отличающее один RTP-сеанс от другого, для создания возможности мультиплексирования. После постоянной фиксированной части RTP-заголовка могут добавляться до 15 тридцати двух разрядных CSRC-полей, которые идентифицируют источники данных.
Опишем процедуру установления RTP сеанса. Протоколом установлено, что трафик разного типа передается в отдельных сеансах связи. Для установления сеанса необходимо определить пару транспортных адресов назначения т.е. один сетевой адрес и два порта для RTP и RTCP. Так для видеоконференции необходимо аудио и видео передавать в разных сеансах с соответственно разными портами назначения. Передача разных типов трафика с использованием перемежения в одном сеансе могло бы вызвать следующие проблемы:
- при изменении одного из типов трафика невозможно определить какой параметр в сеансе необходимо заменить на новое значение;
- для установления сеанса используется только один интервал тайминга, а при передачи разнородного трафика у каждого типа будет свой интервал, и они будут различаться;
- микшер RTP не может объединять перемеженные потоки различных типов трафика в один поток;
- передаче нескольких типов трафика в одном сеансе RTP невозможно по следующим причинам: применение различных сетевых путей или распределение сетевых ресурсов; прием подмножества мультимедийных данных, когда это требуется, например, только звука, если видеосигнал превысил доступную полосу пропускания; реализации приемника, которые используют отдельные процессы для различных типов трафика, в то время как использование отдельных сеансов RTP допускает реализации как с одним, так и с множеством процессов.

Однако протокол RTP (Real-time Transport Protocol) и UDP (User Datagram Protocol) не гарантируют качество, т.е не работают с QoS (Quality of Service). Поэтому протокол RTP поддерживается протоколом RTCP (Real-Time Transport Control Protocol), который предоставляет дополнительную информацию о состоянии сеанса связи RTP.
Протокол RTCP выполняет четыре основные функции:
I. Основная задача протокола RTCP - это обеспечение обратной связи для гарантирования качества при передаче данных. Обратная связь может быть непосредственно полезна при применении при передаче адаптивного кодирования. Также при использовании IP мультикастинга для получателей крайне важно диагностировать ошибки при передаче сообщений(пакетов). Посылка сообщений с отчетами о приеме позволяют передающей стороне определить причину неудачной передачи сообщений, в случаи возникновении таковой.
II. RTCP содержит неизменяемый идентификатор транспортного уровня для RTP источника, который имеет название «каноническое имя» или «Сname» (Canonical Name). Так как SSRC-идентификатор может быть изменятся, в случае нахождения коллизий (столкновений) , для получателя необходимо значение Сname, для того чтобы отслеживать каждого из участников. Получателям также использует Cname, чтобы установить соответствие между многими потоками данных от одного участника при установлении нескольких сессий одновременно, например, чтобы синхронизовать аудио и видео каналы при передаче видео со звуком.
III. Перечисленные выше две функции подразумевают, что все участники сеансов посылали RTCP-пакеты, поэтому скорость передачи должна контролироваться для того, чтобы RTP мог устанвливать сеансы с большим числом пользователей. При передаче каждым участником своих управляющих пакетов всем остальным любой партнер может независимо определить полное число участников сессии. Это необходимо для расчетов частоты передачи сообщений RTCP.
IV. Данная функция служит для передачи минимально необходимой управляющей информации, такой как идентификатор участников, которая используется графическим интерфейсом пользователя. Эта функция используется для слабо контролируемых сессий, когда пользователи входят и выходят без должного согласование параметров и характеристик. RTCP выполняет функции удобного канала для контакта со всеми участниками, но он необязательно поддерживает все коммуникационные требования приложения.
В IP сетях с использованием мультикастинга функции один, два и три являются обязательными при использовании RTP сессий. Также рекомендуется их использование и при передаче в прочих сетях и средах. На сегодняшний день рекомендуется разработчикам приложений RTP использовать средства позволяющие работать в мультикастном режиме, а не только в уникастном.
Рассмотрим формат пакетов RTCP.
Стандартом протокола определено несколько типов пакетов RTCP. RTCP предназначен для передачи служебной информации:
sr: Отчет отправителя. Необходим для статистики приема и передачи участников сеанса, которые непосредственно являются активными отправителями;
rr: Отчет получателя. Необходим для статистики от участников, которые не являются получателями;
sdes: Описывает источник, включает Cname;
bye: Служит для индикации завершения (выхода) сеанса;
app: Специфические функции приложений;
Каждый RTCP пакет состоит из постоянной части, как и для протокола RTP, которая используется RTP-пакетами, за ней следуют поля, которые могут изменяться по длинне в зависимости от типа пакета, но кратную 32 бит. Требования выравнивания и поле длины в фиксированной части заголовка введены для того, чтобы сделать RTCP-пакеты объединяемыми. Несколько RTCP-пакетов могут быть соединены друг с другом без введения каких-либо сепараторов, для того чтобы получить составной RTCP-пакет, который посылается в рамках транспортного протокола низкого уровня, например UDP. Не существует специального счетчика индивидуальных RTCP-пакетов, так как протокол низкого уровня задаст общую длину и определит конец составного пакета.


Формат RTCP пакета сообщения отправителя выглядит следующим образом, как показано на рисунке выше.

Пакеты RTCP подвергаются следующим проверкам на корректность.
- RTP поле версии должно быть равно 2.
- Поле типа данных первого RTCP пакета в составном пакете должно быть SR или RR.
- Бит заполнителя (P) должен быть равен нулю для первого пакета составного RTCP пакета, так как заполнитель может присутствовать только в последнем.
- Длина полей индивидуальных RTCP-пакетов должна в сумме равняться полной длине составного пакета.

Протоколы RTP и RSVP,

http://www.isuct.ru/~ivt/books/NETWORKING/NET10/269/pa.html

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

Непрекращающийся рост Интернета и частных сетей предъявляет новые требования к пропускной способности. Клиент-серверные приложения далеко превосходят Telnet по объемам передаваемых данных. World Wide Web привел к гигантскому увеличению графика графической информации. Сегодня к тому же голосовые и видеоприложения выдвигают свои специфические требования к и без того перегруженным сетям.

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

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

АТМ - единственная сетевая технология, которая изначально разрабатывалась для поддержки обычного трафика TCP и UDP наряду с трафиком реального времени. Однако ориентация на АТМ означает либо создание новой сетевой инфраструктуры для трафика реального времени, либо замену имеющейся конфигурации на базе IP, причем оба варианта обойдутся весьма недешево.

Поэтому потребность в поддержке нескольких типов трафика с различными требованиями к качеству услуг в рамках архитектуры TCP/IP весьма насущна. Эту задачу призваны решить два ключевых инструмента: транспортный протокол реального времени (Real-Time Transport Protocol, RTP) и протокол резервирования ресурсов (Resource Reservation Protocol, RSVP).

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

Наиболее широко используемый протокол транспортного уровня - это TCP. Хотя TCP позволяет поддерживать множество разнообразных распределенных приложений, он не подходит для приложений реального времени.

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

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

Другой широко используемый протокол транспортного уровня - UDP не имеет первых двух

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

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

В типичной среде реального времени отправитель генерирует пакеты с постоянной скоростью. Они отправляются им через одинаковые интервалы времени, проходят через сеть и принимаются получателем, воспроизводящим данные в реальном времени по их получении.

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

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

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

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

Пример приложения для микшера - комбинирование нескольких источников звука. Например, предположим, что часть систем данного аудиосеанса генерирует каждая свой собственный поток RTP. Большую часть времени только один источник активен, хотя иногда одновременно «говорят» несколько источников.

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

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

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

• поле версии (2 бита): текущая версия - вторая;
• поле заполнения (1 бит): это поле сигнализирует о наличии заполняющих октетов в конце полезной нагрузки. (Заполнение применяется, когда приложение требует, чтобы размер полезной нагрузки был кратен, например, 32 битам.) В этом случае последний октет указывает число заполняющих октетов;
• поле расширения заголовка (1 бит): когда это поле задано, то за основным заголовком следует еще один, дополнительный, используемый в экспериментальных расширениях RTP;
• поле числа отправителей (4 бита): это поле содержит число идентификаторов отправителей, чьи данные находятся в пакете, причем сами идентификаторы следуют за основным заголовком;
• поле маркера (1 бит): смысл бита маркера зависит от типа полезной нагрузки. Бит маркера используется обычно для указания границ потока данных. В случае видео он задает конец кадра. В случае голоса он задает начало речи после периода молчания;
• поле типа полезной нагрузки (7 бит): это поле идентифицирует тип полезной нагрузки и формат данных, включая сжатие и шифрование. В стационарном состоянии отправитель использует только один тип полезной нагрузки в течение сеанса, но он может его изменить в ответ на изменение условий, если об этом сигнализирует протокол управления передачей в реальном времени (Real-Time Transport Control Protocol);
• поле порядкового номера (16 бит): каждый источник начинает нумеровать пакеты с произвольного номера, увеличиваемого затем на единицу с каждым посланным пакетом данных RTP. Это позволяет обнаружить потерю пакетов и определить порядок пакетов с одинаковой отметкой о времени. Несколько последовательных пакетов могут иметь одну и ту же отметку о времени, если логически они порождены в один и тот же момент (например, пакеты, принадлежащие одному и тому же видеокадру);
• поле отметки о времени (32 бита): здесь записывается момент времени, когда был создан первый октет данных полезной нагрузки. Единицы, в которых в этом поле указывается время, зависят от типа полезной нагрузки. Значение определяется по локальным часам отправителя;
• поле идентификатора источника синхронизации: генерируемое случайным образом число, уникальным образом идентифицирующее источник в течение сеанса.

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

Протокол RTP используется только для передачи пользовательских данных - обычно многоадресной - всем участникам сеанса. Отдельный протокол управления передачей в реальном времени (Real-Time Transport Control Protocol, RTCP) работает с несколькими адресатами для обеспечения обратной связи с отправителями данных RTP и другими участниками сеанса.

RTCP использует тот же самый базовый транспортный протокол, что и RTP (обычно UDP), но другой номер порта. Каждый участник сеанса периодически посылает RTCP-пакет всем остальным участникам сеанса. RFC 1889 описывает три функции, выполняемые RTCP.

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

Обратная связь с получателями важна также для диагностирования ошибок при распространении.

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

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

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

При небольшом числе участников один пакет RTCP посылается максимум каждые пять секунд. RFC 1889 описывает алгоритм, согласно которому участники ограничивают частоту RTCP-пакетов в зависимости от общего числа участников. Цель состоит в том, чтобы трафик RTCP не превышал 5% от общего трафика сеанса.

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

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

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

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

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

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

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

Некоторые получатели могут не иметь достаточной вычислительной мощи для обработки компонентов с высоким разрешением или быть подключены к сети через подсеть или канал, не обладающие достаточной емкостью, чтобы пропустить полный сигнал.

Резервирование ресурсов позволяет маршрутизаторам заранее определить, в состоянии ли они осуществить доставку многоадресного трафика всем получателям.

В предыдущих попытках реализации резервирования ресурсов и в принятых во frame relay и АТМ подходах необходимые ресурсы запрашивает источник потока данных. Этот метод достаточен в случае одноадресной передачи, потому что передающее приложение передает данные в определенном темпе, а необходимый уровень качества услуг заложен в схему передачи.

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

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

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

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

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

RSVP не определяет содержания спецификации потока, он просто передает запрос. Спецификация потока обычно включает класс услуг, Rspec (R означает резерв) и Tspec (T означает трафик). Два других параметра представляют собой набор чисел. Параметр Rspec определяет требуемое качество услуг, а параметр Tspec описывает поток данных. Содержимое Rspec и Tspec прозрачно для RSVP.

В принципе, спецификация фильтра описывает произвольное подмножество пакетов одного сеанса (то есть тех пакетов, адресат которых определяется данным сеансом). Например, спецификация фильтра может определять только конкретных отправителей либо определять протоколы или пакеты, поля протокольных заголовков которых совпадают с заданными.

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

Основная сложность RSVP связана с многоадресной рассылкой. Пример многоадресной конфигурации приведен на рис. 6 . Эта конфигурация состоит из четырех маршрутизаторов. Канал между двумя любыми маршрутизаторами, изображаемый линией, может представлять собой как прямой канал, так и подсеть. Три хоста - Gl, G2 и G3 - входят в одну группу и получают дейтаграммы с соответствующим групповым адресом. Данные по этому адресу передаются двумя хостами - S1 и S2. Красная линия соответствует дереву маршрутизации для S1 и данной группы, а синяя линия - для S2 и данной группы. Линии со стрелками указывают направление передачи пакетов от S1 (красная) и от S2 (синяя).

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

RSVP использует два основных типа сообщений: Resv и Path. Сообщения Resv генерируются получателями и распространяются вверх по дереву, причем каждый узел по пути объединяет и компонует пакеты от разных получателей, когда это возможно. Эти сообщения приводят к переходу маршрутизатора в состояние резервирования ресурсов для данного сеанса (группового адреса). В конце концов все объединенные сообщения Resv достигают хостов-отправителей. Основываясь на полученной информации, они задают надлежащие параметры управления графиком для первого транзитного узла.

Рис. 7 показывает поток сообщений Resv. Обратите внимание: сообщения объединяются; следовательно, только одно сообщение передается вверх по любой ветви комбинированного дерева доставки. Однако эти сообщения должны периодически рассылаться вновь для продления срока резервирования ресурсов.

Сообщение Path используется для распространения информации об обратном маршруте. Всеми современными протоколами многоадресной маршрутизации поддерживается только прямой маршрут в виде дерева распространения (вниз от отправителя). Но сообщения Resv должны передаваться в обратном направлении через все промежуточные маршрутизаторы всем хостам-отправителям.

Поскольку протокол маршрутизации не предоставляет информации об обратном маршруте, она передается RSVP в сообщениях Path. Любой хост, желающий стать отправителем, посылает сообщение Path всем членам группы. По пути каждый маршрутизатор и каждый хост-адресат переходит в состояние path, указывающее, что пакеты для этого отправителя должны пересылаться на транзитный узел, с которого данный пакет получен. Рис. 5 показывает, что пакеты Path передаются по тем же самым путям, что и пакеты данных.

Рассмотрим работу протокола RSVP. С точки зрения хоста работа протокола состоит из следующих этапов (первые два этапа в этой последовательности имеют иногда обратную очередность).

1. Получатель вступает в группу многоадресной рассылки посредством отправки сообщения по протоколу IGMP соседнему маршрутизатору.
2. Потенциальный отправитель отправляет сообщение по адресу группы.
3. Получатель принимает сообщение Path, идентифицирующее отправителя.
4. Теперь, когда получатель имеет информацию об обратном пути, он может отправлять сообщения Resv с дескрипторами потока.
5. Сообщения Resv передаются по сети отправителю.
6. Отправитель начинает передачу данных.
7. Получатель начинает прием пакетов данных.

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

В качестве примера реального применения этих протоколов можно привести модель VoIP (Voice over IP) – передачи голоса по IP-сетям, которая описана в стандарте H.232 и предусматривает передачу аудио-, видеоинформации и данных через IP-сеть. В этом случае протокол реального времени RTP используется для установления соединения, а протокол RSVP – для резервирования ресурсов сети.

Одной из важнейших тенденций в эволюции современных телекоммуникаций является развитие средств IP-телефонии - множества новых технологий, обеспечивающих передачу мультимедийных сообщений (речи, данных, видео) через информационно-вычислительные сети (ИВС), построенные на базе протокола IP (Internet Protocol), в том числе локальные, корпоративные, глобальные вычислительные сети и сеть Internet. Понятие IP-телефонии включает в себя Internet-телефонию, позволяющую организовать телефонную связь между абонентами сети Internet, между абонентами телефонных сетей общего пользование (ТСОП) через Internet, а также телефонную связь абонентов ТСОП и Internet друг с другом.

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

Какие международные стандарты и протоколы регламентируют основные параметры и алгоритмы функционирования аппаратных и программных средств связи, используемых в IP-телефонии? Очевидно, как следует из названия, данная технология построена на базе протокола IP, который, впрочем, используется не только для телефонии: первоначально он был разработан для передачи цифровых данных в ИВС с коммутацией пакетов.

В сетях, не обеспечивающих гарантированное качество обслуживания (к ним относятся сети, построенные на основе протокола IP), пакеты могут теряться, может изменяться порядок их поступления, данные, передаваемые в пакетах, могут искажаться. Для обеспечения надежной доставки передаваемой информации в этих условиях используются различные процедуры транспортного уровня. При передаче цифровых данных для этой цели применяется протокол ТСР (Transmission Control Protocol). Данный протокол обеспечивает надежную доставку данных и восстанавливает исходный порядок следования пакетов. Если в пакете обнаружена ошибка, или пакет теряется, процедуры TCP посылают запрос на повторную передачу.

Для приложений аудио- и видеоконференцсвязи задержки пакетов гораздо в большей степени влияют на качество сигнала, чем отдельные искажения данных. Различия в задержках могут приводить к появлению пауз. Для таких приложений необходим другой протокол транспортного уровня, обеспечивающий восстановление исходной последовательности пакетов, их доставку с минимальной задержкой, воспроизведение в реальном масштабе времени в точно заданные моменты, распознавание типа трафика, групповую или двухстороннюю связь. Таким протоколом является транспортный протокол реального времени RTP (Real-Time Transport Protocol). Данный протокол регламентирует передачу мультимедийных данных в пакетах через ИВС на транспортном уровне и дополняется протоколом управления передачей данных в реальном масштабе времени RTCP (Real-Time Control Protocol). Протокол RTCP, в свою очередь, обеспечивает контроль доставки мультимедийных данных, контроль качества обслуживания, передачу информации об участниках текущего сеанса связи, управление и идентификацию, и иногда считается частью протокола RTP.

Во многих публикациях, посвященных IP-телефонии, отмечается, что большая часть сетевого оборудования и специального программного обеспечения для данной технологии разрабатывается на базе Рекомендации Сектора стандартизации электросвязи Международного союза электросвязи (МСЭ-Т) Н.323 (в том числе, TAPI 3.0, NetMeeting 2.0 и т.д.). Как соотносится Н.323 с протоколами RTP и RTCP? Н.323 - это широкий концептуальный каркас, включающий множество других стандартов, каждый из которых отвечает за различные аспекты передачи информации. Большинство из этих стандартов, например, стандарты аудио- и видеокодеков, имеют широкое применение не только в IP-телефонии. Что касается протоколов RTP/RTCP, то они составляют основу стандарта H.323, ориентированы на обеспечение именно IP-технологии, лежат в основе организации IP-телефонии. Рассмотрению данных протоколов и посвящена эта статья.

2. Основные понятия

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

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

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

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

Хотя протокол RTP считается протоколом транспортного уровня, он функционирует обычно поверх другого протокола транспортного уровня UDP (User Datagram Protocol). Оба протокола вносят свои доли в функциональность транспортного уровня. Следует отметить, что RTP и RTCP являются независимыми от нижележащих уровней - транспортного и сетевого, поэтому протоколы RTP/RTCP могут использоваться с другими подходящими транспортными протоколами.

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

Для того, чтобы протокол RTP был более гибким и мог применяться для различных приложений, некоторые его параметры сделаны преднамеренно не определенными, но зато в нем предусмотрено понятие профиля. Профиль (profile) - это набор параметров протоколов RTP и RTCP для конкретного класса приложений, определяющий особенности их функционирования. В профиле определяются использование отдельных полей заголовков пакетов, типы трафика, дополнения к заголовкам и расширения заголовков, типы пакетов, услуги и алгоритмы обеспечения безопасности связи, особенности использования протокола нижележащего уровня и т.д (в качестве примере в разделе 11 рассмотрен предложенный в RFC 1890 профиль RTP для аудио- и видеоконференций с минимальным управлением). Каждое приложение обычно работает только с одним профилем, и задание типа профиля происходит путем выбора соответствующего приложения. Никакой явной индикации типа профиля номером порта, идентификатором протокола и т.п. не предусмотрено.

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

Особенности передачи мультимедийных данных при проведении аудио- и видеоконференций рассмотрены в следующих разделах.

2.1. Групповая аудиоконференцсвязь

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

Приложение аудиоконференцсвязи, используемое каждым участником конференции, посылает звуковые данные малыми порциями, например, продолжительностью 20 мс. Каждой порции звуковых данных предшествует заголовок RTP; заголовок RTP и данные поочередно формируются (инкапсулируются) в пакет UDP. Заголовок RTP показывает, какой тип кодирования звука (например, ИКМ, АДИКМ или LPC) использовался при формировании данных в пакете. Это дает возможность изменять тип кодирования в процессе конференции, например, при появлении нового участника, который использует линию связи с низкой полосой пропускания, или при перегрузках сети.

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

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

2.2. Видеоконференцсвязь

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

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

2.3. Понятие о микшерах и трансляторах

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

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

Микшеры и трансляторы могут быть разработаны для ряда целей. Пример: микшер видеосигнала, который масштабирует видеоизображения отдельных людей в независимых потоках видеосигнала и выполняет их композицию в один поток видеосигнала, моделируя групповую сцену. Примеры трансляции: соединение группы хостов, использующих только протоколы IP/UDP с группой хостов, которые воспринимают только ST-II, или перекодирование видеосигнала пакет за пакетом из индивидуальных источников без пересинхронизации или микширования. Детали работы микшеров и трансляторов рассмотрены в разделе 5.

2.4. Порядок байтов, выравнивание и формат меток времени

Все поля пакетов RTP/RTCP передаются по сети байтами (октетами); при этом наиболее значащий байт передается первым. Все данные полей заголовка выравниваются в соответствии с их длиной. Октеты, обозначенные как дополнительные, имеют нулевое значение.

Абсолютное время (время Wallclock) в RTP представлено с использованием формата временной метки сетевого протокола времени NTP (Network Time Protocol), который является отсчетом времени в секундах относительно нуля часов 1 января 1900 года. Полный формат временной метки NTP - 64-разрядное число без знака с фиксированной запятой с целой частью в первых 32 битах и дробной - в последних 32 битах. В некоторых полях с более компактным представлением используются только средние 32 бита - младшие 16 битов целой части и старшие 16 битов дробной части.

В следующих двух разделах данной статьи (3 и 4) рассматриваются форматы пакетов и особенности функционирования протоколов RTP и RTCP соответственно.

3. Протокол передачи данных RTP

3.1. Поля фиксированного заголовка RTP

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

Первые двенадцать октетов присутствуют в каждом пакете RTP, в то время как поле идентификаторов включаемых источников CSRC (сontributing source) присутствует только тогда, когда оно вставлено микшером. Поля имеют следующие назначения.

Версия (V): 2 бита. Это поле идентифицирует версию RTP. В данной статье рассматривается версия 2 протокола RTP (величина 1 использовалась в первой черновой версии RTP).

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

Расширение (X): 1 бит. Если бит расширения установлен, то за фиксированным заголовком следует расширение заголовка с форматом, определенным в .

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

Маркер (M): 1 бит. Интерпретация маркера определяется профилем. Он предназначен для того, чтобы позволить маркировать в потоке пакетов значительные события (например, границы видеокадра). Профиль может вводить дополнительные биты маркера или определять, что никакого бита маркера не имеется, изменяя число битов в поле типа трафика (см. ).

Тип трафика (PT): 7 бит. Это поле идентифицирует формат трафика RTP и определяет его интерпретацию приложением. Профиль определяет заданное по умолчанию статическое соответствие значений РТ и форматов трафика. Дополнительные коды типа трафика могут быть определены динамически через не-RTP средства. Отправитель пакета RTP в любой момент времени выдает единственное значение типа трафика RTP; это поле не предназначено для мультиплексирования отдельных мультимедийных потоков (см. ).

Порядковый номер: 16 бит. Значение порядкового номера увеличивается на единицу с каждым посланным информационным пакетом RTP и может использоваться получателем для обнаружения потерь пакетов и восстановления их исходной последовательности. Начальная величина порядкового номера выбирается случайным образом, чтобы усложнить попытки взлома ключа с опорой на известные значения данного поля (даже если шифрование не используется источником, так как пакеты могут проходить через транслятор, который применяет шифрование). Временная метка: 32 бита. Временная метка отражает момент дискретизации для первого октета в информационном пакете RTP. Момент дискретизации должен быть получен от таймера, который увеличивает свои значения монотонно и линейно во времени, для обеспечения синхронизации и определения джиттера (см. раздел 4.3.1). Разрешение таймера должно быть достаточным для желательной точности синхронизации и измерения джиттера поступления пакетов (одного отчета таймера на видеокадр обычно бывает недостаточно). Частота таймирования зависит от формата передаваемого трафика и задается статически в профиле или спецификации формата трафика или может задаваться динамически для форматов трафика, определенных через «не-RTP средства». Если пакеты RTP генерируются периодически, то должны использоваться номинальные моменты дискретизации, определяемые таймером дискретизации, а не значения системного таймера. Например, для звукового сигнала с фиксированной скоростью желательно, чтобы датчик временной метки увеличивался на единицу для каждого периода дискретизации. Если звуковое приложение из устройства ввода читает блоки, содержащие 160 отсчетов, то временная метка при этом должна увеличиваться на 160 для каждого такого блока, независимо от того, передан ли блок в пакете или сброшен, как пауза. Начальное значение временной метки, так же, как и начальное значение порядкового номера, является случайной величиной. Несколько последовательных пакетов RTP могут иметь равные временные метки, если они логически генерируются одновременно, например, принадлежат одному и тому же видеокадру. Последовательные пакеты RTP могут содержать немонотонные временные метки, если данные не передаются в порядке дискретизации, как в случае интерполируемых видеокадров MPEG (однако порядковые номера пакетов при передаче все же будут монотонными).

SSRC: 32 бита. Поле SSRC (synchronization source) идентифицирует источник синхронизации (см. список используемых сокращений и терминов). Этот идентификатор выбирается случайным образом так, чтобы никакие два источника синхронизации в рамках одного и того же сеанса связи RTP не имели одинаковых идентификаторов SSRC. Хотя вероятность того, что несколько источников выберут один и тот же идентификатор, низка, все же все реализации RTP должны быть готовы обнаруживать и разрешать подобные коллизии. В разделе 6 рассмотрена вероятность коллизий вместе с механизмом для их разрешения и обнаружения зацикливаний уровня RTP, основанным на уникальности идентификатора SSRC. Если источник изменяет свой исходный транспортный адрес, то он должен также выбрать новый идентификатор SSRC, чтобы его не интерпретировали как зацикленный источник.

Список CSRC: от 0 до 15 пунктов, 32 бита каждый. Список CSRC (сontributing source) идентифицирует включаемые источники трафика, содержащегося в пакете. Число идентификаторов задается полем CC. Если имеется более пятнадцати включаемых источников, то только 15 из них могут быть идентифицированы. Идентификаторы CSRC вставляются микшерами при использовании идентификаторов SSRC для включаемых источников. Например, для звуковых пакетов идентификаторы SSRC всех источников, которые были смешаны при создании пакета, перечисляются в списке CSRC, обеспечивая корректную индикацию источников сообщений для получателя.

3.2. Сеансы связи RTP

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

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

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

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

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

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

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

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

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

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

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

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

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

1999

2000