Real-Time Transport Protocol RTP является IP-базированным транспортным протоколом, используемым для передачи мультимедиаданных, таких, как видео и аудио, по сетям с коммутацией пакетов, в частности Internet. В связке с протоколами RTCP и RSVP он способен обеспечить сквозную доставку и необходимый уровень QoS для мультимедиафайлов. RTP не включает функции маршрутизации, поскольку для этого применяется дейтаграммная служба UDP (User Datagram Protocol) из стека протоколов TCP/IP. Хотя протокол TCP, ориентированный на соединение, гарантирует доставку пакетов, причиной для отказа его использования в данном случае служит низкая скорость, что неприемлемо для чувствительного ко времени трафика. Поэтому качество приносится в жертву скорости. RTP выполняет такие функции, как идентификация типа полезной нагрузки, нумерация последовательности пакетов и присвоение временных меток. Последние позволяют передавать мультимедиатрафик без потери информации и временных задержек, недопустимых для этого вида трафика. Хотя RTP разработан для многоадресной передачи, он может быть использован и для сессий типа точка--точка, например для приложений IP-телефонии. RTP-сессия устанавливается приложением, которое определяет набор адресов получателей, состоящих из адреса сети и двух номеров портов: один -- для RTP и один -- для RTCP. Каждому типу мультимедиатрафика соответствует своя сессия. К примеру, аудио- и видеочасти мультимедийной презентации будут передаваться каждая в рамках собственной сессии. Это позволяет пользователю выбирать или оба трафика, или один из них.
Real-Time Control Protocol Как уже упоминалось выше, RTCP выполняет функции управления и, взаимодействуя непосредственно с RTP, поставляет последнему управляющую информацию для диагностики и оптимизации производительности. Вдобавок он осуществляет контроль качества доставки данных. Основные функции протокола следующие:
Идентификация источника проводится на основании информации, размещающейся в заголовке RTP. Протокол RTCP преобразует 32-битное значение соответствующего поля заголовка в уникальные глобальные имена, которые идентифицируют участников любой сессии. Для внутренней синхронизации аудиовизуальной информации используются временные метки RTP и соответствующее значение реального времени. Это позволяет, к примеру, синхронизировать голос и изображение в мультимедийных презентациях. Наконец, RTCP производит масштабирование информации, в результате чего ограничивается сетевой трафик. Чтобы обеспечить выполнение всех этих функций, протокол генерирует ряд специальных управляющих пакетов. Опишем кратко пять их типов. Receiver Report (RR). Эти пакеты создаются участниками сессии, не являющимися активными отправителями. Они содержат такую информацию, как подтверждение получения пакетов, неустойчивость синхронизации между входящими пакетами, задержку, связанную с подтверждением приема. Sender Report (SR). Такие сообщения посылаются активными отправителями, участвующими в сессии. В дополнение к информации, содержащейся в RR, они включают также данные о внутренней аудиовизуальной синхронизации и количестве отправленных байтов. Source Description Items (SDES). Пакеты этого типа содержат информацию об участниках сессии. BYE. "Прощальный" пакет, с помощью которого пользователь отключается от сессии. APP. В пакет входят сведения о специфических функциях приложения. Resource Reservation Protocol Именно этот протокол обеспечивает требуемый для видеоприложений уровень QoS -- от начальной точки до конечной. Он является совместной разработкой известного научного центра Xerox PARC, Массачусетского технологического института (MIT) и Института информатики Калифорнийского университета (Information Science Institute of the University of California). Протокол позволяет резервировать ресурсы маршрутизаторов на всем пути следования мультимедийного трафика.
Запросы распространяются по направлению к отправителю до тех пор, пока не столкнутся с другим запросом. В этой точке они объединяются со всеми запросами, требующими те же ресурсы. Такой механизм позволяет обеспечить высокую надежность и масштабируемость для большой многоадресной группы пользователей. Единственное требование для успешного резервирования ресурсов заключается в том, что маршрутизаторы на всем пути должны поддерживать протокол RSVP. В противном случае запрос дальше не передается. RSVP ответственен за согласование ресурсов для видеопотока со всеми маршрутизаторами. Прежде чем предоставляются требуемые ресурсы, каждый запрос проходит двойную проверку: Policy Control и Admission Control. Первая устанавливает правомочность пользователя резервировать ресурсы, а вторая -- отслеживает имеющиеся ресурсы, чтобы гарантированно предоставить требуемый уровень QoS. Если обе проверки дают положительный результат, то программа-демон RSVP, имеющаяся в составе ПО маршрутизатора, устанавливает необходимые параметры в полях пакетов Packet Classifier и Packet Scheduler. Первое поле определяет QoS для каждого пакета, тогда как второе -- выстраивает пакеты в очередь, для того чтобы обеспечить обещанный уровень QoS для каждого потока данных, проходящих через узел.
Как уже упоминалось выше, резервирование ресурсов происходит на всех маршрутизаторах, лежащих на пути от получателя к отправителю. Обработав запрос, отправитель направляет широковещательные сообщения (PATH) группе получателей, чтобы определить обратный маршрут и зарезервировать необходимые ресурсы. В ответ на PATH получатели направляют пакет RESV, который содержит параметры требуемого уровня QoS. Именно с помощью RESV выполняется резервирование ресурсов в каждом маршрутизаторе на пути получатель--отправитель. Он устанавливает на маршрутизаторах так называемое мягкое состояние резервирования, которое предусматривает освобождение зарезервированных ресурсов через определенный отрезок времени. Для того чтобы поддерживать состояние резервирования активным, RSVP-демон должен посылать "освежающие" сообщения. Такой механизм обеспечивает динамику резервирования при изменении состава участников сессии. Real-Time Streaming Protocol Это четвертый протокол в рассматриваемом наборе. Как уже упоминалось выше, в отличие от трех предыдущих он представляет собой протокол прикладного уровня, во многом подобный HTTP и FTP в стеке TCP/IP. Его уникальным свойством является то, что он предоставляет пользователю возможность управления медиапотоком. Работает RTSP совместно с протоколами нижнего уровня, такими, как RTP, RSVP, IP и TCP/UDP. Важно понимать, что он не занимается транспортом данных -- это протокол, который, кроме управляющих функций, обеспечивает взаимодействие между оборудованием различных производителей, разными типами файлов и кодировщиками. RTSP наделен свойствами масштабируемости и взаимодействия, во многом подобными протоколу HTTP. Фактически каждая презентация или мультимедиапоток идентифицируется в протоколе своим URL. Свойства презентации наряду с другими спецификациями сохраняются в файле дескриптора презентации, также имеющего свой собственный URL. Однако между протоколами RTSP и HTTP есть ряд существенных различий. Одно из основных заключается в том, что в первом и сервер, и клиент способны генерировать запросы. Например, видеосервер может послать запрос для установки параметров воспроизведения определенного видеопотока. Далее, протоколом RTSP предусматривается, что управление состоянием или связью должен осуществлять сервер, тогда как HTTP вообще никакого отношения к этому не имеет. Наконец, в RTSP данные могут передаваться вне основной полосы (out-of-band) другими протоколами, например RTP, что невозможно в случае HTTP. Сервис RTSP поддерживается набором инструкций, которыми обмениваются между собой сервер и клиент. Они отсылаются в виде RTSP-пакетов, содержащих установочные параметры для потока. Вот некоторые из них: DESCRIBE. Клиент требует у сервера описание презентации или медиаобъекта, указанное в URL запроса; ANNOUNCE. Если эта инструкция посылается от клиента серверу, то в ней содержится описание презентации или медиаобъекта, указанное в URL запроса к серверу. Отправленная в обратном направлении, она обновляет описание сессии в режиме реального времени; SETUP. Клиент запрашивает у сервера ресурсы и начинает RTSP-сессию; PLAY. Клиент просит сервер начать передачу данных в потоке, выделенном с помощью SETUP; PAUSE. Клиент временно приостанавливает доставку данных без освобождения ресурсов; TEARDOWN. Клиент просит сервер прекратить доставку указанного потока и освободить связанные с ним ресурсы.
В заключение отметим, что основной ценностью потоковых технологий является возможность доставки мультимедиаконтента по сетям с коммутацией пакетов. По мере объединения телефонных и пакетных сетей они будут играть все большую роль в повседневной жизни, а распространение технологий широкополосного доступа превратят мечту о просмотре по запросу кинофильмов из различных фильмотек, видеофайлов и других мультимедийных данных в реальность.
|