RTSP 2.0 | Метод SET_PARAMETER

RTSP 2.0 | Метод SET_PARAMETER

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

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

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

Метод «SET_PARAMETER» запрашивает установку значения параметра или набора параметров для представления (presentation) или потока (stream), указанного в URI. Если заголовок Session присутствует в запросе, значение параметра ДОЛЖНО быть получено в указанном контексте сеанса. Метод SET_PARAMETER МОЖЕТ также использоваться без тела сообщения. Это РЕКОМЕНДУЕМЫЙ метод, который будет использоваться в запросе, отправленном с единственной целью обновления таймера подтверждения активности. Если этот запрос выполнен успешно, то есть получен ответ 200 OK, таймер поддержания активности обновлен. Любой необязательный заголовок, присутствующий в таком запросе, может или не может быть обработан. Чтобы позволить клиенту определить, был ли обработан какой-либо из таких заголовков, необходимо использовать тег функции и заголовок Require. По этой причине РЕКОМЕНДУЕТСЯ, чтобы любые параметры отправлялись в теле, а не с использованием какого-либо заголовка.

 

При использовании тела сообщения для перечисления параметров, которые необходимо установить, заголовок Content-Type (раздел 18.19 из RFC 7826) используется для указания того, какой формат имеет тело сообщения. Если получатель запроса не поддерживает тип носителя, используемый для тела сообщения, он ДОЛЖЕН ответить, используя код ошибки 415 (Неподдерживаемый тип носителя). Дополнительные сведения о согласовании тела сообщения см. в разделе 9.3 из RFC 7826. Ответчик на запрос SET_PARAMETER ДОЛЖЕН использовать мультимедийный тип запроса для ответа. Дополнительные сведения о согласовании тела сообщения см. в разделе 9.3 из RFC 7826.

Агенты RTSP, реализующие поддержку для ответа на запросы SET_PARAMETER, ДОЛЖНЫ реализовывать формат «text/parameters» (текст/параметры) (Приложение F из RFC 7826). Это должно обеспечить реализацию по меньшей мере одного известного формата для параметров и, таким образом, предотвратить сбой согласования формата параметров.

Запрос РЕКОМЕНДУЕТСЯ содержать только один параметр, позволяющий клиенту определить причину сбоя конкретного запроса. Если запрос содержит несколько параметров, сервер ДОЛЖЕН действовать только по запросу, если все параметры могут быть установлены успешно. Сервер ДОЛЖЕН позволять параметру многократно устанавливать одно и то же значение, но он МОЖЕТ запретить изменение значений параметров. Если получатель запроса не понимает или не может найти параметр, ДОЛЖНА использоваться ошибка 451 (Параметр не понят). Если параметр не может быть изменен, код ошибки — 458 (Параметр доступен только для чтения). Тело ответа ДОЛЖНО содержать только те параметры, в которых есть ошибки. В противном случае тело НЕ ДОЛЖНО быть возвращено. Тело ответа ДОЛЖНО использовать медиа-тип запроса для ответа.

Примечание: транспортные параметры для медиапотока ДОЛЖНЫ быть установлены только с помощью команды SETUP.

Ограничение установки параметров транспорта на SETUP для брандмауэров, подключенных к пограничным прокси RTSP.

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

Пример:

C->S: SET_PARAMETER rtsp://example.com/fizzle/foo RTSP/2.0
CSeq: 421
User-Agent: PhonyClient/1.2
Session: iixT43KLc
Date: Mon, 08 Mar 2010 14:45:04 GMT
Content-length: 20
Content-type: text/parameters

barparam: barstuff

S->C: RTSP/2.0 451 Parameter Not Understood
CSeq: 421
Session: iixT43KLc
Server: PhonyServer/1.0
Date: Mon, 08 Mar 2010 14:44:56 GMT
Content-length: 20
Content-type: text/parameters

barparam: barstuff

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

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

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