Заголовки RTSP

На момент появления документа RFC 2326 rio RTSP информация по НТТР/1.1 содержалась в документе RFC 2068, а не в проекте стандарта RFC 2616. Многие RTSP-заголовки в этой связи были заимствованы из RFC 2068. Как уже рассказывалось в главе 7 (раздел 7.2.2), в HTTP имеются заголовки запросов, заголовки ответов, общие заголовки и заголовки содержимого. В последующих таблицах в этом разделе имеются пометки в виде звездочек (*), указывающие, что заголовки были унаследованы от НТТР/1.1. В конце раздела мы поговорим о заголовках НТТР/1.1, которые не были использованы в RTSP.

ОБЩИЕ ЗАГОЛОВКИ

Общие заголовки могут присутствовать и в сообщениях-запросах, и в сообщениях-ответах. RTSP унаследовал четыре общих заголовка НТТР/1.1, а шесть новых заголовков были добавлены (см. таблицу 12.3). Заголовки Session и CSeq идентифицируют последовательность RTSP-сообщений, ассоциированных с одним сеансом. RTSP не предъявляет требований к наличию одного выделенного соединения транспортного уровня в ходе сеанса. RTSP-ceaнc может иметь песколько ТСР-соединений, либо клиент и сервер могут взаимодействовать по UDP. Каждое RTSP-сообщение, которое воздействует на состояние сеанса, содержит идентификатор сеанса —строку, присваиваемую сервером. RTSP-сервер назначает идентификатор после получения запроса SETUP и возвращает значение в заголовке Session. Последующие сообщения-запросы и сообщения-ответы, относящиеся к данному сеансу, содержат заголовок Session. Заголовок CSeq указывает порядковый номер, ассоциированный с каждым RTSP-сообщением. Необходимость наличия порядковых номеров связана с двумя ключевыми отличиями RTSP от HTTP. Во-первых, поскольку в RTSP промежуточное состояние сохраняется, с одним сеансом могут быть связаны различные пары запрос-ответ. Во-вторых, поскольку RTSP-сообщения могут передаваться но UDP, протокол не может гарантировать надежной, упорядоченной доставки сообщений. Порядковый номер увеличивается на единицу для каждого следующего запроса; соответствующее сообщение-ответ имеет тог же порядковый помер. При передаче RTSP-сообщений по UDP клиент и сервер ответственны за повторную передачу потерянных UDP-сообщений, если такая передача требуется. Любой повторно переданный запрос имеет тот же порядковый помер, что и оригииалыюе сообщение.

Заголовок Transport используется в сообщениях запросов и ответов SETUP для координации выбора транспортного протокола и параметров потока. В сообщении-запросе заголовок

Transport: RTP/AVP/UDP;unicast;client_port=18366-18367

предписывает серверу доставить поток посредством протоколов RTP и UDP с типом полезной нагрузки AVP (Audio Video Profile) [Sch96]; клиент выбирает порт 18366 для UDP-соединения и порт 18367 для RTCP-соединения. В сообщении-запросе заголовок Transport может содержать несколько наборов параметров. Заголовок может включать множество других параметров, таких как адрес назначения для группового вещания, методы RTSP-запросов, поддерживаемые для сеанса, и схему сжатия данных. Заголовок Transport в сообщении-ответе сервера подтверждает параметры, выбранные клиентом

Transport: RTP/AVP/UDP;unicast;client_port=18366-18367; server_port=16970-16971

и содержит номера портов сервера.

Таблица 12.3. Общие RTSP-заголовки (заголовки, имеющиеся в НТТР/1.1, помечены ‘*’)

Заголовки Range, Scale и Speed относятся к временным свойствам мультимедийных потоков. Заголовок Range используется для указания определенного места в потоке. Рассмотрим медиаплейер, который дает возможность пользователю осуществлять прокрутку к любой точке в аудиоклипе. Пользователь может захотеть пропустить первые 30 секунд клипа. Вместо того чтобы получать весь поток, можно включить в RTSP-запрос PLAY заголовок Range, указывающий желаемый интервал времени. Концептуально это похоже на использование заголовка запроса Range в НТТР/1.1. Однако запросы на диапазон в НТТР/1.1 идентифицируют подмножество данных в ресурсе, диапазон в RTSP определяет интервал времени для потока. Например, клиентский запрос PLAY может содержать

Range: npt=30-

для указания серверу начать передачу данных с 30-й секунды в потоке (NPT означает нормальное время воспроизведения (Normal Play Time), при этом началу потока соответствует пулевая секунда). На практике индексирование по времени вызывает больше затруднений, чем индексирование но данным, поскольку размеры кадров на протяжении потока могут меняться. 30-ая секунда точка в 60-секундном потоке может не соответствовать точно середине в последовательности байтов. Кроме того, некоторые кадры в потоке кодируются относительно более ранних или более поздних кадров, что затрудняет начало воспроизведения потока в Точно заданное время. Поскольку RTSP-сервер может оказаться не в состоянии начать передачу данных с произвольной точки в аудио- или видеопотоке, RTSP разрешает серверу инициировать передачу с близкого момента времени. Сервер указывает выбранный интервал времени в заголовке Range сообщения-ответа. Спецификация RTSP не предъявляет каких-либо требований относительно того, насколько значение Range, указанное в сообщении-ответе, может отличаться от значения Range, запрошенного клиентом.

Заголовки Scale и Speed поддерживают функции ускоренной и обратной перемотки для методов PLAY и RECORD. Scale относится к скорости воспроизведения медиаплейером, а Speed относится к скорости передачи данных сервером. Обычная скорость воспроизведения соответствует значению 1. Большие положительные значения соответствуют ускоренной перемотке, меньшие положительные значения соответствуют воспроизведению содержания в замедленном режиме. Отрицательное значение указывает, что поток должен быть воспроизведен в обратном направлении. Клиент передает желаемую скорость воспроизведения в заголовке Scale. Сервер пытается поддерживать желаемую скорость воспроизведения и возвращает выбранную скорость в заголовке Scale сообщения-ответа. Сервер адаптирует передачу потока, чтобы избежать повышения скорости поступления данных. Например, когда клиент запрашивает операцию ускоренной перемотки в видеоклипе, сервер может доставлять не все, а подмножество кадров. Хотя выборка подмножества кадров не предъявляет требований к увеличению скорости передачи, качество ускоренного воспроизведения будет хуже.

Клиент и сервер могут также согласовать скорость передачи, используемую для доставки данных. По умолчанию передача выполняется с потребной для воспроизведения потока скоростью. Это соответствует значению скорости, равному 1. Большее значение соответствует увеличению скорости, а меньшее значение — уменьшению. Клиент запрашивает желаемую скорость передачи в заголовке Speed сообщения-запроса, а сервер возвращает выбранную скорость передачи в заголовке Speed сообщения-ответа. Заголовок Speed может быть использован вместе с заголовком ScaIe для координации передачи потока во время операций ускоренной и обратной перемотки. Клиент может использовать заголовок Speed для получения потока с более высокой скоростью передачи, не допуская снижения качества, как это делается при ускоренной перемотке.

Остальные четыре общих заголовка заимствованы из НТТР/1.1. Заголовок Date указывает время создания сообщения. Заголовок Via используется для идентификации цепочки серверов-посредников на пути между клиентом и исходным сервером. Заголовок Connection содержит список заголовков механизма промежуточных передач, которые удаляются следующим получателем на пути. Заголовок Cache-Control используется для передачи директив кэширования. Однако интерпретация заголовка Cache-Control в RTSP отличается. В отличие HTTP, большинство RTSP-ответов не являются кэшируемыми, за исключением информации с описанием сеанса , возвращаемой в ответ на запрос DESCRIBE. В RTSP директивы Cache-Control относятся к мультимедийному потоку, который передается другим протоколом. Заголовок Cache-Control присутствует только в запросе SETUP и сообщениях-ответах, которые устанавливают параметры транспорта. Как и в НТТР/1.1, различные директивы Cache-Control предоставляют клиенту несколько способов для выражения требований к актуальности информации, а серверу — для выражения возможностей кэширования данных.

ЗАГОЛОВКИ ЗАПРОСОВ

В RTSP девять заголовков запросов были заимствованы из НТТР/1.1 и появилось пять новых заголовков запросов (см. таблицу 12.4). Новые заголовки запросов связаны с таймированием и выделением системных ресурсов. Клиент использует заголовок Bandwidth для предоставления оценки потребных сетевых ресурсов в битах в секунду. Сервер может использовать эту информацию для выбора скорости передачи при доставке мультимедийных данных клиенту с помощью транспортного протокола. Клиент может использовать заголовок Block- size для указания желаемого максимального размера пакета при передаче данных. В размер пакета не входят заголовки нижних уровней, такие как заголовки IP, UDP п RTP. Сервер может выбрать размер пакета меньший или равный размеру, запрошенному клиентом. Заголовки Bandwidth и Blocksize решают проблемы, которые в HTTP просто не могут возникнуть, поскольку HTTP-сервер передает данные в виде упорядоченного, надежного потока данных со скоростью, определяемой транспортным протоколом.

Таблица 12.4. Заголовки запросов RTSP (заголовки, имеющиеся в НТТР/1.1, помечены ‘*’)

Заголовок

Описание

Bandwidth

Оценивает пропускную способность сети, доступную для клиента

Blocksize

Желаемый размер пакета для передачи данных

Conference

Идентификатор конференции, ассоциированный с потоком

Require

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

Proxy-Require

Запрос относительно поддержки функции прокси-сервером

From*

Адрес электронной почты пользователя

User-Agent*

Информация о программном обеспечении агента пользователя

Authorization*

Полномочия агента пользователя

Referer*

URI, от которого получен URI запроса

If-Match*____________

Проверка соответствия с атрибутами содержимого

If-Modified-Since*

Проверка времени последнего изменения

Accept*

Предпочтительные типы содержания

Accept-Encoding*

Предпочтительное кодирование содержания

Accept-Language *

Предпочтительные языки

Заголовок Conference устанавливает логическую связь между потоком RTSP и существующей конференцией по другому протоколу, например, SIP. С точки зрения RTSP-сервера, идентификатор конференции представляет собой кодированную строку. Связывание RTSP-сервера с текущей конференцией полезно для различных целей. Например, клиент хочет воспроизвести предварительно записанный аудиоклип в имеющейся конференции. Клиент может включить заголовок Conference в запрос SETUP, чтобы идентифицировать соответствующую конференцию. Запрос SETUP также включает заголовок Transport для передачи информации о текущей конференции. Например, заголовок Transport может указывать IР-адрес группового вещания, а также номера портов. После получения ответа на сообщение SETUP RTSP-клиент может выдать запрос PLAY для инициирования передачи потока аудиоинформации от RTSP-сервера группе вещания.

Заголовки Require и Proxy-Require предоставляют клиенту эффективный и допускающий расширение способ узнать, какие функциональные возможности поддерживаются сервером. Параметр заголовка представляет собой строку, содержащую названия функций, которые клиент хотел бы использовать (например, Require: unusual-feature). Если сервер не распознает или не поддерживает функцию, приведенную в заголовке Require, RTSP-ответ возвращает клиенту отрицательное подтверждение ("Unsupported Header"). В противоположность этому, в HTTP пет заголовков запроса для определения функциональных возможностей сервера. HTTP-серверы могут без ущерба игнорировать определенные заголовки, которые они не поддерживают. Заголовок Require дает возможность клиенту выдавать RTSP-запрос до того, как он узнает, поддерживает ли сервер нужную функцию. Агент пользователя использует заголовок Proxy-Require для указания, что функции должны поддерживаться также всеми прокси-серверами на пути от сервера к клиенту.

В RTSP имеется несколько заголовков запросов НТТР/1.1, связанных с идентификацией и авторизацией клиента (например, From, User-Agent, Authorization и Referer), кэшированием (например, If-Match и If-Modified-Since) и согласованием содержания (например, Accept, Accept-Encoding и Accept-Language). Однако в RTSP пег полного набора заголовков НТТР/1.1, связанных с кэшированием и согласованием содержания. Большинство методов RTSP не возвращают содержимого, поскольку мультимедийные потоки передаются по отдельным транспортным соединениям. Содержимое включается в запрос ANNOUNCE и в ответ на запрос DESCRIBE. Содержимым является описание сеансов, которое может быть представлено на различных языках (например, английском или швейцарском немецком) и с другим типом содержания (например, SDP).

ЗАГОЛОВКИ ОТВЕТОВ

В RTSP семь заголовков ответов было заимствовано из НТТР/1.1 и введено два новых заголовка ответов (см. таблицу 12.5). Заголовок RTP-Info играет важную роль в координации приема мультимедийных потоков. Присутствуя в ответе сервера на запрос PLAY, заголовок RTP-Info объявляет значения специфических для RTP параметров. Например,

RTP-Info: url=rtsp://foo.com/bar/audio;seq=47; rtptime=2894, url=rtsp://foo.com/bar/video;seq=184;rtptime=6674

В RTSP также имеется заголовок ответа Unsupported для реакции на сообщения-запросы с заголовками Require и Proxy-Require.

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

Таблица 12.5. Заголовки ответов RTSP (заголовки, имеющиеся в НТТР/1.1, помечены ‘*’)

поддерживаемые сервером, идентифицируются в заголовке Unsupported сообщения-ответа. Тем самым серверу предоставляется возможность разъяснить, почему клиентский запрос не может быть выполнен, а не просто возвратить код ошибки. Заголовки ответов, заимствованные из НТТР/1.1, относятся к идентификации сервера (Server), переадресации запроса (Location), повторному запросу (Retry-After), кэшированию (Vary) и аутентификации (WWW-Authenticate и Proxy-Authenticate). Заголовок Public, используемый для указания списка опций, поддерживаемых сервером, определен в RFC 2068 и не был включен в RFC 2616. Заголовок Public в HTTP был заменен на заголовок Allow, как обсуждалось ранее, в главе 6 (раздел 6.2.3). В НТТР/1.1 Allow представляет собой заголовок содержимого.

ЗАГОЛОВКИ СОДЕРЖИМОГО

В RTSP девять заголовков содержимого были заимствованы из НТТР/1.1, а новых заголовков содержимого введено не было (см. таблицу 12.6). По сравнению с HTTP, в RTSP содержимое сообщений трактуется достаточно просто. Содержимое RTSP-сообщения, если оно присутствует, представляет собой описание сеанса . В RTSP любое сообщение, которое содержит какое-либо содержимое, должно иметь заголовок Content-Length, гарантирующий, что получатель сможет идентифицировать конец сообщения. В НТТР/1.1 же применен ряд других способов для определения конца сообщения; например, содержимое в сообщении НТТР/1.1 может передаваться в закодированном виде или состоять из нескольких фрагментов. RTSP не поддерживает эти функции. Заголовок Content-Base предоставляет основной URI, используемый для относительных URI в теле содержимого. Хотя заголовок Content-Base был определен в предложении RFC 2068, в проект стандарта НТТР/1.1 (RFC 2616) этот заголовок не вошел. Заголовки Expires и Last-Modified в RTSP связаны с кэшированием информации, содержащей описание сеанса . Заголовок Expires указывает, как долго описание сеанса может быть кэшировапо без повторной проверки актуальности информации. Заголовок Last-Modified указывает время последнего изменения описания сеанса. Аргумент заголовка Last-Modified может быть использован в дальнейших запросах If-Modified-Since для проверки актуальности кэшированной копии содержимого. Заголовок Allow содержит список методов, которые поддерживаются для запрошенного URI.

Таблица 12.6. Заголовки содержимого RTSP (заголовки, имеющиеся в НТТР/1.1, помечены ‘*’)

Заголовок

Описание

Content-Length*

Длина тела содержимого (обязателен, если имеется содержимое)

Content-Type*

Тип содержания тела содержимого

Content-Language*

Язык, используемый в теле содержимого

Content-Encoding*

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

Content-Location*

Альтернативное местоположение ресурса

Content-Base

Основной URI, используемый для относительной адресации внутри тела содержимого (в RFC 2068)

Expires*

Истечение срока храпения описания сеанса

Last-Modified*

Время последней модификации описания сеанса

Allow*

Методы, которые могут быть применены к ресурсу

ЗАГОЛОВКИ, ОТСУТСТВУЮЩИЕ В HTTP/1.1

Несколько заголовков НТТР/1.1 не были включены в спецификацию RTSP. Эти заголовки относятся к ряду категорий, выражающих различия между двумя протоколами (см. таблицу 12.7). Большинство заголовков связано с поддержкой HTTP различного содержимого в сообщениях запросов и ответов. Как говорилось выше, RTSP-сообщения не содержат содержимого, за исключением описаний сеансов. Описания сеансов представляют собой относительно короткие текстовые документы. По сравнению с HTTP, RTSP не имеет мощных механизмов поддержки передачи различных видов содержимого. Клиенту и серверу RTSP не нужно согласовывать набор символов или способ кодирования для описания сеанса. RTSP-сообщения не содержат хэша MD5 для тела содержимого, а после содержимого сообщения отсутствуют какие-либо трейлеры. RTSP также не поддерживает проверку актуальности ресурсов, передаваемых в RTSP-сообщениях.

В RTSP отсутствует ряд заголовков НТТР/1.1, относящихся к запросам на диапазоны. В НТТР/1.1 клиент может использовать заголовок запроса Range для того, чтобы запросить подмножество байтов ресурса. Если ресурс с указанным URI не допускает запросов на диапазоны, HTTP-ответ возвращает весь ресурс вместе с заголовком Accept-Ranges: none. В отличие от этого, RTSP-сервер, не поддерживающий запросы на диапазоны, не передает клиенту весь мультимедийный поток автоматически. Вместо этого сервер отвечает клиенту кодом ошибки. Таким образом необходимость в заголовке Accept-Ranges отпадает. HTTP и RTSP несколько различным образом реагируют на успешный запрос на диапазон. Сервер НТТР/1.1 указывает, какой диапазон байтов возвращается, в заголовке содержимого Con- tent-Range. В RTSP же сервер указывает интервал времени, выбранный в заголовке Range. Этот диапазон не обязательно должен совпадать с запрашиваемым интервалом. Разница в названии заголовков отражает тог факт, что в RTSP интервал времени относится к мультимедийному потоку, доставляемому по отдельному транспортному соединению, а не к содержимому RTSP.

Таблица 12.7. Заголовки НТТР/1.1, не включенные в RTSP

В RTSP отсутствуют заголовки Host и Pragma, которые были включены в НТТР/1.1 для обратной совместимости с НТТР/1.0. Клиент НТТР/1.1 использует заголовок Host для указания доменного имени сервера, поскольку эта информация не может содержаться в URI запроса. В отличие от этого, URI запроса в RTSP содержит абсолютный путь, что избавляет от необходимости иметь отдельный заголовок, передающий имя сервера. Заголовок Pragma был введен в НТТР/1.0 для директив управления сообщением, таких как Pragma: no-cache. В НТТР/1.1 используется другой подход для передачи информации о кэшировании — заголовок Cache-Control. Однако для поддержания обратной совместимости с НТТР/1.0 требуется, чтобы клиенты и серверы НТТР/1.1 понимали заголовок Pragma. Поскольку в RTSP подобных проблем с обратной совместимостью не существует, заголовки Host и Pragma ему не нужны. Также не используются заголовки Upgrade и Warning. В RTSP также отсутствует заголовок Max-Forwards, который относится к методам запросов НТТР/1.1, и заголовок Expect, который отсутствует в RFC 2068.

Благодарность за помощь в подготовке материала выражается Роману *** (rosforever)

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

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

1 комментарий »

 
  • Роман says:

    Я поправил кучу ошибок сканирования в данной статье, поскольку она мне пригодилась для объема отчета. Если интересно – могу выслать ее!

 

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

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