RTSP 2.0 | Метод OPTIONS

RTSP 2.0 | Метод OPTIONS

Методы RTSP 2.0 — это указание того, что должно быть выполнено на ресурсе, идентифицированном Request-URI на основании синтаксиса строки запроса RTSP, определённой как:

<Method> SP <Request-URI> SP <RTSP-Version> CRLF

Методы RTSP 2.0 перечислены в таблице 2.

Семантика RTSP-метода «OPTIONS» аналогична семантике HTTP-метода OPTIONS, описанного в разделе 4.3.7 [RFC7231 #]. Однако в RTSP OPTIONS является двунаправленным в том смысле, что клиент может отправить запрос на сервер и наоборот. Клиент ДОЛЖЕН реализовать возможность отправки запроса OPTIONS, а сервер или прокси-сервер ДОЛЖЕН реализовать возможность ответа на запрос OPTIONS. В дополнение к этой функциональности «MUST-implement» (ДОЛЖЕН быть реализован), клиенты, серверы и прокси-серверы МОГУТ обеспечивать поддержку как для отправки запросов OPTIONS, так и для генерации ответов на запросы.

 

Запрос OPTIONS может быть выдан в любое время. Такой запрос не изменяет состояние сеанса. Однако это может продлить продолжительность жизни сеанса (см. Ниже). URI в запросе OPTIONS определяет объем запроса и соответствующий ответ. Если Request-URI ссылается на определенный медиаресурс на данном хосте, область действия ограничена набором методов, поддерживаемых для этого медиаресурса указанным агентом RTSP. Request-URI только с адресом хоста ограничивает область применения общими возможностями указанного агента RTSP безотносительно к каким-либо конкретным носителям. Если Request-URI является звездочкой («*»), область действия ограничена общими возможностями следующего перехода (то есть агент RTSP в прямой связи с отправителем запроса).

Независимо от объема запроса открытый заголовок ДОЛЖЕН всегда включаться в ответ OPTIONS, перечисляя методы, которые поддерживаются отвечающим агентом RTSP. Кроме того, если область запроса ограничена медиа-ресурсом, заголовок Allow ДОЛЖЕН быть включен в ответ, чтобы перечислить набор методов, которые разрешены для этого ресурса, если набор методов не полностью совпадает с набором в заголовке Public. Если данный ресурс недоступен, агент RTSP ДОЛЖЕН вернуть соответствующий код ответа, например 3rr или 4xx. Поддерживаемый заголовок МОЖЕТ быть включен в запрос для запроса набора функций, которые поддерживаются отвечающим агентом RTSP.

Метод OPTIONS может использоваться для поддержания сеанса RTSP живым. Однако это не является предпочтительным способом сигнализации поддержания сеанса связи; см. раздел 18.49 из RFC 7826. Запрос OPTIONS, предназначенный для поддержания активности сеанса RTSP, ДОЛЖЕН включать заголовок сеанса с соответствующим идентификатором сеанса. Такой запрос ДОЛЖЕН также использовать медиа или агрегированный управляющий URI в качестве Request-URI.

Пример:

C->S: OPTIONS rtsp://server.example.com RTSP/2.0
CSeq: 1
User-Agent: PhonyClient/1.2
Proxy-Require: gzipped-messages
Supported: play.basic

S->C: RTSP/2.0 200 OK
CSeq: 1
Public: DESCRIBE, SETUP, TEARDOWN, PLAY, PAUSE, OPTIONS
Supported: play.basic, setup.rtp.rtcp.mux, play.scale
Server: PhonyServer/1.1

Обратите внимание, что тег функции «gzipped-messages» в Proxy-Require является фиктивной функцией.

Ссылки на документы

Скачать оригинальный документ на английском языке RFC 7826 — Real-Time Streaming Protocol Version 2.0

Читать полную версию документа на русском языке RFC 7826 — Потоковый протокол в реальном времени (RTSP), версия 2.0