Методы RTSP 2.0 — это указание того, что должно быть выполнено на ресурсе, идентифицированном Request-URI на основании синтаксиса строки запроса RTSP, определённой как:
<Method> SP <Request-URI> SP <RTSP-Version> CRLF
Методы RTSP 2.0 перечислены в таблице 2.
Метод REDIRECT выдается сервером для информирования клиента о том, что предоставленная услуга будет прекращена и где вместо нее может быть предоставлена соответствующая услуга. Это может случиться по разным причинам. Один из них заключается в том, что сервер администрируется таким образом, что он должен прекратить предоставлять услуги. Таким образом, клиент должен подключиться к другому местоположению сервера, чтобы получить доступ к ресурсу, указанному в Request-URI.
Запрос REDIRECT ДОЛЖЕН содержать заголовок Terminate-Reason (раздел 18.52 из RFC 7826) для информирования клиента о причине запроса. Дополнительные параметры, связанные с причиной, также могут быть включены. Цель здесь состоит в том, чтобы позволить администратору сервера выполнить контролируемое отключение сервера RTSP. Это требует достаточного времени для информирования всех объектов, имеющих связанное состояние с сервером, и для того, чтобы они выполнили контролируемую миграцию с этого сервера на резервный сервер.
Запрос REDIRECT с заголовком Session (раздел 18.49 из RFC 7826) имеет сквозную область (то есть сервер-клиент) и применяется только к данному сеансу. Любые промежуточные прокси НЕ ДОЛЖНЫ отключать канал управления, пока есть другие оставшиеся сквозные сеансы. ТРЕБУЕТСЯ чтобы заголовок Location (раздел 18.28 из RFC 7826) ДОЛЖЕН был содержать полный абсолютный URI, указывающий на ресурс, к которому клиент ДОЛЖЕН повторно подключиться. В частности, Location НЕ ДОЛЖНО содержать только хост и порт. Клиент может получить запрос REDIRECT с заголовком Session, если и только если был установлен сквозной сеанс.
Клиент может получить запрос REDIRECT без заголовка Session в любое время, когда у него есть связь или соединение, установленное с сервером. Объем такого запроса ограничен следующим переходом (то есть агентом RTSP, находящимся в прямой связи с сервером) и применяется ко всем контролируемым сеансам, а также к соединению между агентом RTSP следующего перехода и сервером. Запрос REDIRECT без заголовка Session указывает, что все сеансы и ожидающие запросы, управляемые через соединение, ДОЛЖНЫ быть перенаправлены. Заголовок Location, если он включен в такой запрос, ДОЛЖЕН содержать абсолютный URI только с адресом хоста и ДОПОЛНИТЕЛЬНЫМ номером порта сервера, к которому СЛЕДУЕТ подключиться агент RTSP. Любые промежуточные прокси должны делать все следующее в указанном порядке:
- ответить на запрос REDIRECT
- отключить канал управления от запрашивающего сервера
- подключиться к серверу по указанному адресу хоста
- передать запрос REDIRECT каждому подходящему клиенту (обычно это клиенты с активным сеансом или без ответа на запрос)
Примечание. Прокси-сервер отвечает за принятие REDIRECT-ответов от своих клиентов; эти ответы НЕ ДОЛЖНЫ передаваться ни на исходный сервер, ни на перенаправленный сервер.
Сервер, который должен завершить сеанс или все его сеансы и не имеет альтернативного сервера для перенаправления, ДОЛЖЕН использовать запросы TEARDOWN.
Если в запросе REDIRECT отсутствует параметр «time» (время) заголовка Terminate-Reason, клиент ДОЛЖЕН немедленно выполнить перенаправление и вернуть ответ серверу. Сервер должен считать сеанс завершенным и может освободить любое связанное состояние после получения успешного ответа (2xx). Сервер МОЖЕТ закрыть соединение сигнализации после получения ответа, а клиент ДОЛЖЕН закрыть соединение сигнализации после отправки ответа 2xx. Исключением является случай, когда клиент имеет несколько сеансов на сервере, управляемом данным сигнальным соединением. В этом случае клиент ДОЛЖЕН закрыть соединение, когда он получил и ответил на запросы REDIRECT для всех сеансов, управляемых соединением сигнализации.
Параметр «time» (время) заголовка Terminate-Reason МОЖЕТ использоваться для указания времени настенного часа, к которому ДОЛЖНО произойти перенаправление. Чтобы позволить клиенту определить это время перенаправления, не синхронизируя время с сервером, сервер ДОЛЖЕН включить в запрос заголовок Date. Клиент должен был прервать сеанс и закрыть соединение до того, как прервалась временная линия перенаправления. Сервер МОЖЕТ просто перестать предоставлять услуги, когда истечет установленный срок, или он может выдавать запросы TEARDOWN для оставшихся сеансов.
Если запрос REDIRECT истекает в соответствии с правилами в Разделе 10.4 из RFC 7826, сервер МОЖЕТ завершить сеанс или транспортное соединение, которое будет перенаправлено запросом. Это защита от ненадлежащего поведения клиентов, которые отказываются отвечать на запрос REDIRECT. Это действие устраняет любой стимул не подтверждать получение запроса REDIRECT.
После обработки запроса REDIRECT клиент, который хочет продолжить получать мультимедиа для ресурса, идентифицируемого Request-URI, должен будет установить новый сеанс с указанным хостом. Если URI, указанный в заголовке Location, является допустимым URI ресурса, клиент ДОЛЖЕН выпустить запрос DESCRIBE для URI.
Примечание. Медиа-ресурс, указанный в заголовке Location, может быть идентичным, немного другим или совершенно другим. Это причина, по которой новый запрос DESCRIBE ДОЛЖЕН быть выдан.
Если заголовок Location содержит только адрес хоста, клиент может предположить, что носитель на новом сервере идентичен носителю на старом сервере, то есть вся информация о конфигурации носителя из старого сеанса по-прежнему действительна, за исключением адреса хоста. Тем не менее, использование условной SETUP с использованием идентификаторов MTag РЕКОМЕНДУЕТСЯ в качестве средства проверки предположения.
Этот пример запроса перенаправляет трафик для этого сеанса на новый сервер в заданное абсолютное время:
S->C: REDIRECT rtsp://example.com/fizzle/foo RTSP/2.0
CSeq: 732
Location: rtsp://s2.example.com:8001/fizzle/foo
Terminate-Reason: Server-Admin ;time=19960213T143205Z
Session: uZ3ci0K+Ld-M
Date: Thu, 13 Feb 1996 14:30:43 GMT
C->S: RTSP/2.0 200 OK
CSeq: 732
User-Agent: PhonyClient/1.2
Session: uZ3ci0K+Ld-M
Ссылки на документы
Скачать оригинальный документ на английском языке RFC 7826 — Real-Time Streaming Protocol Version 2.0
Читать полную версию документа на русском языке RFC 7826 — Потоковый протокол в реальном времени (RTSP), версия 2.0
