Транспортные протоколы для передачи трафика приложений реального времени.
К трафику реального времени относится поток данных при проведении аудио и видеоконференций, компьютерную телефония и т.п. В компьютерных сетях возможна потеря пакетов, изменение их порядка в процессе транспортировки, а также вариация времени доставки в достаточно широких пределах. В приложения реального времени отправитель генерирует поток данных с постоянной скоростью, а приемник должен предоставлять эти данные приложению с той же скоростью. Такие приложения включают аудио- и видеоконференции, компьютерную телефонию, интерактивные сетевые игры и.т.д.
Наиболее широко используемым протоколом транспортного уровня является ТСР. Однако использование протокола ТСР в качестве транспортного протокола для этих приложений невозможно по следующим причинам:
1. протокол ТСР позволяет установить соединение только между двумя компьютерами. А значит, он не подходит для многоадресной передачи.
2. Протокол ТСР предусматривает повторную передачу потерянных сегментов, прибывающих, когда приложение реального времени уже их не ждет.
3. Протокол ТСР не имеет механизма синхронизации информации с сегментами, что является основным требованием приложений реального времени.
Другой протокол транспортного уровня UDP не имеет части ограничений ТСР, но и он не имеет механизма синхронизации передаваемой информации.
Несмотря на то, что каждое приложение реального времени может иметь свои собственные механизмы для поддержки передачи в реальном времени. Они имеют много общих черт, что делает определение единого протокола весьма желательным.
Эту задачу и призван решать новый транспортный протокол реального времени – RTP (Real-Time Transport Protocol), который гарантирует доставку данных одному или более адресатам с задержкой в заданных пределах времени.
Протокол RTP не поддерживает каких-либо механизмов доставки пакетов, обеспечения достоверности передачи и надежности соединения. Эти все функции возлагаются на транспортный протокол. Протокол RTP работает поверх UDP и может поддерживать передачу данных между несколькими участниками RTP-соединения. Он может работать и поверх любой другой сетевой транспортной среды, поддерживает одновременную доставку по многим адресам, если мультикастинг поддерживается нижележащим сетевым уровнем.
Следует иметь в виду, что сам по себе RTP не обеспечивает своевременной доставки и не предоставляет каких-либо гарантий уровня сервиса (QoS). Пакеты RTP содержат следующие поля: идентификатор отправителя, указывающий, кто из участников генерирует данные, отметки о времени генерирования пакета, чтобы данные могли быть воспроизведены принимающей стороной с правильными интервалами, информация о порядке передачи, а также информация о характере содержимого пакета, например, о типе кодировки данных. Наличие такой информации позволяет оценить величину начальной задержки и объема буфера передачи.
На практике протокол RTP неотделим от протокола RTCP (RTP control protocol), который служит для мониторинга QоS и для передачи информации об участниках обмена в ходе сессии.
При организации аудиоконференции каждый участник должен иметь адрес и два порта, один для мультмедиа-данных, другой — для управляющих RTCP-пакетов. Эти параметры должны быть известны всем участникам конференции. При аудиоконференциях каждый из участников пересылает небольшие закодированные звуковые фрагменты длительностью порядка 20 мсек. Каждый из таких фрагментов помещается в поле данных RTP-пакета, который в свою очередь вкладывается в UDP-дейтограмму.
При передаче звука весьма важным становится взаимное положение закодированных фрагментов во времени. Для решения задачи корректного воспроизведения заголовки пакетов RTP содержат временную информацию и порядковые номера.
Так как участники конференции могут появляться и исчезать по своему усмотрению, полезно знать, кто из них присутствует в сети в данный момент и как до них доходят передаваемые данные. Для этой цели периодически каждый из участников транслирует через порт RTCP мультикастинг-сообщение, содержащее имя участника и диагностические данные.
Если в ходе конференции передается не только звук, но и изображение, они пересылаются как два независимых потока с использованием двух пар UDP-портов. Пакеты посылаются независимо для каждой из этих двух сессий.
Один пакет транспортного нижнего уровня, например, UDP, обычно содержит один RTP-пакет.
Управляющий пакет RTCP, который содержит фиксированный заголовок, сходный с RTP, и за ним следуют структурные элементы, зависящие от типа RTCP-пакета. Обычно несколько RTCP-пакетов посылаются как составной RTCP-пакет, вложенный в дейтограмму нижележащего уровня.
Период с момента формирования группы участников RTP-обмена до ее исчезновения называется сессия RTP. Для каждого из участников сессия определяется конкретной парой транспортных адресов (сетевой адрес и номера портов для RTP и RTCP). Транспортный адрес места назначения может быть общим для всех участников сессии. Допускается реализация нескольких сессий для каждого из участников одновременно.
Источник потока RTP-пакетов, определяется 32-битным числовым SSRC-идентификатором, который записывается в заголовок RTP-пакета и не зависит от сетевого адреса. Все пакеты от источника синхронизации образуют часть с идентичной временной привязкой и нумерацией. Эти данные используются принимающей стороной при воспроизведении. Источниками синхронизации могут служить источники первичного сигнала (микрофоны или видеокамеры), а также RTP-смесители. SSRC-идентификатор представляет собой случайное число, которое является уникальным для данной RTP-сессии. Если участник формирует несколько потоков в рамках одной RTP-сессии (например, от нескольких видеокамер), каждый участник должен быть снабжен уникальным SSRC-идентификатором.
Оконечной системой называется приложение, которое генерирует или воспринимает данные, посылаемые в виде RTP-пакетов. Оконечная система может выступать в качестве одного или нескольких источников синхронизации для конкретной сессии.
Промежуточная система, которая получает RTP-пакеты от одного или нескольких источников, при необходимости меняет их формат, объединяет и пересылает их адресатам называется смесителем. Так как временная привязка входных пакетов может отличаться, смеситель осуществляет их синхронизацию и генерирует свой собственный поток RTP-пакетов. Таким образом, все посылаемые пакеты имеют в качестве источника синхронизации смеситель.
Приложение, которое получает RTCP-пакеты, посланные участниками RTP-сессии, в частности, диагностические сообщения, производит оценку состояния связи, хранит долгосрочную статистику обмена.
Абсолютное время представляется с помощью временных меток в соответствии с форматом NTP (network time protocol), который характеризует время в секундах от начала суток (UTC) 1 января 1900 года. Полное разрешение временной метки NTP определяется 64-битовым числом с фиксированной запятой без знака. Целочисленная часть задается первыми 32 битами, а дробная часть — последними. В некоторых полях, где допустимо более компактное представление, используются только средние 32 бита (16 бит — целочисленная часть и 16 бит — дробная). Заголовок RTP-пакета имеет следующий формат (рис.6.6).
Первые 12 байт присутствуют во всех RTP-пакетах, в то время как список CSRC-идентификаторов присутствует только, когда пакет формируется смесителем. Поля имеют следующие назначения:
Рис. 6.6. Заголовок пакета RTP
V (2 бита). Поле версии. Текущая версия- вторая.
Р (1 бит). Поле заполнения. Это поле сигнализирует о наличии заполняющих байт в конце полезной нагрузки. Заполнение применяется, когда приложение требует, чтобы размер полезной нагрузки был кратен, например, 32 битам. В этом случае последний байт указывает число заполняющих байт.
Х (1 бит). Поле расширения заголовка. Когда это поле задано, то за основным заголовком следует еще один дополнительный, используемый в экспериментальных расширениях RTP.
СС (4 бита). Поле числа отправителей. Это поле содержит число идентификаторов отправителей, чьи данные находятся в пакете, причем сами идентификаторы следуют за основным заголовком.
М (1 бит). Поле маркера. Смысл бита маркера зависит от типа полезной нагрузки. Бит маркера используется обычно для указания границ потока данных. В случае видео он задает конец кадра. В случае голоса он задает начало речи после периода молчания.
РТ (7 бит). Поле типа полезной нагрузки. Это поле идентифицирует тип полезной нагрузки и формат данных, включая сжатие и шифрование. В стационарном состоянии отправитель использует только один тип полезной нагрузки в течение сеанса, но он может его изменить в ответ на изменение условий, если об этом сигнализирует протокол управления передачей в реальном времени (Real-Time Transport Control Protocol).
Номер по порядку (16 бит). Поле порядкового номера. Каждый источник начинает нумеровать пакеты с произвольного номера, увеличиваемого затем на единицу с каждым посланным пакетом данных RTP. Это позволяет обнаружить потерю пакетов и определить порядок пакетов с одинаковой отметкой о времени. Несколько последовательных пакетов могут иметь одну и ту же отметку о времени, если логически они порождены в один и тот же момент, как, например, пакеты, принадлежащие к одному и тому же видеокадру.
Временная метка (32 бита). Поле отметки о времени. Это поле содержит момент времени, в который первый октет данных полезной нагрузки был создан. Единицы, в которых время указывается в этом поле, зависят от типа полезной нагрузки. Значение определяется по локальным часам отправителя.
Идентификатор источника синхронизации (SSRC) (32 бита). Поле идентификатора источника синхронизации: генерируемое случайным образом число, уникальным образом идентифицирующее источник в течение сеанса и независимое от сетевого адреса. Это число играет важную роль при обработке поступившей порции данных от одного источника.
Идентификатор участников (CSRC) (32 бита). Список полей идентификаторов источника, "подмешанных" в основной поток, например, с помощью микшера. Микшер вставляет целый список SSRC идентификаторов источников, которые участвовали в построении данного RTP-пакета. Этот список и называется CSRC. Количество элементов в списке: от 0 до 15. Если число участников более 15 — выбираются первые 15. Примером может служить аудио-конференция, в RTP-пакеты которой собраны речи всех участников, каждый со своим SSRC — они-то и образуют список CSRC. При этом вся конференция имеет общий SSRC.
Протокол RTCP, как и всякий управляющий протокол, значительно сложнее и по структуре, и по выполняемым функциям (сравните, например, протоколы IP и TCP). Хотя основу протокола RTCP составляет RTP, он содержит множество дополнительных полей, с помощью которых он реализует свои функции.
Протокол RTP вместе с другими описанными стандартами позволяет с успехом передавать видео и аудио по обычным IP-сетям.
Формат поля данных определяет то, например, как, закодированный видеосигнал (H.261) должен переноситься RTP-пакетами.
В рамках RTP-стандарта определены следующие элементы поля данных:
заголовок поля данных; тип поля данных; дополнения к заголовку RTP; Расширения заголовка RTP. Безопасность. Нижележащий протокол. транспортное соответствие; соответствие RTP и RTCP адресам транспортного уровня, например, UDP-портам; инкапсуляция. Инкапсуляция RTP-пакетов может быть определена для того, чтобы позволить транспортировку нескольких RTP-пакетов в одной дейтограмме нижележащего протокола.
Управляющий протокол RTCP (RTP Сontrol Protocol) базируется на периодической передаче управляющих пакетов всем участникам сессии, используя тот же механизм рассылки, что и для пакетов данных. Этот протокол не имеет самостоятельного значения и применяется лишь совместно с RTP. Нижележащий протокол должен обеспечивать мультиплексирование пакетов данных и управления, используя разные номера портов. Протокол RTCP выполняет четыре функции.
Главной задачей данного протокола является обеспечение обратной связи для контроля качества при рассылке данных.
Стандарт определяет несколько типов RTCP пакетов, которые предназначены для переноса управляющей информации.
SR: Отчет отправителя. Для статистики приема и передачи участников, которые являются активными отправителями
RR: Отчет получателя. Для получения статистики от участников, которые не являются активными отправителями
SDES: Элементы описания источника, включая CNAME
BYE: Отмечает прекращение участия в группе
APP: Специфические функции приложения
Каждый RTCP-пакет начинается с фиксированной части, сходной с той, которая используется RTP-пакетами; за ней следуют структурные элементы, которые могут иметь переменную длину в зависимости от типа пакета, но кратную 32 бит. Требования выравнивания и поле длины в фиксированной части заголовка введены для того, чтобы сделать RTCP-пакеты объединяемыми. Несколько RTCP-пакетов могут быть соединены друг с другом без введения каких-либо сепараторов, чтобы получить составной RTCP-пакет, который посылается в рамках транспортного протокола низкого уровня, например, UDP. Не существует специального счетчика индивидуальных RTCP-пакетов, так как протокол низкого уровня задаст общую длину и определит конец составного пакета.
Каждый индивидуальный RTCP пакет в составном пакете может обрабатываться независимо, без каких-либо требований к порядку или комбинации пакетов.
Получатели RTP обеспечивают обратную связь контроля качества, используя RTCP пакеты отчетов, которые могут принимать ту или иную форму в зависимости от того, является ли получатель одновременно и отправителем. Единственное различие между формами отчета отправителя (SR) и получателя (RR), помимо кода типа пакета: отчет отправителя содержит 20-байтовую секцию информации об отправителе. SR посылается, если узел отправил какие-либо информационные пакеты за время подотчетного периода (с момента отправки предыдущего отчета), в противном случае отсылается пакет RR.
Как SR, так и RR-формы включают в себя нуль или более блоков отчетов о приеме, по одному для каждого источника синхронизации, от которого получатель принял информационные RTP-пакеты с момента последнего отчета. Каждый блок отчета о приеме содержит статистику данных, полученных от конкретного источника. Так как в SR или RR-пакет можно поместить максимум 31 блок отчетов, дополнительные RR-пакеты укладываются после исходного SR или RR-пакета.