Real Time Streaming Protocol

Протокол (RTSP) дает возможность клиенту запрашивать живые или предварительно записанные потоки с мультимедийных серверов, подобно тому, как HTTP позволяет клиентам выдавать запросы к Web-cepверам. Фактически RTSP перенял большую часть своего синтаксиса и семантики от НТТР/1.1, поскольку формалыю оба протокола выполняют схожие функции. Сходство подчеркивает общий характер многих реализованных в HTTP концепций. Однако протоколы имеют ряд ключевых отличий, которые связаны с уникальными требованиями для мультимедийных потоков и ограниченностью возможностей НТТР/1.1 по передаче мультимедийных данных. В этом разделе мы осуществим сравнение и противопоставление RTSP и HTTP. Затем мы опишем методы запросов RTSP, коды ответов и заголовки в сравнении и противопоставлении с НТТР/1.1. В основу обсуждения положен материал главы 7 (раздел 7.2), описывающий синтаксис НТТР/1.1.

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

Спецификация RTSP в значительной мере перекликается со спецификацией НТТР/1.1. На верхнем уровне оба протокола преследуют одну цель — дать возможность клиенту запрашивать содержание с сервера на основе URI запроса. Исторически разработка RTSP началась после того, как была выполнена часть работ над спецификацией HTTP. Поскольку HTTP послужил основой для RTSP, цели и задачи этих протоколов во многом совпадают. Доставка мультимедийных потоков следует той же модели, что и HTTP: ресурсы, идентифицируемые URI, взаимодействие запрос-ответ, а также возможность передачи данных через одно или нескольких промежуточных звеньев на пути между клиентом и сервером. Протоколы имеют сопоставимые требования к безопасности и требования, предъявляемые к серверам-посредникам. Имешго эти две области потребовали наиболее значительных усилий при разработке НТТР/1.1. Использование готовых концепций, включение специальных заголовков протокола и кодов ответов уменьшило затраты на разработку и реализацию RTSP. Кроме того, оба протокола играют роль в инициировании передачи мультимедийных потоков через Web. Сходство между двумя протоколами обеспечивает значительную гибкость при принятии решения, какой протокол будет обслуживать даниую конкретную функцию.

Любой из рассматриваемых протоколов в принципе может обслужить всю задачу по извлечению описания мультимедийного сеанса и запросу мультимедийных данных. Хотя HTTP, возможно, не лучший протокол для выполнения всех этих действий, оп может применяться для передачи описания сеанса . В ответ на щелчок пользователя мышью на гипертекстовой ссылке браузер может выдать HTTP-запрос на информацию с описанием сеанса (например, http://www.foo.com/bar.sdp). Ответ Web-сервера будет включать информацию, описывающую сеапс, в формате SDP, как показано ниже:

НТТР/1.1 200 OK Content-Type: application/sdp

v=0

o=- 2890844526 2890842807 IN IP4 192.16.24.202 s=RTSP Session

m=audio 0 RTP/AVP 0

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

m=video 0 RTP/AVP 31

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

В этот момент Web-бpayзep уже может активизировать медиаплейер для выполнения остальных действий, как было описано в разделе 12.3.3. Кроме того, медиаплейер может предоставить пользователю интерфейс для выбора мультимедийных сеансов. В этом случае медиаплейер может напрямую взаимодействовать с RTSP-серве- ром для извлечения описаний сеапсов без привлечения Web-бpayзepa.

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

Отдельные соединения для данных и команд. В противоположность HTTP, RTSP-сервер создает для передачи данных отдельное соединение. В этом смысле RTSP близок к FTP. Клиент и сервер обмениваются RTSP-сообщениями через управляющее соединение. Задачу по передаче данных выполняют другие протоколы, такие как RTP и RTCP. Подобное разделение позволяет клиенту и серверу продолжать обмениваться RTSP-сообщениями во время передачи данных, чтобы адаптироваться к текущей обстановке или инициировать дополнительные передачи. Помимо этого, передача команд и передача данных могут использовать различные транспортные протоколы. RTSP-сообщения Обычно передаются через TCP-co- едипепие, хотя может быть использован и UDP. Обмен пакетами RTP и RTCP Обычно осуществляется rio UDP, хотя возможно и применение TCP.

Различные форматы URI. Для RTSP был зарезервирован норг 554. Выбор протокола (UDP или TCP) может быть задай в схеме URI. Схемы rtsp и rtspu относятся к TCP и UDP соответственно. Например, rtsp://foo.com/bar идентифицирует сеапс, который запрашивается и управляется rio RTSP посредством ТСР-соединения. С другой стороны, rtspu://foo.com/bar указывает, что клиент должен выдать RTSP-запрос посредством UDP. Запрашиваемый URI в RTSP может относиться как ко всему сеансу, так и к отдельным мультимедийным потокам. Строка запроса в RTSP-запросе должна содержать абсолютный путь, включая имя хосга. Это позволяет избежать неопределенности относительно того, какой RTSP-сервер должен получать запрос. В противоположность этому, в НТТР/1.1 для этой цели имеется отдельный заголовок Host, призванный сохранить обратную совместимость с НТТР/1.0, как обсуждалось ранее в главе 7 (раздел 7.8).

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

Различные методы, заголовки и коды состояния. В RTSP имеется иной набор методов запросов, нежели в HTTP, в том числе методов, используемых сервером для передачи сообщения-запроса клиенту. RTSP неренял многие коды ответов, хотя для указания ошибочных ситуаций были определены дополнительные коды, отсутствующие в HTTP. В RTSP были заимствованы многие заголовки HTTP с рядом важных добавлений и изъятий. По большей части неприятие ряда заголовков отражает тот факт, что RTSP не передает реальных мультимедийных данных. Большинство сообщений-ответов RTSP содержат только информацию, описывающую сеанс. Новые заголовки, определенные в RTSP, связаны главным образом с (1) параметрами таймирования мультимедийного потока, (2) наличием отдельных протоколов для передачи данных и (3) хранением информации о состоянии на клиенте или на сервере. Эти моменты обусловлены ключевыми различиями между RTSP и HTTP, которые проистекают из уникальных требований, предъявляемых к мультимедийным данным.

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

RTSP-серверы должпы поддерживать четыре основных метода, используемых клиентами для извлечения мультимедийных сеансов: OPTIONS, SETUP, PLAY и TEARDOWN. На верхнем уровне заголовок OPTIONS позволяет клиенту определять функциональные возможности сервера, такие как номер версии RTSP и поддерживаемые методы; этот метод ведет себя так же, как метод OPTIONS НТТР/1.1. Остальные три метода манипулируют сохраненной на сервере информацией о состоянии для координации передачи мультимедийных данных. Клиент использует метод SETUP для установления транспортного соединения для каждого потока в сеансе. Метод PLAY используется для инициирования передачи потока (потоков). Метод TEARDOWN используется для завершения передачи. Эти четыре метода описаны в таблице 12.2 вместе с другими RTSP-методами.

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

В противоположность 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 для изменения транспортпых параметров потока. Сервер продолжает передачу потоков мультимедийных данных, используя, возможно, другой траиспортпый протокол или другие порты.

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

Остальные методы RTSP не оказывают влияния на состояния RTSP на клиенте и на сервере, ноэтому не представлены на рис. 12.1. Например, клиент может выдать запрос OPTIONS, чтобы узнать возможности сервера, не воздействуя на текущую передачу. Клиент в любое время может отправить запрос DESCRIBE, чтобы получить описательную информацию о сеансе или потоке. В RTSP также предусмотрен метод ANNOUNCE, который дает возможность серверу отправлять клиенту новое описание. Допустим, сервер размещает сеанс реалыюго времени, который первоначально состоит из одного аудиопотока. Предположим, что затем появляег- ся еще и видеоноток. Сервер может отправить клиентам, прослушивающим текущую аудиоинформацию, запрос 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-сервере для дальнейшего воспроизведения. В этом случае клиент отправляет описание конференции серверу в сообщении ANNOUNCE. Затем клиент должен отправить сообщение SETUP для каждого из потоков в сеансе, чтобы проинформировать сервер о транспортных параметрах, таких как IP-адреса и номера портов. URI запроса в сообщении SETUP указывает имя, которое клиент хочет ассоциировать с записываемым содержанием. После этого клиенту следует отправить запрос RECORD для начала записи потоков. Через некоторое время клиент может связаться с сервером и просмотреть записанную конференцию.

Источник: Web-протоколы. Теория и практика. — M.: ЗАО «Издательство БИНОМ», 2002 г. – 592 c.: ил.

Вы можете следить за любыми ответами на эту запись через RSS 2.0 ленту. Вы можете оставить ответ, или trackback с вашего собственного сайта.

Оставьте отзыв

XHTML: Вы можете использовать следующие теги: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

 
Rambler's Top100