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

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

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

12.4.3.

Заголовки RTSP

На момент появления документа RFC 2326 по 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-ceanc может иметь несколько

ТСР-соедипений, либо клиент и сервер могут взаимодействовать но 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.

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

Таблица 12.3. Общие RTSP-заголовки

(заголовки, имеющиеся в НТТР/1.1, помечены '*')

Заголовок

Session

CSeq

Transport

Range

Scale

Speed

Date*

Via*

[ Connection*

Cache-Control*

Описание |

Идентификатор сеанса |

Порядковый номер сообщения |

Согласование параметров транспорта |

Выбор интервала времени для воспроизведения |

Согласование скорости воспроизведения |

Согласование скорости передачи |

Дата/время создания сообщения |

Список промежуточных серверов |

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

Директивы кэширования

Заголовки Range, Scale и Speed относятся к временным свойствам мультиме-

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

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

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

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

но включить в RTSP-занрос PLAY заголовок Range, указывающий желаемый ин-

тервал времени. Концептуально это похоже на использование заголовка запроса

Range в НТТР/1.1. Однако запросы на диапазон в НТТР/1.1 идентифицируют

подмножество данных в ресурсе, диапазон в RTSP определяет интервал време1Н1

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

Range: npt=30-

для указания серверу начать передачу данных с 30-й секунды в потоке (NPT озна-

чает нормальное время воспроизведения (Normal Play Time), при этом началу по-

тока соответствует нулевая секунда). На практике индексирование по времени вы-

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

кадров на протяжении потока могут меняться. 30-ая секунда точка в 60-секундном

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

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

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

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

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

серверу инициировать передачу с близкого момента времени. Сервер указывает

выбранный интервал времени в заголовке Range сообщения-ответа. Специфика-

ция RTSP не предъявляет каких-либо требований отгюсительно того, насколько

значение Range, указанное в сообщении-ответе, может отличаться от значения

Range, занрошенного клиентом.

Заголовки Scale и Speed поддерживают функции ускоренной и обратной пере-

мотки для методов PLAY и RECORD. Scale относится к скорости воспроизведе-

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

Обычная скорость воспроизведения соответствует значению 1. Большие положи-

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

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

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

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

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

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

вращает выбранную скорость в заголовке Scale сообщения-ответа. Сервер адапти-

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

Например, когда клиент запрашивает операцию ускоренной перемотки в видеокли-

пе,

сервер может доставлять не все, а подмножество кадров. Хотя выборка подмно-

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

ство ускоренгюго воспроизведения будет хуже.

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

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

веде1Н1я потока скоростью. Это соответствует значению скорости, равному 1. Боль-

шее значение соответствует увеличению скорости, а меньшее значение

—

уменьше-

нию.

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

ния-запроса, а сервер возвращает выбранную скорость передачи в заголовке Speed

сообщения-ответа. Заголовок Speed может быть использован вместе с заголовком

Scale для координации передачи потока во время операций ускоренной и обратной

перемотки. Клиент может использовать заголовок 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,

и DP и RTP. Сервер может выбрать размер пакета меньший или равный размеру,

запрошенному клиентом. Заголовки Bandwidth и Blocksize решают проблемы,

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

Глава

12.

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

443

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

ляемой транспортным протоколом.

Таблица 12.4. Заголовки запросов RTSP

(заголовки, имеющиеся в НТТР/1.1, помечены '*')

Заголовок

Bandwidth

Blocksize

Conference

Require

Proxy-Require

From*

User-Agent*

Authorization*

Referer*

If-Match*

If-Modified-Since*

Accept*

Accept-Encoding*

[Accept-Language*

Описание |

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Заголовок Conference устанавливает логическую связь между потоком RTSP и

существующей конференцией по другому протоколу, например, SIP. С точки зре-

ния RTSP-сервера, идентификатор конференции представляет собой кодирован-

ную строку. Связывание RTSP-сервера с текущей конференцией полезно для раз-

личных целей. Например, клиент хочет воспроизвести предварителыю записанный

аудиоклип в имеющейся конференции. Клиент может включить заголовок Confe-

rence в запрос SETUP, чтобы идентифицировать соответствующую конференцию.

Запрос SETUP также включает заголовок Transport для передачи информации о

текущей конференции. Например, заголовок Transport может указывать IP-адрес

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

SETUP RTSP-клиент может выдать запрос PLAY для инициирования передачи

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

Заголовки Require и Proxy-Require предоставляют клиенту эффективный и до-

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

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

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

Require: unusual-feature). Если сервер не распознает или не поддерживает функ-

цию,

приведенную в заголовке Require, RTSP-ответ возвращает клиенту отрица-

тельное подтверждение ("Unsupported Header"). В противоположность этому,

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

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

которые они не поддерживают. Заголовок Require дает возможность клиенту выда-

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

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

цию.

Агент пользователя использует заголовок 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://f00.com/bar/audio;seq=47;rtptime=2894,

url=rtsp://f00.com/bar/video;seq=184;rtptime=6674

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

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

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

12.3.1.

При передаче,

инициированной RTSP, клиент узнает эти значения из заголовка RTP-Info. Пер-

вый RTP-пакет в потоке будет иметь эти начальные значения. Порядковый номер

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

Таблица 12.5. Заго.повки ответов RTSP

(заголовки, имеющиеся в НТТР/1.1, помечены '*')

Заголовок

RTP-Info

Unsupported

Server*

Location*

Retry-After*

Vary*

Public*

WWW-Authenticate*

[Proxy-Authenticate*

Описание |

Специфические для RTP параметры в запросе PLAY ]

Функция не поддерживается сервером

Идентификация сервера |

Местонахождение ресурса

Задержка перед попыткой повторного запроса

Выбор версии ресурса

Список поддерживаемых методов (Allow в НТТР/1.1) |

Вызов для аутентификации

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

ния-запросы с заголовками Require и Proxy-Require. Запрашиваемые опции, пе

Глава

12.

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

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

ния-ответа. Тем самым серверу предоставляется возможность разъяс1Н4ть, почему

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

головки ответов, заимствованные из НТТР/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-Modi-

fied может быть использован в дальнейших запросах If-Modified-Since для провер-

ки актуальности кэшированной копии содержимого. Заголовок Allow содержит

список методов, которые поддерживаются для запрошенного URI.

Таблица 12.6. Заголовки содержимого RTSP

(заголовки, имеющиеся в НТТР/1.1, помечены '*')

Заголовок

Content-Length*

Content-Type*

Content-Language*

Content-Encoding*

Content-Location*

Content-Base

Expires*

Last-Modified*

[Allow*

Описание |

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

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

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

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

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

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

внутри тела содержимого (в RFC 2068) |

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

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

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

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

ЗАГОЛОВКИ, ОТСУТСТВУЮЩИЕ в НТТР/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

Категория

Передача

содержимого

Проверка

актуальности

Запрос на

диапазон

Заголовок

Accept-Charset

ТЕ

Transfer-Encoding

Content-MD5

Trailer

ETag

Age

If-None-Match

If-Unmodified-Since

If-Range

Accept-Ranges

Content-Range

Описание |

Допустимый набор символов |

Допустимая кодировка при передаче

Преобразование, применяемое к телу сообщения |

Проверка целостности тела содержимого

Список заголовков в конце сообщения

Валидатор |

Время, прошедшее с момента создания ответа |

Сравнение с атрибутами содержимого |

Сравнение со временем последней модификации |

Условный запрос на диапазон

Нежелание принимать запросы на диапазоны

Местоположение диапазона в теле содержимого

Глава

12.

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

Категория

НТТР/1.0

Разное

Заголовок

Host

Pragma

Upgrade

Warning

Max-Forwards

Expect

Описание |

Доменное имя сервера с запрашиваемым ресурсом |

Директива сообщения |

Переход к другим протоколам |

Уведомление об ошибке |

Ограничение на пересылку запроса |

Ожидаемая клиентом реакция сервера

В 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.

12.4.4.

Коды состояния RTSP

Каждое сообщение-ответ содержит код состояния, указывающий на результат

выполнения запроса. Коды состояния RTSP разделены на те же пять категорий,

что и коды ответов HTTP: информационные (1хх), успешного выполнения (2хх),

переадресации (Зхх), ошибки клиента (4хх) и ошибки сервера (5хх). В RTSP вве-

дено несколько новых кодов состояния, приведенных в таблице 12.8. RTSP также

заимствовал многие коды состояния, определенные в документе RFC 2068 (см.

таблицу 12.9). Во избежание конфликтов с новыми кодами ответов НТТР/1.1, ко-

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

с х50. Новые коды относятся к нескольким основным категориям:

• Системные ресурсы. Передача или прием мультимедийного потока может по-

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

стояния 250 Low on Storage Space предупреждает клиента, что на сервере от-

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

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

ка, выдав ответ 453 Not Enough Bandwidth.

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

ную или адрес, которые сервер не распознает. При получении запроса

SET_PARAMETER, который ссылается на неизвестный параметр, сервер по-

сылает ответ 451 Parameter Not Understood. Аналогично сервер посылает от-

вет 452 Conference Not Found или 454 Session Not Found при получении за-

проса с неизвестным идентификатором конференции Conference или сеанса

Session, соответственно. Если сервер не может установить соединение для

448

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

доставки потока данных клиенту, сервер отправляет ответ 462 Destination

Unreachable.

• Неподдерживаемая функция. Клиентский запрос может содержать метод

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

UR1.

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

туации (455 Method Not Valid in This State), a некоторые заголовки могут

быть некорректными для определенных запрашиваемых URI (456 Header

Field Not Valid for Resource). Запрос PLAY может пытаться осуществить пе-

ремещение в несуществующее место в потоке (457 Invalid Range), либо запрос

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

значенного только для чтения (458 Parameter Is Read-Only). Заголовок

Transport в запросе PLAY может не содержать поддерживаемой специфика-

ции транспорта (461 Unsupported Transport), либо сервер может пе поддер-

живать функцию, содержащуюся в заголовках Require или Proxy-Require

(551 Option Not Supported).

• Операции с сеансом/потоком. Клиентский запрос может нарушать иерархию

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

операцию потокового уровня над идентифицируемым по URI запроса ресур-

сом, который является сеансом (459 Aggregate Operation Not Allowed), либо

операцию сеансового уровня над ресурсом, который является потоком (460

Only Aggregate Operation Allowed).

Бо.'1ьшинство новых кодов состояния относится к ошибкам клиента (4хх), за

исключением кодов 250 Low on Storage space и 551 Option Not Supported, кото-

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

ветственно.

Таблица 12.8. Новые коды состояния RTSP

Категория

Системные

ресурсы

Неизвестный

идентификатор

Неподдсржпвас1Мые

функнии

Код состояния и краткое описание |

250 Low on Storage Space (Недостаточно памяти для хранения) |

453 Not Enough Bandwidth (Пропускная способность недостаточна) |

451 Parameter Not Understood (Параметр не может быть распознан) |

452 Conference Not Found (Конференция не найдена) |

454 Session Not Found (Сеанс не найден) |

462 Destination Unreachable (Место назначения недостижимо) |

455 Method Not Vahd in This State (Неверный метод для данного

состояния) 1

456 Header Field Not Valid for Resource (Неверное поле заголовка

для ресурса) |

457 Invalid Range (Неверный интервал) |

458 Parameter Is Read-Only (Параметр только для чтения) |

461 Unsupported Transport (Неподдерживаемый транспорт) |

551 Option Not Supported (Опция не поддерживается)

Глава

12.

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

449

Категория

Сеаис/поток

Код состояния и краткое описание |

459 Aggregate Operation Not Allowed (Операция агрегирования

запрещена) |

460 Only Aggregate Operation Allowed (Разрешена только операция

агрегирования)

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

ки мультимедийных потоков, производный от НТТР/1.1 (см. таблицу 12.9). Про-

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

мультимедийных данных па сервер. RTSP и HTTP PIMCIOT сходную инфраструкту-

ру для применения метода запроса к ресурсу, идентифицируемому URI, в соответ-

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

зательное содержимое. Спецификация RTSP во многом следует концепциям

НТТР/1.1,

связанным с кэшированием, серверами-посредниками и аутегггифика-

цией. Эти сходные черты проявляют себя во многих заголовках и кодах состояния

RTSP, заимствованных из НТТР/1.1. Тем не менее, RTSP имеет ряд существенных

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

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

того,

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

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

таймировапия, а также к иерархическими отношениями между кадрами, потоками

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

заголовках и кодах состояния.

Таблица 12.9. Коды состояния RTSP, заимствованные из НТТР/1.1

100 Continue

200 OK

201 Created

300 Multiple Choices

|301 Moved Permanently

302 Moved Tcmporaly

1303 See Other

304 Not Modified

305 Use Proxy

1400 Bad Request

401 Authorized

1402 Payment Required

|403 Forbidden

1404 Not Found

1405 Method Not Allowed

406 Not Acceptable

407 Proxy Authentication Required |

408 Request Time-out j

410 Gone

411 Length Required |

412 Precondition Failed |

413 Request Entity Too Large |

414 Request"URI Too Large

415 Unsupported Media Type |

500 Internal Server Error |

501 Not Implemented

502 Bad Gateway

503 Service Unavailable |

504 Gateway Time-out |

505 RTSP Version Not Supported J