Общие заголовки RTSP 2.0 — это заголовки, которые могут использоваться как в запросах, так и в ответах. Общие заголовки RTSP 2.0 перечислены в таблице 1
Общий заголовок «Transport» указывает, какой транспортный протокол должен использоваться, и настраивает его параметры, такие как адрес назначения, сжатие, время жизни многоадресной рассылки и порт назначения для одного потока. Он устанавливает те значения, которые еще не определены описанием презентации.
Заголовок запроса Transport МОЖЕТ содержать список вариантов транспорта, приемлемых для клиента, в форме нескольких записей спецификации транспорта. Транспортные спецификации разделены запятыми и перечислены в порядке убывания предпочтений. Каждая транспортная спецификация состоит из идентификатора транспортного протокола, за которым следует любое количество параметров, разделенных точками с запятой. Заголовок запроса Transport МОЖЕТ содержать несколько транспортных спецификаций, использующих один и тот же идентификатор транспортного протокола. Сервер ДОЛЖЕН возвратить заголовок ответа Transport в ответе, чтобы указать фактически выбранные значения, если они есть. Если спецификация транспорта не поддерживается, заголовок транспорта не возвращается, и ответ ДОЛЖЕН использовать код состояния 461 Unsupported Transport (Неподдерживаемый транспорт) (Раздел 17.4.25 из RFC 7826). В случае, если в запросе присутствовало более одной транспортной спецификации, сервер ДОЛЖЕН возвратить единственную транспортную спецификацию (transportspec), которая была фактически выбрана, если таковая имеется. Ожидается, что количество записей транспортных спецификаций будет ограничено, так как клиент получит руководство о том, какие конфигурации возможны из описания презентации.
Транспортный заголовок МОЖЕТ также использоваться в последующих запросах SETUP для изменения транспортных параметров. Сервер МОЖЕТ отказаться от изменения параметров существующего потока.
Идентификатор транспортного протокола для каждой транспортной спецификации определяет используемый транспортный протокол и любые связанные с ним правила. Каждый идентификатор транспортного протокола определяет параметры, которые должны быть выполнены; Могут возникнуть дополнительные необязательные параметры. Эта гибкость обеспечивается, поскольку параметры могут различаться и предоставлять различные параметры агенту RTSP. Транспортная спецификация может содержать только один из заданных параметров. Параметр состоит из имени и необязательно строки значения. Параметры МОГУТ быть заданы в любом порядке. Кроме того, спецификация транспорта может содержать только параметр типа одноадресной или многоадресной передачи. Идентификатор транспортного протокола и все параметры необходимо понимать в транспортной спецификации; в противном случае спецификацию перевозки ДОЛЖНЫ игнорировать. Прокси-сервер RTSP любого типа, который использует или изменяет спецификацию транспорта, например, прокси-сервер доступа или прокси-сервер безопасности, ДОЛЖЕН удалить спецификации с неизвестными параметрами, прежде чем пересылать сообщение RTSP. Если это не приводит к оставшейся спецификации транспорта, прокси ДОЛЖЕН отправить ответ 461 (Unsupported Transport) (раздел 17.4.25 из RFC 7826) без заголовка транспорта.
Заголовок Transport ограничен описанием одного медиапотока. (RTSP также может управлять несколькими потоками как единым целым.) Включение его в RTSP вместо того, чтобы полагаться на множество форматов описания сеанса, значительно упрощает разработку межсетевых экранов.
Общий синтаксис для идентификатора транспортного протокола представляет собой список разделенных слэшем токенов:
Value1/Value2/Value3...
Который для RTP-транспорта принимает форму:
RTP/profile/lower-transport.
Значение по умолчанию для параметров «lower-transport» (более низкий транспорт) зависит от профиля. Для RTP / AVP по умолчанию используется UDP.
Существует два разных способа указать, куда следует доставлять носители для одноадресной передачи:
- dest_addr: наличие этого параметра и его значений указывает адрес или адреса назначения (адрес хоста и пары портов для потоков IP), необходимые для передачи мультимедиа.
- No dest_addr: Отсутствие параметра dest_addr указывает, что сервер ДОЛЖЕН отправлять мультимедиа на тот же адрес, с которого отправляются сообщения RTSP.
Выбор метода для указания того, куда должен быть доставлен носитель, зависит от варианта использования. В некоторых случаях единственный разрешенный метод будет состоять в том, чтобы не использовать явную индикацию адреса и чтобы сервер доставлял мультимедиа в источник сообщений RTSP.
Для многоадресной рассылки существует несколько способов указания адресов, но они отличаются по своей работе от одноадресной:
- dest_addr с выбранным клиентом адресом: адрес и соответствующие параметры, такие как TTL (область действия), для фактической группы многоадресной рассылки, на которую будет доставлен носитель. С этим методом связаны некоторые аспекты безопасности (раздел 21 из RFC 7826), которые необходимо устранить, поскольку сервер RTSP можно использовать в качестве атакующего DoS в существующей многоадресной группе.
- dest_addr с использованием информации описания сеанса: вся информация, включенная в транспортный заголовок, может поступать из описания сеанса, например, строк SDP «c =» и «m =». Это смягчает некоторые проблемы безопасности предыдущих методов, поскольку именно поставщик сеансов выбирает группу многоадресной рассылки и область действия. Клиент ДОЛЖЕН включать информацию, если она доступна в описании сеанса.
- No dest_addr: поведение, когда в запросе нет явной многоадресной группы, не определено.
Прокси RTSP должен позаботиться. Если мультимедиа не требуется маршрутизировать через прокси, прокси должен будет ввести указатель назначения.
Ниже приведены параметры конфигурации, связанные с транспортом:
Общие параметры транспорта
unicast / multicast (одноадресная / многоадресная рассылка): этот параметр является взаимоисключающим указанием того, будет ли предпринята одноадресная или многоадресная доставка. ДОЛЖНО быть указано одно из двух значений. Клиенты, которые способны обрабатывать как одноадресную, так и многоадресную передачу, должны указать такую возможность, включив две полные транспортные спецификации с отдельными параметрами для каждого.
layers: количество многоадресных слоёв, которые будут использоваться для этого медиапотока. Слои отправляются по последовательным адресам, начиная с адреса dest_addr. Если параметр не включен, по умолчанию используется один слой.
dest_addr: общий параметр адреса назначения, который может содержать одну или несколько спецификаций адреса. Каждая комбинация протокола / профиля / более низкого транспорта должна иметь формат и интерпретацию своей спецификации адреса. Для RTP / AVP / UDP и RTP / AVP / TCP спецификация адреса представляет собой кортеж, содержащий адрес хоста и порт. Обратите внимание, что для каждой транспортной спецификации предназначен только один параметр назначения. Использование нескольких адресатов для распределения одного носителя по нескольким объектам не определено.
Клиент, отправляющий запрос RTSP, МОЖЕТ указать адрес назначения получателя потока с адресом хоста как часть кортежа. Когда адрес получателя указан, получатель может быть другой стороной, чем отправитель запроса. Чтобы не стать невольным исполнителем DoS-атаки с дистанционным управлением, сервер ДОЛЖЕН выполнить проверки безопасности (см. Раздел 21.2.1 из RFC 7826) и ДОЛЖЕН зарегистрировать такие попытки, прежде чем разрешить клиенту направить поток мультимедиа на адрес получателя, не выбранный сервером. Реализации не могут полагаться на TCP как на надежное средство идентификации клиента. Если сервер не позволяет установить адресную часть хоста для кортежа, он ДОЛЖЕН вернуть 463 (Destination Prohibited).
Часть адреса хоста кортежа МОЖЕТ быть пустой, например «: 58044», в тех случаях, когда необходимо указать только порт назначения. Ответы на запросы, включая заголовок транспорта с параметром dest_addr, ДОЛЖНЫ включать полный адрес назначения, который фактически используется сервером. Сервер НЕ ДОЛЖЕН удалять информацию об адресе, которая уже присутствует в запросе при ответе, если этого не требует протокол.
src_addr: общий параметр адреса источника, который может содержать одну или несколько спецификаций адреса. Каждая комбинация «протокола / профиля / более низкого транспорта» должна иметь формат и интерпретацию своей спецификации адреса. Для «RTP / AVP / UDP» и «RTP / AVP / TCP» спецификация адреса представляет собой кортеж, содержащий адрес хоста и порт.
Этот параметр ДОЛЖЕН быть задан сервером, если он передает медиапакеты с адреса, отличного от того, на который отправляются сообщения RTSP. Это позволит клиенту проверить адрес источника и дать ему адрес назначения для своих пакетов обратной связи RTCP, если используется RTP. Адрес или адреса, указанные в параметре src_addr, ДОЛЖНЫ использоваться как для отправки, так и для приема пакетов данных медиапотока. Основными причинами являются три причины: во-первых, указание порта и адреса источника позволяет получателю узнать, откуда ожидается получение пакетов. Во-вторых, обход NAT значительно упрощается, когда трафик проходит симметрично по привязке NAT. В-третьих, определенные механизмы прохождения NAT должны знать, по какому адресу и порту отправлять так называемые «пакеты привязки» от получателя к отправителю, таким образом создавая привязку адреса в NAT, которую может использовать поток пакетов отправитель-получатель.
Эта информация также может быть доступна через SDP. Однако, поскольку это скорее функция транспорта, чем инициализация мультимедиа, официальным источником этой информации должен быть ответ SETUP.
mode: параметр mode указывает методы, которые будут поддерживаться в этом сеансе. В настоящее время определено допустимое значение «PLAY». Если не указан, по умолчанию используется «PLAY». Значение «ЗАПИСЬ» было определено в RFC 2326 #; в этой спецификации это не определено, но зарезервировано. RECORD и другие значения могут быть указаны в будущем.
interleaved: параметр interleaved подразумевает смешивание потока мультимедиа с потоком управления в любом протоколе, который используется потоком управления, с использованием механизма, определенного в разделе 14 из RFC 7826. Аргумент предоставляет номер канала для использования в блоке $ (см. раздел 14 из RFC 7826 ) и ДОЛЖНЫ присутствовать. Этот параметр МОЖЕТ быть задан как интервал, например, interleaved = 4-5 в тех случаях, когда этого требует выбор транспорта для медиапотока, например, для RTP с RTCP. Номер канала, указанный в запросе, является лишь указанием от клиента к серверу, какой номер (а) канала использовать. Сервер МОЖЕТ установить любой действительный номер канала в ответе. Объявленные каналы являются двунаправленными, поэтому обе конечные стороны МОГУТ отправлять данные по данному каналу. Одним примером такого использования является второй канал, используемый для RTCP, где и сервер, и клиент отправляют пакеты RTCP по одному и тому же каналу.
Это позволяет обрабатывать RTP / RTCP аналогично тому, как это делается с UDP, т. е. Один канал для RTP, а другой — для RTCP.
MIKEY: этот параметр используется вместе со спецификациями транспорта, которые могут использовать MIKEY [RFC3830 #] для установления контекста безопасности. Пока только MIKEY могут использовать только профили RTP на основе SRTP SAVP и SAVPF, и это определено в Приложении C.1.4.1 из RFC 7826. Этот параметр может быть включен как в запрос, так и в ответные сообщения. Бинарное сообщение MIKEY ДОЛЖНО быть закодировано в Base64 [RFC4648 #] перед включением в часть значения параметра, где кодирование соответствует определению в Разделе 4 RFC 4648 и где биты заполнения установлены в ноль.
Multicast-specific
ttl: время жизни многоадресной рассылки для IPv4. При включении в запросы значение указывает значение TTL, которое клиент запрашивает у сервера. В ответ возвращается значение, фактически используемое сервером. Сервер должен будет рассмотреть, какие значения являются разумными, а также полномочия пользователя установить это значение. Соответствующие функции не нужны для IPv6, так как область действия является частью многоадресного адреса IPv6 [RFC4291 #].
RTP-specific
Эти параметры МОГУТ использоваться только в том случае, если транспортным протоколом мультимедиа является RTP.
ssrc: параметр ssrc, если он включен в ответ SETUP, указывает значение (значения) RRC SSRC [RFC3550 #], которое будет использоваться медиасервером для пакетов RTP в потоке. Значения выражаются в виде последовательности значений SSRC, разделенных косой чертой, каждый SSRC выражается шестнадцатеричным значением из восьми цифр.
Параметр ssrc НЕ ДОЛЖЕН быть указан в запросах. Функциональность указания параметра ssrc в запросе SETUP устарела, поскольку она несовместима со спецификацией RTP [RFC3550 #]. Если параметр включен в заголовок запроса Transport SETUP, сервер ДОЛЖЕН игнорировать его и выбрать соответствующие SSRC для потока. Серверу СЛЕДУЕТ установить параметр ssrc в заголовке ответа Transport.
RTCP-mux: используется для согласования использования мультиплексирования RTP и RTCP [RFC5761] для одного базового транспортного потока / потока. Наличие этого параметра в запросе SETUP указывает на поддержку клиента и требует от сервера использования мультиплексирования RTP и RTCP. Клиент ДОЛЖЕН включать только один транспортный поток в спецификацию заголовка Transport. Чтобы предоставить серверу выбор между использованием мультиплексирования RTP / RTCP или без него, должны быть включены две различные спецификации транспортных заголовков.
Настройка параметров и соединения, определенные ниже, МОГУТ использоваться только в том случае, если транспортный протокол медиаданных транспорта нижнего уровня ориентирован на соединение (например, TCP). Однако эти параметры НЕ ДОЛЖНЫ использоваться при чередовании данных по соединению RTSP.
setup: клиенты используют параметр настройки в строке Transport в запросе SETUP, чтобы указать роли, которые он хочет играть в соединении TCP. Этот параметр адаптирован из [RFC4145 #]. Использование этого параметра в транспорте без чередования RTP / AVP / TCP обсуждается в Приложении C.2.2 из RFC 7826; обсуждение ниже ограничено синтаксическими проблемами. Клиенты могут указать следующие значения для параметра настройки:
- active: клиент инициирует исходящее соединение.
- passive: клиент примет входящее соединение.
- actpass: клиент готов принять входящее соединение или инициировать исходящее соединение.
Если клиент не указывает значение настройки, предполагается «активное» значение.
В ответ на запрос клиента SETUP, где параметр установки установлен на «активный», ответ сервера 2xx ДОЛЖЕН назначить параметр настройки на «пассивный» в строке заголовка Transport.
В ответ на запрос клиента SETUP, где параметр установки установлен в «пассивный», ответ сервера 2xx ДОЛЖЕН назначить параметр настройки «активный» в строке заголовка Transport.
В ответ на запрос клиента SETUP, в котором для параметра установки задано значение «actpass», ответ сервера 2xx ДОЛЖЕН назначить параметр настройки для «активный» или «пассивный» в строке заголовка Transport.
Обратите внимание, что значение «holdconn» для настройки не определено для использования RTSP, и НЕ ДОЛЖНО появляться на линии Transport.
connection: Клиенты используют параметр соединения в части спецификации транспорта заголовка Transport в запросе SETUP, чтобы указать предпочтение клиента для повторного использования существующего соединения между клиентом и сервером (в этом случае клиент устанавливает параметр «connection» на «existing«) или запрос на создание нового соединения между клиентом и сервером (при котором приведение клиента устанавливает для параметра «connection» значение «new«). Как правило, клиенты используют «new» значение для первого запроса SETUP для URL-адреса и «existing» (существующее) для последующих запросов SETUP для URL-адреса.
Если клиентский запрос SETUP назначает «new» значение «connection«, ответ сервера ДОЛЖЕН также назначать «new» значение «connection» на линии Transport.
Если клиентский запрос SETUP назначает «existing» значение для «connection«, ответ сервера ДОЛЖЕН назначить значение «existing» или «new» для «connection» на линии Transport по своему усмотрению.
Значением по умолчанию «connection» является «existing» для всех запросов SETUP (начальный и последующий).
Необходимо определить комбинацию транспортного протокола, профиля и нижнего транспортного уровня. Ряд комбинаций определен в Приложении С из RFC 7826.
Ниже приведен пример использования, показывающий клиенту, рекламирующему возможность обрабатывать многоадресную или одноадресную передачу, предпочитая многоадресную рассылку. Поскольку это поток, предназначенный только для одноадресной передачи, сервер отвечает правильными транспортными параметрами для одноадресной передачи.
C->S: SETUP rtsp://example.com/foo/bar/baz.rm RTSP/2.0
CSeq: 302
Transport: RTP/AVP;multicast;mode="PLAY",
RTP/AVP;unicast;dest_addr="192.0.2.5:3456"/
"192.0.2.5:3457";mode="PLAY"
Accept-Ranges: npt, smpte, clock
User-Agent: PhonyClient/1.2
S->C: RTSP/2.0 200 OK
CSeq: 302
Date: Fri, 20 Dec 2013 10:20:32 +0000
Session: rQi1hBrGlFdiYld241FxUO
Transport: RTP/AVP;unicast;dest_addr="192.0.2.5:3456"/
"192.0.2.5:3457";src_addr="192.0.2.224:6256"/
"192.0.2.224:6257";mode="PLAY"
Accept-Ranges: npt
Media-Properties: Random-Access=0.6, Dynamic,
Time-Limited=20081128T165900
Синтаксис поля общего заголовка Transport в RTSP 2.0
Transport = "Transport" HCOLON transport-spec *(COMMA transport-spec)
transport-spec = transport-id *trns-parameter
transport-id = trans-id-rtp / other-trans
trans-id-rtp = "RTP/" profile ["/" lower-transport] ; LWS не допускается внутри идентификатора транспорта
other-trans = token *("/" token)
profile = "AVP" / "SAVP" / "AVPF" / "SAVPF" / token
lower-transport = "TCP" / "UDP" / token
trns-parameter = (SEMI ( "unicast" / "multicast" ))
/ (SEMI "interleaved" EQUAL channel ["-" channel])
/ (SEMI "ttl" EQUAL ttl)
/ (SEMI "layers" EQUAL 1*DIGIT)
/ (SEMI "ssrc" EQUAL ssrc *(SLASH ssrc))
/ (SEMI "mode" EQUAL mode-spec)
/ (SEMI "dest_addr" EQUAL addr-list)
/ (SEMI "src_addr" EQUAL addr-list)
/ (SEMI "setup" EQUAL contrans-setup)
/ (SEMI "connection" EQUAL contrans-con)
/ (SEMI "RTCP-mux")
/ (SEMI "MIKEY" EQUAL MIKEY-Value)
/ (SEMI trn-param-ext)
contrans-setup = "active" / "passive" / "actpass"
contrans-con = "new" / "existing"
trn-param-ext = par-name [EQUAL trn-par-value]
par-name = token
trn-par-value = *(rtsp-unreserved / quoted-string)
ttl = 1*3DIGIT ; 0 to 255
ssrc = 8HEX
channel = 1*3DIGIT ; 0 to 255
MIKEY-Value = base64
mode-spec = ( DQUOTE mode *(COMMA mode) DQUOTE )
mode = "PLAY" / token
addr-list = quoted-addr *(SLASH quoted-addr)
quoted-addr = DQUOTE (host-port / extension-addr) DQUOTE
host-port = ( host [":" port] ) / ( ":" port )
extension-addr = 1*qdtext
host = < Определён в RFC 3986 #>
port = < Определён в RFC 3986 #>
Ссылки
Скачать оригинальный документ на английском языке RFC 7826 — Real-Time Streaming Protocol Version 2.0
Читать полную версию документа на русском языке RFC 7826 — Потоковый протокол в реальном времени (RTSP), версия 2.0
Ссылка на синтаксис
