RTSP 2.0 | Поле общего заголовка Pipelined-Requests

RTSP 2.0 | Поле общего заголовка Pipelined-Requests

Общие заголовки RTSP 2.0 — это заголовки, которые могут использоваться как в запросах, так и в ответах. Общие заголовки RTSP 2.0 перечислены в таблице 1

Общий заголовок «Pipelined-Requests» используется для указания того, что запрос должен быть выполнен в контексте, созданном предыдущим запросом (запросами). Основное использование этого заголовка состоит в том, чтобы разрешить конвейеризацию запросов метода SETUP, чтобы любому дополнительному запросу SETUP после первого не нужно было ждать отправки идентификатора сеанса обратно запрашивающему агенту. Заголовок содержит уникальный идентификатор, который ограничен постоянным соединением, используемым для отправки запросов.

При получении запроса с Pipelined-Requests отвечающий агент ДОЛЖЕН искать, существует ли связь между этим идентификатором Pipelined-Requests для текущего постоянного соединения и идентификатором сеанса RTSP. Если привязка существует, то полученный запрос обрабатывается так же, как если бы он содержал заголовок Session с найденным идентификатором сеанса. Если сопоставление не существует и заголовок Session не включен в запрос, отвечающий агент ДОЛЖЕН создать привязку после успешного завершения запроса на создание сеанса, т.е. SETUP. Привязка НЕ ​​ДОЛЖНА создаваться, если запросу не удалось создать сеанс RTSP. В случае, если запрос содержит заголовок Session и заголовок Pipelined-Requests, заголовок Pipelined-Requests ДОЛЖЕН игнорироваться.

 

Примечание. Исходя из приведенного выше определения, по крайней мере, первый запрос, содержащий новый уникальный заголовок Pipelined-Requests, должен быть запросом SETUP (если протокол не расширен новыми методами создания сеанса). После этого первого дополнительные запросы SETUP или запросы любого типа, использующие контекст сеанса RTSP, могут включать заголовок Pipelined-Requests.

При ответе на любой запрос, который содержит заголовок Pipelined-Requests, сервер ДОЛЖЕН также включать заголовок Session, когда существует привязка к контексту сеанса. Агент RTSP, который знает идентификатор сеанса, НЕ ДОЛЖЕН использовать заголовок Pipelined-Requests в любом запросе и использовать только заголовок Session. Это так, как идентификатор Session является постоянным во всех транспортных контекстах, таких как TCP-соединения, а идентификатор конвейерного запроса — нет.

Агент RTSP, отправляющий запрос с заголовком Pipelined-Requests, несет ответственность за использование уникального и ранее неиспользованного идентификатора в транспортном контексте. В настоящее время только TCP-соединение определено как такой транспортный контекст. Сервер ДОЛЖЕН удалить идентификатор Pipelined-Requests и его привязку к сеансу после завершения этого сеанса. Несмотря на предыдущий мандат, агентам RTSP РЕКОМЕНДУЕТСЯ не использовать идентификаторы повторно, чтобы обеспечить лучшую обработку ошибок и ведение журнала.

Прокси-серверам RTSP может потребоваться преобразовать значения идентификатора Pipelined-Requests из входящих запросов в исходящие, чтобы обеспечить агрегирование запросов в постоянное соединение.

Синтаксис поля общего заголовка Pipelined-Requests в RTSP 2.0

Pipelined-Requests = "Pipelined-Requests" HCOLON startup-id

startup-id = 1*8DIGIT

Ссылки

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

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

Ссылка на синтаксис