Методы RTSP 2.0 — это указание того, что должно быть выполнено на ресурсе, идентифицированном Request-URI на основании синтаксиса строки запроса RTSP, определённой как:
<Method> SP <Request-URI> SP <RTSP-Version> CRLF
Методы RTSP 2.0 перечислены в таблице 2.
Метод GET_PARAMETER извлекает значение любого указанного параметра или параметров для презентации (presentation) или потока (stream), указанного в URI. Если заголовок «Session» присутствует в запросе, значение параметра ДОЛЖНО быть получено в указанном контексте сеанса. Есть два способа указания параметров, которые будут получены.
Первый подход включает заголовки, которые были определены как пригодные для этой цели. Заголовки для этой цели должны позволять пустые или лишенные части значения, чтобы избежать необходимости указывать фиктивные данные при указании желания извлечь значение. Успешное завершение запроса также должно быть видно из любых заполненных значений в ответе. Заголовки в этой спецификации, которые МОГУТ использоваться для получения их текущего значения с помощью GET_PARAMETER, перечислены ниже; дополнительные заголовки МОГУТ быть указаны в будущем:
Другой способ — указать тело сообщения, в котором перечислены параметры, которые необходимо получить. Заголовок Content-Type (раздел 18.19 из RFC 7826) используется для указания того, какой формат имеет тело сообщения. Если получатель запроса не поддерживает тип носителя, используемый для тела сообщения, он ДОЛЖЕН ответить, используя код ошибки 415 (Неподдерживаемый тип носителя). Ответчик на запрос GET_PARAMETER ДОЛЖЕН использовать мультимедийный тип запроса для ответа. Дополнительные сведения о согласовании тела сообщения смотри в разделе 9.3 из RFC 7826.
Агенты RTSP, реализующие поддержку для ответа на запросы GET_PARAMETER, ДОЛЖНЫ реализовывать формат «text/parameters» (текст / параметры) (Приложение F из RFC 7826). Это необходимо для обеспечения реализации по меньшей мере одного известного формата для параметров и, таким образом, предотвращения сбоя согласования формата параметров.
Все параметры, указанные в теле сообщения, должны быть понятны агенту-получателю запроса. Если один или несколько параметров не поняты, НЕОБХОДИМО отправить 451 (Непонятный параметр), включая тело, в котором перечислены параметры, которые не были поняты. Если все параметры понятны, их значения заполняются и возвращаются в теле ответного сообщения.
Этот метод также можно использовать без тела сообщения или какого-либо заголовка, который запрашивает параметры для целей поддержания активности. Таймер поддержания активности обновлен для любого успешного запроса, то есть получен ответ 200 OK. Любой необязательный заголовок, присутствующий в таком запросе, может или не может быть обработан. Обычно наличие заполненных значений в заголовке будет указывать на то, что заголовок был обработан. Однако в случаях, когда это трудно определить, рекомендуется использовать тег функции и заголовок Require (раздел 18.43 из RFC 7826). По этой причине обычно легче получить какие-либо параметры для отправки в теле, чем использовать какой-либо заголовок.
Пример:
S->C: GET_PARAMETER rtsp://example.com/fizzle/foo RTSP/2.0
CSeq: 431
User-Agent: PhonyClient/1.2
Session: OccldOFFq23KwjYpAnBbUr
Content-Length: 26
Content-Type: text/parameters
packets_received
jitter
C->S: RTSP/2.0 200 OK
CSeq: 431
Session: OccldOFFq23KwjYpAnBbUr
Server: PhonyServer/1.1
Date: Mon, 08 Mar 2010 13:43:23 GMT
Content-Length: 38
Content-Type: text/parameters
packets_received: 10
jitter: 0.3838
Ссылки на документы
Скачать оригинальный документ на английском языке RFC 7826 — Real-Time Streaming Protocol Version 2.0
Читать полную версию документа на русском языке RFC 7826 — Потоковый протокол в реальном времени (RTSP), версия 2.0
