Кришнамурти Б., Рексфорд Дж. Web-протоколы. Теория и практика

Подождите немного. Документ загружается.

430 Часть V. Web-приложения

ность, название и назначение сеанса. Эта информация передается с помощью

протокола Session Description Protocol (SDP) [HJ98J.

• Описание представления. Создание мультимедийных документов требует эф-

фективного способа для организации воспроизведения сеансов во времени.

Являясь альтернативой HTML, язык Synchronized Multimedia Integration

Language (SMIL) предоставляет возможность управлять, когда, где и как бу-

дут воспроизводиться мультимедийные сеансы [Syn98, HosOO, SmiJ.

RTP,

RTCP, SIP, SAP, RTSP и SDP специфицированы в документах запросов на

комментарии (Request for Comments), разработанных Internet Engineering Task Force

(IETF). 3a спецификацию SMIL отвечает World Wide Web Consortium (W3C).

12.3.1.

Передача данных

RTP и RTCP координируют доставку мультимедийного потока одному или не-

скольким получателям. RTP [SCFJ96, Tho96J удовлетворяет основным требовани-

ям по транспортировке мультимедийных потоков для разнообразных приложений,

таких как мультимедиа по запросу, IP-телефония и телеконференции. Данные

в RTP-накете ассоциируются с определенным звуковым сэмплом или видеокадром

в потоке; один сэмпл или кадр может размещаться в нескольких RTP-накетах. За-

головок RTP помогает получателю интерпретировать данные.

Таймирование. Получатель должен иметь информацию для координации вос-

произведения потока. Промежутки между кадрами могут быть определены из

RTP-заголовков без необходимости синхронизации часов отправителя и получате-

ля.

RTP-заголовок содержит 32-битное поле временной метки относительно мо-

мента времени, когда был воспроизведен первый сэмпл. Все пакеты звукового сэм-

пла или видеокадра имеют одно и то же значение временной метки. Первый

RTP-пакет в потоке имеет случайную отметку времени, подобно случайному на-

чальному порядковому номеру первого пакета в TCP. Временные метки способст-

вуют корректному воспроизведению последовательности сэмплов или кадров в по-

токе.

Это дает возможность получателю воспроизводить данные с соответствующи-

ми интервалами времени между последовательными сэмплами или кадрами.

Упорядочение. В RTP отсутствует механизм надежной доставки и управления

информационным потоком. Доставка RTP-накетов зависит от транспортного про-

токола. RTP не предполагает, что транспортный протокол обеспечивает упорядо-

ченный, надежный байтовый поток, поскольку повторная передача потерянных па-

кетов для многих мультимедийных потоков нежелательна. В действительности

RTP обычно работает поверх UDP, а каждый RTP-пакет передается в одном

UDP-пакете. Альтернативой является использование TCP для обеспечения надеж-

ного транспорта либо передачи потока через межсетевой экран, который отвергает

UDP-пакеты. Однако IP-пакеты могут быть потеряны или поступать не в том по-

рядке, а UDP не осуществляет какой-либо повторной передачи или упорядочения

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

чателю обрабатывать поступающие пакеты в нужном порядке и обнаруживать по-

тери пакетов. Получатель может вести статистику потерь пакетов для обратгюй

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

ректировать скорость передачи данных.

Идентификация источника. Помимо информации для таймирования и упоря-

дочения, RTP-заголовок идентифицирует источник (источники), ответственные за

Глава

12.

Доставка мультимедийных потоков 431

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

сколько источников данных (например, телеконференции). Каждый источник

идентифицируется 32-битным числом. Каждый RTP-пакет имеет синхронизирую-

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

В некоторых ситуациях синхронизирующий источник генерирует данные с помо-

щью одного или нескольких дополнительных источников. Рассмотрим приложение

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

генерирует аудиопоток и направляет RTP-пакеты промежуточной системе

—

мик-

шеру. Микшер объединяет пакеты участников и генерирует один аудиопоток. Мик-

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

участники являются участвующими источниками. При объединении отдельных ау-

диопотоков микшер формирует список участвующих источников для синхрониза-

ции составляющих потоков. Включая идентификаторы участвующих источников

в RTP-заголовок, микшер информирует получателей обо всех сторонах, ответст-

венных за объединенный ноток.

Формат представления. Интерпретация данных RTP па стороне получателя за-

висит от выбранного формата кодирования. RTP-заголовок содержит 7-битное

поле тина полезной нагрузки, идентифицирующее формат мультимедийных дан-

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

включая частоту временных меток. Формат полезной нагрузки определяет синтак-

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

ков.

Первый набор типов полезной нагрузки был определен в документе RFC 1890

[Sch96].

Новые тины кодировок регистрируются организацией Internet Assigned

Numbers Authority (IANA). Подробные описания типов полезной нахрузки, содер-

жащиеся в соответствующих документах, таких как RFC, позволяют разработчи-

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

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

RTP-микшеры и избыточное кодирование аудиоинформации, устойчивое к поте-

рям пакетов. Для достижения гибкости и расширяемости RTP также поддерживает

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

рированы IANA.

Хотя RTP предоставляет большую часть информации, необходимой для переда-

чи мультимедийных данных от отправителя одному или нескольким получателям,

иногда требуется некоторая дополнительная управляющая информация. Опреде-

ленный в том же RFC, что и RTP [SCFJ96], RTCP выполняет следующие три

функции:

• Обратная связь. RTCP предоставляет обратную связь о качестве приема, па-

пример, статистику потерь RTP-пакетов получателем. Это помогает RTP-OT-

правителю выявлять проблемы с производительностью и соответствующим

образом адаптировать скорость передачи дагпгых.

• Идентификация. RTCP связывает каждый идегггификатор источника из

RTP-пакетов с уникальным каноническим именем. Это дает возможность полу-

чателю ассоциировать набор потоков, возможно, имеющих различные 32-бит-

ные идентификаторы источников, с одним отправителем.

• Синхронизация. RTCP связывает реальное время с временными метками

в RTP-пакетах. Это позволяет получателю синхронизировать воспроизведение

нескольких потоков, вк7почая аудио и видео, принадлежащих одному сеансу.

432 Часть V. Web-приложения

12.3.2.

Создание сеанса

Отправители и получатели должны иметь способ выразить свою заинтересован-

ность в участии в определенном мультимедийном сеансе. Детали установления со-

единения между двумя или более сторонами варьируются в зависимости от тина

приложения, как говорилось ранее в разделе

12.1.3.

Это получило воплощение

в нескольких различных протоколах:

• Session Initiation Protocol (SIP). SIP [SSR99, SR99J поддерживает приложе-

ния, такие как IP-телефония, в которых принимающая сторона получает пер-

сональное приглашение для участия в сеансе. Сторона, инициирующая сеанс,

может использовать SIP для нахождения одного или более пользователей и

пригласить их принять участие в сеансе. SIP выполняет пять основных функ-

ций: (1) решает, с каким компьютером установить контакт, (2) определяет, ка-

кие параметры использовать, (3) определяет, желает ли пользователь принять

вызов, (4) устанавливает соединение с пользователем, (5) обслуживает пере-

дачу и завершает вызов.

• Session Announcement Protocol (SAP). SAP [HPWOO] поддерживает такие

приложения, как Internet-радио, в которых предполагаемые участники зара-

нее не известны. Вместо того чтобы организовывать обращение к получателям

на стороне отправителя, заинтересованные пользователи посылают запрос на

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

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

сеансу. SAP периодически отправляет анонсирующий пакет, содержащий опи-

сание сеанса, на известный адрес группового вещания и номер порта (9875).

Это можно сравнить с телевизионной станцией, которая сообщает о програм-

ме передач средствам массовой информации. SAP-слушатель получает анонс,

присоединяясь к известной группе вещания. SAP-слушатели могут сами рас-

пространять информацию о сеансе среди других пользователей.

• Real Time Streaming Protocol (RTSP). RTSP дает возможность пользователям

извлекать мультимедийное содержание но запросу, выдавая запрос мультиме-

дийному серверу, подобно отправке НТТР-занроса на Web-сервер. Мультиме-

дийные сеансы и составляющие их потоки идентифицируются URL. Клиент

выдает RTSP-запросы для получения информации о сервере и мультимедий-

ном сеансе, а также для воспроизведения, паузы, записи или просмотра пото-

ков.

RTSP предоставляет абстракцию «дистанционного сетевого управления»

мультимедийным сервером. RTSP обычно не доставляет данные. Он использу-

ется для выбора трапснорт1юго механизма (например, RTP и RTCP), транс-

портного протокола (например, индивидуальное вещание но UDP, групповое

вещание но UDP или TCP) и определенных номеров портов (например, пор-

тов 6970 и 6971). Спецификация RTSP во многом основана на синтаксисе и се-

мантике НТТР/1.1, о чем подробнее рассказывается в разделе 12.4.

12.3.3.

Описание сеанса

Вне зависимости от того, как был создан мультимедийный сеанс, участникам

нужно получить описание сеанса. Например, участникам нужно знать имя и назна-

чение сеанса, параметры представления составляющих его потоков аудио и видео,

IP-адреса и номера портов. Эта информация передается в стандартном формате,

определяемом SDP (Session Description Protocol) [HJ98]. В действительности

SDP

—

это не протокол, а язык или формат доставки информации о сеансе. Ониса-

Глава

12.

Доставка мультимедийных потоков 433

ПИЯ сеансов передаются другими протоколами, например, SIP, SAP, RTSP и HTTP.

Например, HTML-файл может иметь гипертекстовую ссылку, которая указывает

на SDP-файл. С точки зрения пользователя щелчок мышью на гипертекстовой

ссылке инициирует передачу данных аудио или видео. В реальности же Web-брау-

зер посылает HTTP-запрос Web-серверу для извлечения описания сеанса, а затем

активизирует медиаплейер для обработки сообщения HTTP-ответа (например,

SDP-файла). После этого медиаплейер осуществляет синтаксический разбор SDP-

файла и связывается с одним или с несколькими мультимедийными серверами для

извлечения аудио- и видеопотоков.

Описание SDP состоит из одной или нескольких строк текста в формате ASCII.

Каждая строка включает состоящий из одного символа

ш-ып

и значение в виде тек-

стовой строки, разделенные знаком равенства. Формат строки значения зависит от

типа. Описание содержит одну или несколько строк с информацией сеансового

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

потоках в сеансе. Информация сеансового уровня применяется ко всему сеансу и

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

имя и назначение сеанса в виде текстовых строк, например

s=Web Seminar

i=What everyone needs to know about the World Wide Web

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

номер телефона лица, ответственного за сеанс, а также URL с дополнительной ин-

формацией. Кроме того, раздел сеансового уровня может содержать информацию о

ключах шифрования, необходимых для участия в мультимедийном сеансе или для

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

время окончания сеанса в формате Network Time Protocol (NTP) [Mil92J и необя-

зательные указания по требованиям к пропускной способности.

Описание SDP также содержит информацию о каждом мультимедийном пото-

ке,

такую как тип содержания и формат кодирования (например, видео в формате

MPEG). Кроме этого, SDP сообщает информацию по доставке потока: транспорт-

ный протокол (например, UDP) и разбивка на кадры (например, RTP). Для потока

фуннового вещания описание сеанса включает IP-адрес и номер порта группового

вещания. Получатель использует эту информацию для вступления в соответствую-

щую группу вещания. Для гютока индивидуального вещания описание сеанса со-

держит доменное имя или IP-адрес источника данных. Получатель может выдать

DNS-запрос для преобразования доменного имени в IP-адрес, а затем связаться

с удаленным компьютером для установления коммуникационного взаимодействия.

Описание может также указывать на требования потока к пропускной способности

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

чтобы определить, принимать ли поток.

12.3.4.

Описание презентаций

Создание мультимедийного содержимого требует наличия стандартного способа

для подготовки презентаций. Язык гипертекстовой разметки Hypertext Markup

Language (HTML) служит этой цели применительно к традиционному Web-содер-

жанию. Однако HTML не имеет составляющих для управления временными свой-

ствами мультимедийных презентаций. Разработанный W3C стандарт SMIL пред-

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

таций с привязкой по времени, где объедены аудио-, видеоданные, текст и

434 Часть V. Web-приложения

изображения [Syn98, HosOO, SmiJ. SMIL позволяет разработчикам задавать, какое

содержание отображать (и где оно находится), где содержание следует отобразить

на экране и когда содержание должно быть отображено. Подобно HTML, SMIL

дает возможность авторам встраивать гипертекстовые ссылки, по которым осуще-

ствляются переходы, когда пользователь щелкает мышью па соответствующей чув-

ствительной области на экране.

Автор SMIL-файла может определять разметку в виде набора областей. Каждая

область представляет собой прямоугольник с определе1П1ыми размерами в определен-

ном месте на экрана. Каждая область ассоциируется с мультимедийными данными.

Рассмотрим пример, когда университетский профессор читает лекцию удаленной ау-

дитории. Презентация может связывать различные области с видеоизображением пре-

подавателя, картинкой текущего слайда, демонстрируемого аудитории, и видеоизобра-

жением аудитории. Каждое из трех представлений занимает определенную часть экра-

на и может быть извлечено из различных источников с помощью различных

протоколов и форматов кодирования. SMIL поддерживает встроенные гипертексто-

вые ссылки, например, щелчок па области с изображением в презентации может ини-

циировать HTTP-запрос на Web-страницу, которая отображает подробную информа-

цию по теме, освещаемой текущим слайдом. В более общем случае гипертекстовая

ссылка может ассоциироваться с определегпюй областью и интерва;юм времени.

Помимо связывания отображения содержания с областями экрана, SMIL дает

возможность автору координировать отображение данных во времени. В SMIL

имеются возможности для указания, когда начинать воспроизведение потока и ка-

кую часть потока воспроизводить. SMIL содержит средства для синхронизации

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

довательно, когда воспроизведение одного потока начинается после завершения

воспроизведения предыдущего потока. Альтернативой является одновременное

воспроизведение нескольких потоков. Плейер определяет, все ли параллельные по-

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

тельности. Параллельный и последовательный подходы могут быть объединены,

чтобы дать возможность воспроизвести один длинный поток параллельно с после-

довательностью более коротких потоков.

Подготовка мультимедийьюго содержания осложняется тем фактом, что клиенты

могут сильно различаться по пропускной способности, размеру экрана, возможно-

стям плейера и предпочтениям пользователя. Например, один пользователь может

иметь 21-дюймовый монитор с высоким разрешением и высокопроизводителыюе

подключение к Internet. Другой пользователь может иметь кармагншш компьютер

с беспроводным подключением. Слабослышащий пользователь может предпочесть

получать текстовое сопровождение вместо потока аудиоинформации. SMIL может

задавать различные параметры презентации, соответствующие различным мультиме-

дийным потокам. Медиаплейер определяет, какие потоки извлекать и как их следует

отображать. Это является удобной альтернативой обращения клиента к серверу с це-

лью определить соответствующие параметры для потоков. SMIL может также зада-

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

вают, как пользователь может взаимодействовать с презентацией. Например, область

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

Глава

12.

Доставка мультимедийных потоков 435

12.4.

Real Time Streaming Protocol

Протокол Real Time Streaming Protocol (RTSP) дает возможность клиенту за-

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

веров, подобно тому, как HTTP позволяет клиентам выдавать запросы к Web-сер-

верам. Фактически RTSP перенял большую часть своего синтаксиса и семантики

от НТТР/1.1, поскольку формально оба протокола выполняют схожие функции.

Сходство подчеркивает общий характер многих реализованных в HTTP концеп-

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

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

стей НТТР/1.1 но передаче мультимедийных дагнтых. В этом разделе мы осущест-

вим сравнение и противопоставление RTSP и HTTP. Затем мы опишем методы

запросов RTSP, коды ответов и заголовки в сравнении и противопоставлении

с НТТР/1.1. В основу обсуждения положен материал главы 7 (раздел 7.2), описы-

вающий синтаксис НТТР/1.1.

12.4.1.

Сходства и различия

Спецификация RTSP в значительной мере перекликается со спецификацией

НТТР/1.1.

На верхнем уровне оба протокола преследуют одну цель — дать воз-

можность клиенту запрашивать содержание с сервера на основе URI запроса. Ис-

торически разработка RTSP началась после того, как была выполнена часть работ

над спецификацией HTTP. Поскольку HTTP послужил основой для RTSP, цели и

задачи этих протоколов во многом совпадают. Доставка мультимедийных потоков

следует той же модели, что и HTTP: ресурсы, идентифицируемые URI, взаимодей-

ствие запрос-ответ, а также возможность передачи данных через одно или несколь-

ких промежуточных звеньев на пути между клиентом и сервером. Протоколы име-

ют сопоставимые требования к безопасности и требования, предъявляемые к серве-

рам-посредникам. Именно эти две области потребовали наиболее значительных

усилий при разработке НТТР/1.1. Использование готовых концепций, включение

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

ботку и реализацию RTSP. Кроме того, оба протокола играют роль в инициирова-

нии передачи мультимедийных потоков через Web. Сходство между двумя прото-

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

кол будет обслуживать данную конкретную функцию.

Любой из рассматриваемых протоколов в принципе может обслужить всю задачу

по извлечению описания мультимедийного сеанса и запросу мультимедийных дан-

ных. Хотя HTTP, возможно, не лучший протокол для. вьн1олне1Н1я всех этих де11ст-

вий, он может применяться для передачи описания сеанса. В ответ на щелчок поль-

зователя мышью па гипертекстовой ссылке браузер может выдать НТТР-занрос на

информацию с описанием сеанса (например, http://www.foo.com/bar.sdp). Ответ

Web-сервера будет включать информацию, описывающую сеанс, в формате SDP, как

показано ниже:

НТТР/1.1 200

ОК

Content-Type: application/sdp

v=0

о=-

2890844526 2890842807

IP4 192.16.24.202

s=RTSP Session

436 Часть V. Web-приложения

m=audio О RTP/AVP О

a=control:rtsp://foo.com/bar/audio

m=video 0 RTP/AVP 31

a=cont rol:rtsp://foo.com/bar/video

В этот момент Web-браузер уже может активизировать медиаплейер для выполне-

ния остальных действий, как было описано в разделе

12.3.3.

Кроме того, медиаплей-

ер может предоставить пользователю интерфейс для выбора мультимедийных сеан-

сов.

В этом случае медиаплейер может напрямую взаимодействовать с RTSP-серве-

ром для извлечения описаний сеансов без привлечения Web-браузера.

Несмотря на многие черты сходства между двумя протоколами, RTSP отличает-

ся от HTTP по ряду ключевых моментов.

Отдельные соединения для данных и команд. В противоположность HTTP,

RTSP-сервер создает для передачи данных отдельное соединение. В этом смысле

RTSP близок к FTP. Клиент и сервер обмениваются RTSP-сообщениями через

управляющее соединение. Задачу по передаче данных выполняют другие протоко-

лы,

такие как RTP и RTCP. Подобное разделение позволяет клиенту и серверу

продолжать обмениваться RTSP-сообщениями во время передачи данных, чтобы

адаптироваться к текущей обстановке или инициировать дополнительные переда-

чи.

Помимо этого, передача команд и передача данных могут использовать различ-

ные транспортные протоколы. RTSP-сообщепия обычно передаются через ТСР-со-

единение, хотя может быть использован и UDP. Обмен пакетами RTP и RTCP

обычно осуществляется по UDP, хотя возможно и применение TCP.

Различные форматы URI. Для RTSP был зарезервирован порт 554. Выбор про-

токола (UDP или TCP) может быть задан в схеме URI. Схемы rtsp и rtspu отно-

сятся к TCP и UDP соответственно. Например, rtsp://foo.com/bar идентифициру-

ет сеанс, который запрашивается и управляется но RTSP посредством ТСР-соеди-

нения. С другой стороны, rtspu://foo.com/bar указывает, что клиент должен

выдать RTSP-запрос посредством UDP. Запрашиваемый URI в RTSP может отно-

ситься как ко всему сеансу, так и к отдельным мультимедийным потокам. Строка

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

Это позволяет избежать неопределенности относительно того, какой RTSP-сервер

должен получать запрос. В противоположность этому, в HTTP/1.1 для этой цели

имеется отдельный заголовок Host, призванный сохранить обратную совмести-

мость с НТТР/1.0, как обсуждалось ранее в главе 7 (раздел 7.8).

Протокол с сохранением промежуточного состояния. В противоположность

HTTP RTSP-сервер сохраняет информацию между последовательными запросами.

Клиент может отправлять несколько RTSP-сообщений, относящихся к одному се-

ансу или потоку. Это необходимо, поскольку клиент может выполнять функции

видеомагнитофона, включая воспроизведение, пауза, ускоренная перемотка и об-

ратная перемотка, в течение одного сеанса. Сервер должен иметь возможность ин-

терпретировать эти запросы в контексте соответствующего потока. Чтобы обрабо-

тать определенные запросы, серверу может также потребоваться хранить информа-

цию о текущей передаче потока. Допустим, клиент запрашивает паузу в потоке,

после чего запрашивает воспроизведение. Сервер должен продолжить передачу

с определенного места в потоке. Сохранение промежуточного состояния в протоко-

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

дисковых и сетевых ресурсов. В RTSP клиент должен выдать запрос серверу на

выделение системных ресурсов для мультимедийного сеанса. Это дает возмож-

ность серверу заранее определить, достаточно ли у него системных ресурсов.

Глава

12.

Доставка мультимедийных потоков 437

Различные методы, заголовки и коды состояния. В RTSP имеется иной набор

методов запросов, нежели в HTTP, в том числе методов, используемых сервером

для передачи сообщения-запроса клиенту. RTSP перенял многие коды ответов,

хотя для указания ошибочных ситуаций были определены дополнительные коды,

отсутствующие в HTTP. В RTSP были заимствованы многие заголовки HTTP

с рядом важных добавлений и изъятий. По большей части неприятие ряда заголов-

ков отражает тот факт, что RTSP не передает реальных мультимедийных данных.

Большинство сообщений-ответов RTSP содержат только информацию, описываю-

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

с (1) параметрами таймировапия мультимедийного потока, (2) наличием отдель-

ных протоколов для передачи данных и (3) хранением информации о состоянии на

клиенте или на сервере. Эти моменты обусловлены ключевыми различиями между

RTSP и HTTP, которые проистекают из уникальных требований, предъявляемых

к мультимедийным данным.

12.4.2.

Методы запросов RTSP

RTSP-серверы должны поддерживать четыре основных метода, используемых

клиентами для извлечения мультимедийных сеансов: OPTIONS, SETUP, PLAY и

TEARDOWN. На верхнем уровне заголовок OPTIONS гюзволяет клиенту опреде-

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

держиваемые методы; этот метод ведет себя так же, как метод OPTIONS НТТР/1.1.

Остальные три метода манипулируют сохраненной на сервере иР1формацией о со-

стоянии для координации передачи мультимедийных данных. Клиент использует

метод SETUP для установления транснортгюго соединения для каждого потока в се-

ансе.

Метод PLAY используется для инициирования передачи потока (потоков).

Метод TEARDOWN используется для завершения передачи. Эти четыре метода

описаны в таблице 12.2 вместе с другими RTSP-методами.

Таблица 12.2. Методы запросов RTSP

Направление

От клиента

к серверу

Двуиаправлеппое

От сервера

к клиенту

Метод

SETUP

PLAY

TEARDOWN

DESCRIBE

PAUSE

RECORD

OPTIONS

ANNOUNCE

GET_PARAMETER

SET_PARAMETER

REDIRECT

Описание |

Выделяет системные ресурсы потоку |

Начинает передачу данных потока |

Освобождает ресурсы, связанные с потоком |

Возвращает описание сеанса |

Временно останавливает передачу потока |

Начинает запись потока |

Возвращает список поддерживаемых методов |

Регистрирует описание презентации |

Извлекает значение именованного параметра |

Устанавливает значение именованного

параметра |

Направляет клиента к другому серверу

438

Часть

Web-приложения

В противоположность HTTP RTSP сохраняет информацию о состоянии в ответ

на клиентские запросы. Помимо запросов SETUP, PLAY и TEARDOWN, методы

RECORD и PAUSE также влияют на информацию о сеансе. Метод RECORD

предписывает RTSP-серверу принять и сохранить поток с указанным URI для по-

следующего воспроизведения. Метод PAUSE временно приостанавливает переда-

чу, не освобождая системных ресурсов сервера. Последующий запрос PLAY (или

RECORD) предписывает серверу продолжить передачу (или запись) потока. И

клиент, и сервер сохраняют информацию о состоянии в интересах каждого потока.

Методы PLAY, RECORD, PAUSE и TEARDOWN могут быть применены к от-

дельному потоку или ко всему сеансу, в зависимости от того, соответствует ли URI

в RTSP-запросе потоку или сеансу. Метод запроса, применяемый к сеансу, воздей-

ствует на каждый из составляющих сеанс потоков. Метод SETUP применяется

только к отдельному потоку.

Механизм управления состоянием для клиента и сервера представлен на

рис.

12.1. Сервер изменяет состояние при обработке метода запроса; клиент изме-

няет состояние после получения ответа от сервера. Метод SETUP запускает пере-

дачу с начального состояния (Инициализация) и вызывает переход к состоянию Го-

товность.

Метод TEARDOWN возвращает клиента и сервер в состояние Инициа-

лизация. Методы PLAY и RECORD переводят в состояния Воспроизведение и

Запись,

соответственно, а метод PAUSE возвращает в состояние

Готовность.

Пере-

дача данных осуществляется только в состояниях

Воспроизведение

и Запись. Нахо-

дясь в одном из этих двух состояний, клиент может инициировать запрос SETUP

для изменения транспортных параметров потока. Сервер продолжает передачу по-

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

кол или другие порты.

TEARDOWN

SETUP,

Воспроизведение

Инициализация

SETUP

PAUSE

2 TEARDOWN

TEARDOWN

Запись

Готовность

SETUP

RECORD

PAUSE

SETUP

Рис.

12.1.

Диаграмма состояний для клиентов и серверов RTSP

Остальные методы RTSP не оказывают влияния на состояния RTSP на клиенте

и на сервере, поэтому не представлены на рис. 12.1. Например, клиент может вы-

дать запрос OPTIONS, чтобы узнать возможности сервера, не воздействуя на теку-

щую передачу. Клиент в любое время может отправить запрос DESCRIBE, чтобы

получить описательную информацию о сеансе или потоке. В RTSP также преду-

смотрен метод ANNOUNCE, который дает возможность серверу отправлять клиен-

ту новое описание. Допустим, сервер размещает сеанс реального времени, который

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

Глава

12.

Доставка мультимедийных потоков 439

ся еще и видеопоток. Сервер может отправить клиентам, прослушивающим теку-

щую аудиоинформацию, запрос ANNOUNCE, содержащий обновленное описание

сеанса. На основе этой информации клиент может инициировать запрос на видео-

поток, отправив запрос SETUP с последующим запросом PLAY. RTSP также дает

возможность клиенту отправлять запрос ANNOUNCE серверу, чтобы тот создал

новое описание сеанса; здесь имеется аналогия с методом PUT HTTP.

Давая возможность серверам посылать запросы клиентам, RTSP отличается от

традиционной модели клиент-сервер. Хотя поддержка запросов от сервера к клиен-

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

сервера. Например, метод REDIRECT позволяет серверу проинструктировать кли-

ента связаться с другим сервером по указанному URI. После получения запроса

REDIRECT клиент должен выдать запрос TEARDOWN для текущего сеанса, а за-

тем выдать запрос SETUP новому серверу. Сервер может иметь множество причин

для переадресации клиента. Переадресация может повысить производительность,

если новый сервер находится ближе к клиенту или менее загружен. Кроме того, но-

вый сервер может предоставить другое содержание, отсутствующее на исходном

сервере. В этом смысле метод REDIRECT схож с классом кодов ответов нереадре-

сации в НТТР/1.1. Однако RTSP-сервер может переадресовывать клиента в любое

время в процессе передачи мультимедийного потока.

Чтобы выдать запрос, сервер должен знать, какие методы поддерживаются кон-

кретным клиентом. Для этого сервер может отправить клиенту запрос OPTIONS.

Кроме методов OPTIONS и ANNOUNCE в RTSP имеются два других метода, ко-

торые могут использоваться как клиентами, так и серверами. Методы GET_PARA-

METER и SET_PARAMETER дают возможность отправителю узнать и откоррек-

тировать параметры мультимедийного сеанса или потока, ассоциированного с кон-

кретным URI запроса. Эти два метода обеспечивают поддержку операций чтения и

записи произвольного набора параметров для конкретного клиента и сервера. На-

пример, сервер может использовать метод GET_PARAMETER для запроса количе-

ства пакетов данных, полученных клиентом для определенного потока. Тем самым

обеспечивается альтернатива протоколу RTCP для получения информации о каче-

стве транспортировки данных. У клиента имеется возможность отправить запрос

SET_PARAMETER с целью уменьшения сервером скорости передачи. Эти методы

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

ции взаимодействия в управлении мультимедийным потоком.

Большинство методов запросов связано с поддержкой клиента, который запра-

шивает воспроизведение потока с мультимедийного сервера. Однако RTSP-сервер

может также допускать запись мультимедийного содержания с помощью необяза-

тельных методов ANNOUNCE и RECORD. Допустим, пользователь хочет запи-

сать телеконференцию па RTSP-сервере для дальнейшего воспроизведения. В этол4

случае клиент отправляет описание конференции серверу в сообщении ANNO-

UNCE.

Затем клиент должен отправить сообщение SETUP для каждого из потоков

в сеансе, чтобы проинформировать сервер о транспортных параметрах, таких как

IP-адреса и гюмера портов. URI запроса в сообщении SETUP указывает имя, кото-

рое клиент хочет ассоциировать с записываемым содержанием. После этого клиен-

ту следует отправить запрос RECORD для начала записи потоков. Через некото-

рое время клиент может связаться с сервером и просмотреть записанную конфе-

ренцию.