RTSP 2.0 | Поле общего заголовка CSeq

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

Поле общего заголовка «CSeq» указывает порядковый номер (целое число) для пары «запрос/ответ» RTSP. Это поле ДОЛЖНО присутствовать во всех запросах и ответах. Агенты RTSP поддерживают серию порядковых номеров для каждого респондента, к которому у них есть открытый транспортный канал сообщения. Для каждого нового запроса RTSP агент отправляется на конкретном транспорте сообщения RTSP, значение CSeq ДОЛЖНО быть увеличено на единицу. Начальный порядковый номер может быть любым числом; однако РЕКОМЕНДУЕТСЯ начинать с нуля «0». Каждый ряд порядковых номеров уникален для каждого запрашивающего и отвечающего, то есть клиент имеет одну серию для своих запросов к серверу, а сервер имеет другую при отправке запросов клиенту. Каждый запросчик и ответчик идентифицируются по своему адресу сокета (IP-адрес и номер порта), то есть по направлению TCP-соединения.

Любой повторно переданный запрос ДОЛЖЕН содержать тот же порядковый номер, что и исходный, то есть порядковый номер не увеличивается для повторных передач одного и того же запроса. Принимающие запросы агента RTSP ДОЛЖНЫ обрабатывать запросы, поступающие на конкретный транспорт, в порядке порядковых номеров. Ответы отправляются в том порядке, в котором они были сгенерированы. Ответ RTSP ДОЛЖЕН иметь тот же порядковый номер, который присутствовал в соответствующем запросе. Агент RTSP, получающий ответ, МОЖЕТ получать ответы не по порядку по сравнению с порядком отправленных им запросов. Таким образом, агент ДОЛЖЕН использовать порядковый номер в ответе, чтобы связать его с соответствующим запросом.

Основное назначение порядкового номера — сопоставить ответы на запросы.

Требование использовать приращение порядкового номера, равное единице, для каждого нового запроса должно поддерживать любую будущую спецификацию транспорта сообщений RTSP по протоколу, который не обеспечивает доставку по порядку или является ненадежным.

Приведенные выше правила, относящиеся к начальному порядковому номеру, могут показаться излишне свободными. Причиной этого является удовлетворение некоторого общего поведения существующих реализаций: при последовательном использовании нескольких надежных соединений все же может быть проще всего использовать одну серию порядковых номеров для клиента, соединяющегося с конкретным сервером. Таким образом, начальный порядковый номер может быть произвольным в зависимости от количества предыдущих запросов. Для любого ненадежного транспорта потребуется более строгое определение или другое решение, позволяющее обнаружить любую потерю первого запроса.

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

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

Клиент, подключенный к прокси-серверу и использующий этот транспорт для отправки запросов на несколько серверов, создает ситуацию, когда вполне вероятно, что ответы будут получены не по порядку. Это связано с тем, что прокси-сервер будет устанавливать отдельные транспорты от прокси-сервера к серверам, на которых следует пересылать запросы клиента. Когда ответы поступают с разных серверов, они передаются клиенту в порядке их поступления на прокси-сервер и могут обрабатываться, а не в порядке исходных порядковых номеров клиента. Это сделано специально, чтобы избежать блокирования некоторых запросов сеанса медленной обработкой запросов другим сервером.

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

CSeq = "CSeq" HCOLON cseq-nr

cseq-nr = 1*9DIGIT

Ссылки

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

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

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

Поделись записью