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

Каждое сообщение-ответ содержит код состояния, указывающий на результат выполнения запроса. разделены на те же пять категорий, что и коды ответов HTTP: информационные (lxx), успешного выполнения (2xx), нереадресации (Зхх), ошибки клиента (4xx) и ошибки сервера (5xx). В RTSP введено несколько новых кодов состояния, приведенных в таблице 12.8. RTSP также заимствовал многие коды состояния, определенные в документе RFC 2068 (см. таблицу 12.9). Во избежание конфликтов с новыми кодами ответов НТТР/1.1, которые могут появиться в будущем, специфические для RTSP коды начинаются с x50. Новые коды относятся к нескольким основным категориям:

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

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

•          Неподдерживаемая функция. Клиентский запрос может содержать метод или заголовок, который не поддерживается для ресурса с указанным в запросе URI. Например, некоторые методы могут быть некорректными для даипой ситуации (455 Method Not Valid in This State), а некоторые заголовки могут быть некорректными для определенных запрашиваемых 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).

Большинство новых кодов состояния относится к ошибкам клиента (4xx), за ис ключением кодов 250 Low on Storage space и 551 Option Not Supported, которые представляют собой код успешного выполпепия и код ошибки сервера, соответственно.

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

Категория

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

Системные ресурсы

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

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

Неизвестный идентификатор

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

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

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

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

Неподдерживаемые функцин

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

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

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

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

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

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

Категория

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

Ссанс/поток

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

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

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

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

Резюме

Аудио- и видеопотоки отличаются от традиционного Web-содержания по трем основным признакам. Во-первых, аудио- и видеоданные имеют параметры гайми- роваиия, которые оказывают влияние на то, как медиаплейер иолучает и воспроизводит даииые. Во-вторых, доставка мультимедийных потоков требует от сервера выделения значительной полосы пропускания в течение продолжительного периода времени. В-третьих, для ряда приложений, работающих с мультимедийными потоками, допустима потеря некоторого количества данных. Эти уникальные характеристики вкупе с наличием разнообразных мультимедийных приложений привели к разработке протоколов, пригодных для доставки мультимедийных нотоков. Взаимное сближение мультимедийных приложений и Web пока еще только начинается. В дальнейшем приложения для мультимедийных потоков и соответствующие протоколы будут продолжать эволюционировать.

Источник: 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