Методы RTSP 2.0 — это указание того, что должно быть выполнено на ресурсе, идентифицированном Request-URI на основании синтаксиса строки запроса RTSP, определённой как:
<Method> SP <Request-URI> SP <RTSP-Version> CRLF
Методы RTSP 2.0 перечислены в таблице 2.
В приведенном ниже описании используются следующие состояния в машине состояний протокола, которая связана с конкретным сеансом, когда этот сеанс был создан. Переходы между состояниями управляются протокольными взаимодействиями. Для получения дополнительной информации о состоянии машины см. Приложение B из RFC 7826.
Init: начальное состояние. Сессия не существует.
Ready: сессия готова начать воспроизведение.
Play: сеанс воспроизводится, т.е. отправляет данные медиапотока в направлении S-> C.
Запрос метода «SETUP» для URI указывает транспортный механизм, который будет использоваться для потоковой информации. Метод SETUP может использоваться в двух разных случаях, а именно: создание сеанса RTSP и изменение транспортных параметров медиапотоков, которые уже установлены. SETUP может использоваться во всех трех состояниях: Init, Ready и Play для изменения транспортных параметров. Кроме того, Init и Ready также могут использоваться для создания сеанса RTSP. Использование метода SETUP в состоянии Play для добавления медиаресурса в сеанс не определено.
Заголовок Transport, см. Раздел 18.54 из RFC 7826, определяет параметры медиатранспорта, приемлемые для клиента для передачи данных; ответ будет содержать параметры транспорта, выбранные сервером. Это позволяет клиенту перечислять в порядке убывания предпочтения транспортные механизмы и параметры, приемлемые для него, чтобы сервер мог выбрать наиболее подходящий. Ожидается, что используемый формат описания сеанса позволит клиенту выбрать ограниченное число возможных конфигураций, которые предлагаются в качестве вариантов для сервера. Все транспортные параметры должны быть включены в заголовок Transport; использование других заголовков для этой цели НЕ РЕКОМЕНДУЕТСЯ из-за промежуточных блоков, таких как брандмауэры или NAT.
В интересах любых промежуточных межсетевых экранов клиент ДОЛЖЕН указывать известные транспортные параметры, даже если он не влияет на эти параметры, например, когда сервер объявляет адрес фиксированной групповой адресации в качестве пункта назначения.
Поскольку SETUP включает в себя всю информацию инициализации транспорта, брандмауэры и другие промежуточные сетевые устройства (которые нуждаются в этой информации) избавлены от более трудной задачи анализа ответа DESCRIBE, который был зарезервирован для инициализации мультимедиа.
Клиент ДОЛЖЕН включать в запрос заголовок Accept-Ranges, указывая все поддерживаемые форматы модулей в заголовке Range. Это позволяет серверу знать, какие форматы он может использовать в будущих ответах, связанных с сеансом, таких как ответ PLAY без какого-либо диапазона в запросе. Если клиент не поддерживает формат времени, необходимый для представления, сервер ДОЛЖЕН ответить, используя 456 (Поле заголовка, недопустимое для ресурса), и включить заголовок Accept-Ranges с поддерживаемыми для ресурса форматами единиц измерения диапазона.
В ответе SETUP сервер ДОЛЖЕН включать заголовок Accept-Ranges (см. Раздел 18.5 из RFC 7826), чтобы указать, какие форматы времени приемлемо использовать для этого медиаресурса.
Ответ SETUP 200 OK ДОЛЖЕН включать заголовок Media-Properties (см. Раздел 18.29 из RFC 7826). Комбинация параметров заголовка Media-Properties указывает на характер содержимого, присутствующего в сеансе (см. Также раздел 4.7 из RFC 7826). Например, прямой эфир со смещением времени обозначается как
- Random access (Произвольный доступ) установлен на «Random-Access»,
- Content Modifications (Модификации контента), установлена на «Time-Progressing»
- Retention (Удержание) установлено на «Time-Duration» (с определенным значением времени окна записи).
Ответ SETUP 200 OK ДОЛЖЕН включать заголовок Media-Range (см. Раздел 18.30 из RFC 7826), если среда имеет прогресс по времени.
Базовый пример для SETUP:
C->S: SETUP rtsp://example.com/foo/bar/baz.rm RTSP/2.0
CSeq: 302
Transport: RTP/AVP;unicast;dest_addr=":4588"/":4589",
RTP/AVP/TCP;unicast;interleaved=0-1
Accept-Ranges: npt, clock
User-Agent: PhonyClient/1.2
S->C: RTSP/2.0 200 OK
CSeq: 302
Date: Thu, 23 Jan 1997 15:35:06 GMT
Server: PhonyServer/1.1
Session: QKyjN8nt2WqbWw4tIYof52;timeout=60
Transport: RTP/AVP;unicast;dest_addr="192.0.2.53:4588"/
"192.0.2.53:4589"; src_addr="198.51.100.241:6256"/
"198.51.100.241:6257"; ssrc=2A3F93ED
Accept-Ranges: npt
Media-Properties: Random-Access=3.2, Time-Progressing,
Time-Duration=3600.0
Media-Range: npt=0-2893.23
В приведенном выше примере клиент хочет создать сеанс RTSP, содержащий медиа-ресурс «rtsp://example.com/foo/bar/baz.rm». Транспортными параметрами, приемлемыми для клиента, являются либо RTP / AVP / UDP (UDP по умолчанию), которые должны приниматься через клиентские порты 4588 и 4589 по адресу, с которого происходит установочное соединение RTSP, либо RTP / AVP, чередующийся по каналу управления RTSP. Сервер выбирает транспорт RTP / AVP / UDP и добавляет адрес и порты, с которых он будет отправлять и получать RTP и RTCP, а также RTP SSRC, который будет использоваться сервером.
Сервер ДОЛЖЕН генерировать идентификатор сеанса в ответ на успешный запрос SETUP, если только запрос SETUP к серверу не содержит идентификатор сеанса или заголовок Pipelined-Requests, ссылающийся на существующий контекст сеанса. В этом последнем случае сервер ДОЛЖЕН объединить этот запрос SETUP в существующий сеанс (агрегированный сеанс) или вернуть код ошибки 459 (Агрегированная операция не разрешена) (см. Раздел 17.4.23 из RFC 7826). Агрегированный URI управления ДОЛЖЕН использоваться для управления агрегированным сеансом. Этот URI ДОЛЖЕН отличаться от URI управления потоком отдельных медиапотоков, включенных в агрегат (см. Раздел 13.4.2 из RFC 7826 для агрегированных сеансов и для конкретных URI см. Приложение D.1.1 из RFC 7826). Совокупный управляющий URI должен быть указан в описании сеанса, если сервер поддерживает агрегированное управление, и для сеанса требуется агрегированное управление.
Однако, даже если предлагается агрегированное управление, клиент МОЖЕТ выбрать не устанавливать сеанс в агрегированном управлении. Если агрегатный URI управления не указан в описании сеанса, это обычно указывает на то, что следует использовать неагрегированный элемент управления.
SETUP медиапотоков в агрегате, которому не был предоставлен агрегированный контрольный URI, не указана.
Хотя идентификатор сеанса иногда несет достаточно информации для совокупного управления сеансом, совокупный URI управления все еще важен для некоторых методов, таких как SET_PARAMETER, где управляющий URI позволяет легко идентифицировать рассматриваемый ресурс. Совокупный управляющий URI также полезен для прокси-серверов, позволяя им направить запрос на соответствующий сервер, и для ведения журнала, где полезно отметить фактический ресурс, на котором работал запрос.
Сеанс будет существовать до тех пор, пока он не будет удален по запросу TEARDOWN или не истечет время ожидания сервера. Сервер МОЖЕТ удалить сеанс, который не продемонстрировал признаки жизнеспособности от клиента (ов) в течение определенного периода времени ожидания. Значение тайм-аута по умолчанию составляет 60 секунд; сервер МОЖЕТ установить это значение на другое значение и указать это в поле времени ожидания заголовка сеанса в ответе SETUP. Для дальнейшего обсуждения см. раздел 18.49 из RFC 7826. Признаки жизнеспособности для сеанса RTSP включают в себя любые запросы RTSP от клиента, которые содержат заголовок сеанса с идентификатором для этого сеанса, а также отчеты отправителя или получателя RTCP, если RTP используется для транспортировки основного медиапотока. Отчеты отправителя RTCP могут, например, приниматься в сеансе, где сервер приглашен в сеанс конференции, и, таким образом, являются действительными в качестве индикатора жизнеспособности.
Если запрос SETUP для сеанса завершается неудачей по какой-либо причине, состояние сеанса, а также параметры транспорта и другие параметры для связанных потоков ДОЛЖНЫ оставаться неизменными по сравнению с их значениями, как если бы запрос SETUP никогда не был получен сервером.
Изменение параметров транспорта
Клиент МОЖЕТ выдать запрос SETUP для потока, который уже настроен или воспроизводится в сеансе, для изменения транспортных параметров, которые сервер МОЖЕТ разрешить. Если он не позволяет изменять параметры, он ДОЛЖЕН ответить ошибкой 455 (Метод не действителен в этом состоянии). Причины для поддержки изменения транспортных параметров включают предоставление мобильности и гибкости на уровне приложений возможности использовать наилучший доступный транспорт по мере его доступности. Если клиент получает ошибку 455 при попытке изменить параметры транспорта, когда сервер находится в состоянии воспроизведения, он МОЖЕТ попытаться перевести сервер в состояние готовности с помощью PAUSE, прежде чем снова выполнить запрос SETUP. Если это также не удается, изменение транспортных параметров потребует, чтобы клиент выполнил TEARDOWN затронутого носителя, а затем снова настроил его. В агрегированном сеансе одновременное отключение всех носителей не позволит создать новый сеанс.
Все транспортные параметры МОГУТ быть изменены. Тем не менее, основное использование ожидается либо полностью изменить транспортный протокол, как, например, переключение из режима TCP с чередованием в UDP или наоборот, либо изменить адрес доставки.
В ответе SETUP на запрос об изменении транспортных параметров в состоянии Play сервер ДОЛЖЕН включить заголовок Range, чтобы указать, в какой момент будут использоваться новые транспортные параметры. Кроме того, если RTP используется для доставки, сервер ДОЛЖЕН также включать заголовок RTP-Info, чтобы указать, с какой отметкой времени и порядковым номером RTP произойдет изменение. Если в ответ включены и RTP-Info, и Range, параметр «rtp_time» и начальная точка в заголовке Range ДОЛЖНЫ быть в течение соответствующего времени, т. е. использоваться так же, как и для PLAY, чтобы гарантировать правильность информации синхронизации. (имеется в наличии)
Если изменение транспортных параметров, которое произошло в то время как в состоянии Play, приводит к изменению информации, связанной с синхронизацией, например, к изменению RTP SSRC, сервер ДОЛЖЕН включить необходимую информацию синхронизации в ответ SETUP. Однако серверу СЛЕДУЕТ избегать изменения информации синхронизации, если это возможно.
Ссылки на документы
Скачать оригинальный документ на английском языке RFC 7826 — Real-Time Streaming Protocol Version 2.0
Читать полную версию документа на русском языке RFC 7826 — Потоковый протокол в реальном времени (RTSP), версия 2.0
