RFC 7826 | Потоковый протокол в реальном времени (RTSP), версия 2.0

Аннотация

Этот меморандум определяет протокол потоковой передачи в реальном времени (RTSP) версии 2.0, который устаревает RTSP версии 1.0, определенной в RFC 2326 #.

RTSP — это протокол прикладного уровня для настройки и управления доставкой данных со свойствами в реальном времени. RTSP предоставляет расширяемую структуру, позволяющую осуществлять контролируемую доставку данных в реальном времени, таких как аудио и видео. Источники данных могут включать как живые потоки данных, так и сохраненные клипы. Этот протокол предназначен для управления несколькими сеансами доставки данных; предоставить средства для выбора каналов доставки, таких как UDP, многоадресная передача UDP и TCP; и предоставить средства для выбора механизмов доставки на основе RTP (RFC 3550 #).

Скачать оригинальный документ на английском языке RFC 7826 PDF

Статус этой заметки

Это документ по отслеживанию стандартов Интернета.

Этот документ является продуктом Инженерной рабочей группы по Интернету (IETF). Он представляет собой консенсус сообщества IETF. Он получил общественное обозрение и был одобрен для публикации Руководящей группой по Интернет-разработкам (IESG). Дополнительная информация о Интернет-стандартах доступна в Разделе 2 RFC 7841.
Информацию о текущем состоянии этого документа, любых ошибках и способах предоставления отзывов о нем можно получить по адресу http://www.rfc-editor.org/info/rfc7826.

Уведомление об авторских правах

На данный документ распространяется действие ПП 78 и Правовые положения IETF Trust, относящиеся к документам IETF (http://trustee.ietf.org/license-info), действующие на дату публикации этого документа. Пожалуйста, внимательно ознакомьтесь с этими документами, так как они описывают ваши права и ограничения в отношении этого документа. Компоненты кода, извлеченные из этого документа, должны включать в себя текст упрощенной лицензии BSD, как описано в разделе 4.e Правил доверия, и предоставляются без гарантии, как описано в упрощенной лицензии BSD.

Этот документ может содержать материалы из Документов IETF или Вкладов IETF, опубликованных или обнародованных до 10 ноября 2008 года. Лица, контролирующие авторские права на некоторые из этих материалов, возможно, не предоставили Доверие IETF право разрешать модификации таких материалов. вне процесса стандартизации IETF.

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

1. Введение

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

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

RTSP 2.0 является заменой RTSP 1.0 [RFC2326 #], и этот документ устарел в этой спецификации. Этот протокол основан на RTSP 1.0, но не имеет обратной совместимости, кроме как в базовом механизме согласования версий. Изменения между этими двумя документами перечислены в Приложении I. Существует множество причин, по которым RTSP 2.0 не может быть обратно совместим с RTSP 1.0; Вот некоторые из основных:

Большинство заголовков, которые должны были быть расширяемыми, не определяли разрешенный синтаксис, препятствующий безопасному развертыванию расширений;
Измененное поведение метода PLAY при получении в состоянии Play;
Измененное поведение модели расширяемости и ее механизма;
Изменение синтаксиса для некоторых заголовков.

Существует так много небольших обновлений, что изменение версий стало необходимым для обеспечения ясности и согласованности поведения. Любой, кто внедряет RTSP для нового варианта использования, в котором он не установил RTSP 1.0, должен только реализовывать RTSP 2.0, чтобы избежать необходимости работать с несоответствиями RTSP 1.0.

Этот документ структурирован следующим образом. Он начинается с краткого обзора операций протокола и его функций. Затем вводится набор определений используемых терминов и условных обозначений. Далее следует актуальная спецификация протокола ядра RTSP 2.0. В приложениях описываются и определяются некоторые функциональные возможности, которые не являются частью основной спецификации RTSP, но которые по-прежнему важны для обеспечения возможности их использования. Среди них использование RTP определено в Приложении C, использование протокола описания сеанса (SDP) с RTSP определено в Приложении D, а формат F «text/parameters» (текст/параметры) в Приложении F представляет собой три приложения нормативной спецификации. Другие приложения включают ряд информационных частей, в которых обсуждаются изменения, варианты использования, различные соображения или мотивы.

2. Обзор протокола

В этом разделе представлен информативный обзор различных механизмов протокола RTSP 2.0, чтобы дать читателю понимание высокого уровня, прежде чем углубляться во все конкретные детали. В случае конфликта с этим описанием и более поздними разделами, более поздние разделы имеют приоритет. Для получения дополнительной информации о случаях использования, рассматриваемых для RTSP, см. Приложение E.

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

RTSP использует текстовые сообщения, запросы и ответы, которые могут содержать двоичное тело сообщения. Запрос RTSP начинается со строки метода, которая идентифицирует метод, протокол и версию и ресурс, на котором нужно действовать. Ресурс идентифицируется URI, а часть имени хоста URI используется клиентом RTSP для разрешения адреса IPv4 или IPv6 сервера RTSP. После строки метода указан ряд заголовков RTSP. Эти строки заканчиваются двумя последовательными парами символов перевода строки (CRLF — carriage return line feed). Тело сообщения, если оно присутствует, следует за двумя парами символов CRLF, а длина тела описывается заголовком сообщения. Ответы RTSP похожи, но они начинаются со строки ответа с протоколом и версией, за которой следует код состояния и фраза причины. Сообщения RTSP отправляются по надежному транспортному протоколу между клиентом и сервером. RTSP 2.0 требует, чтобы клиенты и серверы использовали TCP и TLS через TCP в качестве обязательного транспорта для сообщений RTSP.

2.1. Описание презентации

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

Параметры, которые обычно должны быть включены в описание презентации, следующие:

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

RTSP использует свои собственные схемы URI («rtsp» и «rtsps») для ссылки на медиаресурсы и агрегаты под общим контролем (см. Раздел 4.2).

Эта спецификация описывает в Приложении D, как используется SDP [RFC4566 #] для описания презентации.

2.2. Учреждение Сессии

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

Клиент создает сеанс RTSP, отправляя запрос с использованием метода SETUP (раздел 13.3) на сервер. В заголовке транспорта (раздел 18.54) запроса SETUP клиент также включает все транспортные параметры, необходимые для работы протокола доставки мультимедиа. Это включает в себя параметры, которые предварительно установлены в описании презентации, но необходимы для любого промежуточного блока для правильной обработки протоколов доставки мультимедиа. Заголовок транспорта в запросе может содержать несколько альтернатив для доставки мультимедиа в списке приоритетов, из которого сервер может выбирать. Эти альтернативы обычно основаны на информации в описании презентации.

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

Запрос SETUP, который ссылается на существующий сеанс RTSP, но идентифицирует новый медиаресурс, является запросом на добавление этого медиаресурса под общим контролем с уже присутствующими медиаресурсами в агрегированном сеансе. Клиент может ожидать, что это будет работать для всех медиаресурсов под управлением RTSP в контейнере мультимедийного контента. Однако сервер, скорее всего, откажется объединять ресурсы из разных контейнеров контента. Даже если сеанс RTSP содержит только один медиапоток, на сеанс RTSP может ссылаться совокупный управляющий URI.

Чтобы избежать дополнительного обхода при установлении агрегированных сеансов RTSP, RTSP 2.0 поддерживает конвейерные запросы; т. е. клиент может отправлять несколько запросов подряд, не дожидаясь вначале завершения любого из них. Клиент использует выбранный клиентом идентификатор в заголовке Pipelined-Requests (раздел 18.33), чтобы указать серверу связывать несколько запросов вместе, как если бы они включали идентификатор сеанса.

Ответ SETUP также предоставляет дополнительную информацию об установленных сеансах в нескольких разных заголовках. Заголовок Media-Properties (раздел 18.29) включает в себя ряд свойств, которые применяются для агрегата, который полезен при управлении доставкой мультимедиа и настройке пользовательского интерфейса. Заголовок Accept-Ranges (раздел 18.5) информирует клиента о форматах диапазонов, которые сервер поддерживает для этих медиаресурсов. Заголовок Media-Range (раздел 18.30) информирует клиента о временном диапазоне медиа, доступном в настоящее время.

2.3. Контроль доставки медиа

После установления сеанса RTSP клиент может начать контролировать доставку мультимедиа. Основными операциями являются «begin playback» (начать воспроизведение) с использованием метода PLAY (раздел 13.4) и «suspend (pause) playback» (временно прекратить (приостановить) воспроизведение) с помощью метода PAUSE (раздел 13.6). PLAY также позволяет выбрать начальную позицию мультимедиа, с которой сервер должен доставлять мультимедиа. Позиционирование осуществляется с помощью заголовка Range (раздел 18.40), который поддерживает несколько различных форматов времени: нормальное время воспроизведения (NPT — Normal Play Time) (раздел 4.4.2), отметки времени Общества инженеров кино и телевидения (SMPTE — Society of Motion Picture and Television Engineers) (раздел 4.4.1) и абсолютное время (раздел 4.4.3). Заголовок Range также позволяет клиенту указывать позицию, в которой должна заканчиваться доставка, что позволяет доставлять определенный интервал.

Поддержка позиционирования / поиска в медиа-контенте зависит от медиа-свойств контента. Контент существует в нескольких различных типах, таких как по требованию, в прямом эфире и в прямом эфире с одновременной записью. Даже в пределах этих категорий существуют различия в том, как контент генерируется и распространяется, что влияет на то, как к нему можно получить доступ для воспроизведения. Свойства, применимые для сеанса RTSP, предоставляются сервером в ответе SETUP с использованием заголовка Media-Properties (раздел 18.29). Они выражаются с использованием одного или нескольких независимых атрибутов. Первым атрибутом является произвольный доступ, который указывает, возможно ли позиционирование и с какой степенью детализации. Другой аспект заключается в том, будет ли содержимое изменяться в течение времени жизни сеанса. Хотя контент по требованию будет предоставляться полностью с самого начала, записываемый поток в реальном времени приводит к увеличению длины доступного контента по мере продолжения сеанса. Также существует контент, который динамически создается с помощью протокола, отличного от RTSP, и, таким образом, также изменяется по шагам во время сеанса, но, возможно, не непрерывно. Кроме того, когда контент записывается, бывают случаи, когда весь контент не поддерживается, но, например, только в последний час. Все эти свойства приводят к необходимости механизмов, которые будут обсуждаться ниже.

Когда клиент получает доступ к контенту по запросу, который обеспечивает произвольный доступ, он может выдать запрос PLAY для любой точки в контенте между началом и концом. Сервер доставит медиа из ближайшей точки произвольного доступа до запрошенной точки и укажет это в своем ответе PLAY. Если клиент выдает ПАУЗУ, доставка будет остановлена, а точка, в которой остановлен сервер, будет сообщена в ответе. Позже клиент может возобновить работу, отправив запрос PLAY без заголовка Range. Когда сервер собирается завершить запрос PLAY путем доставки конца контента или запрошенного диапазона, сервер отправит запрос PLAY_NOTIFY (раздел 13.5), указывающий это.

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

Для записываемых сеансов в реальном времени клиенту необходимо следить за ходом записи. После установления сеанса клиент узнает текущую продолжительность записи из заголовка Media-Range. Поскольку запись продолжается, контент растет в прямой зависимости от прошедшего времени. Поэтому ответ каждого сервера на запрос PLAY будет содержать текущий заголовок Media-Range. Сервер также должен регулярно отправлять (приблизительно каждые 5 минут) текущий диапазон медиа в запросе PLAY_NOTIFY (раздел 13.5.2). Если передача в реальном времени заканчивается, сервер должен отправить запрос PLAY_NOTIFY с обновленными Media-Properties, указывающими, что контент перестал быть записанным живым сеансом и вместо этого стал контентом по требованию; запрос также содержит окончательный диапазон медиа. Пока доставка в реальном времени продолжается, клиент может запросить воспроизведение текущей точки в реальном времени, используя символ временной шкалы NPT «сейчас», или он может запросить конкретную точку в доступном контенте с помощью явного запроса диапазона для этой точки. Если запрошенная точка находится за пределами доступного интервала, сервер отрегулирует положение до ближайшей доступной точки, то есть либо в начале, либо в конце.

Особый случай записи — это случай, когда запись не сохраняется дольше определенного периода времени; таким образом, при продолжении доставки в реальном времени клиент может получить доступ к любому мультимедиа в пределах движущегося окна, которое охватывает, например, «сейчас» — «сейчас» минус 1 час. Клиент, который делает паузу в определенной точке содержимого, может больше не иметь возможности получать содержимое. Если клиент ждет слишком долго, прежде чем возобновить точку паузы, контент может быть недоступен. В этом случае точка паузы будет скорректирована до ближайшей точки на доступных носителях.

2.4. Манипуляции с параметрами сеанса

Сеанс может иметь дополнительное состояние или функциональность, которые влияют на то, как сервер или клиент относится к сеансу или контенту, как он функционирует, или отзывы о том, насколько хорошо работает сеанс. Такие расширения не определены в данной спецификации, но они могут охватываться различными расширениями. RTSP имеет два метода для получения и установки значений параметров на клиенте или на сервере: GET_PARAMETER (раздел 13.8) и SET_PARAMETER (раздел 13.9). Эти методы передают параметры в теле сообщения соответствующего формата. Можно также использовать заголовки для запроса состояния с помощью метода GET_PARAMETER. В качестве примера, клиенты, которым необходимо знать текущий диапазон мультимедиа для сеанса с прогрессирующим временем, могут использовать метод GET_PARAMETER и включать диапазон мультимедиа. Кроме того, информация о синхронизации может быть запрошена с использованием комбинации RTP-Info (раздел 18.45) и диапазона (раздел 18.40).

RTSP 2.0 не имеет сильного механизма для согласования заголовков или параметров и их форматов. Однако ответы будут указывать заголовки запроса или параметры, которые не поддерживаются. Априорное определение того, какие функции доступны, необходимо выполнить с помощью внешних механизмов, таких как описание сеанса, или с помощью тегов функций (раздел 4.5).

2.5. Доставка Медиа

Этот документ определяет, как носитель доставляется с RTP [RFC3550 #] через UDP [RFC768 #], TCP [RFC793 #] или соединение RTSP. Дополнительные протоколы могут быть указаны в будущем по мере необходимости.

Использование RTP в качестве протокола доставки мультимедиа требует некоторой дополнительной информации для нормального функционирования. Ответ PLAY содержит информацию для обеспечения надежной и своевременной доставки того, как клиент должен синхронизировать разные источники в разных сеансах RTP. Он также обеспечивает отображение между метками времени RTP и шкалой времени контента. Когда сервер хочет уведомить клиента о завершении доставки мультимедиа, он отправляет клиенту запрос PLAY_NOTIFY. Запрос PLAY_NOTIFY включает в себя информацию об окончании потока, включая последний порядковый номер RTP для каждого потока, что позволяет клиенту плавно очистить буфер.

2.5.1. Манипуляции с доставкой медиа

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

Масштаб: соотношение времени медиа-контента, доставляемого на единицу времени воспроизведения.

Скорость: соотношение времени воспроизведения, доставляемого на единицу времени на стене.

Оба влияют на доставку носителя за единицу времени. Однако они манипулируют двумя независимыми временными рамками, и эффекты можно комбинировать.

Scale (шкала) (раздел 18.46) используется для управления ускоренной перемоткой вперед или замедленной съемкой, поскольку она изменяет объем временной шкалы контента, который должен воспроизводиться в единицу времени. Масштаб> 1,0 означает ускоренную перемотку вперед, например, масштаб = 2,0 приводит к тому, что 2 секунды контента воспроизводятся каждую секунду воспроизведения. Масштаб = 1,0 — это значение по умолчанию, которое используется, если масштаб не указан, т.е. воспроизведение с исходной скоростью контента. Значения шкалы от 0 до 1,0 обеспечивают медленное движение. Масштаб может быть отрицательным, чтобы обеспечить обратное воспроизведение в обычном темпе (масштаб = -1,0), быстром назад (масштаб <-1,0) или замедленном движении назад (-1,0 <масштаб <0). Масштаб = 0 будет равен паузе и не допускается.

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

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

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

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

Скорость (раздел 18.50) влияет на то, сколько времени воспроизведения воспроизводится в данный период часов. Значение по умолчанию — Speed = 1, что означает, что доставка осуществляется с той же скоростью, с которой расходуется носитель. Скорость> 1 означает, что получатель будет получать контент быстрее, чем он регулярно потребляет его. Скорость <1 означает, что доставка медленнее, чем обычная скорость передачи. Значения скорости 0 или ниже не имеют значения и не допускаются. Этот механизм обеспечивает две общие функции. Одним из них являются операции масштабирования на стороне клиента, то есть клиент принимает все кадры и выполняет локальную настройку воспроизведения. Вторым является контроль доставки для буферизации медиа. Задавая скорость выше 1,0, клиент может увеличить количество времени воспроизведения, которое он имеет в своих буферах, до уровня, достаточного для его потребностей.

Наивная реализация Speed повлияет только на расписание передачи мультимедиа и окажет явное влияние на необходимую пропускную способность. Это приведет к тому, что скорость передачи данных будет пропорциональна коэффициенту скорости. Скорость = 1,5, т. е. На 50% быстрее, чем при обычной доставке, что приведет к увеличению скорости передачи данных на 50%. Возможность поддержки этого зависит только от основного сетевого пути. Масштаб также может оказать некоторое влияние на требуемую пропускную способность из-за манипулирования контентом в новом расписании воспроизведения. Примером является перемотка вперед, когда в поток мультимедиа включены только независимо декодируемые внутренние кадры. Такое использование исключительно внутрикадрового изображения значительно увеличивает скорость передачи данных по сравнению с обычной последовательностью с таким же количеством кадров, где большинство кадров кодируются с использованием прогнозирования.

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

Необходимость адаптации битрейта становится особенно проблематичной в связи с семантикой скорости. Если цель состоит в том, чтобы заполнить буфер, клиент может не захотеть делать это за счет снижения качества. Если клиент хочет внести локальные изменения воспроизведения, он может фактически потребовать соблюдения запрошенной скорости. Чтобы решить эту проблему, Speed использует диапазон, чтобы можно было поддерживать оба случая. Серверу предлагается использовать максимально возможное значение скорости в диапазоне, которое совместимо с доступной пропускной способностью. Пока сервер может поддерживать значение скорости в пределах диапазона, он не должен изменять качество носителя, а вместо этого изменять фактическую скорость доставки в ответ на доступную полосу пропускания и отражать ее в значении скорости в ответе. Однако, если это невозможно, сервер должен вместо этого изменить качество мультимедиа с учетом минимального значения скорости и доступной пропускной способности.

Эта функциональность позволяет реализации локального масштабирования использовать узкий диапазон или даже диапазон, где нижняя граница равна верхней границе, чтобы идентифицировать, что ему требуется, чтобы сервер доставил запрошенное количество времени мультимедиа за время доставки, независимо от того, сколько он необходимо адаптировать качество мультимедиа в соответствии с доступной полосой пропускания пути. Для заполнения буфера целесообразно использовать диапазон с разумным диапазоном и с нижней границей при номинальной скорости носителя 1,0, например 1,0–2,5. Если клиент хочет уменьшить буфер, он может указать верхнюю границу ниже 1,0, чтобы заставить сервер доставлять медленнее, чем номинальная скорость передачи данных.

2.6. Сессии «Обслуживание» и «Завершение»

Установленный контекст сеанса сохраняется благодаря тому, что клиент демонстрирует жизнеспособность. Это делается двумя основными способами:

Поддержание медиа-транспортного протокола. Протокол управления RTP (RTCP) может использоваться при использовании RTP.
Любой запрос RTSP, ссылающийся на контекст сеанса.

В разделе 10.5 обсуждаются методы более глубокого показа жизни. Если клиенту не удается отобразить срок действия больше установленного значения времени ожидания сеанса (обычно 60 секунд), сервер может прекратить контекст. Другие значения могут быть выбраны сервером посредством включения параметра времени ожидания в заголовок сеанса.

Контекст сеанса обычно завершается клиентом, отправляющим запрос TEARDOWN (раздел 13.7) на сервер, ссылающийся на агрегированный управляющий URI. Отдельный медиаресурс может быть удален из контекста сеанса с помощью запроса TEARDOWN, ссылающегося на этот конкретный медиаресурс. Если все медиаресурсы удалены из контекста сеанса, контекст сеанса прекращается.

Клиент может поддерживать сеанс в течение неопределенного времени, если это разрешено сервером; однако клиенту рекомендуется освободить контекст сеанса, когда расширенный период времени без активности доставки мультимедиа прошел. Клиент может восстановить контекст сеанса, если потребуется позже. То, что составляет длительный период времени, зависит от клиента, сервера и их использования. Клиенту рекомендуется прекратить сеанс до того, как истечет десять раз значение времени ожидания сеанса. Сервер может прервать сеанс после одного периода ожидания сеанса без каких-либо действий клиента, кроме поддержания активности. Когда сервер завершает контекст сеанса, он делает это, отправляя запрос TEARDOWN с указанием причины.

Сервер также может запросить, чтобы клиент завершил сеанс и заново установил его на альтернативном сервере, что может потребоваться для обслуживания. Это делается с помощью метода REDIRECT (раздел 13.10). Заголовок Terminate-Reason (раздел 18.52) используется для указания, когда и почему. Заголовок Location указывает, куда он должен подключиться, если есть альтернативный доступный сервер. Когда срок истекает, сервер просто перестает предоставлять услугу. Чтобы добиться полного закрытия, клиент должен инициировать завершение сеанса до истечения срока. Если у сервера нет другого сервера для перенаправления, и он хочет закрыть сеанс для обслуживания, он должен использовать метод TEARDOWN с заголовком Terminate-Reason.

2.7. Расширение RTSP

RTSP является довольно универсальным протоколом, который поддерживает расширения во многих различных направлениях. Даже эта базовая спецификация содержит несколько функциональных блоков, которые являются необязательными для реализации. Вариант использования и необходимость развертывания протокола должны определять, какие части реализованы. Разрешение на расширение позволяет RTSP учитывать дополнительные варианты использования. Однако расширения будут влиять на совместимость протокола; поэтому важно, чтобы их можно было добавлять структурированным образом.

Клиент может изучить возможности сервера, используя метод OPTIONS (раздел 13.1) и заголовок Supported (Поддерживаемый ) (раздел 18.51). Он также может попытаться и, возможно, потерпеть неудачу, используя новые методы, или потребовать поддержки определенных функций с помощью заголовка Require (раздел 18.43) или Proxy-Require (раздел 18.37).
Протокол RTSP сам по себе может быть расширен тремя способами, перечисленными здесь в порядке возрастания величины поддерживаемых изменений:

Существующие методы могут быть расширены новыми параметрами, например, заголовками, если получатель может безопасно игнорировать эти параметры. Если клиенту требуется отрицательное подтверждение, когда расширение метода не поддерживается, тег, соответствующий расширению, может быть добавлен в поле заголовков Require или Proxy-Require.
Новые методы могут быть добавлены. Если получатель сообщения не понимает запрос, он должен ответить с кодом ошибки 501 (не реализовано), чтобы отправитель мог избежать повторного использования этого метода. Клиент также может использовать метод OPTIONS, чтобы узнать о методах, поддерживаемых сервером. Сервер должен перечислить методы, которые он поддерживает, используя Public response-header.
Можно определить новую версию протокола, позволяющую изменять почти все аспекты (кроме положения номера версии протокола). Новая версия протокола должна быть зарегистрирована в документе «Отслеживание стандартов».

Механизм обнаружения основных возможностей можно использовать как для обнаружения поддержки определенной функции, так и для обеспечения доступности функции при выполнении запроса. Для подробного объяснения этого см. Раздел 11.

Новые протоколы доставки мультимедиа могут быть добавлены и согласованы при установлении сеанса в дополнение к расширениям основного протокола. Определенные типы манипуляций с протоколом могут быть выполнены через форматы параметров с использованием SET_PARAMETER и GET_PARAMETER.

3. Документ Соглашения

3.1. Условные обозначения

Все механизмы, указанные в этом документе, описаны как в прозе, так и в расширенной форме Бэкуса-Наура (ABNF), подробно описанной в [RFC5234 #].

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

Ключевые слова «ОБЯЗАН — MUST», «НЕ ОБЯЗАН — MUST NOT», «ТРЕБУЕТСЯ — REQUIRED», «ДОЛЖЕН — SHALL», «НЕ ДОЛЖЕН — SHALL NOT», «СЛЕДУЕТ — SHOULD», «НЕ СЛЕДУЕТ — SHOULD NOT», «РЕКОМЕНДУЕТСЯ — RECOMMENDED», «НЕ РЕКОМЕНДУЕТСЯ — NOT RECOMMENDED», «ВОЗМОЖЕН — MAY» и «ДОПОЛНИТЕЛЬНО — OPTIONAL» в этом документе интерпретироваться как описано в [RFC2119 #], [RFC8174 #]

Слово «не определено» (unspecified) используется для обозначения функциональности или функций, которые не определены в данной спецификации. Такие функциональные возможности не могут быть использованы стандартизированным образом без дальнейшего определения в спецификации расширения к RTSP.

3.2. Терминология

Совокупный контроль (Aggregate control): концепция управления несколькими потоками с использованием одной временной шкалы, обычно поддерживаемой сервером. Например, клиент использует совокупный контроль, когда выдает одно сообщение воспроизведения или паузы для одновременного управления аудио и видео в фильме. Сеанс, который находится под агрегированным контролем, называется «агрегированным сеансом».

URI совокупного контроля (Aggregate control URI): URI, используемый в запросе RTSP для ссылки и управления агрегированным сеансом. Обычно, но не всегда, соответствует URI представления, указанному в описании сеанса. См. Раздел 13.3 для получения дополнительной информации.

Клиент (Client): клиент является запросчиком медиа-службы с медиа-сервера.

Соединение (Connection): виртуальный канал транспортного уровня, установленный между двумя программами для связи.

Контейнерный файл (Container file): файл, который может содержать несколько медиапотоков, которые часто представляют собой презентацию при совместном воспроизведении. Концепция файла контейнера не включена в протокол. Однако серверы RTSP могут предлагать совокупный контроль над потоками мультимедиа в этих файлах.

Непрерывные носители (Continuous media): данные, в которых существует временная зависимость между источником и приемником; то есть приемник должен воспроизводить временные отношения, которые существовали в источнике. Наиболее распространенными примерами непрерывного медиа являются аудио и видео. Непрерывное мультимедиа может быть в реальном времени (интерактивное или диалоговое), где существует «жесткая» временная связь между источником и приемником, или это может быть потоковая передача, когда отношения менее строгие.

Тег признака(Feature tag): тег, представляющий определенный набор функций, то есть функцию.

IRI: Интернационализированный идентификатор ресурса похож на URI, но допускает символы из всего универсального набора символов (Unicode/ISO 10646), а не только для US-ASCII. См. [RFC3987 #] для получения дополнительной информации.

Прямая трансляция (Live): живая презентация или сеанс начинается с мультимедийного события, которое происходит одновременно с доставкой мультимедиа. Живые сеансы часто имеют неограниченную или только слабо определенную продолжительность, и операции поиска могут быть невозможны.

Инициализация носителя (Media initialization): инициализация, относящаяся к типу данных или кодеку. Это включает в себя такие вещи, как тактовые частоты, таблицы цветов и т. д.. Любая независимая от транспорта информация, которая требуется клиенту для воспроизведения медиапотока, происходит на этапе инициализации мультимедиа установки потока.

Параметр мультимедиа (Media parameter): параметр, относящийся к типу мультимедиа, который можно изменить до или во время потоковой доставки.

Медиасервер (Media server): сервер, предоставляющий услуги доставки мультимедиа для одного или нескольких медиапотоков. Различные медиа-потоки в презентации могут происходить с разных медиа-серверов. Медиасервер может находиться на том же хосте или на другом хосте, с которого вызывается презентация.

(Мультимедийный) поток (Stream): один экземпляр мультимедиа, например аудиопоток или видеопоток, а также одна доска или группа общих приложений. При использовании RTP поток состоит из всех пакетов RTP и RTCP, созданных источником мультимедиа в сеансе RTP.

Сообщение (Message): базовая единица связи RTSP, состоящая из структурированной последовательности октетов, соответствующих синтаксису, определенному в разделе 20, и передаваемых по транспорту между агентами RTSP. Сообщение — это либо запрос, либо ответ.

Тело сообщения (Message body): информация, передаваемая как полезная нагрузка сообщения (запрос или ответ). Тело сообщения состоит из метаинформации в форме заголовков тела сообщения и содержимого в виде произвольного числа октетов данных, как описано в разделе 9.

Неагрегированный контроль (Non-aggregated control): контроль одного медиапотока.

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

Описание презентации (Presentation description). Описание презентации содержит информацию об одном или нескольких медиапотоках в презентации, такую как набор кодировок, сетевых адресов и информация о контенте. Другие протоколы IETF, такие как SDP ([RFC4566 #]), используют термин «сеанс» для презентации. Описание презентации может принимать несколько разных форматов, включая, но не ограничиваясь, формат SDP.

Ответ (Response): ответ RTSP на запрос. Один тип сообщения RTSP. Если подразумевается HTTP-ответ, он указывается явно.

Запрос (Request): запрос RTSP. Один тип сообщения RTSP. Если подразумевается HTTP-запрос, он указывается явно.

Request-URI: URI, используемый в запросе для указания ресурса, на котором должен выполняться запрос.

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

Сеанс RTSP (RTSP session): абстракция с отслеживанием состояния, в которой работают основные методы управления RTSP. Сеанс RTSP является общим контекстом; он создается и поддерживается по запросу клиента и может быть уничтожен клиентом или сервером. Он устанавливается сервером RTSP по завершении успешного запроса SETUP (когда отправляется ответ 200 OK) и в это время помечается идентификатором сеанса. Сеанс существует до истечения времени ожидания сервером или явного удаления по запросу TEARDOWN. Сеанс RTSP является объектом с состоянием; сервер RTSP поддерживает явный автомат состояний сеанса (см. Приложение B), где большинство переходов состояний инициируются клиентскими запросами. Существование сеанса подразумевает наличие состояния о медиапотоках сеанса и их соответствующих транспортных механизмах. С данным сеансом может быть связан один или несколько медиапотоков. Сервер RTSP использует сеанс для агрегирования контроля над несколькими медиапотоками.

Исходный сервер (Origin server): сервер, на котором находится данный ресурс.

Поиск (Seeking): Запрос воспроизведения с определенной точки на временной шкале контента.

Инициализация транспорта (Transport initialization): согласование транспортной информации (например, номеров портов, транспортных протоколов) между клиентом и сервером.

URI: универсальный идентификатор ресурса; см. [RFC3986 #]. URI, используемые в RTSP, обычно являются URL-адресами, поскольку они дают местоположение для ресурса.

оскольку URL-адреса являются подмножеством URI, они будут называться URI, чтобы охватывать также случаи, когда URI RTSP не будет URL-адресом.

URL: универсальный локатор ресурсов — это URI, который идентифицирует ресурс с помощью своего основного механизма доступа, а не идентифицирует ресурс по имени или по некоторым другим атрибутам этого ресурса.

4. Параметры протокола

4.1. Версия RTSP

Эта спецификация определяет версию 2.0 RTSP.

RTSP использует схему нумерации <major>. <Minor> для обозначения версий протокола. Политика управления версиями протокола предназначена для того, чтобы позволить отправителю указывать формат сообщения и его способность понимать дальнейшую связь RTSP, а не функции, полученные через эту связь. Не вносится никаких изменений в номер версии для добавления компонентов сообщения, которые не влияют на поведение связи или которые только добавляют к значениям расширяемого поля.

Число <minor> увеличивается, когда изменения, внесенные в протокол, добавляют функции, которые не изменяют общий алгоритм синтаксического анализа сообщения, но могут добавить к семантике сообщения и подразумевают дополнительные возможности отправителя. Число <major> увеличивается при изменении формата сообщения в протоколе. Версия сообщения RTSP указывается в поле RTSPVersion в первой строке сообщения. Обратите внимание, что старшие и младшие числа ДОЛЖНЫ рассматриваться как отдельные целые числа и что каждое МОЖЕТ быть увеличено выше, чем одна цифра. Таким образом, RTSP / 2.4 является более низкой версией, чем RTSP / 2.13, что, в свою очередь, ниже, чем RTSP / 12.3. Ведущие нули НЕ ДОЛЖНЫ отправляться и ДОЛЖНЫ игнорироваться получателями.

4.2. RTSP IRI и URI

RTSP 2.0 определяет и регистрирует или обновляет три схемы URI: «rtsp», «rtsps» и «rtspu». Использование последнего, «rtspu», не указано в RTSP 2.0 и определяется здесь для регистрации схемы URI, определенной в RTSP 1.0. Схема «rtspu» указывает неуказанную передачу сообщений RTSP по ненадежным транспортным средствам (UDP в RTSP 1.0). Сервер RTSP ДОЛЖЕН ответить кодом ошибки, указывающим, что схема «rtspu» не реализована (501) на запрос, который несет схему URI «rtspu».

Детали синтаксиса URI «rtsp» и «rtsps» были изменены с RTSP 1.0. Эти изменения включают добавление:

Поддержка литерала IPv6 в принимающей части и будущих литералах IP с помощью механизма, определенного в [RFC3986 #].
Новый относительный формат для использования в элементах RTSP, который не обязательно должен начинаться с «/».

Ни один из них не должен оказывать существенного влияния на совместимость. Если в URI RTSP необходимы литералы IPv6, то этот сервер RTSP должен поддерживать IPv6, а RTSP 1.0 не является полностью совместимым протоколом IPv6. Если клиент RTSP 1.0 пытается обработать URI, URI не будет соответствовать разрешенному синтаксису, он будет считаться недействительным, и обработка будет остановлена. Это явно неспособность достичь ресурса; тем не менее, это не проблема значения, так как поддержка RTSP 2.0 в любом случае требовалась как для сервера, так и для клиента. Таким образом, сбой произойдет только на более позднем этапе, когда существует несоответствие версии RTSP между клиентом и сервером. Второе изменение будет происходить только внутри заголовков сообщений RTSP, поскольку Request-URI должен быть абсолютным URI. Таким образом, такое использование будет происходить только после того, как агент принял и начал обрабатывать сообщения RTSP 2.0, и агенту, использующему только RTSP 1.0, не потребуется анализировать такие типы относительных URI.

Эта спецификация также определяет формат IRI RTSP [RFC3987 #], который можно использовать в качестве идентификаторов и локаторов ресурса RTSP на веб-страницах, пользовательских интерфейсах, на бумаге и т. Д. Однако формат сообщения запроса RTSP допускает использование только абсолютного формата URI. Формат RTSP IRI ДОЛЖЕН использовать правила и преобразования для IRI в URI, как определено в [RFC3987 #]. Это позволяет создавать URI, который соответствует спецификации RTSP 2.0 и поэтому подходит для использования в запросе, из IRI RTSP.

RTSP IRI и URI оба ограничены синтаксисом по сравнению с общим синтаксисом, определенным в [RFC3986 #] и [RFC3987 #]:

Абсолютный URI требует авторитетной части; то есть, идентификатор хоста ДОЛЖЕН быть предоставлен.
Параметры в элементе пути начинаются с зарезервированного разделителя «;».

Части «схемы» и «хоста» всех URI [RFC3986 #] и IRI [RFC3987 #] нечувствительны к регистру. Все остальные части URI и IRI RTSP чувствительны к регистру, и они НЕ ДОЛЖНЫ отображаться с учетом регистра.

Идентификатор фрагмента используется, как определено в разделах 3.5 и 4.3 [RFC3986 #], то есть фрагмент должен быть удален из IRI запрашивающей стороной и не включен в Request-URI. Пользовательский агент должен интерпретировать значение фрагмента на основе типа медиа, к которому относится запрос; то есть тип носителя, указанный в заголовке Content-Type в ответе на запрос DESCRIBE.

Синтаксис любой строки запроса URI не определен и зависит от респондента (обычно от сервера). Запрос, с точки зрения запрашивающей стороны, является непрозрачной строкой и должен обрабатываться как таковой.

Обратите внимание, что относительные URI с запросами трудно обрабатывать из-за правил обработки относительных URI в RFC 3986 #. Любое изменение элемента пути с использованием относительного URI приводит к разбивке запроса, что означает, что относительная часть должна содержать запрос.

Схема URI «rtsp» требует, чтобы команды передавались через надежный протокол (в пределах Интернета, TCP), а схема «rtsps» идентифицирует надежный транспорт с использованием безопасного транспорта (TLS [RFC5246 #]); см. раздел 19.

Для схемы «rtsp», если в части полномочий URI номер порта не указан, ДОЛЖЕН использоваться номер порта 554. Для схемы «rtsps», если в части полномочий номера порта URI не указан номер порта, ДОЛЖЕН использоваться порт 322 TCP.

Презентация или поток идентифицируется текстовым идентификатором мультимедиа с использованием набора символов и условных обозначений URI [RFC3986 #]. URI могут относиться к потоку или совокупности потоков; то есть презентация. Соответственно, запросы, описанные в разделе 13, могут применяться либо ко всей презентации, либо к отдельному потоку в презентации. Обратите внимание, что некоторые методы запроса могут применяться только к потокам, а не к презентациям, и наоборот.

Например, URI RTSP:

rtsp://media.example.com:554/twister/audiotrack

может идентифицировать аудиопоток в «твистере» презентации, которым можно управлять с помощью запросов RTSP, выдаваемых через TCP-соединение с портом 554 хоста media.example.com.

Кроме того, URI RTSP:

rtsp://media.example.com:554/twister

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

Это не подразумевает стандартного способа ссылки на потоки в URI. Описание презентации определяет иерархические отношения в презентации и URI для отдельных потоков. Описание презентации может называть поток «a.mov» и всю презентацию «b.mov».

Компоненты пути URI RTSP непрозрачны для клиента и не подразумевают какой-либо конкретной структуры файловой системы для сервера.

Эта развязка также позволяет использовать описания презентаций с не-RTSP-протоколами управления мультимедиа просто заменой схемы в URI.

4.3. Идентификаторы сеанса

Идентификаторы сеанса — это строки длиной от 8 до 128 символов. Идентификатор сеанса ДОЛЖЕН быть создан с использованием методов, которые делают его криптографически случайным (см. [RFC4086 #]). РЕКОМЕНДУЕТСЯ, чтобы идентификатор сеанса содержал 128 битов энтропии, то есть приблизительно 22 символа от высококачественного генератора (см. Раздел 21). Тем не менее, обратите внимание, что идентификатор сеанса не обеспечивает никакой защиты от перехвата сеанса, если он не является конфиденциальным для клиента, сервера и доверенных прокси.

4.4. Форматы медиа-времени

В настоящее время RTSP поддерживает три различных формата медиа-времени, определенных ниже. Дополнительные форматы времени могут быть указаны в будущем. Эти форматы времени можно использовать с заголовком Range (раздел 18.40), чтобы запрашивать воспроизведение и указывать, в каком запросе протокола позиции мультимедиа фактически будут или имели место. Они также используются при описании свойств носителя с помощью заголовка Media-Range (раздел 18.30). Неквалифицированный идентификатор формата используется сам по себе в заголовке Accept-Ranges (раздел 18.5) для объявления поддерживаемых форматов времени, а также в заголовке Range (раздел 18.40) для запроса формата времени, используемого в ответе.

4.4.1. SMPTE-Относительные метки времени

Временная метка может использовать формат, полученный из спецификации Общества инженеров кино и телевидения (SMPTE), и выражает временные сдвиги, закрепленные в начале медиаклипа. Относительные временные метки выражаются в виде временных кодов SMPTE [SMPTE-TC] для точности доступа на уровне кадров. Временной код имеет формат:

hours:minutes:seconds:frames.subframes

с началом в начале клипа. Формат SMPTE по умолчанию — это формат «SMPTE 30 drop» с частотой кадров 29,97 кадров в секунду. Другие коды SMPTE МОГУТ поддерживаться (например, «SMPTE 25») посредством использования «smpte-type». Для SMPTE 30 поле «frames» во временном значении может принимать значения от 0 до 29. Разница между 30 и 29,97 кадрами в секунду обрабатывается путем сброса первых двух индексов кадров (значения 00 и 01) каждой минуты, кроме каждую десятую минуту Если значения кадра и подкадра равны нулю, они могут быть опущены. Подкадры измеряются в сотых долях кадра.

Примеры:

smpte=10:12:33:20- smpte=10:07:33- smpte=10:07:00-10:07:33:05.01 smpte-25=10:07:00-10:07:33:05.01

4.4.2. Нормальное время воспроизведения

Нормальное время воспроизведения (NPT) указывает абсолютную позицию потока относительно начала презентации. Отметка времени состоит из двух частей: обязательная первая часть может быть выражена либо в секундах, либо в часах, минутах и секундах. Необязательная вторая часть состоит из десятичной точки и десятичных цифр и указывает доли секунды.

Начало презентации соответствует 0,0 секундам. Отрицательные значения не определены.

Специальная константа «сейчас» определяется как текущий момент живого события. Он МОЖЕТ использоваться только для живых событий и НЕ ДОЛЖЕН использоваться для контента по требованию (т.е. не для живого).

NPT определяется как в разделе «Управление цифровыми носителями информации (DSMb; CC)» [ISO.13818-6.1995]:

Интуитивно понятно, что NPT — это часы, которые зритель ассоциирует с программой. Он часто отображается в цифровом виде на DVD-плеере. NPT продвигается нормально, когда в режиме обычного воспроизведения (масштаб = 1), продвигается с более высокой скоростью при быстром сканировании вперед (высокий коэффициент положительной шкалы), уменьшается при обратном сканировании (отрицательный масштаб) и фиксируется в режиме паузы. NPT (логически) эквивалентен временным кодам SMPTE.

Примеры:

npt=123.45-125 npt=12:05:35.3- npt=now-

Синтаксис основан на ISO 8601 [ISO.8601.2000] и выражает время, прошедшее с начала презентации, с двумя различными допустимыми обозначениями:

o В нотации npt-hhmmss используется расширенное полное представление времени дня в формате ISO 8601 (раздел 5.3.1.1 [ISO.8601.2000]) с использованием двоеточий («:») в качестве разделителей между часами, минутами и секундами (чч). : мм: сс). Счетчик часов не ограничен 0-24 часами; допускается до девятнадцати (19) часовых цифр.

* В соответствии с требованиями формата времени ISO 8601 ДОЛЖНЫ присутствовать часы, минуты и секунды, причем две цифры используются для минут и секунд и как минимум две цифры для часов. NPT 7 минут и 0 секунд представлен как «00:07:00», а NPT 392 часа, 0 минут и 6 секунд представлен как «392: 00: 06».
* RTSP 1.0 разрешил NPT в нотации npt-hhmmss без начальных нулей, чтобы гарантировать, что реализации не потерпят неудачу; для обратной совместимости все реализации RTSP 2.0 ОБЯЗАНЫ поддерживать поддержку значений NPT, часов, минут или секунд без начальных нулей.

o Обозначение npt-sec выражает время в секундах, используя от одной до девятнадцати (19) цифр.

Обе записи допускают десятичные доли секунды, как указано в разделе 5.3.1.3 [ISO.8601.2000], используя не более девяти цифр и разрешая только «.» (полная остановка) в качестве десятичного разделителя.

Нотация npt-sec оптимизирована для автоматической генерации; нотация npt-hhmmss оптимизирована для чтения людьми. Константа «сейчас» позволяет клиентам запрашивать прямую трансляцию, а не сохраненную или задержанную версию. Это необходимо, поскольку ни абсолютное время, ни нулевое время не подходят для этого случая.

4.4.3. Абсолютное Время

Абсолютное время выражается с использованием метки времени, основанной на ISO 8601 [ISO.8601.2000]. Дата является полным представлением календарной даты в базовом формате (YYYYMMDD) без разделителей (согласно Разделу 5.2.1.1 [ISO.8601.2000]). Время суток указывается в базовом формате полного представления (hhmmss), как указано в разделе 5.3.1.1 [ISO.8601.2000], что позволяет использовать десятичные доли секунд после раздела 5.3.1.3, требующего «.» (полная остановка) как десятичный разделитель и ограничение количества цифр не более девяти. Выраженное время ДОЛЖНО использовать UTC (GMT), т.е. смещения часового пояса не допускаются. Полное указание даты и времени — это восьмизначная дата, за которой следует буква «T», за которой следует шестизначное значение времени, необязательно, за ним следует точка с полной остановкой, за которой следуют от одной до девяти долей секунды, и заканчивающаяся буквой «Z», например , YYYYMMDDThhmmss.ssZ.

Причины этого формата времени, а не использования «Дата и время в Интернете: метки времени» [RFC3339 #], являются историческими. Мы продолжаем использовать формат, указанный в RTSP 1.0. Мотивации, поднятые в RFC 3339, относятся к тому, почему был сделан выбор из ISO 8601; однако в этом случае был применен другой и еще более ограничительный отбор.

Ниже приведены три примера форматов времени мультимедиа, во-первых, запрос запроса диапазона форматов часов для времени начала 8 ноября 1996 года в 14 ч 37 мин и 20 1/4 секунды по UTC, воспроизводящемуся в течение 10 минут и 5 секунд, за которым следует свойство UTC заголовка Media-Properties «Time-Limited» за 24 декабря 2014 года в 15 часов 00 минут и, наконец, свойство «time» заголовка Terminate-Reason 18 июня 2013 года в 16 часов 12 минут и 56 секунд:

clock=19961108T143720.25Z-19961108T144725.25Z Time-Limited=20141224T1500Z time=20130618T161256Z

4.5. Теги функций

Теги объектов — это уникальные идентификаторы, используемые для обозначения объектов в RTSP. Эти теги используются в полях заголовка Require (раздел 18.43), Proxy-Require (раздел 18.37), Proxy-Supported (раздел 18.38), Supported (раздел 18.51) и Unsupported (раздел 18.55).

Определение тега функции ДОЛЖНО указывать, к какой комбинации клиентов, серверов или прокси-серверов он применяется.

Создатель нового тега функции RTSP должен либо добавить префикс тега функции к обратному доменному имени (например, «com.example.mynewfeature» — это подходящее имя для функции, с изобретателем которой можно связаться по адресу «example.com»), либо зарегистрироваться новый тег функции с Органом по присвоению номеров в Интернете (IANA). (См. Раздел 22 «Соображения IANA».)

Использование тегов функций более подробно описано в Разделе 11, который касается обработки возможностей.

4.6. Теги сообщения

Теги тела сообщения — это непрозрачные строки, которые используются для сравнения двух тел сообщения из одного и того же ресурса, например, в кэш-памяти или для оптимизации настройки после перенаправления. Теги тела сообщения могут быть перенесены в заголовок MTag (см. Раздел 18.31) или в SDP (см. Приложение D.1.9). MTag аналогичен ETag в HTTP / 1.1 (см. Раздел 3.11 [RFC2068 #]).

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

Теги тела сообщения используются в RTSP, чтобы сделать некоторые методы условными. Методы сделаны условными через включение заголовков; см. раздел 18.24 и раздел 18.26 для получения информации о заголовках If-Match и If-None-Match соответственно. Следует отметить, что теги тела сообщения RTSP применяются ко всей презентации, то есть как к описанию презентации, так и к отдельным медиапотокам. Таким образом, теги тела сообщения могут использоваться для проверки во время установки после перенаправления того, что то же описание сеанса применяется к мультимедиа в новом местоположении с использованием заголовка If-Match.

4.7. Медиа Свойства

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

По требованию (On-demand): носитель с фиксированной (заданной) продолжительностью, которая не изменяется в течение времени жизни сеанса RTSP и известна во время создания сеанса. Ожидается, что содержимое мультимедиа не изменится, даже если представление, такое как кодирование или качество, может измениться. Как правило, можно искать, то есть запрашивать любой диапазон в средствах массовой информации.

Динамический по требованию (Dynamic On-demand): это вариант случая по требованию, где внешние методы используются для управления фактическим содержимым настройки мультимедиа для сеанса RTSP. Основным примером является контент, определенный списком воспроизведения.

Прямая трансляция (Live): Live media представляет собой прогрессирующий поток контента (например, широковещательное телевидение), продолжительность которого может быть или не быть известна. Он не доступен для поиска, только доступ к доставляемому в настоящее время контенту.

Прямая трансляция с записью (Live with Recording). Прямая трансляция, которая в сочетании с возможностью на стороне сервера хранить и сохранять содержимое сеанса в реальном времени и обеспечивает доставку с произвольным доступом в части уже записанного содержимого. Фактическое поведение медиапотока очень сильно зависит от политики хранения для медиапотока; либо сервер сможет захватить весь поток мультимедиа, либо у него будет ограничение на то, сколько будет сохранено. Диапазон носителей будет динамически меняться по мере продвижения сеанса. Для серверов с ограниченным объемом памяти, доступным для записи, обычно будет скользящее окно, которое перемещается вперед, в то время как новые данные становятся доступными, а более старые данные отбрасываются.

Чтобы охватить вышеуказанное использование, указаны следующие свойства носителя с соответствующими значениями.

4.7.1. Случайный доступ и поиск

Произвольный доступ — это возможность задавать и получать медиаданные, начиная с любого (мгновенного) времени в контенте, и эта операция называется «поиск». Заголовок Media-Properties будет указывать общую возможность для медиа-ресурса выполнять произвольный доступ.

Произвольный доступ (Random-Access): Медиа доступны для поиска в любом из большого числа точек в медиа. Из-за ограничений кодирования мультимедиа конкретная точка может быть недоступна, но поиск точки рядом включен. Может быть предоставлено число секунд с плавающей точкой, чтобы выразить расстояние наихудшего случая между точками произвольного доступа.

Только начало (Beginning-Only): поиск возможен только до начала контента.

Без поиска (No-Seeking): Поиск невозможен вообще.

Если возможен произвольный доступ, как указано в заголовке Media-Properties, фактической политикой поведения при поиске можно управлять с помощью заголовка Seek-Style (раздел 18.47).

4.7.2. Удержание

Следующие политики хранения используются носителями для ограничения возможных операций протокола:

Неограниченный (Unlimited): носитель не будет удален, пока существует сеанс RTSP.

Ограниченное по времени (Time-Limited): носитель не будет удален до истечения указанного времени настенного часового режима. По истечении этого времени он может быть недоступен или недоступен.

Длительность времени (Time-Duration): носитель (фрагмент или единица) будет сохранен в течение указанной продолжительности.

4.7.3. Модификации контента

Медиа-контент и его временная шкала могут быть разных типов, например, предварительно созданный контент по запросу, живой источник, который генерируется с течением времени, или что-то, что динамически изменяется или перекомпоновывается во время воспроизведения. Следовательно, свойство media для модификации контента необходимо, и определены следующие начальные значения:

Неизменный (Immutable): содержимое носителя не изменится, даже если меняется представление, такое как кодировка или качество.

Динамический (Dynamic): содержимое может измениться из-за внешних методов или триггеров, таких как списки воспроизведения, но это будет объявлено явными обновлениями.

Время прогрессирует (Time-Progressing): со временем, новый контент станет доступным. Если содержимое также сохраняется, оно станет длиннее, так как все между начальной точкой и точкой, доступной в данный момент, может быть доступно. Если медиасервер использует политику скользящего окна для сохранения, начальная точка также будет меняться с течением времени.

4.7.4. Поддерживаемые коэффициенты масштабирования

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

4.7.5. Отображение на атрибуты

В этом разделе показаны примеры того, как можно сопоставить вышеперечисленное использование со свойствами и их значениями.

Пример по требованию

Random Access: Random-Access=5.0, Content Modifications: Immutable, Retention: Unlimited or Time-Limited.

Пример динамического по требованию

Random Access: Random-Access=3.0, Content Modifications: Dynamic, Retention: Unlimited or Time-Limited.

Пример Live

Random Access: No-Seeking, Content Modifications: Time-Progressing, Retention: Time-Duration=0.0

Пример Live с записью

Random Access: Random-Access=3.0, Content Modifications: Time-Progressing, Retention: Time-Duration=7200.0

5. Сообщение RTSP

RTSP — это текстовый протокол, который использует набор символов ISO 10646 в кодировке UTF-8 согласно RFC 3629 [RFC3629 #]. Строки ДОЛЖНЫ заканчиваться CRLF.

Текстовые протоколы облегчают добавление необязательных параметров с само-описанием. Поскольку количество параметров и частота команд невелики, эффективность обработки не имеет значения. Текстовые протоколы, если их использовать осторожно, также позволяют легко реализовать исследовательские прототипы на таких языках сценариев, как Python, PHP, Perl и TCL.

Набор символов ISO 10646 позволяет избежать переключения набора символов, но невидим для приложения, пока используется US-ASCII. Это также кодировка, используемая для текстовых полей в RTCP [RFC3550 #].

Запрос содержит метод, объект, над которым работает метод, и параметры для дальнейшего описания метода. Методы являются идемпотентными, если не указано иное. Методы также разработаны так, чтобы на медиасервере практически не требовалось поддерживать состояние.

5.1. Типы сообщений

Сообщения RTSP — это либо запросы от клиента к серверу, либо с сервера на клиент, а также ответы в обратном направлении. Сообщения ЗАПРОСА (Раздел 7) и сообщения ОТВЕТА (Раздел 8) используют формат, основанный на общем формате сообщения RFC 5322 [RFC5322 #] для передачи тел (полезная нагрузка сообщения). Оба типа сообщений состоят из строки начала, нуля или более полей заголовка (также известных как «заголовки»), пустой строки (то есть строки, в которой ничего не предшествует CRLF), указывающей конец заголовков, и, возможно, данных тела сообщения. ABNF [RFC5234 #] ниже только для иллюстрации; Формальная спецификация сообщения представлена в разделе 20.2.2.

generic-message = start-line
*(rtsp-header CRLF)
CRLF
[ message-body-data ]
start-line = Request-Line / Status-Line

В интересах надежности агенты ДОЛЖНЫ игнорировать любую полученную пустую строку (и), где ожидается строка запроса или строка состояния. Другими словами, если агент читает поток протокола в начале сообщения и сначала получает любое количество CRLF, он ДОЛЖЕН игнорировать все CRLF.

5.2. Заголовки сообщений

Поля заголовка RTSP (см. Раздел 18) включают в себя поля общего заголовка, заголовка запроса, заголовка ответа и заголовка тела сообщения.

Порядок получения полей заголовков с разными именами не имеет значения. Однако, это «хорошая практика» — сначала отправлять поля общего заголовка, затем поле заголовка запроса или заголовка ответа и заканчивать полями заголовка тела сообщения.

Несколько полей заголовка с одним и тем же именем поля МОГУТ присутствовать в сообщении тогда и только тогда, когда все значение поля для этого поля заголовка определено как список, разделенный запятыми. ДОЛЖНО быть возможно объединить несколько полей заголовка в одну пару «имя-поля: поле-значение», не изменяя семантику сообщения, добавляя каждое последующее значение поля к первому, каждое из которых разделяется запятой. Порядок, в котором принимаются поля заголовка с одинаковым именем поля, имеет значение для интерпретации значения объединенного поля; таким образом, прокси-сервер НЕ ДОЛЖЕН изменять порядок этих значений полей при пересылке сообщения.

НЕИЗВЕСТНЫЕ заголовки сообщения ДОЛЖНЫ игнорироваться (пропуская заголовок до следующего элемента протокола и не вызывая ошибки) сервером или клиентом RTSP. Прокси RTSP ДОЛЖЕН пересылать неизвестные заголовки сообщений. Заголовки сообщений, определенные за пределами этой спецификации, которые должны интерпретироваться агентом RTSP, должны будут использовать теги функций (раздел 4.5) и включать их в соответствующий заголовок Require (раздел 18.43) или Proxy-Require (раздел 18.37).

5.3. Тело сообщения

Тело сообщения (если имеется) сообщения RTSP используется для переноса дополнительной информации для конкретного ресурса, связанного с запросом или ответом. Примером тела сообщения является сообщение SDP.

Наличие тела сообщения в запросе или ответе ДОЛЖНО сигнализироваться включением заголовка Content-Length (см. Раздел 18.17) и заголовка Content-Type (см. Раздел 18.19). Тело сообщения НЕ ДОЛЖНО быть включено в запрос или ответ, если спецификация конкретного метода (см. Определения методов (раздел 13)) не позволяет отправить тело сообщения. В случае, если тело сообщения получено в сообщении, когда оно не ожидается, данные тела сообщения ДОЛЖНЫ быть отброшены. Это позволяет будущим расширениям определять необязательное использование тела сообщения.

5.4. Длина сообщения

Сообщение RTSP, которое не содержит тела сообщения, заканчивается первой пустой строкой после полей заголовка (примечание: пустая строка — это строка, в которой ничего не предшествует CRLF.). В сообщениях RTSP, которые содержат тела сообщений, за пустой строкой следует тело сообщения. Длина этого тела определяется значением заголовка Content-Length (раздел 18.17). Значение в заголовке представляет длину тела сообщения в октетах. Если это поле заголовка отсутствует, предполагается нулевое значение, то есть в сообщении отсутствует тело сообщения. В отличие от сообщения HTTP, сообщение RTSP ДОЛЖНО содержать заголовок Content-Length всякий раз, когда он содержит тело сообщения. Обратите внимание, что RTSP не поддерживает HTTP-1.1 «чанкованное» кодирование передачи (см. Раздел 4.1 [RFC7230 #]).

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

6. Поля общего заголовка

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

Имя общего заголовка в RTSP	Определено в …
Accept-Ranges	Раздел 18.5
Cache-Control	Раздел 18.11
Connection	Раздел 18.12
CSeq	Раздел 18.20
Date	Раздел 18.21
Media-Properties	Раздел 18.29
Media-Range	Раздел 18.30
Pipelined-Requests	Раздел 18.33
Proxy-Supported	Раздел 18.38
Range	Раздел 18.40
RTP-Info	Раздел 18.45
Scale	Раздел 18.46
Seek-Style	Раздел 18.47
Server	Раздел 18.48
Session	Раздел 18.49
Speed	Раздел 18.50
Supported	Раздел 18.51
Timestamp	Раздел 18.53
Transport	Раздел 18.54
User-Agent	Раздел 18.56
Via	Раздел 18.57

Таблица 1: Общие заголовки, используемые в RTSP

7. Запрос

Сообщение запроса использует формат, описанный ниже, независимо от направления запроса, будь то клиент на сервер или сервер на клиент:

Строка запроса, содержащая метод, который будет применен к ресурсу, идентификатор ресурса и используемую версию протокола;
Ноль или более строк заголовка, которые могут быть следующих типов: общие заголовки (раздел 6), заголовки запроса (раздел 7.2) или заголовки тела сообщения (раздел 9.1);
Одна пустая строка (CRLF) для обозначения конца раздела заголовка;
При необходимости, тело сообщения, состоящее из одной или нескольких строк. Длина тела сообщения в октетах указывается заголовком сообщения Content-Length.

7.1. Строка запроса

Строка запроса предоставляет ключевую информацию о запросе: какой метод, на каких ресурсах и с какой версией RTSP. Методы, которые определены в этой спецификации, перечислены в таблице 2.

Метод RTSP	Определено в …
DESCRIBE	Раздел 13.2
GET_PARAMETER	Раздел 13.8
OPTIONS	Раздел 13.1
PAUSE	Раздел 13.6
PLAY	Раздел 13.4
PLAY_NOTIFY	Раздел 13.5
REDIRECT	Раздел 13.10
SETUP	Раздел 13.3
SET_PARAMETER	Раздел 13.9
TEARDOWN	Раздел 13.7

Таблица 2: Методы RTSP

Синтаксис строки запроса RTSP имеет следующий вид:

<Method> SP <Request-URI> SP <RTSP-Version> CRLF

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

В отличие от HTTP / 1.1 [RFC7230 #], запросы RTSP идентифицируют ресурс по абсолютному URI RTSP (включая схему, хост и порт) (см. Раздел 4.2), а не только по абсолютному пути.

HTTP / 1.1 требует, чтобы серверы понимали абсолютный URI, но клиенты должны использовать заголовок запроса Host. Это просто необходимо для обратной совместимости с серверами HTTP / 1.0, что не относится к RTSP.

Звездочка «*» может использоваться вместо абсолютного URI в части Request-URI, чтобы указать, что запрос не применяется к конкретному ресурсу, но к самому серверу или прокси-серверу, и разрешен только тогда, когда метод запроса не обязательно обратиться к ресурсу.

Например:

OPTIONS * RTSP/2.0

ОПЦИИ в этой форме будут определять возможности сервера или прокси-сервера, который первым получает запрос. Если необходимо определить возможности конкретного сервера без учета возможностей промежуточного прокси-сервера, адрес сервера должен быть адресован явно с абсолютным URI, который содержит адрес сервера.

Например:

OPTIONS rtsp://example.com RTSP/2.0

7.2. Поля заголовка запроса

Заголовки RTSP в Таблице 3 могут быть включены в запрос как request-headers (заголовки запроса), чтобы изменить специфику запроса.

Заголовки запросов RTSP	Определено в …
Accept	Раздел 18.1
Accept-Credentials	Раздел 18.2
Accept-Encoding	Раздел 18.3
Accept-Language	Раздел 18.4
Authorization	Раздел 18.8
Bandwidth	Раздел 18.9
Blocksize	Раздел 18.10
From	Раздел 18.23
If-Match	Раздел 18.24
If-Modified-Since	Раздел 18.25
If-None-Match	Раздел 18.26
Notify-Reason	Раздел 18.32
Proxy-Authorization	Раздел 18.36
Proxy-Require	Раздел 18.37
Referrer	Раздел 18.41
Request-Status	Раздел 18.42
Require	Раздел 18.43
Terminate-Reason	Раздел 18.52

Таблица 3: Заголовки запросов RTSP

Подробные определения заголовков приведены в разделе 18.

Новые заголовки запроса могут быть определены. Если получатель запроса должен понимать заголовок запроса, запрос ДОЛЖЕН включать соответствующий тег функции в заголовок Require или Proxy-Require, чтобы обеспечить обработку заголовка.

8. Ответ

После получения и интерпретации сообщения-запроса получатель отвечает сообщением-ответом RTSP. Обычно, есть только один, последний, ответ. Ответы, использующие код ответа класса 1xx, являются единственным классом, для которого МОЖЕТ быть отправлен один или несколько ответов до окончательного ответного сообщения.

Действительные коды ответов и методы, которые они могут использовать, перечислены в таблице 4.

8.1. Status-Line

Первая строка ответного сообщения — это строка состояния (Status-Line), состоящая из версии протокола (RTSP-Version), за которой следует числовой код состояния (Status-Code) и текстовая фраза (Reason Phrase), связанная с кодом состояния, причем каждый элемент разделен символами SP. CR или LF не допускаются, кроме как в окончательной последовательности CRLF.

<RTSP-Version> SP <Status-Code> SP <Reason Phrase> CRLF

8.1.1. Код состояния и фраза причины

Элемент «Status-Code» представляет собой трехзначный целочисленный код результата попытки понять и удовлетворить запрос. Эти коды полностью определены в разделе 17. Фраза причины (Reason Phrase) предназначена для краткого текстового описания Status-Code (кода состояния). Status-Code предназначен для использования автоматами, а фраза причины предназначена для пользователя. Клиент не обязан изучать или отображать фразу причины.

Первая цифра Status-Code определяет класс ответа. Последние две цифры не имеют никакой роли категоризации. Для первой цифры есть пять значений:

1xx: информационный — запрос получен, процесс продолжается
2xx: успех — действие было успешно получено, понято и принято
3rr: перенаправление — для выполнения запроса необходимо предпринять дальнейшие действия (используется 3rr, а не 3xx, так как 304 исключено; см. Раздел 17.3)
4xx: ошибка клиента — запрос содержит неверный синтаксис или не может быть выполнен
5xx: ошибка сервера — серверу не удалось выполнить явно допустимый запрос

Отдельные значения числовых кодов состояния, определенных для RTSP 2.0, и пример набора соответствующих фраз причины представлены в Таблице 4. Перечисленные здесь фразы причины рекомендуются только; они могут быть заменены локальными эквивалентами, не влияя на протокол. Обратите внимание, что RTSP принял большинство кодов состояния HTTP/1.1 [RFC2068 #], а затем добавил специфичные для RTSP коды состояния, начиная с «x50», чтобы избежать конфликтов с будущими кодами состояния HTTP, которые желательно импортировать в RTSP. Все эти коды являются специфичными для RTSP, и RTSP имеет свой собственный реестр, отдельный от HTTP для кодов состояния.

Коды состояния RTSP являются расширяемыми. Приложения RTSP не обязаны понимать значение всех зарегистрированных кодов состояния, хотя такое понимание, очевидно, желательно. Однако приложения ДОЛЖНЫ понимать класс любого кода состояния, как указано в первой цифре, и обрабатывать любой нераспознанный ответ как эквивалент кода состояния «x00» этого класса, за исключением неизвестных кодов 3xx, которые ДОЛЖНЫ рассматриваться как 302 (Найдено). Причина этого исключения состоит в том, что код состояния 300 (Множественный выбор в HTTP) не определен для RTSP. Ответ с нераспознанным кодом состояния НЕ ДОЛЖЕН кэшироваться. Например, если клиент получил нераспознанный код состояния 431, он может с уверенностью предположить, что с его запросом что-то не так, и обработать ответ так, как если бы он получил код состояния 400. В таких случаях пользовательские агенты ДОЛЖНЫ представлять пользователю тело сообщения, возвращенное с ответом, поскольку это тело сообщения, вероятно, будет содержать удобочитаемую информацию, которая объяснит необычный статус.

Код (Code)	Причина (Reason)	Метод (Method)
100	Продолжать (Continue)	Все (all)
200	Хорошо (OK)	Все (all)
301	Перемещён навсегда (Moved Permanently)	Все (all)
302	Найден (Found)	Все (all)
303	Смотрите Другое (See Other)	Недоступен (n/a)
304	Не модифицировано (Not Modified)	Все (all)
305	Использовать прокси (Use Proxy)	Все (all)
400	Неверный запрос (Bad Request)	Все (all)
401	Не авторизовавшийся (Unauthorized)	Все (all)
402	Требуется оплата (Payment Required)	Все (all)
403	Запрещено (Forbidden)	Все (all)
404	Не найдено (Not Found)	Все (all)
405	Метод не разрешен (Method Not Allowed)	Все (all)
406	Неприемлимо (Not Acceptable)	Все (all)
407	Требуется проверка подлинности прокси (Proxy Authentication Required)	Все (all)
408	Тайм-аут запроса (Request Timeout)	Все (all)
410	Ушел (Gone)	Все (all)
412	Предварительное условие не выполнено (Precondition Failed)	DESCRIBE, SETUP
413	Тело запроса слишком велико (Request Message Body Too Large)	Все (all)
414	Слишком длинный запрос URI (Request-URI Too Long)	Все (all)
415	Неподдерживаемый тип носителя (Unsupported Media Type)	Все (all)
451	Параметр не понят (Parameter Not Understood)	SET_PARAMETER, GET_PARAMETER
452	зарезервированный (reserved)	Недоступен (n/a)
453	Не хватает пропускной способности (Not Enough Bandwidth)	SETUP
454	Сессия не найдена (Session Not Found)	Все (all)
455	Метод не действителен в этом состоянии (Method Not Valid in This State)	Все (all)
456	Поле заголовка недопустимо для ресурса (Header Field Not Valid for Resource)	Все (all)
457	Неверный диапазон (Invalid Range)	PLAY, PAUSE
458	Параметр доступен только для чтения (Parameter Is Read-Only)	SET_PARAMETER
459	Совокупная операция не разрешена (Aggregate Operation Not Allowed)	Все (all)
460	Разрешена только совокупная операция (Only Aggregate Operation Allowed)	Все (all)
461	Неподдерживаемый транспорт (Unsupported Transport)	Все (all)
462	Пункт назначения недоступен (Destination Unreachable)	Все (all)
463	Направление запрещено (Destination Prohibited)	SETUP
464	Транспорт данных еще не готов (Data Transport Not Ready Yet)	PLAY
465	Причина уведомления неизвестна (Notification Reason Unknown)	PLAY_NOTIFY
466	Ошибка управления ключами (Key Management Error)	Все (all)
470	Требуется авторизация соединения (Connection Authorization Required)	Все (all)
471	Учетные данные подключения не принимаются (Connection Credentials Not Accepted)	Все (all)
472	Неспособность установить безопасное соединение (Failure to Establish Secure Connection)	Все (all)
500	Внутренняя ошибка сервера (Internal Server Error)	Все (all)
501	Не реализовано (Not Implemented)	Все (all)
502	плохой шлюз (Bad Gateway)	Все (all)
503	Сервис недоступен (Service Unavailable)	Все (all)
504	Время ожидания шлюза (Gateway Timeout)	Все (all)
505	Версия RTSP не поддерживается (RTSP Version Not Supported)	Все (all)
551	Опция не поддерживается (Option Not Supported)	Все (all)
553	Прокси недоступен (Proxy Unavailable)	Все (all)

Таблица 4 — Коды состояния и их использование с методами RTSP
Таблица 4 - Коды состояния и их использование с методами RTSP

8.2. Заголовки ответа

Заголовки ответа позволяют получателю запроса передавать дополнительную информацию об ответе, которую нельзя поместить в строку состояния. Этот заголовок предоставляет информацию о сервере и о дальнейшем доступе к ресурсу, идентифицированному Request-URI. Все заголовки, в настоящее время классифицируемые как заголовки ответа, перечислены в таблице 5.

Заголовки ответа RTSP	Определено в …
Authentication-Info	Раздел 18.7
Connection-Credentials	Раздел 18.13
Location	Раздел 18.28
MTag	Раздел 18.31
Proxy-Authenticate	Раздел 18.34
Public	Раздел 18.39
Retry-After	Раздел 18.44
Unsupported	Раздел 18.55
WWW-Authenticate	Раздел 18.58

Таблица 5: Заголовки ответа RTSP

Имена заголовков ответов могут быть надежно расширены только в сочетании с изменением версии протокола. Однако использование тегов признаков в запросе позволяет отвечающей стороне изучить возможности получателя ответа. Новому или экспериментальному заголовку может быть дана семантика заголовка ответа, если все стороны в сообщении признают их заголовком ответа. Нераспознанные заголовки в ответах ДОЛЖНЫ игнорироваться.

9. Тело сообщения

Некоторые сообщения запроса и ответа включают в себя Тело сообщения (Message body) если иное не ограничено методом запроса или кодом состояния ответа. Тело сообщения состоит из самих данных контента (см. также раздел 5.3).

Запросы и ответы методами SET_PARAMETER и GET_PARAMETER, а также ответ DESCRIBE, как определено в этой спецификации, могут иметь Тело сообщения; Цель тела сообщения определяется в каждом конкретном случае. Все ответы 4xx и 5xx МОГУТ также иметь тело сообщения для переноса дополнительной информации ответа. Как правило, тело сообщения МОЖЕТ быть присоединено к любому запросу или ответу RTSP 2.0, но содержимое тела сообщения МОЖЕТ игнорироваться получателем. Расширения данной спецификации могут указывать назначение и содержание тел сообщений, в том числе требующих их включения.

В этом разделе и отправитель, и получатель ссылаются либо на клиента, либо на сервер, в зависимости от того, кто отправляет, а кто получает тело сообщения.

9.1. Поля заголовка Тела сообщения

Поля заголовка Тела сообщения определяют мета-информацию о данных содержимого в теле сообщения. Поля заголовка тела сообщения перечислены в таблице 6.

Имя поля заголовка	Определено в …
Allow	Раздел 18.6
Content-Base	Раздел 18.14
Content-Encoding	Раздел 18.15
Content-Language	Раздел 18.16
Content-Length	Раздел 18.17
Content-Location	Раздел 18.18
Content-Type	Раздел 18.19
Expires	Раздел 18.22
Last-Modified	Раздел 18.27

Таблица 6: Заголовки тела сообщения RTSP

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

9.2. Тело сообщения

Сообщение RTSP с телом сообщения ДОЛЖНО включать заголовки Content-Type и Content-Length. Когда тело сообщения включается в сообщение, тип данных этих данных контента определяется через поля заголовка Content-Type и Content-Encoding.

Content-Type определяет тип носителя базовых данных. Формат мультимедиа по умолчанию отсутствует, и фактический формат, используемый в теле, должен быть явно указан в заголовке Content-Type. Будучи явным и всегда требующим включения заголовка Content-Type с точной информацией, можно избежать многих подводных камней в эвристической интерпретации содержимого тела. Пользовательский опыт HTTP и электронной почты пострадали от такой эвристики.

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

Контент-длина сообщения — это длина контента, измеряемая в октетах.

9.3. Согласование формата сообщения

Формат содержимого тела сообщения предоставляется с использованием заголовка «Content-Type» (раздел 18.19). Чтобы дать возможность ответчику на запрос определить, какой тип мультимедиа он должен использовать, запрашивающий может включить заголовок «Accept» (раздел 18.1) в запрос для определения поддерживаемых типов мультимедиа или диапазонов типов мультимедиа, подходящих для ответа. Если респондент не поддерживает какой-либо из указанных форматов, ответом на запрос будет код ошибки 406 (не приемлемо).

Типы мультимедиа, которые могут использоваться в запросах с телами сообщений, должны определяться с помощью тегов функций, требований спецификации или проб и ошибок. Метод проб и ошибок работает, потому что, когда респондент не поддерживает тип носителя в теле сообщения, он ответит 415 (Неподдерживаемый тип носителя).

Поддерживаемые форматы и их согласование выполняется индивидуально для каждого метода и направления (тела запроса или ответа). Требования в отношении поддержки определенных типов носителей для использования в качестве тел сообщений в запросах и ответах ДОЛЖНЫ быть также определены для каждого метода и для каждого направления.

10. Соединения

Сообщения RTSP передаются между агентами RTSP и прокси с использованием транспортного соединения. Это транспортное соединение использует TCP или TCP / TLS. Это транспортное соединение упоминается как «соединение» или «соединение RTSP» в этом документе.

Запросы RTSP могут передаваться с использованием двух различных сценариев подключения, перечисленных ниже:

постоянный (persistent) — транспортное соединение используется для нескольких транзакций запрос / ответ;
переходный (transient) — транспортное соединение используется для каждой отдельной транзакции запрос / ответ.

RFC 2326 # попытался указать необязательный механизм для передачи сообщений RTSP в режиме без установления соединения через транспортный протокол, такой как UDP. Тем не менее, он не был указан достаточно подробно, чтобы учесть совместимые реализации. В попытке уменьшить сложность и объем и из-за отсутствия интереса RTSP 2.0 не пытается определить механизм для поддержки RTSP через UDP или другие транспортные протоколы без установления соединения. Побочным эффектом этого является то, что запросы RTSP НЕ ДОЛЖНЫ отправляться группам многоадресной рассылки, поскольку не может быть установлено соединение с конкретным получателем в многоадресных средах.

Некоторые заголовки RTSP, такие как заголовок CSeq (раздел 18.20), которые могут показаться относящимися только к сценариям транспортировки без установления соединения, все еще сохраняются и ДОЛЖНЫ быть реализованы в соответствии с этой спецификацией. В случае CSeq, это очень полезно для сопоставления ответов на запросы, если запросы передаются по конвейеру (см. раздел 12). Это также полезно в прокси для отслеживания различных запросов при объединении нескольких клиентских запросов в одном TCP-соединении.

10.1. Надежность и благодарность

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

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

Отсутствие подтверждения запроса RTSP должно быть обработано в рамках ограничений времени ожидания соединения, описанных ниже (Раздел 10.4).

10.2. Использование подключений

Транспорт TCP может использоваться как для постоянных соединений (для нескольких обменов сообщениями), так и для временных соединений (для обмена одним сообщением). Реализации этой спецификации ДОЛЖНЫ поддерживать RTSP через TCP. Схема URI RTSP (раздел 4.2) позволяет клиенту указать порт, с которым он будет связываться с сервером, и определяет порт по умолчанию, который будет использоваться, если он явно не указан.

В дополнение к зарегистрированным портам по умолчанию, то есть 554 (rtsp) и 322 (rtsps), есть альтернативный зарегистрированный порт 8554. Этот порт может предоставлять некоторые преимущества по сравнению с незарегистрированными портами, если сервер RTSP не может использовать порты по умолчанию. Преимущества могут включать предварительно настроенные политики безопасности, а также классификаторы в инструментах мониторинга сети.

Клиент RTSP, открывающий TCP-соединение для доступа к конкретному ресурсу, идентифицированному URI, использует IP-адрес и порт, полученные из частей URI узла и порта. IP-адрес является либо явным адресом, предоставленным в URI, либо любым из адресов, предоставленных при выполнении A и AAAA записи DNS-поиска имени хоста в URI.

Сервер ДОЛЖЕН обрабатывать как постоянные, так и временные соединения.

Переходные соединения облегчают механизмы отказоустойчивости. Они также обеспечивают мобильность на уровне приложений. Пара сервер-клиент, которая поддерживает временные соединения, может пережить потерю соединения TCP; например, из-за таймаута NAT. Когда клиент обнаружил, что TCP-соединение было потеряно, он может установить новое, когда необходимо снова установить связь.

Постоянное соединение РЕКОМЕНДУЕТСЯ использовать для всех транзакций между сервером и клиентом, включая сообщения для нескольких сеансов RTSP. Однако постоянное соединение МОЖЕТ быть закрыто после нескольких обменов сообщениями. Например, клиент может использовать постоянное соединение для первоначального обмена сообщениями SETUP и PLAY в сеансе, а затем закрыть соединение. Позже, когда клиент захочет отправить новый запрос, такой как PAUSE, для сеанса, будет открыто новое соединение. Это соединение может быть временным или постоянным.

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

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

RTSP позволяет серверу отправлять запросы клиенту. Однако это может поддерживаться только в том случае, если клиент устанавливает постоянное соединение с сервером. В случаях, когда между сервером и его клиентом не существует постоянного соединения, из-за отсутствия канала сигнализации сервер может быть вынужден молча отбросить сообщения RTSP, и он может даже отбросить сеанс RTSP без уведомления клиента. Примером такого случая является случай, когда сервер желает отправить клиенту запрос REDIRECT для сеанса RTSP, но не может этого сделать, поскольку он не может связаться с клиентом. Сервер, который пытается отправить запрос клиенту, который в данный момент не подключен к серверу, ДОЛЖЕН отклонить запрос.

Без постоянного соединения между клиентом и сервером у медиасервера нет надежного способа связаться с клиентом. Из-за вероятного сбоя установленных соединений между серверами сервер даже не попытается установить какое-либо соединение.

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

Отправка клиентских и серверных запросов может быть асинхронным событием. Чтобы избежать взаимоблокировок, клиент и сервер ДОЛЖНЫ иметь возможность отправлять и получать запросы одновременно. Поскольку ответ RTSP может быть поставлен в очередь для передачи, приема или обработки за собственными запросами равноправного агента RTSP, все агенты RTSP должны иметь определенную возможность обработки ожидающих сообщений. Потенциальная проблема заключается в том, что ожидающие запросы могут истечь, несмотря на то, что их обрабатывает одноранговый узел; это может быть связано с тем, что ответ находится в очереди за рядом запросов, которые обрабатывает агент RTSP, но для их завершения требуется некоторое время. Чтобы избежать этой проблемы, агент RTSP должен буферизовать входящие сообщения локально, чтобы любые ответные сообщения могли быть обработаны сразу после получения. Если ответы отделяются от запросов и направляются непосредственно для обработки, результат может быть использован не только немедленно, но и состояние, связанное с этим невыполненным запросом. Однако буферизация нескольких запросов на получающем агенте RTSP потребляет ресурсы и включает атаку на исчерпание ресурсов на агента. Следовательно, этот буфер должен быть ограничен, чтобы неоправданное количество запросов или общий размер сообщения не могли использовать ресурсы получающего агента. В большинстве API прекращение чтения принимающим агентом из сокета TCP приведет к тому, что окно TCP будет заблокировано, что приведет к наложению буферизации на отправляющего агента, когда нагрузка будет больше, чем ожидалось. Однако, поскольку в будущем размеры и частота сообщений RTSP могут изменяться с помощью расширений протокола, агент должен быть осторожен при проведении более жестких измерений против потенциальной атаки. При атаке агент RTSP может закрывать TCP-соединения и освобождать состояние, связанное с этим TCP-соединением.

Чтобы дать некоторые рекомендации о том, что является разумным, приведены следующие рекомендации. РЕКОМЕНДУЕТСЯ, чтобы:

агент RTSP не должен иметь более 10 невыполненных запросов на сеанс RTSP;
агент RTSP не должен иметь более 10 невыполненных запросов, которые не связаны с сеансом RTSP или которые запрашивают создание сеанса RTSP.

В свете вышесказанного РЕКОМЕНДУЕТСЯ, чтобы клиенты по возможности использовали постоянные соединения. Клиент, который поддерживает постоянные соединения, МОЖЕТ «направить» свои запросы (см. Раздел 12).

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

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

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

10.3. Закрытие соединения

Клиент МОЖЕТ закрыть соединение в любой момент, когда не существует невыполненных транзакций запроса / ответа для какого-либо сеанса RTSP, управляемого через соединение. Однако серверу НЕ СЛЕДУЕТ закрывать соединение, пока не истечет время ожидания для всех сеансов RTSP, управляемых через соединение (Раздел 18.49). Серверу НЕ СЛЕДУЕТ закрывать соединение сразу после ответа на запрос TEARDOWN уровня сеанса для последнего сеанса RTSP, контролируемого через соединение. Вместо этого сервер должен подождать, пока клиент получит разумное количество времени, и принять меры в ответ на ответ TEARDOWN, а затем инициировать закрытие соединения. Сервер ДОЛЖЕН подождать не менее 10 секунд после отправки ответа TEARDOWN, прежде чем закрывать соединение.

Это делается для того, чтобы у клиента было время для установки SETUP для нового сеанса на существующем соединении после того, как было прервано последнее. Десять секунд должны дать клиенту широкие возможности для передачи его сообщения на сервер.

Сервер НЕ ДОЛЖЕН закрывать соединение напрямую в результате ответа на запрос с кодом ошибки.

Определенные ответы об ошибках, такие как 460 (разрешена только совокупная операция) (раздел 17.4.24), используются для согласования возможностей сервера в отношении содержимого или других факторов. В таких случаях серверу неэффективно закрывать соединение при появлении сообщения об ошибке. Кроме того, такое поведение препятствует реализации расширенных или специальных типов запросов или приводит к дополнительным накладным расходам для клиента при тестировании новых функций. С другой стороны, сохранение открытых соединений после отправки сообщения об ошибке создает угрозу безопасности отказа в обслуживании (DoS) (раздел 21).

Сервер МОЖЕТ закрыть соединение, если он получит неполное сообщение и если сообщение не будет завершено в течение разумного периода времени. РЕКОМЕНДУЕТСЯ, чтобы сервер подождал не менее 10 секунд для завершения сообщения или для получения следующей части сообщения (что указывает на то, что транспорт и клиент все еще живы). Серверы, считающие, что они подвергаются атакам или которым не хватает ресурсов во время этого события, МОГУТ рассмотреть возможность использования более короткого времени ожидания.

Если сервер закрывает соединение, когда клиент пытается отправить новый запрос, клиент должен будет закрыть свое текущее соединение, установить новое соединение и отправить свой запрос через новое соединение.

Сообщение RTSP НЕ ДОЛЖНО прерываться закрытием соединения. Такое сообщение МОЖЕТ быть сочтено получателем неполным и отклонено. Сообщение RTSP правильно завершается, как определено в разделе 5.

10.4. Отключение соединений и сообщений RTSP

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

Ответчик ДОЛЖЕН ответить на все запросы в течение 5 секунд. Если респондент признает, что обработка запроса займет больше 5 секунд, он ДОЛЖЕН отправить ответ 100 (Продолжить) как можно скорее. После этого он ДОЛЖЕН продолжать отправлять ответ 100 каждые 5 секунд, пока он не будет готов отправить окончательный ответ запрашивающей стороне. После отправки ответа 100 ответчик ДОЛЖЕН отправить окончательный ответ, указывающий на успех или неудачу запроса.

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

В некоторых случаях несколько сеансов RTSP совместно используют одно и то же транспортное соединение; Отмена запроса и закрытие соединения могут оказать существенное влияние на эти другие сеансы. Прежде всего, другие запросы RTSP могли быть поставлены в очередь из-за того, что запрос занимал много времени для обработки. Во-вторых, эти сеансы также теряют возможность получать запросы от сервера к клиенту. Чтобы смягчить эту ситуацию, клиент или сервер RTSP СЛЕДУЕТ установить новое соединение и отправить любые запросы, которые поставлены в очередь или не получили ответ на это новое соединение. В-третьих, чтобы гарантировать, что RTSP-сервер знает, какое соединение является действительным для конкретного сеанса RTSP, агент RTSP ДОЛЖЕН отправить запрос подтверждения активности, если никакой другой запрос не будет отправлен немедленно для этого сеанса RTSP, для каждого сеанса RTSP в старом сеансе RTSP. подключение. Запросом проверки активности обычно будет SET_PARAMETER с заголовком сеанса, чтобы сообщить серверу, что этот агент заботится об этом сеансе RTSP.

Запросчик ДОЛЖЕН ждать ответа более 10 секунд, если он испытывает значительные транспортные задержки при подключении к ответчику. Запрашивающая сторона способна определить время прохождения сигнала в оба конца (RTT) цикла запрос / ответ с использованием заголовка метки времени (раздел 18.53) в любом запросе RTSP.

10-секундное ожидание было выбрано по следующим причинам. Это дает TCP время для выполнения нескольких повторных передач, даже если они работают со значениями по умолчанию. Он достаточно короткий, чтобы пользователи не могли сами отказаться от процесса. Однако следует отметить, что 10 секунд могут быть агрессивными в определенных типах сетей. 5-секундное значение для сообщений 1xx составляет половину времени ожидания, что дает разумную вероятность успешной доставки до того, как время ожидания произойдет на стороне запросчика.

10.5. Показ живучести

RTSP требует, чтобы клиент периодически показывал свою работоспособность серверу, или сервер может прекратить любое состояние сеанса. Несколько различных протокольных механизмов включают в свои доказательства жизни клиента. Эти механизмы представляют собой запросы RTSP с заголовком Session на сервер; если RTP & RTCP используется для передачи мультимедийных данных, и передача установлена, сообщение RTCP подтверждает жизнеспособность; или через любой другой используемый медиатранспортный протокол, способный указывать жизнеспособность клиента RTSP. РЕКОМЕНДУЕТСЯ, чтобы клиент не ждал до последней секунды тайм-аута, прежде чем пытаться отправить сообщение живучести. Сообщение RTSP может занять некоторое время, чтобы безопасно прибыть к получателю из-за потери пакета и повторных передач TCP. Чтобы показать жизнеспособность между запросами RTSP, выдаваемыми для выполнения других задач, можно использовать следующие механизмы в порядке убывания предпочтений:

RTCP: Если RTP используется для передачи мультимедиа, следует использовать RTCP. Если RTCP используется для отчета о транспортной статистике, он также обязательно будет поддерживать жизнь. Сервер может определить клиента по сетевому адресу и порту вместе с тем фактом, что клиент сообщает об источниках отправителя RTP сервера (источник синхронизации (SSRC)). Недостатком использования RTCP является то, что он дает только статистические гарантии достижения сервера. Однако вероятность ложного тайм-аута клиента настолько мала, что его можно игнорировать в большинстве случаев. Например, предположим, что сеанс с 60-секундным таймаутом и достаточным битрейтом, назначенным сообщениям RTCP, будет отправлять сообщение от клиента на сервер в среднем каждые 5 секунд. Этот клиент имеет для сети с потерей пакетов 5% вероятность того, что ему не удастся подтвердить жизнеспособность в течение интервала времени ожидания для этого сеанса 2,4 * E-16. Сеансы с более короткими тайм-аутами, гораздо более высокой потерей пакетов или малой пропускной способностью RTCP ДОЛЖНЫ также реализовать один или несколько из перечисленных ниже механизмов.
SET_PARAMETER: при использовании SET_PARAMETER для keep-alive тело НЕ ДОЛЖНО включаться. Этот метод РЕКОМЕНДУЕТСЯ использовать метод RTSP для запроса, предназначенного только для поддержки активности. Серверы RTSP ДОЛЖНЫ поддерживать метод SET_PARAMETER, чтобы клиенты всегда могли использовать этот механизм.
GET_PARAMETER: при использовании GET_PARAMETER для keep-alive тело НЕ ДОЛЖНО включаться, в зависимости от поддержки реализации на сервере. Используйте метод OPTIONS, чтобы определить, есть ли поддержка метода, или попробуйте.
OPTIONS: Этот метод также можно использовать, но он заставляет сервер выполнять больше ненужной обработки и приводит к большему количеству ответов, чем необходимо для задачи. Причина заключается в том, что серверу необходимо определить возможности, связанные с медиаресурсом, для правильного заполнения заголовков Public и Allow.

Параметр времени ожидания заголовка сеанса (раздел 18.49) МОЖЕТ быть включен в ответ SETUP и НЕ ДОЛЖЕН включаться в запросы. Сервер использует его, чтобы указать клиенту, как долго сервер готов ждать между командами RTSP или другими признаками жизни, прежде чем закрыть сеанс из-за отсутствия активности (см. Приложение B). Время ожидания измеряется в секундах, по умолчанию оно составляет 60 секунд. Продолжительность тайм-аута сеанса НЕ ДОЛЖНА изменяться в установленном сеансе.

10.6. Использование IPv6

Явная поддержка IPv6 [RFC2460 #] отсутствовала в RTSP 1.0. RTSP 2.0 был обновлен для явной поддержки IPv6. Реализации RTSP 2.0 ДОЛЖНЫ понимать буквальные адреса IPv6 в URI и заголовках RTSP. Хотя общий формат URI предусматривает потенциальные будущие новые версии буквального IP-адреса, использование любой такой новой версии потребует других модификаций спецификации RTSP (например, полей адреса в заголовке транспорта (раздел 18.54)).

10.7. Контроль перегрузки

Перегрузка в RTSP может возникать, когда у серверов и прокси-серверов недостаточно ресурсов для завершения обработки запроса. Неправильная обработка такой ситуации перегрузки на прокси-серверах и серверах может повлиять на работу развертывания RTSP и, вероятно, ухудшить ситуацию. RTSP определяет ответ 503 (Service Unavailable) (Раздел 17.5.4), чтобы позволить серверам и прокси-серверам уведомлять запрашивающие прокси и клиенты RTSP о ситуации перегрузки. В сочетании с заголовком Retry-After (раздел 18.44) сервер или прокси-сервер могут указывать время, после которого запрашивающий объект может отправить другой запрос на прокси-сервер или сервер.

Таких 503 ответов есть две. Первая область предназначена для установленного сеанса RTSP, где запрос, приводящий к ответу 503, а также сам ответ содержит заголовок сеанса, идентифицирующий сеанс, который испытывает перегрузку. Этот ответ относится только к этой конкретной сессии. Другая область действия — это общий сервер RTSP, идентифицируемый хостом в Request-URI. Такой ответ 503 с любым заголовком Retry-After применяется ко всем запросам, которые не относятся к конкретному сеансу для этого сервера, включая запрос SETUP, предназначенный для создания нового сеанса RTSP.

Существует еще одна область действия для ситуаций перегрузки: прокси RTSP. Чтобы позволить прокси-серверу RTSP сигнализировать о том, что он перегружен или иным образом недоступен и не может обработать запрос, был определен код ответа 553 со значением «Прокси-сервер недоступен». Как и в случае с серверами, в областях ответов существует разделение между запросами, связанными с существующими сеансами RTSP, и запросами на создание новых сеансов или общих запросов прокси.

Простого внедрения и использования кодов ответов 503 (служба недоступна) и 553 (недоступен прокси) недостаточно для правильной обработки ситуаций перегрузки. Например, упрощенным подходом будет отправка ответа 503 с заголовком Retry-After, установленным в фиксированное значение. Однако это может вызвать ситуацию, в которой несколько клиентов RTSP снова отправляют запросы на прокси или сервер примерно в одно и то же время, что может снова вызвать ситуацию перегрузки. Другая ситуация может возникнуть, если «старая» ситуация перегрузки еще не разрешена, то есть длина, указанная в заголовке Retry-After, была слишком короткой, чтобы ситуация перегрузки могла спадать.

Сервер RTSP или прокси-сервер в ситуации перегрузки должны тщательно выбирать значение заголовка Retry-After, учитывая его текущую ситуацию загрузки. ТРЕБУЕТСЯ увеличить период ожидания пропорционально текущей нагрузке на сервер, т. Е. Увеличение рабочей нагрузки должно привести к увеличению продолжительности указанной недоступности. НЕОБХОДИМО отправить не одно и то же значение в заголовке Retry-After всем запрашивающим прокси и клиентам, но добавить изменение к среднему значению заголовка Retry-After.

Более сложный случай может возникнуть, когда используется прокси RTSP с балансировкой нагрузки. Это тот случай, когда прокси-сервер RTSP используется для выбора из набора серверов RTSP для обработки запросов или когда для данного имени сервера доступно несколько адресов серверов. Прокси-сервер или клиент может получить код ответа 503 (служба недоступна) или 553 (недоступен прокси-сервер) от одного из своих серверов или прокси-серверов RTSP или тайм-аут TCP (если сервер даже не может обработать сообщение запроса). Прокси-сервер или клиент просто повторяет другие адреса или настроенные прокси-серверы, но он также может получить 503 (служба недоступна) или 553 (прокси-сервер недоступен) или тайм-ауты TCP с этих адресов. В такой ситуации, когда ни один из серверов / прокси-серверов / адресов RTSP не может обработать запрос, агент RTSP должен подождать, прежде чем он сможет отправить любые новые запросы на сервер RTSP. Любой дополнительный запрос к определенному адресу ДОЛЖЕН быть задержан в соответствии с полученными заголовками Retry-After. Для адресов, на которые не был получен ответ или произошел таймаут TCP, начальный таймер ожидания ДОЛЖЕН быть установлен на 5 секунд. Этот таймер ДОЛЖЕН быть удвоен для каждого дополнительного сбоя подключения или получения ответа, пока значение не превысит 30 минут, а среднее значение таймера может быть установлено равным 30 минутам. ТРЕБУЕТСЯ не устанавливать одно и то же значение в таймере для каждого расписания, а вместо этого добавлять изменение к среднему значению, в результате чего выбирается случайное значение в диапазоне от 0,5 до 1,5 раз среднего значения.

11. Возможность обработки

В этом разделе описывается доступный механизм обработки возможностей, который позволяет расширять RTSP. Расширения этой версии протокола в основном делаются двумя способами. Во-первых, могут быть добавлены новые заголовки. Во-вторых, могут быть добавлены новые методы. Механизм обработки возможностей предназначен для обработки обоих случаев.

Когда метод добавляется, участвующие стороны могут использовать метод OPTIONS, чтобы определить, поддерживается ли он. Это делается путем выдачи запроса OPTIONS другой стороне. В зависимости от URI он будет применяться в отношении определенного медиаресурса, всего сервера в целом или просто следующего перехода. Ответ OPTIONS ДОЛЖЕН содержать заголовок Public, который объявляет все методы, поддерживаемые для указанного ресурса.

Нет необходимости использовать OPTIONS для обнаружения поддержки метода, поскольку клиент может просто попробовать метод. Если получатель запроса не поддерживает метод, он ответит кодом ошибки, указывающим, что метод либо не реализован (501), либо не применяется к ресурсу (405). Выбор между двумя методами обнаружения зависит от требований службы.

Теги объектов определены для обработки функциональных дополнений, которые не являются новыми методами. Каждый тег функции представляет определенный блок функциональности. Количество функциональных возможностей, которые представляет тег функции, может значительно различаться. Например, тег функции может представлять функциональность, которую обеспечивает один заголовок RTSP. Другой тег функции может представлять гораздо больше функций, например тег функции «play.basic» (раздел 11.1), который представляет минимальную доставку мультимедиа для реализации воспроизведения.

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

Поддерживается (Supported): этот заголовок используется для определения полного набора функций, которые, как правило, имеются и у клиента, и у сервера, и не зависит от конкретного ресурса. Предполагаемое использование состоит в том, чтобы определить, прежде чем нужно будет использовать функциональность, которую он поддерживает. Его можно использовать в любом методе, но OPTIONS является наиболее подходящим, поскольку он одновременно определяет все реализуемые методы. При отправке запроса заявитель объявляет все свои возможности, включая все поддерживаемые теги функций. Это приводит к тому, что получатель изучает поддержку функции запрашивающей стороны. Затем получатель включает в ответ свой набор функций.
Поддерживается Прокси (Proxy-Supported): этот заголовок используется аналогично заголовку Supported, но вместо предоставления поддерживаемой функциональности клиента или сервера он предоставляет запрашивающей стороне и респонденту представление об общей функциональности, поддерживаемой в целом всеми членами цепочки прокси между клиентом и сервером; это не зависит от ресурса. Прокси-серверы обязаны добавлять этот заголовок всякий раз, когда присутствует поддерживаемый заголовок, но прокси-серверы также могут добавлять его независимо от запрашивающей стороны.
Требуется (Require): этот заголовок может быть включен в любой запрос, когда конечная точка, то есть клиент или сервер, требуется для понимания функции для правильного выполнения запроса. Это может быть, например, запрос SETUP, когда сервер должен понимать определенный параметр, чтобы иметь возможность правильно настроить доставку мультимедиа. Игнорирование этого параметра не будет иметь желаемого эффекта и является неприемлемым. Поэтому конечная точка, получающая запрос, содержащий Require, ДОЛЖНА отрицательно подтвердить любую функцию, которую она не понимает, и не выполнить запрос. Ответ в случаях, когда функции не поддерживаются, составляет 551 (опция не поддерживается). Кроме того, функции, которые не поддерживаются, указаны в заголовке Unsupported в ответе.
Требуется Прокси (Proxy-Require): этот заголовок имеет то же назначение и поведение, что и Require, за исключением того, что он применяется только к прокси, а не к конечной точке. Функции, которые должны поддерживаться как прокси, так и конечными точками, должны быть включены в заголовки Require и Proxy-Require.
Неподдерживаемый (Unsupported): этот заголовок используется в ответе об ошибке 551 (опция не поддерживается), чтобы указать, какие функции не поддерживаются. Такой ответ является только результатом использования заголовков Require или Proxy-Require, когда одна или несколько функций не поддерживаются. Эта информация позволяет запрашивающей стороне максимально использовать ситуации, поскольку она знает, какие функции не поддерживаются.

11.1. Feature Tag: play.basic

Реализация, поддерживающая все нормативные части этой спецификации для настройки и управления воспроизведением мультимедиа, использует тег функции «play.basic», чтобы указать эту поддержку. Приложения (начинающиеся с букв) не являются частью функциональности, включенной в тег функции, если только приложение явно не указано в главном разделе как обязательное приложение.

Примечание. Этот тег функции не требует какого-либо протокола доставки мультимедиа, такого как RTP.

В RTSP 1.0 был минимальный раздел реализации. Однако это не соответствовало остальной части спецификации. Таким образом, вместо того, чтобы пытаться явно перечислить функции для play.basic, эта спецификация должна быть взята в целом, и включены необходимые функции, нормативно определенные как требуемые.

12. Поддержка конвейеризации

Конвейерная обработка — это общий метод повышения производительности протоколов запросов / ответов, позволяющий запрашивающему агенту иметь более одного невыполненного запроса и отправлять их по одному и тому же постоянному соединению. Для RTSP, где относительный порядок запросов будет иметь значение, важно поддерживать порядок запросов. Из-за этого отвечающий агент ДОЛЖЕН обрабатывать входящие запросы в порядке их отправки. Порядок отправки может определяться заголовком CSeq и его порядковым номером. Для TCP порядок доставки будет таким же, между двумя агентами, как и порядок отправки. Обработка запроса ДОЛЖНА также быть завершена до обработки следующего запроса от того же агента. Ответы ДОЛЖНЫ быть отправлены в порядке обработки запросов.

RTSP 2.0 имеет расширенную поддержку конвейерной передачи за пределы возможностей в RTSP 1.0. В качестве основного улучшения все запросы, связанные с настройкой и инициированием доставки мультимедиа, теперь можно конвейеризовать, что указывается в заголовке Pipelined-Request (см. Раздел 18.33). Этот заголовок позволяет клиенту запрашивать обработку двух или более запросов в одном и том же контексте сеанса RTSP, который создает первый запрос. Другими словами, клиент может запросить, чтобы два или более медиапотока были настроены, а затем воспроизведены без необходимости ждать одного ответа. Это ускоряет начальное время запуска сеанса RTSP как минимум на один RTT.

Если конвейерный запрос основывается на успешном завершении одного или нескольких предыдущих запросов, запрашивающая сторона должна проверить, что все запросы были выполнены, как ожидалось. Типичным примером будут два запроса SETUP и запрос PLAY. В случае неожиданного сбоя одного из запросов SETUP, запрос PLAY все еще может быть успешно выполнен. Однако результирующее представление не будет таким, как ожидалось запрашивающим клиентом, поскольку будет воспроизводиться только один носитель вместо двух. В этом случае клиент может отправить запрос PAUSE, исправить ошибочный запрос SETUP и затем запросить его воспроизведение.

13. Определения методов

Метод указывает, что должно быть выполнено на ресурсе, идентифицированном Request-URI. Имя метода чувствительно к регистру. Новые методы могут быть определены в будущем. Имена методов НЕ ДОЛЖНЫ начинаться с символа $ (десятичное число 36) и ДОЛЖНЫ быть токенами, как определено ABNF [RFC5234 #] в Разделе 20. Методы приведены в Таблице 7.

Метод (method)	Направление (direction)	Объект, цель (object)	Реализация Сервера	Реализация Клиента
DESCRIBE	C -> S	P: presentation, S: stream	Рекомендуема	Рекомендуема
GET_PARAMETER	C -> S	Представление, Поток	Необязательна	Необязательна
	S -> C	Представление, Поток	Необязательна	Необязательна
OPTIONS	C -> S	Представление, Поток	Обязательна	Обязательна
	S -> C	Представление, Поток	Необязательна	Необязательна
PAUSE	C -> S	Представление, Поток	Обязательна	Обязательна
PLAY	C -> S	Представление, Поток	Обязательна	Обязательна
PLAY_NOTIFY	S -> C	Представление, Поток	Обязательна	Обязательна
REDIRECT	S -> C	Представление, Поток	Необязательна	Необязательна
SETUP	C -> S	Поток	Обязательна	Обязательна
SET_PARAMETER	C -> S	Представление, Поток	Обязательна	Обязательна
	S -> C	Представление, Поток	Необязательна	Необязательна
TEARDOWN	C -> S	Представление, Поток	Обязательна	Обязательна
	S -> C	Представление	Обязательна	Обязательна

Таблица 7 — Обзор методов RTSP

Примечание к таблице 7: Эта таблица охватывает методы RTSP, их направление и то, с какими объектами (P: представление, S: поток) они работают. Кроме того, он указывает, является ли реализация сервера или клиента требуемой (обязательной), рекомендуемой или необязательной.

Дополнительное примечание к таблице 7: GET_PARAMETER является необязательным. Например, полнофункциональный сервер может быть создан для доставки медиа без каких-либо параметров. Однако SET_PARAMETER требуется, т. е. Обязателен для реализации на сервере; это связано с его использованием для поддержания активности. PAUSE требуется, потому что это единственный способ выйти из состояния Play без завершения всего сеанса.

Если агент RTSP не поддерживает конкретный метод, он ДОЛЖЕН вернуть код ответа 501 (не реализован), а запрашивающий агент RTSP, в свою очередь, НЕ ДОЛЖЕН пробовать этот метод снова для данной комбинации агент / ресурс. Прокси-сервер RTSP, основная функция которого состоит в том, чтобы регистрировать или проверять и никоим образом не изменять обработку транспорта или мультимедиа, МОЖЕТ пересылать сообщения RTSP неизвестными методами. Обратите внимание, что прокси-сервер все еще должен выполнять минимально необходимую обработку, такую как добавление заголовка Via.

13.1. OPTIONS — ОПЦИИ

Семантика RTSP-метода «OPTIONS» аналогична семантике HTTP-метода OPTIONS, описанного в разделе 4.3.7 [RFC7231 #]. Однако в RTSP OPTIONS является двунаправленным в том смысле, что клиент может отправить запрос на сервер и наоборот. Клиент ДОЛЖЕН реализовать возможность отправки запроса OPTIONS, а сервер или прокси-сервер ДОЛЖЕН реализовать возможность ответа на запрос OPTIONS. В дополнение к этой функциональности «MUST-implement» (ДОЛЖЕН быть реализован), клиенты, серверы и прокси-серверы МОГУТ обеспечивать поддержку как для отправки запросов OPTIONS, так и для генерации ответов на запросы.

Запрос OPTIONS может быть выдан в любое время. Такой запрос не изменяет состояние сеанса. Однако это может продлить продолжительность жизни сеанса (см. Ниже). URI в запросе OPTIONS определяет объем запроса и соответствующий ответ. Если Request-URI ссылается на определенный медиаресурс на данном хосте, область действия ограничена набором методов, поддерживаемых для этого медиаресурса указанным агентом RTSP. Request-URI только с адресом хоста ограничивает область применения общими возможностями указанного агента RTSP безотносительно к каким-либо конкретным носителям. Если Request-URI является звездочкой («*»), область действия ограничена общими возможностями следующего перехода (то есть агент RTSP в прямой связи с отправителем запроса).

Независимо от объема запроса открытый заголовок ДОЛЖЕН всегда включаться в ответ OPTIONS, перечисляя методы, которые поддерживаются отвечающим агентом RTSP. Кроме того, если область запроса ограничена медиа-ресурсом, заголовок Allow ДОЛЖЕН быть включен в ответ, чтобы перечислить набор методов, которые разрешены для этого ресурса, если набор методов не полностью совпадает с набором в заголовке Public. Если данный ресурс недоступен, агент RTSP ДОЛЖЕН вернуть соответствующий код ответа, например 3rr или 4xx. Поддерживаемый заголовок МОЖЕТ быть включен в запрос для запроса набора функций, которые поддерживаются отвечающим агентом RTSP.

Метод OPTIONS может использоваться для поддержания сеанса RTSP живым. Однако это не является предпочтительным способом сигнализации поддержания сеанса связи; см. раздел 18.49. Запрос OPTIONS, предназначенный для поддержания активности сеанса RTSP, ДОЛЖЕН включать заголовок сеанса с соответствующим идентификатором сеанса. Такой запрос ДОЛЖЕН также использовать медиа или агрегированный управляющий URI в качестве Request-URI.

Пример:

C->S: OPTIONS rtsp://server.example.com RTSP/2.0 CSeq: 1 User-Agent: PhonyClient/1.2 Proxy-Require: gzipped-messages Supported: play.basic

S->C: RTSP/2.0 200 OK CSeq: 1 Public: DESCRIBE, SETUP, TEARDOWN, PLAY, PAUSE, OPTIONS Supported: play.basic, setup.rtp.rtcp.mux, play.scale Server: PhonyServer/1.1

Обратите внимание, что тег функции «gzipped-messages» в Proxy-Require является фиктивной функцией.

13.2. DESCRIBE — ОПИСАНИЯ

Метод «DESCRIBE» используется для получения описания презентации или медиа-объекта с сервера. Request-URI запроса DESCRIBE идентифицирует интересующий медиаресурс. Клиент МОЖЕТ включить в запрос заголовок Accept для перечисления форматов описания, которые он понимает. Сервер ДОЛЖЕН ответить описанием запрошенного ресурса и вернуть описание в теле сообщения ответа, если запрос метода DESCRIBE может быть успешно выполнен. Пара «reply-respons» (ответ-ответа) DESCRIBE составляет фазу инициализации среды RTSP.

Ответ DESCRIBE ДОЛЖЕН содержать всю информацию инициализации мультимедиа для ресурса (ов), который он описывает. Серверы НЕ ДОЛЖНЫ использовать ответ DESCRIBE как средство косвенного обращения к медиаданным, имея точку описания на другом сервере; Вместо этого рекомендуется использовать ответы 3rr.

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

Пример:

C->S: DESCRIBE rtsp://server.example.com/fizzle/foo RTSP/2.0 CSeq: 312 User-Agent: PhonyClient/1.2 Accept: application/sdp, application/example

S->C: RTSP/2.0 200 OK CSeq: 312 Date: Thu, 23 Jan 1997 15:35:06 GMT Server: PhonyServer/1.1 Content-Base: rtsp://server.example.com/fizzle/foo/ Content-Type: application/sdp Content-Length: 358

v=0 o=MNobody 2890844526 2890842807 IN IP4 192.0.2.46 s=SDP Seminar i=A Seminar on the session description protocol u=http://www.example.com/lectures/sdp.ps e=seminar@example.com (Seminar Management) c=IN IP4 0.0.0.0 a=control:* t=2873397496 2873404696 m=audio 3456 RTP/AVP 0 a=control:audio m=video 2232 RTP/AVP 31 a=control:video

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

через запрос RTSP DESCRIBE
через какой-то другой протокол (HTTP, вложение электронной почты и т. д.)
через некоторую форму пользовательского интерфейса

Если клиент получает действительное описание из альтернативного источника, клиент МОЖЕТ использовать это описание для целей инициализации, не отправляя запрос DESCRIBE для того же носителя. Клиент должен использовать любой «MTag» либо для проверки описания презентации, либо для того, чтобы установление сеанса было обусловлено действительностью.

РЕКОМЕНДУЕТСЯ, чтобы минимальные серверы поддерживали метод DESCRIBE, и настоятельно рекомендуется, чтобы минимальные клиенты поддерживали возможность выступать в роли «helper applications» (вспомогательных приложений), которые принимают файл инициализации мультимедиа из пользовательского интерфейса, или других средств, соответствующих операционной среде клиентов.

13.3. SETUP — НАСТРОИТЬ

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

Init: начальное состояние. Сессия не существует.

Ready: сессия готова начать воспроизведение.

Play: сеанс воспроизводится, т.е. отправляет данные медиапотока в направлении S-> C.

Запрос метода «SETUP» для URI указывает транспортный механизм, который будет использоваться для потоковой информации. Метод SETUP может использоваться в двух разных случаях, а именно: создание сеанса RTSP и изменение транспортных параметров медиапотоков, которые уже установлены. SETUP может использоваться во всех трех состояниях: Init, Ready и Play для изменения транспортных параметров. Кроме того, Init и Ready также могут использоваться для создания сеанса RTSP. Использование метода SETUP в состоянии Play для добавления медиаресурса в сеанс не определено.

Заголовок Transport, см. Раздел 18.54, определяет параметры медиатранспорта, приемлемые для клиента для передачи данных; ответ будет содержать параметры транспорта, выбранные сервером. Это позволяет клиенту перечислять в порядке убывания предпочтения транспортные механизмы и параметры, приемлемые для него, чтобы сервер мог выбрать наиболее подходящий. Ожидается, что используемый формат описания сеанса позволит клиенту выбрать ограниченное число возможных конфигураций, которые предлагаются в качестве вариантов для сервера. Все транспортные параметры должны быть включены в заголовок Transport; использование других заголовков для этой цели НЕ РЕКОМЕНДУЕТСЯ из-за промежуточных блоков, таких как брандмауэры или NAT.

В интересах любых промежуточных межсетевых экранов клиент ДОЛЖЕН указывать известные транспортные параметры, даже если он не влияет на эти параметры, например, когда сервер объявляет адрес фиксированной групповой адресации в качестве пункта назначения.

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

Клиент ДОЛЖЕН включать в запрос заголовок Accept-Ranges, указывая все поддерживаемые форматы модулей в заголовке Range. Это позволяет серверу знать, какие форматы он может использовать в будущих ответах, связанных с сеансом, таких как ответ PLAY без какого-либо диапазона в запросе. Если клиент не поддерживает формат времени, необходимый для представления, сервер ДОЛЖЕН ответить, используя 456 (Поле заголовка, недопустимое для ресурса), и включить заголовок Accept-Ranges с поддерживаемыми для ресурса форматами единиц измерения диапазона.

В ответе SETUP сервер ДОЛЖЕН включать заголовок Accept-Ranges (см. Раздел 18.5), чтобы указать, какие форматы времени приемлемо использовать для этого медиаресурса.

Ответ SETUP 200 OK ДОЛЖЕН включать заголовок Media-Properties (см. Раздел 18.29). Комбинация параметров заголовка Media-Properties указывает на характер содержимого, присутствующего в сеансе (см. Также раздел 4.7). Например, прямой эфир со смещением времени обозначается как

Random access (Произвольный доступ) установлен на «Random-Access»,
Content Modifications (Модификации контента), установлена на «Time-Progressing»
Retention (Удержание) установлено на «Time-Duration» (с определенным значением времени окна записи).

Ответ SETUP 200 OK ДОЛЖЕН включать заголовок Media-Range (см. Раздел 18.30), если среда имеет прогресс по времени.

Базовый пример для 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). Агрегированный URI управления ДОЛЖЕН использоваться для управления агрегированным сеансом. Этот URI ДОЛЖЕН отличаться от URI управления потоком отдельных медиапотоков, включенных в агрегат (см. Раздел 13.4.2 для агрегированных сеансов и для конкретных URI см. Приложение D.1.1). Совокупный управляющий URI должен быть указан в описании сеанса, если сервер поддерживает агрегированное управление, и для сеанса требуется агрегированное управление.

Однако, даже если предлагается агрегированное управление, клиент МОЖЕТ выбрать не устанавливать сеанс в агрегированном управлении. Если агрегатный URI управления не указан в описании сеанса, это обычно указывает на то, что следует использовать неагрегированный элемент управления.

SETUP медиапотоков в агрегате, которому не был предоставлен агрегированный контрольный URI, не указана.

Хотя идентификатор сеанса иногда несет достаточно информации для совокупного управления сеансом, совокупный URI управления все еще важен для некоторых методов, таких как SET_PARAMETER, где управляющий URI позволяет легко идентифицировать рассматриваемый ресурс. Совокупный управляющий URI также полезен для прокси-серверов, позволяя им направить запрос на соответствующий сервер, и для ведения журнала, где полезно отметить фактический ресурс, на котором работал запрос.

Сеанс будет существовать до тех пор, пока он не будет удален по запросу TEARDOWN или не истечет время ожидания сервера. Сервер МОЖЕТ удалить сеанс, который не продемонстрировал признаки жизнеспособности от клиента (ов) в течение определенного периода времени ожидания. Значение тайм-аута по умолчанию составляет 60 секунд; сервер МОЖЕТ установить это значение на другое значение и указать это в поле времени ожидания заголовка сеанса в ответе SETUP. Для дальнейшего обсуждения см. раздел 18.49. Признаки жизнеспособности для сеанса RTSP включают в себя любые запросы RTSP от клиента, которые содержат заголовок сеанса с идентификатором для этого сеанса, а также отчеты отправителя или получателя RTCP, если RTP используется для транспортировки основного медиапотока. Отчеты отправителя RTCP могут, например, приниматься в сеансе, где сервер приглашен в сеанс конференции, и, таким образом, являются действительными в качестве индикатора жизнеспособности.

Если запрос SETUP для сеанса завершается неудачей по какой-либо причине, состояние сеанса, а также параметры транспорта и другие параметры для связанных потоков ДОЛЖНЫ оставаться неизменными по сравнению с их значениями, как если бы запрос SETUP никогда не был получен сервером.

13.3.1. Изменение параметров транспорта

Клиент МОЖЕТ выдать запрос 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. Однако серверу СЛЕДУЕТ избегать изменения информации синхронизации, если это возможно.

13.4. PLAY — ВОСПРОИЗВЕДЕНИЕ

В этом разделе описывается использование метода «PLAY» в целом, для агрегированных сеансов и в различных сценариях использования.

13.4.1. Общее использование

Метод «PLAY» указывает серверу начать отправку данных через механизм, указанный в SETUP, и какую часть мультимедиа следует воспроизвести. Запросы PLAY действительны, когда сеанс находится в состоянии готовности (Ready) или воспроизведения (Play). Запрос PLAY ДОЛЖЕН включать заголовок Session, чтобы указать, к какому сеансу применяется запрос.

После получения запроса PLAY сервер ДОЛЖЕН установить нормальное время воспроизведения на начало диапазона, указанного в принятом заголовке Range, в пределах медиаресурса и в соответствии с заголовком Seek-Style (раздел 18.47). Он ДОЛЖЕН доставлять потоковые данные до конца диапазона, если он задан, до получения нового запроса PLAY, до получения запроса PAUSE (раздел 13.5) или до достижения конца носителя. Если в запросе PLAY отсутствует заголовок Range, сервер ДОЛЖЕН воспроизводиться с текущей точки паузы до конца мультимедиа. По умолчанию точка паузы при запуске сеанса начинается с начала носителя. Для носителей, у которых время увеличивается и не сохраняется, точка паузы всегда будет установлена равной NPT «now» (сейчас), то есть текущей точкой доставки. Точка паузы также может быть установлена для определенной точки на носителе методом PAUSE; см. раздел 13.6. Точка паузы для медиафайлов, которые воспроизводятся в данный момент, равна текущей медиа-позиции. Для носителей с прогрессирующим временем и ограниченным во времени хранением, если точка паузы представляет позицию, которая старше, чем та, которую удерживает сервер, точка паузы будет перемещена в самую старую сохраненную позицию.

Какие значения диапазона допустимы, зависит от типа контента. Для контента, который не прогрессирует во времени, значение диапазона допустимо, если данный диапазон является частью какого-либо носителя в совокупности. Другими словами, допустимым диапазоном мультимедиа для агрегата является объединение всех компонентов мультимедиа в агрегате. Если данное значение диапазона указывает за пределы носителя, ответ ДОЛЖЕН быть кодом ошибки 457 (Недопустимый диапазон) и включать заголовок Media-Range (раздел 18.30) с допустимым диапазоном для носителя. За исключением контента с прогрессирующим временем, когда клиент запрашивает начальную точку до того, что сохраняется, начальная точка настраивается на самый старый сохраненный контент. Для начальной точки, которая находится за передним краем носителя, то есть за пределами текущего значения для «now», сервер ДОЛЖЕН настроить начальное значение на текущий передний край. Значение точки остановки заголовка Range может указывать за пределы текущей границы носителя. В этом случае сервер ДОЛЖЕН доставлять носитель из запрошенной (и, возможно, скорректированной) начальной точки до первой из предоставленной конечной точки или конца носителя. Обратите внимание, что если кто-то просто хочет играть с определенной начальной точки до конца носителя, РЕКОМЕНДУЕТСЯ использовать заголовок Range с неявной конечной точкой.

Если клиент запрашивает начало воспроизведения в конце носителя, либо явно с заголовком Range, либо неявно с точкой паузы, находящейся в конце носителя, ДОЛЖНА быть отправлена ошибка 457 (Недопустимый диапазон), которая включает заголовок Media-Range (Раздел 18.30). Ниже указывается, что заголовок Range также должен быть включен в ответ и что он будет переносить точку паузы на носителе в случае, когда сеанс находится в состоянии готовности. Обратите внимание, что это также применимо, если точка паузы или запрошенная начальная точка находятся в начале носителя и заголовок Scale (раздел 18.46) включен с отрицательным значением (воспроизведение в обратном направлении).

Для носителей со свойствами произвольного доступа клиент может указать, какую политику для выбора начальной точки должен использовать сервер. Это делается путем включения заголовка Seek-Style (раздел 18.47) в запрос PLAY. Примененный стиль поиска будет влиять на содержимое заголовка Range, так как он будет скорректирован, чтобы указывать, с какой точки медиа фактически доставляется.

Клиент, желающий воспроизвести мультимедиа с начала, ДОЛЖЕН послать запрос PLAY с заголовком Range, указывающим на начало, например, «npt = 0-». Если запрос PLAY получен без заголовка Range, и доставка мультимедиа в конце остановлена, сервер ДОЛЖЕН ответить ошибкой 457 (Invalid Range). В этом ответе текущая точка паузы ДОЛЖНА быть включена в заголовок диапазона.

Все спецификаторы диапазона в этой спецификации допускают диапазоны с неявной начальной точкой (например, «npt = -30»). При использовании в запросе PLAY сервер обрабатывает его как запрос на запуск или возобновление доставки с текущей точки паузы, заканчивающейся в время окончания, указанное в заголовке Range. Если точка паузы находится позже заданного конечного значения, ответ 457 (Недопустимый диапазон) ДОЛЖЕН быть возвращен.

В приведенном ниже примере будут воспроизводиться секунды с 10 по 25. Он также запрашивает у сервера доставку мультимедиа с первой точки произвольного доступа до указанной начальной точки.

C->S: PLAY rtsp://audio.example.com/audio RTSP/2.0 CSeq: 835 Session: ULExwZCXh2pd0xuFgkgZJW Range: npt=10-25 Seek-Style: RAP User-Agent: PhonyClient/1.2

Серверы ДОЛЖНЫ включать заголовок Range в любой ответ с методом PLAY, даже если в запросе отсутствует заголовок Range. Ответ ДОЛЖЕН использовать тот же формат, что и заголовок Range, содержащийся в запросе. Если в запросе не было заголовка Range, формат ДОЛЖЕН использоваться в любом предыдущем запросе PLAY в рамках сеанса. Если в предыдущем запросе формат не указан, сервер МОЖЕТ использовать любой формат времени, поддерживаемый носителем и указанный в заголовке Accept-Ranges в запросе SETUP. РЕКОМЕНДУЕТСЯ, чтобы NPT использовался, если поддерживается средствами массовой информации.

Для любого ответа об ошибке на запрос PLAY ответ сервера зависит от текущего состояния сеанса. Если сеанс находится в состоянии готовности, текущая точка паузы возвращается с использованием заголовка Range с точкой паузы в качестве явной начальной точки и неявной конечной точки. Для контента с прогрессирующим временем, когда точка паузы перемещается в реальном времени из-за ограниченного хранения, возвращается текущая точка паузы. Для сеансов в состоянии Play, текущая точка воспроизведения и остальные части запроса диапазона возвращаются. Для любого носителя с задержкой более 0 секунд действующий в настоящее время заголовок Media-Range ДОЛЖЕН также быть включен в ответ.

Ответ PLAY МОЖЕТ включать заголовок, несущий информацию синхронизации. Поскольку необходимая информация зависит от формата медиатранспорта, необходимы дополнительные правила, определяющие заголовок и его использование. Для RTP указывается заголовок RTP-Info, см. Раздел 18.45, и используется в следующем примере.

Вот простой пример для отдельного аудиопотока, где клиент запрашивает мультимедиа, начиная с 3,52 секунды и до конца. Сервер отправляет ответ 200 OK с фактическим временем воспроизведения, которое предшествует 10 мс (3,51), и заголовком RTP-Info, который содержит необходимые параметры для стека RTP.

C->S: PLAY rtsp://example.com/audio RTSP/2.0 CSeq: 836 Session: ULExwZCXh2pd0xuFgkgZJW Range: npt=3.52- User-Agent: PhonyClient/1.2

S->C: RTSP/2.0 200 OK CSeq: 836 Date: Thu, 23 Jan 1997 15:35:06 GMT Server: PhonyServer/1.0 Range: npt=3.51-324.39 Seek-Style: First-Prior Session: ULExwZCXh2pd0xuFgkgZJW RTP-Info:url="rtsp://example.com/audio" ssrc=0D12F123:seq=14783;rtptime=2345962545

S->C: RTP Packet TS=2345962545 => NPT=3.51 Media duration=0.16 seconds

Сервер отвечает с фактической начальной точкой, которая будет доставлена. Это может отличаться от запрошенного диапазона, если для медиаисточника требуется выравнивание запрошенного диапазона с действительными границами кадра. Обратите внимание, что некоторые мультимедийные потоки в совокупности, возможно, должны быть доставлены из более ранних точек. Кроме того, некоторые мультимедийные форматы имеют очень большую длительность для каждого отдельного блока данных; поэтому клиенту может потребоваться проанализировать блок данных и выбрать, с чего начать. Сервер ДОЛЖЕН также указывать, какую политику он использует для выбора фактической начальной точки, включая заголовок Seek-Style.

В следующем примере клиент получает первый медиапакет, который растягивается до конца и превышает запрошенное время воспроизведения. Таким образом, клиент принимает решение, отображать ли пользователю время между 3,52 и 7,05 или пропустить его. В большинстве случаев, вероятно, наиболее целесообразно не отображать этот период времени.

C->S: PLAY rtsp://example.com/audio RTSP/2.0 CSeq: 836 Session: ZGGyCJOs8xaLkdNK2dmxQO Range: npt=7.05- User-Agent: PhonyClient/1.2

S->C: RTSP/2.0 200 OK CSeq: 836 Date: Thu, 23 Jan 1997 15:35:06 GMT Server: PhonyServer/1.0 Session: ZGGyCJOs8xaLkdNK2dmxQO Range: npt=3.52- Seek-Style: First-Prior RTP-Info:url="rtsp://example.com/audio" ssrc=0D12F123:seq=14783;rtptime=2345962545

S->C: RTP Packet TS=2345962545 => NPT=3.52 Duration=4.15 seconds

После воспроизведения желаемого диапазона презентация НЕ переходит в состояние готовности, доставка мультимедиа просто прекращается. Если необходимо перевести поток в состояние готовности, ДОЛЖЕН быть выполнен запрос PAUSE. Запрос PLAY, когда поток все еще находится в состоянии Play, является законным и может быть выдан без промежуточного запроса PAUSE. Такой запрос ДОЛЖЕН заменить текущее действие PLAY новым запрошенным, то есть обрабатываться так же, как если бы запрос был получен в состоянии готовности. В случае, если диапазон в заголовке Range имеет неявное время начала («-endtime»), сервер ДОЛЖЕН продолжать воспроизведение с того места, где он в данный момент находился, до указанной конечной точки. Это полезно для изменения конца в другой точке, чем в предыдущем запросе.

В следующем примере воспроизводится вся презентация, начиная с временного кода SMPTE 0:10:20 и до конца клипа. Примечание: заголовки RTP-Info разбиты на несколько строк, где последующие строки начинаются с пробела, как это разрешено синтаксисом.

C->S: PLAY rtsp://audio.example.com/twister.en RTSP/2.0 CSeq: 833 Session: N465Wvsv0cjUy6tLqINkcf Range: smpte=0:10:20- User-Agent: PhonyClient/1.2

S->C: RTSP/2.0 200 OK CSeq: 833 Date: Thu, 23 Jan 1997 15:35:06 GMT Session: N465Wvsv0cjUy6tLqINkcf Server: PhonyServer/1.0 Range: smpte=0:10:22-0:15:45 Seek-Style: Next RTP-Info:url="rtsp://example.com/twister.en" ssrc=0D12F123:seq=14783;rtptime=2345962545

Для воспроизведения записи живой презентации может быть желательно использовать единицы времени:

C->S: PLAY rtsp://audio.example.com/meeting.en RTSP/2.0 CSeq: 835 Session: N465Wvsv0cjUy6tLqINkcf Range: clock=19961108T142300Z-19961108T143520Z User-Agent: PhonyClient/1.2

S->C: RTSP/2.0 200 OK CSeq: 835 Date: Thu, 23 Jan 1997 15:35:06 GMT Session: N465Wvsv0cjUy6tLqINkcf Server: PhonyServer/1.0 Range: clock=19961108T142300Z-19961108T143520Z Seek-Style: Next RTP-Info:url="rtsp://example.com/meeting.en" ssrc=0D12F123:seq=53745;rtptime=484589019

13.4.2. Агрегированные сессии

Запросы PLAY могут работать в сеансах, управляющих одним медиапотоком, и в агрегированных сеансах, управляющих несколькими медиапотоками.

В агрегированном сеансе запрос PLAY ДОЛЖЕН содержать агрегированный контрольный URI. Сервер ДОЛЖЕН ответить ошибкой 460 (Разрешена только совокупная операция), если клиентский URI запроса PLAY предназначен для одного носителя. Медиа в совокупности ДОЛЖНЫ воспроизводиться синхронно. Если клиенту требуется индивидуальный контроль над мультимедиа, ему необходимо использовать отдельные сеансы RTSP для каждого мультимедиа.

Для агрегированных сеансов, в которых за первоначальным запросом SETUP (созданием сеанса) следует один или несколько дополнительных запросов SETUP, запрос PLAY МОЖЕТ быть передан по конвейеру (раздел 12) после этих дополнительных запросов SETUP, не ожидая их ответов. Эта процедура может уменьшить задержку от начала установления сеанса до начала воспроизведения мультимедиа с одним RTT. Однако клиент должен знать, что использование этой процедуры приведет к воспроизведению состояния сервера, установленного во время обработки PLAY, то есть после обработки всех запросов до запроса PLAY в конвейере. Это состояние может не соответствовать предполагаемому из-за сбоя любого из предыдущих запросов. Клиент может легко определить это на основе ответов на эти запросы. В случае сбоя клиент может остановить воспроизведение мультимедиа с помощью PAUSE и попытаться снова установить желаемое состояние, прежде чем отправлять другой запрос PLAY.

13.4.3. Обновление текущих запросов PLAY

Клиенты могут выдавать запросы PLAY, когда поток находится в состоянии воспроизведения, и, таким образом, обновлять свой запрос.

Важным отличием по сравнению с запросом PLAY в состоянии готовности является обработка текущей точки воспроизведения и способ построения заголовка Range в запросе. Сеанс активно воспроизводит мультимедиа, и точка воспроизведения будет перемещаться, что затрудняет прогнозирование точного времени запроса. В зависимости от того, как выглядит заголовок PLAY, существуют два разных случая: полная замена или продолжение. Полная замена сигнализируется тем, что первая спецификация диапазона имеет явное начальное значение, например, «npt = 45-» или «npt = 45-60», и в этом случае сервер останавливает воспроизведение в текущей точке воспроизведения и затем начинает доставлять медиа в соответствии с заголовком Range. Это эквивалентно тому, что клиент сначала отправляет PAUSE, а затем новый запрос PLAY, который не основан на точке паузы. В случае продолжения первый спецификатор диапазона имеет неявную начальную точку и явное конечное значение (Z), например, «npt = -60», которые указывают, что он ДОЛЖЕН преобразовывать спецификатор диапазона, воспроизводимый до этого запроса PLAY ( От X до Y) в (от X до Z) и продолжайте, как если бы это был первоначально исполненный запрос. Если текущая точка доставки находится за пределами конечной точки, сервер ДОЛЖЕН немедленно приостановить доставку. Поскольку запрос был успешно выполнен, на него должен быть дан ответ 200 OK. PLAY_NOTIFY с концом потока также отправляется для указания фактической точки остановки. Точка паузы установлена на запрошенную точку остановки.

Ниже приведен пример такого поведения: Сервер получил запросы на воспроизведение диапазонов от 10 до 15. Если новый запрос PLAY поступит на сервер через 4 секунды после предыдущего, он вступит в силу, пока сервер все еще воспроизводит первый диапазон (10-15). Сервер изменяет текущее воспроизведение, чтобы оно продолжалось до 25 секунд, то есть эквивалентный одиночный запрос был бы PLAY с «range: npt = 10-25».

C->S: PLAY rtsp://example.com/fizzle/foo RTSP/2.0 CSeq: 834 Session: apzA8LnjQ5KWTdw0kUkiRh Range: npt=10-15 User-Agent: PhonyClient/1.2

S->C: RTSP/2.0 200 OK CSeq: 834 Date: Thu, 23 Jan 1997 15:35:06 GMT Session: apzA8LnjQ5KWTdw0kUkiRh Server: PhonyServer/1.0 Range: npt=10-15 Seek-Style: Next RTP-Info:url="rtsp://example.com/fizzle/audiotrack" ssrc=0D12F123:seq=5712;rtptime=934207921, url="rtsp://example.com/fizzle/videotrack" ssrc=789DAF12:seq=57654;rtptime=2792482193

C->S: PLAY rtsp://example.com/fizzle/foo RTSP/2.0 CSeq: 835 Session: apzA8LnjQ5KWTdw0kUkiRh Range: npt=-25 User-Agent: PhonyClient/1.2

S->C: RTSP/2.0 200 OK CSeq: 835 Date: Thu, 23 Jan 1997 15:35:09 GMT Session: apzA8LnjQ5KWTdw0kUkiRh Server: PhonyServer/1.0 Range: npt=14-25 Seek-Style: Next RTP-Info:url="rtsp://example.com/fizzle/audiotrack" ssrc=0D12F123:seq=5712;rtptime=934239921, url="rtsp://example.com/fizzle/videotrack" ssrc=789DAF12:seq=57654;rtptime=2792842193

Обычное использование запроса PLAY в состоянии воспроизведения — это изменение масштаба мультимедиа, т. е. Вход или Выход из режима ускоренной перемотки вперед или назад. Клиент может выдать запрос на обновление PLAY, который является либо продолжением, либо полной заменой, как обсуждалось выше в этом разделе. Ниже приведен пример клиента, который запрашивает ускоренную перемотку вперед (масштаб = 2) без указания точки остановки, а затем переход от ускоренной перемотки вперед к обычному воспроизведению (масштаб = 1). Во втором запросе PLAY время задается явно так, чтобы сервер воспроизводил данные в данный момент (npt = now-), и сервер отвечает фактической точкой воспроизведения, где новый масштаб фактически вступает в силу (npt = 02: 17: 27.144- ).

C->S: PLAY rtsp://example.com/fizzle/foo RTSP/2.0 CSeq: 2034 Session: apzA8LnjQ5KWTdw0kUkiRh Range: npt=now- Scale: 2.0 User-Agent: PhonyClient/1.2

S->C: RTSP/2.0 200 OK CSeq: 2034 Date: Thu, 23 Jan 1997 15:35:06 GMT Session: apzA8LnjQ5KWTdw0kUkiRh Server: PhonyServer/1.0 Range: npt=02:17:21.394- Seek-Style: Next Scale: 2.0 RTP-Info:url="rtsp://example.com/fizzle/audiotrack" ssrc=0D12F123:seq=5712;rtptime=934207921, url="rtsp://example.com/fizzle/videotrack" ssrc=789DAF12:seq=57654;rtptime=2792482193

[перемотка вперед и возврат к масштабу = 1]

C->S: PLAY rtsp://example.com/fizzle/foo RTSP/2.0 CSeq: 2035 Session: apzA8LnjQ5KWTdw0kUkiRh Range: npt=now- Scale: 1.0 User-Agent: PhonyClient/1.2

S->C: RTSP/2.0 200 OK CSeq: 2035 Date: Thu, 23 Jan 1997 15:35:09 GMT Session: apzA8LnjQ5KWTdw0kUkiRh Server: PhonyServer/1.0 Range: npt=02:17:27.144- Seek-Style: Next Scale: 1.0 RTP-Info:url="rtsp://example.com/fizzle/audiotrack" ssrc=0D12F123:seq=5712;rtptime=934239921, url="rtsp://example.com/fizzle/videotrack" ssrc=789DAF12:seq=57654;rtptime=2792842193

13.4.4. Воспроизведение медиа по запросу

Носитель по требованию указывается содержимым заголовка «Media-Properties» в ответе SETUP, когда (см. Также раздел 18.29):

для свойства Random Access (Произвольный доступ) установлено значение «Random-Access»;
для свойства Content Modifications (Модификации содержимого) установлено значение «Immutable» (Неизменный);
для свойства Retention (Удержание) установлено значение «Unlimited» (Неограниченный) или «Time-Limited» (Ограниченный).

Воспроизведение мультимедиа по требованию следует общему использованию, как описано в разделе 13.4.1.

13.4.5. Воспроизведение динамических носителей по требованию

Динамический носитель по требованию указывается содержимым заголовка «Media-Properties» в ответе SETUP, когда (см. Также раздел 18.29):

для свойства Random Access (Произвольный доступ) установлено значение «Random-Access»;
для свойства Content Modifications (Модификации содержимого) установлено значение «Dynamic» (Динамический);
для свойства Retention (Удержание) установлено значение «Unlimited» (Неограниченный) или «Time-Limited» (Ограниченный).

Воспроизведение носителей по требованию следует общему использованию, как описано в разделе 13.4.1, если носитель не был изменен.

Клиент может быть информирован об изменениях медиаресурсов в состоянии Play двумя способами. Во-первых, клиент получит запрос PLAY_NOTIFY с заголовком Notify-Reason, установленным в media-properties-update (см. Раздел 13.5.2). Клиент может использовать значение заголовка Media-Range для решения дальнейших действий, если заголовок Media-Range присутствует в запросе PLAY_NOTIFY. Второй способ заключается в том, что клиент выдает запрос GET_PARAMETER без тела, но включает заголовок Media-Range. Ответ 200 OK ДОЛЖЕН включать текущий заголовок Media-Range (см. Раздел 18.30).

13.4.6. Воспроизведение Live Media

Живое мультимедиа указывается содержимым заголовка Media-Properties в ответе SETUP, когда (см. Также раздел 18.29):

Для свойства Random Access (Произвольный доступ) установлено значение «No-Seeking»;
Для свойства Content Modifications (Модификации содержимого) установлено значение «Time-Progressing» (Прогрессирование по времени);
Длительность свойства Retention (Удержание) «Time-Duration» установлена равной 0,0.

Для живого мультимедиа ответ SETUP 200 OK ДОЛЖЕН включать заголовок Media-Range (см. Раздел 18.30).

Клиент МОЖЕТ отправлять запросы PLAY без заголовка Range. Если запрос включает заголовок Range, он ДОЛЖЕН использовать символическое значение, представляющее «now» (сейчас). Для NPT эта спецификация диапазона — «npt = now-». Сервер ДОЛЖЕН включать заголовок Range в ответ, и он ДОЛЖЕН указывать явное значение времени, а не символическое значение. Другими словами, «npt = now-» не может использоваться в ответе. Вместо этого рекомендуется время с начала сеанса, выраженное в виде открытого интервала, например, «npt = 96,23-». МОЖЕТ быть дано абсолютное значение времени (часы) для соответствующего времени, то есть «часы = 20030213T143205Z-». Формат Абсолютного Времени можно использовать только в том случае, если клиент показал его поддержку с помощью заголовка Accept-Ranges.

13.4.7. Воспроизведение вживую с записью

Некоторые медиа-серверы могут предлагать своим клиентам услуги записи живых сеансов. Эта запись обычно происходит с начала медиа-сессии. Клиенты могут осуществлять произвольный доступ к мультимедиа с настоящего момента до начала мультимедийного сеанса. Этот живой носитель с записью указывается содержимым заголовка Media-Properties в ответе SETUP, когда (см. Также раздел 18.29):

для свойства Random Access (Произвольный доступ) установлено значение «Random-Access»;
для свойства Content Modifications (Модификации содержимого) установлено значение «Time-Progressing» (Прогрессирование по времени);
для свойства Retention (Удержание) задано значение Time-Limited или Unlimited.

Ответ SETUP 200 OK ДОЛЖЕН включать заголовок Media-Range (см. Раздел 18.30) для этого типа медиа. Для живых носителей с записью заголовок Range указывает текущую точку доставки на носителе, а заголовок Media-Range указывает текущее доступное окно мультимедиа около текущего времени. Это окно может охватывать записанный контент в прошлом (если смотреть с текущего времени на носителе) или записанный контент в будущем (если смотреть с текущего времени на носителе). Сервер настраивает точку доставки в соответствии с запрошенной границей окна. Если клиент запрашивает точку доставки, которая находится за пределами окна записи, например, если запрошенная точка находится слишком далеко в прошлом, сервер выбирает самую старую точку в записи. Соображения в разделе 13.5.3 применяются, если клиент запрашивает доставку со значениями масштаба (раздел 18.46), отличными от 1,0 (нормальная скорость воспроизведения), во время доставки живого мультимедиа с записью.

13.4.8. Воспроизведение вживую с Time-Shift

Некоторые медиасерверы могут предлагать услуги смены времени своим клиентам. Этот сдвиг по времени записывает фиксированный интервал в прошлом, то есть механизм записи скользящего окна, но не пропускает этот интервал. Клиенты могут получить произвольный доступ к мультимедиа между моментом и интервалом. Этот живой носитель с записью указывается содержимым заголовка Media-Properties в ответе SETUP, когда (см. Также раздел 18.29):

для свойства Random Access (Произвольный доступ) установлено значение «Random-Access»;
для свойства Content Modifications (Модификации содержимого) установлено значение «Time-Progressing» (Прогрессирование по времени);
для свойства Retention (Удержание) задано значение Time-Duration и значение, указывающее интервал записи (> 0).

Ответ SETUP 200 OK ДОЛЖЕН включать заголовок Media-Range (см. Раздел 18.30) для этого типа медиа. Для живых носителей с записью заголовок Range указывает текущее время на носителе, а заголовок Media-Range указывает окно вокруг текущего времени. Это окно может охватывать записанный контент в прошлом (если смотреть с текущего времени на носителе) или записанный контент в будущем (если смотреть с текущего времени на носителе). Сервер устанавливает точку воспроизведения в соответствии с запрошенной границей окна, если клиент запрашивает точку воспроизведения, которая находится за пределами окон записи, например, если запрошен слишком далеко в прошлом, сервер выбирает самый старый диапазон в записи. Соображения в разделе 13.5.3 применяются, если клиент запрашивает доставку с использованием значения шкалы Scale (раздел 18.46), отличного от 1,0 (нормальная скорость воспроизведения), при доставке живого мультимедиа со сдвигом по времени.

13.5. PLAY_NOTIFY

Метод «PLAY_NOTIFY» выдается сервером для информирования клиента об асинхронном событии для сеанса в состоянии воспроизведения. Заголовок сеанса ДОЛЖЕН быть представлен в запросе PLAY_NOTIFY и указывает объем запроса. Для отправки запросов PLAY_NOTIFY требуется постоянное соединение между сервером и клиентом; в противном случае сервер не может отправить этот метод запроса клиенту.

Запросы PLAY_NOTIFY имеют сквозную область (то есть сервер-клиент), поскольку они содержат заголовок сеанса и применяются только к данному сеансу. Клиент ДОЛЖЕН немедленно вернуть ответ серверу.

Запросы PLAY_NOTIFY МОГУТ использовать как совокупный управляющий URI, так и отдельные URI медиаресурса, в зависимости от объема уведомления. Эта область может иметь важные различия для агрегированных сеансов, и каждая причина для запроса PLAY_NOTIFY должна указывать интерпретацию, а также если в запросах могут использоваться агрегированные контрольные URI или отдельные URI.

Запросы PLAY_NOTIFY могут использоваться с телом сообщения в зависимости от значения заголовка Notify-Reason (см. Раздел 18.32). Это описано в отдельном разделе для каждой причины-уведомления, если используется тело сообщения. Однако в настоящее время нет причины-уведомления, позволяющей использовать тело сообщения. В этом случае необходимо соблюдать некоторые ограничения при добавлении новых причин-уведомлений, которые намереваются использовать тело сообщения: сервер может отправлять тело сообщения любого типа, но не гарантируется, что клиент сможет понять тело полученного сообщения. , Это связано с DESCRIBE (см. Раздел 13.2); но в этом конкретном случае клиент может указать свои приемлемые тела сообщений, используя заголовок Accept. В случае PLAY_NOTIFY сервер не знает, какие тела сообщения понятны клиенту.

Заголовок Notify-Reason (см. Раздел 18.32) указывает причину, по которой сервер отправляет запрос PLAY_NOTIFY. Это расширяется, и в будущем могут быть добавлены новые причины (см. Раздел 22.8). Если клиент не понимает причину уведомления, он ДОЛЖЕН ответить кодом ошибки 465 (Причина уведомления неизвестна) (раздел 17.4.29). Этот документ определяет, как серверы могут отправлять PLAY_NOTIFY со значениями Notify-Reason следующих типов:

End-of-Stream (Конец потока) (см. раздел 13.5.1);
Media-Properties-Update (Обновление свойств медиа) (см. раздел 13.5.2);
Scale-Change (Изменение масштаба) (см. раздел 13.5.3).

13.5.1. End-of-Stream (Конец потока)

Запрос PLAY_NOTIFY с заголовком Notify-Reason, установленным в «end-of-stream«, указывает на завершение или близкое завершение запроса PLAY и окончательную доставку медиапотока (-ов). Запрос НЕ ДОЛЖЕН быть выдан, если сервер не находится в состоянии воспроизведения. Конец уведомления о доставке медиапотока может использоваться либо для указания успешного завершения запроса PLAY, который в данный момент обслуживается, либо для указания некоторой ошибки, приводящей к невозможности завершить запрос. Заголовок Request-Status (Состояние запроса) (раздел 18.42) ДОЛЖЕН быть включен, чтобы указывать, для какого запроса предназначено уведомление, и его статус завершения. Коды состояния ответа на сообщение (раздел 8.1.1) используются для указания завершения запроса PLAY. Отправитель PLAY_NOTIFY МОЖЕТ выпустить обновленный PLAY_NOTIFY, в случае PLAY_NOTIFY, отправленного с неверной информацией. Например, PLAY_NOTIFY был выдан до достижения конца потока, но произошла некоторая ошибка, в результате которой ранее отправленный PLAY_NOTIFY содержал неправильное время, когда поток закончится. В этом случае ДОЛЖЕН быть отправлен новый PLAY_NOTIFY, включая правильный статус для завершения и всю дополнительную информацию.

Запросы PLAY_NOTIFY с заголовком Notify-Reason, установленным на «end-of-stream«, ДОЛЖНЫ включать заголовок Range и заголовок Scale, если значение масштаба не равно 1. (Обновление свойств медиа) Заголовок Range указывает точку в потоке или потоках, где доставка заканчивается с временной шкалой, которая была использована сервером в ответе PLAY на выполняемый запрос. Сервер НЕ ДОЛЖЕН использовать константу «now» (сейчас) в заголовке Range; он ДОЛЖЕН использовать фактическую конечную позицию в правильном масштабе времени. Когда уведомления об окончании потока (end-of-stream) выдаются до отправки последних медиа-пакетов, это становится очевидным, потому что время окончания в заголовке Range превышает текущее время в медиа, получаемом клиентом, например, «npt = — 15 «, если npt в настоящее время составляет 14,2 секунды. Заголовок Scale должен быть включен, чтобы было очевидно, перемещается ли шкала времени мультимедиа назад или имеет темп не по умолчанию. Уведомление об окончании потока не препятствует отправке клиентом нового запроса PLAY.

Если RTP используется в качестве транспорта мультимедиа, ДОЛЖЕН быть включен заголовок RTP-Info, и заголовок RTP-Info ДОЛЖЕН указывать последний порядковый номер в параметре «sequence».

Для сеанса RTSP, где медиа-ресурсы находятся под агрегированным контролем, медиа-ресурсы обычно заканчиваются примерно в одно и то же время, хотя могут существовать некоторые небольшие различия в масштабе нескольких сотен миллисекунд. В этих случаях сеанс RTSP под агрегированным управлением ДОЛЖЕН отправить только один запрос PLAY_NOTIFY. Используя совокупный управляющий URI в запросе PLAY_NOTIFY, сервер RTSP указывает, что это применяется ко всем медиаресурсам в течение сеанса. В тех случаях, когда RTP используется для доставки мультимедиа, необходимо включить соответствующую RTP-Info для всех медиаресурсов. В случаях, когда один или несколько медиаресурсов имеют значительно более короткую продолжительность, чем некоторые другие ресурсы в агрегированном сеансе, сервер МОЖЕТ отправлять уведомления об окончании потока, используя отдельные URI медиаресурса, чтобы указать агентам, что для этого больше не будет медиа определенный медиаресурс, связанный с текущим активным запросом PLAY. В таких случаях, когда оставшиеся медиаресурсы приходят в конец потока, они ДОЛЖНЫ отправить запрос PLAY_NOTIFY, используя совокупный управляющий URI, чтобы указать, что больше не осталось ресурсов.

Запрос PLAY_NOTIFY с заголовком «Notify-Reason», установленным в конец потока, НЕ ДОЛЖЕН содержать тело сообщения.

Этот пример запроса уведомляет клиента о будущем событии окончания потока:

S->C: PLAY_NOTIFY rtsp://example.com/fizzle/foo RTSP/2.0 CSeq: 854 Notify-Reason: end-of-stream Request-Status: cseq=853 status=200 reason="OK" Range: npt=-145 RTP-Info:url="rtsp://example.com/fizzle/foo/audio" ssrc=0D12F123:seq=14783;rtptime=2345962545, url="rtsp://example.com/fizzle/video" ssrc=789DAF12:seq=57654;rtptime=2792482193 Session: CDtUJfDQXJWtJ7Iqua2xOi Date: Mon, 08 Mar 2010 13:37:16 GMT

C->S: RTSP/2.0 200 OK CSeq: 854 User-Agent: PhonyClient/1.2 Session: CDtUJfDQXJWtJ7Iqua2xOi

13.5.2. Media-Properties-Update (Обновление свойств медиа)

Запрос PLAY_NOTIFY с заголовком Notify-Reason, установленным в «media-properties-update«, указывает на обновление свойств мультимедиа для данного сеанса (см. Раздел 18.29) или доступного диапазона мультимедиа, который можно воспроизвести, как указано в заголовке Media-Range (раздел 18.30). Запросы PLAY_NOTIFY с заголовком Notify-Reason, установленным в media-properties-update, ДОЛЖНЫ включать заголовок Media-Properties и Date и ДОЛЖНЫ включать заголовок Media-Range. Заголовок Media-Properties имеет область действия сеанса; таким образом, для агрегированных сеансов запрос PLAY_NOTIFY ДОЛЖЕН использовать агрегированный контрольный URI.

Это уведомление ДОЛЖНО быть отправлено для носителей, которые прогрессируют по времени каждый раз, когда происходит событие, которое меняет основу для оценки того, как диапазон доступных для воспроизведения мультимедиа будет изменяться со временем настенных часов. Кроме того, РЕКОМЕНДУЕТСЯ, чтобы сервер отправлял эти уведомления примерно каждые 5 минут для контента с прогрессирующим временем, чтобы обеспечить долгосрочную стабильность оценки клиента и учесть обнаружение отклонения тактового сигнала клиентом. Время между уведомлениями должно быть больше 1 минуты и меньше 2 часов. По причинам, только что объясненным, запросы ДОЛЖНЫ включать заголовок Media-Range для предоставления текущей длительности Media и заголовок Range для указания текущей точки воспроизведения и любых оставшихся частей запрошенного диапазона.

Рекомендация для отправки обновлений каждые 5 минут из-за любых проблем с перекосом часов. Через 5 минут перекос часов не должен стать слишком значительным, поскольку он не используется для воспроизведения и синхронизации мультимедиа, он предназначен только для определения того, какой контент доступен пользователю.

Запрос PLAY_NOTIFY с заголовком Notify-Reason, установленным в «media-properties-update», НЕ ДОЛЖЕН содержать тело сообщения.

S->C: PLAY_NOTIFY rtsp://example.com/fizzle/foo RTSP/2.0 Date: Tue, 14 Apr 2008 15:48:06 GMT CSeq: 854 Notify-Reason: media-properties-update Session: CDtUJfDQXJWtJ7Iqua2xOi Media-Properties: Time-Progressing, Time-Limited=20080415T153919.36Z, Random-Access=5.0 Media-Range: npt=00:00:00-01:37:21.394 Range: npt=01:15:49.873-

C->S: RTSP/2.0 200 OK CSeq: 854 User-Agent: PhonyClient/1.2 Session: CDtUJfDQXJWtJ7Iqua2xOi

13.5.3. Scale-Change (Изменение масштаба)

Сервер может быть вынужден изменить скорость мультимедиа на время воспроизведения, когда клиент запрашивает доставку с использованием значения масштаба (раздел 18.46), отличного от 1,0 (нормальная скорость воспроизведения). Для прогрессирующих во времени носителей с некоторым хранением, то есть сервер хранит уже отправленное содержимое, клиент, запрашивающий воспроизведение со значениями масштаба, большими 1, может догнать внешний интерфейс носителя. В этом случае сервер не сможет продолжать предоставлять контент в масштабе, превышающем 1, поскольку контент доступен только для сервера в масштабе = 1. Другой случай — когда масштаб <1, а срок хранения носителя ограничен по длительности. В этом случае точка доставки может достигать самого старого доступного медиа-блока, и дальнейшее воспроизведение в этом масштабе становится невозможным, так как не будет доступных медиа-файлов. Чтобы клиент не потерял какой-либо носитель, масштаб должен быть настроен на ту же скорость, с которой носитель извлекается из буфера хранения, обычно масштаб = 1,0.

Другой случай, когда сам контент состоит из соединенных частей или динамически обновляется. В этих случаях серверу может потребоваться перейти от одного поддерживаемого значения масштаба (отличного от масштаба = 1,0) к другому. В этом случае сервер выберет ближайшее значение и сообщит клиенту о том, что он выбрал. В этих случаях свойства мультимедиа также будут отправлены с обновлением поддерживаемых значений масштаба. Это позволяет клиенту корректировать используемое значение шкалы (scale).

Чтобы минимизировать влияние на воспроизведение в любом из вышеупомянутых случаев, сервер ДОЛЖЕН изменить свойства воспроизведения, установить масштаб на поддерживаемое значение и продолжить доставку мультимедиа. При выполнении этой модификации он ДОЛЖЕН послать сообщение PLAY_NOTIFY с заголовком Notify-Reason, установленным в «scale-change». Запрос ДОЛЖЕН содержать заголовок Range со временем мультимедиа, когда изменение вступило в силу, заголовок Scale с новым используемым значением, заголовок Session с идентификатором для сеанса, к которому он применяется, и заголовок Date с временем настенного отключения сервера изменения. Для содержимого, изменяющегося во времени, заголовки Media-Range и Media-Properties на данный момент также ДОЛЖНЫ быть включены. Заголовок Media-Properties ДОЛЖЕН быть включен, если изменение масштаба произошло из-за изменения содержимого, какие значения масштаба («Scales») поддерживаются.

Для медиапотоков, доставляемых с использованием RTP, ДОЛЖЕН также быть включен заголовок RTP-Info. Он ДОЛЖЕН содержать параметр «rtptime» со значением, соответствующим точке изменения в этом носителе и, необязательно, порядковый номер.

Запросы PLAY_NOTIFY для агрегированных сеансов ДОЛЖНЫ использовать агрегированный контрольный URI в запросе. Изменение масштаба для любого агрегированного сеанса применяется ко всем медиапотокам, которые являются частью агрегата.

Запрос PLAY_NOTIFY с заголовком Notify-Reason, установленным в «Scale-Change», НЕ ДОЛЖЕН содержать тело сообщения.

S->C: PLAY_NOTIFY rtsp://example.com/fizzle/foo RTSP/2.0 Date: Tue, 14 Apr 2008 15:48:06 GMT CSeq: 854 Notify-Reason: scale-change Session: CDtUJfDQXJWtJ7Iqua2xOi Media-Properties: Time-Progressing, Time-Limited=20080415T153919.36Z, Random-Access=5.0 Media-Range: npt=00:00:00-01:37:21.394 Range: npt=01:37:21.394- Scale: 1 RTP-Info: url="rtsp://example.com/fizzle/foo/audio" ssrc=0D12F123:rtptime=2345962545, url="rtsp://example.com/fizzle/foo/videotrack" ssrc=789DAF12:seq=57654;rtptime=2792482193

C->S: RTSP/2.0 200 OK CSeq: 854 User-Agent: PhonyClient/1.2 Session: CDtUJfDQXJWtJ7Iqua2xOi

13.6. PAUSE — ПАУЗА (Приостановить)

Запрос с методом «PAUSE» приводит к тому, что доставка потока немедленно прерывается (останавливается). Запрос PAUSE ДОЛЖЕН быть выполнен либо с агрегированным управляющим URI для агрегированных сеансов, что приводит к остановке всех носителей, либо с URI мультимедиа для неагрегированных сеансов. На любую попытку приглушить один носитель с помощью запроса PAUSE в агрегированном сеансе ДОЛЖЕН быть дан ответ с ошибкой 460 (Только агрегированная операция разрешена). После возобновления воспроизведения ДОЛЖНА поддерживаться синхронизация треков. Любые ресурсы сервера сохраняются, хотя серверы МОГУТ закрыть сеанс и освободить ресурсы после приостановки на время, указанное в параметре «timeout» заголовка Session в сообщении SETUP.

Пример:

C->S: PAUSE rtsp://example.com/fizzle/foo RTSP/2.0 CSeq: 834 Session: OoOUPyUwt0VeY9fFRHuZ6L User-Agent: PhonyClient/1.2

S->C: RTSP/2.0 200 OK CSeq: 834 Date: Thu, 23 Jan 1997 15:35:06 GMT Session: OoOUPyUwt0VeY9fFRHuZ6L Range: npt=45.76-75.00

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

Точка паузы после любого запроса PAUSE ДОЛЖНА быть возвращена клиенту путем добавления заголовка Range с тем, что остается неиспользованным из диапазона запроса PLAY. Для носителей со свойствами произвольного доступа, если кто-то хочет возобновить воспроизведение ранжированного запроса, он просто включает заголовок Range из ответа PAUSE и включает заголовок Seek-Style с политикой Next в запросе PLAY. Для носителей, которые прогрессируют во времени и имеют длительность хранения = 0, последующий запрос PLAY на повторное начало доставки носителей ДОЛЖЕН использовать «npt = now-», а не ответ, данный в ответе на PAUSE.

C->S: PLAY rtsp://example.com/fizzle/foo RTSP/2.0 CSeq: 834 Session: OccldOFFq23KwjYpAnBbUr Range: npt=10-30 User-Agent: PhonyClient/1.2

S->C: RTSP/2.0 200 OK CSeq: 834 Date: Thu, 23 Jan 1997 15:35:06 GMT Server: PhonyServer/1.0 Range: npt=10-30 Seek-Style: First-Prior RTP-Info:url="rtsp://example.com/fizzle/audiotrack" ssrc=0D12F123:seq=5712;rtptime=934207921, url="rtsp://example.com/fizzle/videotrack" ssrc=4FAD8726:seq=57654;rtptime=2792482193 Session: OccldOFFq23KwjYpAnBbUr

Через 11 секунд, то есть через 21 секунду после презентации:

C->S: PAUSE rtsp://example.com/fizzle/foo RTSP/2.0 CSeq: 835 Session: OccldOFFq23KwjYpAnBbUr User-Agent: PhonyClient/1.2

S->C: RTSP/2.0 200 OK CSeq: 835 Date: 23 Jan 1997 15:35:17 GMT Server: PhonyServer/1.0 Range: npt=21-30 Session: OccldOFFq23KwjYpAnBbUr

Если клиент отправляет запрос PAUSE, а сервер подтверждает и входит в состояние готовности, правильный ответ сервера, если игрок выдает другую PAUSE, все еще остается 200 OK. Ответ 200 OK ДОЛЖЕН включать заголовок Range с текущей точкой паузы. Смотрите примеры ниже:

C->S: PAUSE rtsp://example.com/fizzle/foo RTSP/2.0 CSeq: 834 Session: OccldOFFq23KwjYpAnBbUr User-Agent: PhonyClient/1.2

S->C: RTSP/2.0 200 OK CSeq: 834 Session: OccldOFFq23KwjYpAnBbUr Date: Thu, 23 Jan 1997 15:35:06 GMT Range: npt=45.76-98.36

C->S: PAUSE rtsp://example.com/fizzle/foo RTSP/2.0 CSeq: 835 Session: OccldOFFq23KwjYpAnBbUr User-Agent: PhonyClient/1.2

S->C: RTSP/2.0 200 OK CSeq: 835 Session: OccldOFFq23KwjYpAnBbUr Date: 23 Jan 1997 15:35:07 GMT Range: npt=45.76-98.36

13.7. TEARDOWN — СРЫВАТЬ

13.7.1. Клиент на сервер

Запрос клиента к серверу методом «TEARDOWN» останавливает доставку потока для данного URI, освобождая ресурсы, связанные с ним. Запрос TEARDOWN может быть выполнен как для агрегированного, так и для URI управления мультимедиа. Тем не менее, некоторые ограничения применяются в зависимости от текущего состояния. Запрос TEARDOWN ДОЛЖЕН содержать заголовок Session, указывающий, к какому сеансу применяется запрос. Запрос TEARDOWN НЕ ДОЛЖЕН включать заголовок Terminate-Reason.

TEARDOWN, использующий агрегированный управляющий URI или мультимедийный URI в сеансе под неагрегированным управлением (одиночный мультимедийный сеанс), МОЖЕТ быть выполнен в любом состоянии (Ready and Play). Успешный запрос ДОЛЖЕН привести к немедленной остановке доставки мультимедиа и разрушению состояния сеанса. Это ДОЛЖНО быть указано из-за отсутствия заголовка сеанса в ответе.

TEARDOWN, использующий URI мультимедиа в агрегированном сеансе, может быть выполнен только в состоянии Ready. Такой запрос только удаляет указанный мультимедийный поток и связанные с ним ресурсы из сеанса. Это может привести к возвращению сеанса к неагрегированному элементу управления, поскольку он содержит только один носитель после завершения запроса. Сеанс, который будет существовать после обработки запроса TEARDOWN, ДОЛЖЕН в ответе на этот запрос TEARDOWN содержать заголовок Session.

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

Пример:

C->S: TEARDOWN rtsp://example.com/fizzle/foo RTSP/2.0 CSeq: 892 Session: OccldOFFq23KwjYpAnBbUr User-Agent: PhonyClient/1.2

S->C: RTSP/2.0 200 OK CSeq: 892 Server: PhonyServer/1.0

13.7.2. Сервер к клиенту

Сервер может отправлять запросы TEARDOWN в направлении сервер-клиент, чтобы указать, что сервер был вынужден завершить текущий сеанс. Это может произойти по нескольким причинам, например, обслуживание сервера без доступной резервной копии или то, что сеанс неактивен в течение продолжительных периодов времени. Причина указана в заголовке Terminate-Reason (Прекращение действия) (раздел 18.52).

Когда клиент RTSP поддерживает сеанс RTSP, который в противном случае неактивен в течение продолжительного периода времени, сервер может восстановить ресурсы. Это делается путем выдачи запроса TEARDOWN с установленным значением «Session-Timeout» (Завершение сеанса). Это МОЖЕТ быть сделано, когда клиент был неактивен в сеансе RTSP в течение более одного периода ожидания сеанса (раздел 18.49). Однако серверу НЕ РЕКОМЕНДУЕТСЯ выполнять эту операцию до тех пор, пока не истечет 10-кратный период бездействия, превышающий период ожидания сеанса. Оператор сервера RTSP должен сам настроить, как долго этот длительный период бездействия. При выполнении этой конфигурации оператор должен учитывать, что представляет собой обслуживаемый контент и что это означает для продолжительного периода бездействия.

В случае, если серверу необходимо прекратить предоставление услуг установленным сеансам, и в запросе REDIRECT нет сервера, на который можно было бы указать, тогда TEARDOWN ДОЛЖЕН использоваться для завершения сеанса. Этот метод может также использоваться, когда произошли невосстановимые внутренние ошибки, и у сервера нет другого выбора, кроме как прекратить сеансы.

Запрос TEARDOWN ДОЛЖЕН быть сделан только на URI управления агрегатом сеанса (т. е. ему не разрешено завершать отдельные медиапотоки, если он агрегат сеанса), и он ДОЛЖЕН включать следующие заголовки: Session и Terminate-Reason. Запрос применяется только к сеансу, указанному в заголовке сеанса. Сервер может включать сообщение пользователю клиента с параметром «user-msg».

В качестве альтернативы запрос TEARDOWN может быть выполнен с использованием универсального URI «*» и без заголовка сеанса. Объем такого запроса ограничен следующим переходом (то есть агентом RTSP в прямой связи с сервером) и применяется также к соединению RTSP между агентом RTSP следующего перехода и сервером. Этот запрос указывает, что все сеансы и ожидающие запросы, управляемые через соединение, прекращаются. Любые промежуточные прокси должны делать все следующее в указанном порядке:

ответить на запрос TEARDOWN
отключить канал управления от запрашивающего сервера
передать запрос TEARDOWN каждому подходящему клиенту (обычно это клиенты с активным сеансом или без ответа на запрос)

Примечание. Прокси-сервер отвечает за прием ответов TEARDOWN от своих клиентов; эти ответы НЕ ДОЛЖНЫ передаваться ни на исходный сервер, ни на целевой сервер при перенаправлении.

13.8. GET_PARAMETER

Запрос GET_PARAMETER извлекает значение любого указанного параметра или параметров для презентации (presentation) или потока (stream), указанного в URI. Если заголовок «Session» присутствует в запросе, значение параметра ДОЛЖНО быть получено в указанном контексте сеанса. Есть два способа указания параметров, которые будут получены.

Первый подход включает заголовки, которые были определены как пригодные для этой цели. Заголовки для этой цели должны позволять пустые или лишенные части значения, чтобы избежать необходимости указывать фиктивные данные при указании желания извлечь значение. Успешное завершение запроса также должно быть видно из любых заполненных значений в ответе. Заголовки в этой спецификации, которые МОГУТ использоваться для получения их текущего значения с помощью GET_PARAMETER, перечислены ниже; дополнительные заголовки МОГУТ быть указаны в будущем:

Accept-Ranges
Media-Range
Media-Properties
Range
RTP-Info

Другой способ — указать тело сообщения, в котором перечислены параметры, которые необходимо получить. Заголовок Content-Type (раздел 18.19) используется для указания того, какой формат имеет тело сообщения. Если получатель запроса не поддерживает тип носителя, используемый для тела сообщения, он ДОЛЖЕН ответить, используя код ошибки 415 (Неподдерживаемый тип носителя). Ответчик на запрос GET_PARAMETER ДОЛЖЕН использовать мультимедийный тип запроса для ответа. Дополнительные сведения о согласовании тела сообщения смотри в разделе 9.3.

Агенты RTSP, реализующие поддержку для ответа на запросы GET_PARAMETER, ДОЛЖНЫ реализовывать формат «text/parameters» (текст / параметры) (Приложение F). Это необходимо для обеспечения реализации по меньшей мере одного известного формата для параметров и, таким образом, предотвращения сбоя согласования формата параметров.

Все параметры, указанные в теле сообщения, должны быть понятны агенту-получателю запроса. Если один или несколько параметров не поняты, НЕОБХОДИМО отправить 451 (Непонятный параметр), включая тело, в котором перечислены параметры, которые не были поняты. Если все параметры понятны, их значения заполняются и возвращаются в теле ответного сообщения.

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

Пример:

S->C: GET_PARAMETER rtsp://example.com/fizzle/foo RTSP/2.0 CSeq: 431 User-Agent: PhonyClient/1.2 Session: OccldOFFq23KwjYpAnBbUr Content-Length: 26 Content-Type: text/parameters packets_received jitter

C->S: RTSP/2.0 200 OK CSeq: 431 Session: OccldOFFq23KwjYpAnBbUr Server: PhonyServer/1.1 Date: Mon, 08 Mar 2010 13:43:23 GMT Content-Length: 38 Content-Type: text/parameters packets_received: 10 jitter: 0.3838

13.9. SET_PARAMETER

Метод «SET_PARAMETER» запрашивает установку значения параметра или набора параметров для представления (presentation) или потока (stream), указанного в URI. Если заголовок Session присутствует в запросе, значение параметра ДОЛЖНО быть получено в указанном контексте сеанса. Метод SET_PARAMETER МОЖЕТ также использоваться без тела сообщения. Это РЕКОМЕНДУЕМЫЙ метод, который будет использоваться в запросе, отправленном с единственной целью обновления таймера подтверждения активности. Если этот запрос выполнен успешно, то есть получен ответ 200 OK, таймер поддержания активности обновлен. Любой необязательный заголовок, присутствующий в таком запросе, может или не может быть обработан. Чтобы позволить клиенту определить, был ли обработан какой-либо из таких заголовков, необходимо использовать тег функции и заголовок Require. По этой причине РЕКОМЕНДУЕТСЯ, чтобы любые параметры отправлялись в теле, а не с использованием какого-либо заголовка.

При использовании тела сообщения для перечисления параметров, которые необходимо установить, заголовок Content-Type (раздел 18.19) используется для указания того, какой формат имеет тело сообщения. Если получатель запроса не поддерживает тип носителя, используемый для тела сообщения, он ДОЛЖЕН ответить, используя код ошибки 415 (Неподдерживаемый тип носителя). Дополнительные сведения о согласовании тела сообщения см. в разделе 9.3. Ответчик на запрос SET_PARAMETER ДОЛЖЕН использовать мультимедийный тип запроса для ответа. Дополнительные сведения о согласовании тела сообщения см. в разделе 9.3.

Агенты RTSP, реализующие поддержку для ответа на запросы SET_PARAMETER, ДОЛЖНЫ реализовывать формат «text/parameters» (текст/параметры) (Приложение F). Это должно обеспечить реализацию по меньшей мере одного известного формата для параметров и, таким образом, предотвратить сбой согласования формата параметров.

Запрос РЕКОМЕНДУЕТСЯ содержать только один параметр, позволяющий клиенту определить причину сбоя конкретного запроса. Если запрос содержит несколько параметров, сервер ДОЛЖЕН действовать только по запросу, если все параметры могут быть установлены успешно. Сервер ДОЛЖЕН позволять параметру многократно устанавливать одно и то же значение, но он МОЖЕТ запретить изменение значений параметров. Если получатель запроса не понимает или не может найти параметр, ДОЛЖНА использоваться ошибка 451 (Параметр не понят). Если параметр не может быть изменен, код ошибки — 458 (Параметр доступен только для чтения). Тело ответа ДОЛЖНО содержать только те параметры, в которых есть ошибки. В противном случае тело НЕ ДОЛЖНО быть возвращено. Тело ответа ДОЛЖНО использовать медиа-тип запроса для ответа.

Примечание: транспортные параметры для медиапотока ДОЛЖНЫ быть установлены только с помощью команды SETUP.

Ограничение установки параметров транспорта на SETUP для брандмауэров, подключенных к пограничным прокси RTSP.

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

Пример:

C->S: SET_PARAMETER rtsp://example.com/fizzle/foo RTSP/2.0 CSeq: 421 User-Agent: PhonyClient/1.2 Session: iixT43KLc Date: Mon, 08 Mar 2010 14:45:04 GMT Content-length: 20 Content-type: text/parameters

barparam: barstuff

S->C: RTSP/2.0 451 Parameter Not Understood CSeq: 421 Session: iixT43KLc Server: PhonyServer/1.0 Date: Mon, 08 Mar 2010 14:44:56 GMT Content-length: 20 Content-type: text/parameters

barparam: barstuff

13.10. REDIRECT

Метод REDIRECT выдается сервером для информирования клиента о том, что предоставленная услуга будет прекращена и где вместо нее может быть предоставлена соответствующая услуга. Это может случиться по разным причинам. Один из них заключается в том, что сервер администрируется таким образом, что он должен прекратить предоставлять услуги. Таким образом, клиент должен подключиться к другому местоположению сервера, чтобы получить доступ к ресурсу, указанному в Request-URI.

Запрос REDIRECT ДОЛЖЕН содержать заголовок Terminate-Reason (раздел 18.52) для информирования клиента о причине запроса. Дополнительные параметры, связанные с причиной, также могут быть включены. Цель здесь состоит в том, чтобы позволить администратору сервера выполнить контролируемое отключение сервера RTSP. Это требует достаточного времени для информирования всех объектов, имеющих связанное состояние с сервером, и для того, чтобы они выполнили контролируемую миграцию с этого сервера на резервный сервер.

Запрос REDIRECT с заголовком Session имеет сквозную область (то есть сервер-клиент) и применяется только к данному сеансу. Любые промежуточные прокси НЕ ДОЛЖНЫ отключать канал управления, пока есть другие оставшиеся сквозные сеансы. ТРЕБУЕТСЯ чтобы заголовок Location ДОЛЖЕН был содержать полный абсолютный 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, сервер МОЖЕТ завершить сеанс или транспортное соединение, которое будет перенаправлено запросом. Это защита от ненадлежащего поведения клиентов, которые отказываются отвечать на запрос 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

14. Встроенные (чередующиеся) двоичные данные

Чтобы выполнить определенные требования на стороне сети, например, в сочетании с преобразователями сетевых адресов, которые блокируют трафик RTP по UDP, может потребоваться чередование сообщений RTSP и данных медиапотока. Как правило, такого чередования следует избегать, если в этом нет необходимости, поскольку оно усложняет работу клиента и сервера и накладывает дополнительные накладные расходы. Кроме того, блокировка заголовка строки может вызвать проблемы. Чередующиеся двоичные данные ДОЛЖНЫ использоваться, только если RTSP передается по TCP. Чередующиеся данные не допускаются в сообщениях RTSP.

Потоковые данные, такие как пакеты RTP, инкапсулируются знаком доллара ASCII (десятичное число 36), за которым следуют однооктетный идентификатор канала и длина инкапсулированных двоичных данных в виде двоичного, двухоктетного целого числа без знака в порядке октетов сети (Приложение B of [RFC791 #]). Данные потока следует сразу же после этого, без CRLF, но включая заголовки протокола верхнего уровня. Каждый блок знака доллара ДОЛЖЕН содержать ровно один протокольный блок данных верхнего уровня, например, один пакет RTP.

Обратите внимание, что этот механизм не поддерживает PDU, размер которых превышает 65535 октетов, что соответствует максимальному размеру полезной нагрузки обычных, не больших пакетов IPv4 и IPv6. Если протокол доставки мультимедиа, предназначенный для использования, имеет более крупные PDU, чем это, потребуется определение механизма фрагментации PDU для поддержки встроенных двоичных данных.

Рисунок 1 - Встроенный формат двоичных данных с чередованием — Рисунок 1 — Встроенный формат двоичных данных с чередованием

Идентификатор канала определяется в заголовке транспорта с параметром чередования (раздел 18.54).

Если выбран транспортный протокол RTP, сообщения RTCP также чередуются сервером по TCP-соединению. Использование сообщений RTCP указывается включением интервала, содержащего второй канал, в параметр чередования заголовка транспорта (см. Раздел 18.54). Если используется RTCP, пакеты ДОЛЖНЫ отправляться по первому доступному каналу, который выше, чем канал RTP. Каналы являются двунаправленными, используя один и тот же идентификатор канала в обоих направлениях; поэтому трафик RTCP отправляется по второму каналу в обоих направлениях.

RTCP иногда необходим для синхронизации, когда два или более потока чередуются таким образом. Кроме того, это обеспечивает удобный способ туннелирования пакетов RTP / RTCP через соединение RTSP (TCP или TCP / TLS), когда этого требует конфигурация сети, и по возможности их передача в UDP.

C->S: SETUP rtsp://example.com/bar.file RTSP/2.0 CSeq: 2 Transport: RTP/AVP/TCP;unicast;interleaved=0-1 Accept-Ranges: npt, smpte, clock User-Agent: PhonyClient/1.2

S->C: RTSP/2.0 200 OK CSeq: 2 Date: Thu, 05 Jun 1997 18:57:18 GMT Transport: RTP/AVP/TCP;unicast;interleaved=5-6 Session: OccldOFFq23KwjYpAnBbUr Accept-Ranges: npt Media-Properties: Random-Access=0.2, Immutable, Unlimited

C->S: PLAY rtsp://example.com/bar.file RTSP/2.0 CSeq: 3 Session: OccldOFFq23KwjYpAnBbUr User-Agent: PhonyClient/1.2

S->C: RTSP/2.0 200 OK CSeq: 3 Session: OccldOFFq23KwjYpAnBbUr Date: Thu, 05 Jun 1997 18:57:19 GMT RTP-Info: url="rtsp://example.com/bar.file" ssrc=0D12F123:seq=232433;rtptime=972948234 Range: npt=0-56.8 Seek-Style: RAP

S->C: $005{2 octet length}{"length" octets data, w/RTP header} S->C: $005{2 octet length}{"length" octets data, w/RTP header} S->C: $006{2 octet length}{"length" octets RTCP packet}

15. Прокси

Прокси-серверы RTSP — это агенты RTSP, расположенные между клиентом и сервером. Прокси-сервер может выполнять роли как клиента, так и сервера, в зависимости от того, что он пытается выполнить. Прокси-серверы RTSP используют два соединения транспортного уровня: одно от клиента RTSP к прокси-серверу RTSP и второе от прокси-сервера RTSP к серверу RTSP. Прокси вводятся по нескольким причинам; перечисленные ниже часто объединяются.

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

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

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

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

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

Все типы прокси также могут использоваться при использовании защищенной связи с TLS, поскольку RTSP 2.0 позволяет клиенту утверждать цепочки сертификатов, используемые для установления соединения, из прокси; см. раздел 19.3.2. Однако эта модель доверия может не подходить для всех типов развертывания. В этих случаях защищенные сеансы обходят прокси-серверы.

Прокси доступа НЕ ДОЛЖНЫ использоваться в оборудовании, таком как NAT и брандмауэры, которое, как ожидается, не будет регулярно обслуживаться, например, в домашнем или небольшом офисном оборудовании. В этих случаях лучше использовать процедуры обхода NAT, определенные для RTSP 2.0 [RFC7825 #]. Причиной этих рекомендаций является то, что любые расширения RTSP, приводящие к новым медиатранспортным протоколам или профилям, новым параметрам и т. д., Могут не работать в прокси, который не поддерживается. Это будет препятствовать будущему развитию и использованию RTSP.

15.1. Прокси и протокол расширений

Существование прокси всегда необходимо учитывать при разработке новых расширений RTSP. Большинству типов прокси потребуется реализовать любой новый метод для правильной работы при наличии этого расширения. Новые заголовки могут быть введены и не будут блокироваться старыми прокси. Тем не менее, важно учитывать, должен ли этот заголовок и его функция быть понятными для прокси-сервера или его можно просто переслать. Если необходимо понять заголовок, тег заголовка, представляющий функциональность, ДОЛЖЕН быть включен в заголовок Proxy-Require. Ниже приведены рекомендации по анализу необходимости понимания заголовка. Заголовок транспорта и его параметры являются расширяемыми, что требует правил обработки для прокси-сервера для обеспечения правильной интерпретации.

Нужно ли прокси-серверу понимать заголовок, непросто определить, поскольку он выполняет широкий спектр функций. Оценивая, нужно ли понимать заголовок, можно разделить функциональность на три основные категории:

Модификация носителя (Media modifying): прокси-серверы кэширования и транслятора изменяют фактический носитель и, следовательно, должны также понимать запрос, направленный на сервер, который влияет на способ отображения носителя. Таким образом, этот тип прокси также должен понимать функциональность на стороне сервера.

Модификация транспорта (Transport modifying): и доступ, и прокси-сервер безопасности должны понимать, как осуществляется транспорт мультимедиа, либо для открытия точечных отверстий, либо для перевода внешних заголовков, например, IP и UDP или TCP.

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

Расширение должно быть классифицировано как обязательное для реализации для прокси, если расширение должно быть понято типом прокси «Модификация транспорта».

15.2. Мультиплексирование и демультиплексирование сообщений

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

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

16. Кеширование

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

Получив запрос SETUP или PLAY, прокси-сервер выясняет, имеется ли у него актуальная копия непрерывного медиа-контента и его описание. Он может определить, актуальна ли копия, выполнив запрос SETUP или DESCRIBE соответственно и сравнив заголовок Last-Modified с заголовком кэшированной копии. Если копия не актуальна, она соответствующим образом изменяет транспортные параметры SETUP и перенаправляет запрос на исходный сервер. Последующие управляющие команды, такие как PLAY или PAUSE, затем передают прокси без изменений. Прокси-сервер доставляет клиенту непрерывные мультимедийные данные и, возможно, делает локальную копию для последующего повторного использования. Точное допустимое поведение кэша задается директивами cache-response, описанными в разделе 18.11. Кэш ДОЛЖЕН отвечать на любые запросы DESCRIBE, если он в данный момент обслуживает поток запрашивающей стороне, поскольку возможно, что низкоуровневые подробности описания потока могли измениться на исходном сервере.

Обратите внимание, что кэш RTSP имеет «сквозную» разновидность. Вместо того, чтобы извлекать весь ресурс с исходного сервера, кеш просто копирует потоковые данные, когда они проходят по пути к клиенту. Таким образом, это не вводит дополнительную задержку.

Для клиента прокси-кеш RTSP выглядит как обычный медиа-сервер. Для сервера источника мультимедиа кэш прокси RTSP выглядит как клиент. Так же, как кеш HTTP должен хранить тип контента, язык контента и т. д. Для объектов, которые он кэширует, кеш медиа должен хранить описание презентации. Как правило, кеш исключает все транспортные ссылки (например, многоадресную информацию) из описания презентации, поскольку они не зависят от доставки данных из кеша клиенту. Информация о кодировках остается прежней. Если кэш может преобразовывать кэшированные мультимедийные данные, он создаст новое описание презентации со всеми возможностями кодирования, которые он может предложить.

16.1. Модель проверки

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

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

Затем сервер проверяет этот валидатор по текущему валидатору для запрошенного ресурса и, если они совпадают (см. Раздел 16.1.3), отвечает с помощью специального кода состояния (обычно 304 (не изменено)) и без тела сообщения. В противном случае он возвращает полный ответ (включая текст сообщения). Таким образом, избегая передачи полного ответа, если валидатор совпадает, и избегая дополнительного обхода, если он не совпадает.

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

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

Примечание: ответ, в котором отсутствует валидатор, может все еще кэшироваться и обслуживаться из кэша до истечения срока его действия, если это явно не запрещено директивой кэширования (см. Раздел 18.11). Однако кэш не может выполнить условное извлечение, если у него нет валидатора для ресурса, что означает, что он не будет обновляться после истечения срока его действия.

Медиапотоки, которые адаптируются на основе транспортной емкости между сервером и кешем, усложняют кеширование. Сервер должен учитывать, как он смотрит на кэширование потоков мультимедиа, которые он адаптирует, и, возможно, инструктировать любые кэши не кэшировать такие потоки.

16.1.1. Дата последнего изменения

Значение заголовка Last-Modified (раздел 18.27) часто используется в качестве средства проверки кэша. Проще говоря, запись в кэше считается действительной, если запись в кэше была создана после времени последнего изменения.

16.1.2. Валидаторы кэша тегов тела сообщения

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

Теги тела сообщения описаны в разделе 4.6.

16.1.3. Слабые и сильные валидаторы

Поскольку исходные серверы и кэши будут сравнивать два средства проверки, чтобы определить, представляют ли они одинаковые или разные объекты, обычно можно ожидать, что если тело сообщения (т. е. Описание презентации) или любые связанные заголовки тела сообщения изменятся каким-либо образом, то связанный валидатор также изменится. Если это правда, то этот валидатор является «strong validator» (сильным валидатором). Тело сообщения (то есть описание презентации) или любые связанные заголовки тела сообщения называются объектом для лучшего понимания.

Однако могут быть случаи, когда сервер предпочитает менять валидатор только при семантически значимых изменениях, а не при изменении незначительных аспектов сущности. Валидатор, который не всегда изменяется при изменении ресурса, является «weak validator» (слабым валидатором).

Тэги тела сообщения обычно являются сильными валидаторами, но протокол предоставляет механизм для пометки тега тела сообщения как «слабого». Можно рассматривать сильный валидатор как тот, который изменяется всякий раз, когда изменяются биты объекта, тогда как слабое значение изменяется всякий раз, когда меняется значение объекта. В качестве альтернативы можно рассматривать сильный валидатор как часть идентификатора для конкретной сущности, в то время как слабый валидатор является частью идентификатора для набора семантически эквивалентных сущностей.

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

Время модификации объекта, если оно представлено с разрешением в одну секунду, может быть слабым средством проверки, поскольку вполне возможно, что ресурс может быть изменен дважды в течение одной секунды.

Поддержка слабых валидаторов не является обязательной. Однако слабые валидаторы обеспечивают более эффективное кэширование эквивалентных объектов.

«Использование» валидатора — это либо когда клиент генерирует запрос и включает валидатор в поле заголовка валидации, либо когда сервер сравнивает два валидатора.

Сильные валидаторы можно использовать в любом контексте. Слабые валидаторы можно использовать только в тех контекстах, которые не зависят от точного равенства сущности. Например, любой вид можно использовать для условного описания полного объекта. Однако для поиска в поддиапазоне можно использовать только надежный валидатор, поскольку в противном случае клиент может получить внутренне противоречивую сущность.

Клиенты МОГУТ выдавать запросы DESCRIBE со слабыми или сильными валидаторами. Клиенты НЕ ДОЛЖНЫ использовать слабые валидаторы в других формах запросов.

Единственная функция, которую RTSP определяет для валидаторов, — это сравнение. Существует две функции сравнения валидаторов, в зависимости от того, позволяет ли контекст сравнения использовать слабые валидаторы:

Функция сильного сравнения: чтобы считаться равными, оба валидатора ДОЛЖНЫ быть одинаковыми во всех отношениях, и оба НЕ ДОЛЖНЫ быть слабыми.
Функция слабого сравнения: чтобы считаться равными, оба валидатора ДОЛЖНЫ быть одинаковыми во всех отношениях, но любой из них или оба они МОГУТ быть помечены как «слабые», не влияя на результат.

Тег тела сообщения является сильным, если он явно не помечен как слабый.

Время последнего изменения, когда оно используется в качестве валидатора в запросе, является неявно слабым, если только невозможно сделать вывод, что оно является сильным, используя следующие правила:

Валидатор сравнивается исходным сервером с фактическим текущим валидатором для объекта и,
Этот исходный сервер достоверно знает, что связанный объект не менялся более одного раза в течение секунды, охватываемой представленным средством проверки.

ИЛИ ЖЕ

Валидатор собирается использоваться клиентом в If-Modified-Since, потому что у клиента есть запись в кэше для ассоциированного объекта, и
Эта запись в кэше содержит значение Date, которое указывает время, когда исходный сервер отправил исходный ответ, и
Представленное время последнего изменения не менее чем за 60 секунд до значения даты.

ИЛИ ЖЕ

Валидатор сравнивается промежуточным кэшем с валидатором, сохраненным в его записи кэша для объекта, и
Эта запись в кэше содержит значение Date, которое указывает время, когда исходный сервер отправил исходный ответ, и
Представленное время последнего изменения не менее чем за 60 секунд до значения даты.

Этот метод основан на том факте, что если исходный сервер отправил два разных ответа в течение одной и той же секунды, но оба имели одинаковое время последнего изменения, то хотя бы один из этих ответов будет иметь значение Date, равное его Last-Modified время. Произвольный 60-секундный предел защищает от возможности того, что значения Date и Last-Modified генерируются из разных часов или в несколько разное время при подготовке ответа. Реализация МОЖЕТ использовать значение больше 60 секунд, если считается, что 60 секунд слишком мало.

Если клиент желает выполнить поиск в поддиапазоне для значения, для которого у него есть только время последнего изменения и нет непрозрачного валидатора, он МОЖЕТ делать это только в том случае, если время последнего изменения является сильным в смысле, описанном здесь.

16.1.4. Правила использования тегов тела сообщения и даты последнего изменения

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

Исходные серверы RTSP:

СЛЕДУЕТ отправлять валидатор тега тела сообщения, если его невозможно сгенерировать.
МОЖЕТ отправить слабую метку тела сообщения вместо сильной метки тела сообщения, если соображения производительности поддерживают использование слабых меток тела сообщения или если невозможно отправить сильную метку тела сообщения.
СЛЕДУЕТ отправлять значение Last-Modified, если это возможно, если только риск нарушения семантической прозрачности, который может возникнуть в результате использования этой даты в заголовке If-Modified-Since, не приведет к серьезным проблемам.

Другими словами, предпочтительным поведением для исходного сервера RTSP является отправка как сильного тега тела сообщения, так и значения Last-Modified.

Чтобы быть законным, сильный тег тела сообщения ДОЛЖЕН изменяться всякий раз, когда значение соответствующего объекта изменяется каким-либо образом. Слабый тег тела сообщения ДОЛЖЕН изменяться всякий раз, когда связанный объект изменяется семантически значимым образом.

Примечание: чтобы обеспечить семантически прозрачное кэширование, сервер происхождения ДОЛЖЕН избегать повторного использования определенного значения тега тела сильного сообщения для двух разных объектов или повторного использования определенного значения тега тела слабого сообщения для двух семантически разных объектов. Записи кэша могут сохраняться в течение сколь угодно длительных периодов независимо от времени их истечения, поэтому может быть неуместным ожидать, что кэш никогда больше не будет пытаться проверить запись с использованием средства проверки, полученного в какой-то момент в прошлом.

Клиенты RTSP:

Если исходный сервер предоставил тег тела сообщения, ДОЛЖЕН использовать этот тег тела сообщения в любом условно-кеш-запросе (используя If-Match или If-None-Match).
Если исходный сервер предоставил только значение Last-Modified, СЛЕДУЕТ использовать это значение в условных запросах без поддиапазона кэширования (используя If-Modified-Since).
Если исходный сервер предоставил оба тега тела сообщения и значение Last-Modified, СЛЕДУЕТ использовать оба средства проверки в условных запросах кеша.

Исходный сервер RTSP после получения условного запроса, который включает в себя как дату последнего изменения (например, в заголовке If-Modified-Since), так и один или несколько тегов тела сообщения (например, в If-Match, If-None- Соответствие или поле заголовка If-Range) как валидаторы кэша НЕ ДОЛЖНЫ возвращать статус ответа 304 (не изменен), если это не согласуется со всеми полями условного заголовка в запросе.

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

16.1.5. Не проверяющие условия

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

16.2. Аннулирование после обновлений или удалений

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

RTSP не может гарантировать, что все такие записи кэша помечены как недействительные. Например, запрос, вызвавший изменение на исходном сервере, возможно, не прошел через прокси, где хранится запись в кэше. Однако несколько правил помогают снизить вероятность ошибочного поведения.

В этом разделе фраза «сделать объект недействительным» означает, что кэш либо удалит все экземпляры этого объекта из своего хранилища, либо пометит их как «недействительные» и нуждается в обязательной повторной проверке, прежде чем они могут быть возвращены в ответ на последующий запрос.

Некоторые методы RTSP ДОЛЖНЫ приводить к тому, что кеш делает объект недействительным. Это либо объект, на который ссылается Request-URI, либо заголовки Location или Content-Location (если есть). Эти методы:

DESCRIBE
SETUP

Чтобы предотвратить DoS-атаки, аннулирование на основе URI в заголовке Location или Content-Location ДОЛЖНО выполняться только в том случае, если часть хоста такая же, как в Request-URI.

Кэш, который проходит через запросы методов, которые он не понимает, ДОЛЖЕН сделать недействительными любые объекты, на которые ссылается Request-URI.

17. Определения кода статуса

Где это применимо, коды состояния HTTP (см. Раздел 6 [RFC7231 #]) используются повторно. В Таблице 4 в Разделе 8.1 приведен список того, какие коды состояния могут быть возвращены по каким запросам. Все сообщения об ошибках 4xx и 5xx МОГУТ возвращать тело, содержащее дополнительную информацию об ошибке.

17.1. Информационные 1xx

17.1.1. Код 100 Продолжить

Запрашивающий агент ДОЛЖЕН продолжить свой запрос. Этот промежуточный ответ используется для информирования запрашивающего агента о том, что начальная часть запроса была получена и еще не была отклонена отвечающим агентом. Запрашивающий агент ДОЛЖЕН продолжить, отправив оставшуюся часть запроса или, если запрос уже выполнен, продолжать ждать окончательного ответа (см. Раздел 10.4). Отвечающий агент ДОЛЖЕН отправить окончательный ответ после того, как запрос был выполнен.

17.2. Успешные 2xx

Этот класс кода состояния указывает, что запрос агента был успешно получен, понят и принят.

17.2.1. Код 200 ОК

Запрос успешно выполнен. Информация, возвращаемая с ответом, зависит от метода, используемого в запросе.

17.3. Перенаправления 3xx

Обозначение «3xx» указывает коды ответа от 300 до 399 включительно, предназначенные для перенаправления. ВНИМАНИЕ! Мы используем обозначение «3rr» для обозначения всех кодов 3xx, используемых для перенаправления, то есть, за исключением 304. Здесь появляется код ответа 304, а не код ответа 2xx, который был бы уместен; 304 также используется в RTSP 1.0 [RFC2326 #].

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

3rr код МОЖЕТ быть использован для ответа на любой запрос. Заголовок Location ДОЛЖЕН быть включен в любой ответ 3rr. РЕКОМЕНДУЕТСЯ, чтобы они использовались при необходимости до установления сеанса, то есть в ответ на ОПИСАНИЕ или НАСТРОЙКУ. Однако в тех случаях, когда сервер не может отправить агенту запрос REDIRECT, серверу МОЖЕТ потребоваться использовать ответы 3rr для информирования агента с установленным сеансом о необходимости перенаправления сеанса. Если на запрос в отношении установленного сеанса получен ответ 3rr, агент ДОЛЖЕН отправить запрос TEARDOWN для сеанса и МОЖЕТ восстановить сеанс, используя ресурс, указанный в Location.

Если заголовок Location используется в ответе, он ДОЛЖЕН содержать абсолютный URI, указывающий медиаресурс, на который перенаправлен агент; URI НЕ ДОЛЖЕН содержать только имя хоста.

В случае получения неизвестного кода состояния 3rr агент ДОЛЖЕН вести себя так, как если бы был получен код ответа 302 (Раздел 17.3.3).

17.3.1. Код 300

Код ответа 300 не используется в RTSP 2.0.

17.3.2. Код 301 — Перемещено навсегда

Запрашиваемый ресурс перемещается навсегда и теперь находится по адресу URI, указанному в заголовке Location. Пользовательский агент ДОЛЖЕН автоматически перенаправлять на указанный URI. Этот ответ НЕ ДОЛЖЕН содержать текст сообщения. Заголовок Location ДОЛЖЕН быть включен в ответ.

17.3.3. Код 302 — Найдено

Запрашиваемый ресурс временно находится в URI, указанном в заголовке Location. Этот ответ предназначен для использования во многих типах временных перенаправлений, например, для балансировки нагрузки. РЕКОМЕНДУЕТСЯ, чтобы в этих случаях сервер устанавливал для причины фразу что-то более значимое, чем «Found» (Найдено). Заголовок Location ДОЛЖЕН быть включен в ответ. Пользовательский агент ДОЛЖЕН автоматически перенаправлять на указанный URI. Этот ответ НЕ ДОЛЖЕН содержать текст сообщения.

В этом примере показано, как клиент перенаправляется на другой сервер:

C->S: SETUP rtsp://example.com/fizzle/foo RTSP/2.0 CSeq: 2 Transport: RTP/AVP/TCP;unicast;interleaved=0-1 Accept-Ranges: npt, smpte, clock User-Agent: PhonyClient/1.2

S->C: RTSP/2.0 302 Try Other Server CSeq: 2 Location: rtsp://s2.example.com:8001/fizzle/foo

17.3.4. Код 303 — См. Другое

Этот код состояния НЕ ДОЛЖЕН использоваться в RTSP 2.0. Однако это было разрешено в RTSP 1.0 [RFC2326 #].

17.3.5. Код 304 — Не модифицировано

Если агент выполнил условное ОПИСАНИЕ (метод DESCRIBE) или НАСТРОЙКУ (метод SETUP) (см. Разделы 18.25 и 18.26) и запрошенный ресурс не был изменен, сервер ДОЛЖЕН отправить ответ 304. Этот ответ НЕ ДОЛЖЕН содержать текст сообщения.

Ответ ДОЛЖЕН включать следующие поля заголовка:

«Date»
«MTag» или «Content-Location», если заголовки были бы отправлены в ответе 200 на тот же запрос.
«Expires» и «Cache-Control», если значение поля может отличаться от значения, отправленного в любом предыдущем ответе для того же варианта.

Этот ответ не зависит от запросов DESCRIBE и SETUP. Таким образом, ответ 304 на DESCRIBE НЕ подразумевает, что контент ресурса неизменен (только описание сеанса), а ответ 304 на SETUP НЕ подразумевает, что описание ресурса не изменяется. Таким образом, заголовки «MTag» и «If-Match» (раздел 18.24) могут использоваться для связи DESCRIBE и SETUP.

17.3.6. Код 305 — Использовать прокси

Запрошенные ресурсы ДОЛЖНЫ быть доступны через прокси-сервер, заданный заголовком Location, который ДОЛЖЕН быть включен. Значение поля заголовка Location дает URI прокси. Ожидается, что получатель будет повторять этот единственный запрос через прокси. 305 ответы ДОЛЖНЫ быть сгенерированы только исходными серверами.

17.4. Ошибки клиента 4xx

17.4.1. Код 400 — ошибка неверный запрос

Запрос не может быть понят агентом из-за неправильного синтаксиса. Агент НЕ ДОЛЖЕН повторять запрос без изменений. Если запрос не имеет заголовка CSeq, агент НЕ ДОЛЖЕН включать CSeq в ответ.

17.4.2. Код 401 — Неавторизован

Запрос требует аутентификации пользователя с использованием механизма аутентификации HTTP [RFC7235 #]. Использование кода ошибки определено в [RFC7235 #] и любой применимой схеме аутентификации HTTP, такой как дайджест [RFC7616 #]. Ответ должен включать поле заголовка «WWW-Authenticate» (раздел 18.58), содержащее запрос, применимый к запрашиваемому ресурсу. Агент может повторить запрос с подходящим полем заголовка «Authorization». Если в запрос уже включены учетные данные авторизации, то ответ 401 указывает, что в авторизации было отказано для этих учетных данных. Если ответ 401 содержит ту же проблему, что и предыдущий ответ, и пользовательский агент уже предпринял попытку аутентификации, по крайней мере, один раз, тогда пользователю СЛЕДУЕТ представить тело сообщения, которое было дано в ответе, поскольку это тело сообщения может включать в себя соответствующую диагностическую информацию.

17.4.3. Код 402 — Требуется оплата

Этот код зарезервирован для будущего использования.

17.4.4. Код 403 — Запрещено

Агент понял запрос, но отказывается его выполнить. Авторизация не поможет, и запрос НЕ ДОЛЖЕН повторяться. Если агент желает обнародовать, почему запрос не был выполнен, он ДОЛЖЕН описать причину отказа в теле сообщения. Если агент не желает предоставлять эту информацию агенту, вместо него можно использовать код состояния 404 (не найден).

17.4.5. Код 404 — Не Найдено

Агент не нашел ничего, соответствующего Request-URI. Не указывается, является ли состояние временным или постоянным. Код состояния 410 (Унесенные) СЛЕДУЕТ использовать, если агент через некоторый внутренне конфигурируемый механизм знает, что старый ресурс постоянно недоступен и не имеет адреса пересылки.

Этот код состояния обычно используется, когда агент не желает точно указать, почему запрос был отклонен, или когда другой ответ не применим.

17.4.6. Код 405 — Метод не разрешен

Метод, указанный в запросе, не разрешен для ресурса, идентифицируемого Request-URI. Ответ ДОЛЖЕН включать заголовок Allow, содержащий список допустимых методов для запрошенного ресурса. Этот код состояния также должен использоваться, если запрос пытается использовать метод, не указанный во время SETUP.

17.4.7. Код 406 — Недопустимо

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

Ответ ДОЛЖЕН включать тело сообщения, содержащее список доступных характеристик тела сообщения и местоположений, из которых пользователь или пользовательский агент может выбрать наиболее подходящее. Формат тела сообщения определяется типом носителя, указанным в поле заголовка Content-Type. В зависимости от формата и возможностей пользовательского агента, выбор наиболее подходящего варианта МОЖЕТ выполняться автоматически. Однако эта спецификация не определяет какого-либо стандарта для такого автоматического выбора.

Если ответ может быть неприемлемым, пользовательский агент ДОЛЖЕН временно прекратить получение дополнительных данных и запросить у пользователя решение о дальнейших действиях.

17.4.8. Код 407 — Требуется Прокси-аутентификация

Этот код похож на 401 (Неавторизованный) (Раздел 17.4.2), но он указывает, что клиент должен сначала аутентифицировать себя с прокси. Использование этого кода ошибки определено в [RFC7235 #] и любой применимой схеме аутентификации HTTP, такой как дайджест [RFC7616 #]. Прокси ДОЛЖЕН вернуть поле заголовка Proxy-Authenticate (раздел 18.34), содержащее запрос, применимый к прокси для запрошенного ресурса.

17.4.9. Код 408 — Время ожидания запроса

Агент не представил запрос в течение времени, когда агент был готов ждать. Агент МОЖЕТ повторить запрос без изменений в любое более позднее время.

17.4.10. Код 410 — Ушел

Запрашиваемый ресурс больше не доступен на сервере, а адрес пересылки неизвестен. Ожидается, что это условие будет считаться постоянным. Если сервер не знает или не имеет возможности определить, является ли условие постоянным, СЛЕДУЕТ использовать код состояния 404 (не найден). Этот ответ кешируется, если не указано иное.

Ответ 410 в первую очередь предназначен для содействия задаче обслуживания хранилища, уведомляя получателя о том, что ресурс намеренно недоступен и что владельцы серверов хотят, чтобы удаленные ссылки на этот ресурс были удалены. Такое мероприятие характерно для ограниченных по времени рекламных услуг и для ресурсов, принадлежащих лицам, которые больше не работают на сайте сервера. Нет необходимости отмечать все постоянно недоступные ресурсы как «gone» (пропавшие) или сохранять отметку в течение любого промежутка времени — это оставлено на усмотрение владельца сервера.

17.4.11. Код 412 — Не выполнено предварительное условие

Предварительное условие, заданное в одном или нескольких полях заголовка запроса «if-«, оценивалось как ложное, когда оно тестировалось на агенте. См. Эти разделы для заголовков «if-»: раздел 18.24 If-Match, раздел 18.25 If-Modified-Since и раздел 18.26 If-None-Match. Этот код ответа позволяет агенту помещать предварительные условия в текущую метаинформацию ресурса (данные поля заголовка) и, таким образом, предотвращать применение запрошенного метода к ресурсу, отличному от того, который предполагался.

17.4.12. Код 413 — Слишком большое тело сообщения запроса

Агент отказывается обрабатывать запрос, потому что тело сообщения запроса больше, чем агент желает или может обработать. Агент МОЖЕТ закрыть соединение, чтобы не допустить продолжения запроса запрашивающим агентом.

Если условие является временным, агент ДОЛЖЕН включить поле заголовка Retry-After, чтобы указать, что оно является временным, и по истечении которого запрашивающий агент МОЖЕТ повторить попытку.

17.4.13. Код 414 — URI запроса слишком длинный

Отвечающий агент отказывается обслуживать запрос, потому что Request-URI длиннее, чем агент хочет интерпретировать. Это редкое условие может возникнуть только тогда, когда агент использовал запрос с длинной информацией о запросе, когда агент спустился в «черную дыру» перенаправления URI (например, префикс перенаправленного URI, который указывает на сам суффикс), или когда агент подвергается атаке со стороны агента, пытающегося использовать дыры в безопасности, присутствующие в некоторых агентах, использующих буферы фиксированной длины для чтения или манипулирования Request-URI.

17.4.14. Код 415 — Неподдерживаемый тип носителя

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

17.4.15. Код 451 — Параметр не понят

Получатель запроса не поддерживает один или несколько параметров, содержащихся в запросе. При возврате этого сообщения об ошибке агент ДОЛЖЕН вернуть тело сообщения, содержащее ошибочные параметры.

17.4.16. Код 452 — Неверный идентификатор конференции

Этот код состояния НЕ ДОЛЖЕН использоваться в RTSP 2.0. Однако это было разрешено в RTSP 1.0 [RFC2326 #].

17.4.17. Код 453 — Недостаточно пропускной способности

Запрос был отклонен из-за недостаточной пропускной способности. Это может, например, быть результатом сбоя резервирования ресурса.

17.4.18. Код 454 — Сессия не найдена

Идентификатор сеанса RTSP в заголовке сеанса отсутствует, недопустим или истекло время ожидания.

17.4.19. Код 455 — Метод не действителен в этом состоянии

Агент не может обработать этот запрос в его текущем состоянии. Ответ ДОЛЖЕН содержать заголовок Allow, чтобы сделать возможным исправление ошибок.

17.4.20. Код 456 — Поле заголовка недопустимо для ресурса

Целевой агент не может обработать требуемый заголовок запроса. Например, если запрос методом PLAY содержит поле заголовка Range, но поток не разрешает поиск. Это сообщение об ошибке также можно использовать для указания, когда формат времени в диапазоне невозможен для ресурса. В этом случае ДОЛЖЕН быть возвращен заголовок Accept-Ranges, чтобы сообщить агенту, какие форматы разрешены.

17.4.21. Код 457 — Неверный диапазон

Указанное значение диапазона выходит за границы, например, выходит за пределы конца презентации.

17.4.22. Код 458 — Параметр только для чтения

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

17.4.23. Код 459 — Совокупная операция не разрешена

Запрашиваемый метод не может быть применен к рассматриваемому URI, поскольку он является совокупным (презентационным) URI. Способ может быть применен к медиа-URI.

17.4.24. Код 460 — Разрешена только совокупная операция

Запрашиваемый метод не может быть применен к рассматриваемому URI, поскольку он не является совокупным URI управления (представления). Способ может применяться к совокупному контрольному URI.

17.4.25. Код 461 — Неподдерживаемый транспорт

Поле Transport не содержит поддерживаемую спецификацию транспорта.

17.4.26. Код 462 — Пункт назначения недоступен

Не удалось установить канал передачи данных, поскольку не удалось получить адрес агента. Эта ошибка, скорее всего, будет результатом попытки агента разместить недопустимый параметр dest_addr в поле транспорта.

17.4.27. Код 463 — Пункт назначения запрещен

Канал передачи данных не был установлен, поскольку сервер запретил доступ к адресу агента. Эта ошибка, скорее всего, является результатом попытки агента перенаправить медиа-трафик в другое место назначения с параметром dest_addr в заголовке транспорта.

17.4.28. Код 464 — Транспорт данных еще не готов

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

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

17.4.29. Код 465 — Причина уведомления неизвестна

Это указывает на то, что клиент получил PLAY_NOTIFY (раздел 13.5) с заголовком «Notify-Reason» (раздел 18.32), неизвестным клиенту.

17.4.30. Код 466 — Ошибка управления ключами

Это указывает на то, что произошла ошибка в функции управления ключами, используемой вместе с запросом. Например, использование Multimedia Internet KEYing (MIKEY) [RFC3830 #] в соответствии с Приложением C.1.4.1 может привести к этой ошибке.

17.4.31. Код 470 — Требуется авторизация соединения

Перед попыткой защищенного соединения требуется авторизация пользователя или клиента. Сертификат следующего перехода включен в этот ответ в заголовке Accept-Credentials.

17.4.32. Код 471 — Учетные данные не принимаются

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

17.4.33. Код 472 — Не удалось установить безопасное соединение

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

17.5. Ошибки сервера 5xx

Коды состояния ответа, начинающиеся с цифры «5», указывают на случаи, когда сервер знает, что он допустил ошибку или не может выполнить запрос. Сервер ДОЛЖЕН включать тело сообщения, содержащее объяснение ситуации ошибки и является ли это временным или постоянным условием. Пользовательские агенты ДОЛЖНЫ отображать любое включенное тело сообщения пользователю. Эти коды ответов применимы к любому методу запроса.

17.5.1. Код 500 — Внутренняя ошибка сервера

Агент столкнулся с непредвиденным состоянием, которое не позволило ему выполнить запрос.

17.5.2. Код 501 — Не реализовано

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

17.5.3. Код 502 — Неверный шлюз

Агент, выступая в качестве шлюза или прокси-сервера, получил неверный ответ от вышестоящего агента, к которому он обращался при попытке выполнить запрос.

17.5.4. Код 503 — Сервис недоступен

В настоящее время сервер не может обработать запрос из-за временной перегрузки или обслуживания сервера. Подразумевается, что это временное состояние, которое будет смягчено после некоторой задержки. Если известно, длина задержки МОЖЕТ быть указана в заголовке Retry-After. Если Retry-After не задано, агент ДОЛЖЕН обработать ответ, как это было бы для ответа 500. Агент ДОЛЖЕН учитывать длину, если она указана, в заголовке Retry-After.

Примечание. Наличие кода состояния 503 не означает, что сервер должен использовать его при перегрузке. Некоторые серверы могут просто отказаться от транспортного соединения.

Объем ответа зависит от запроса. Если запрос относился к существующему сеансу RTSP, область ответа перегрузки относится к этому отдельному сеансу RTSP. Если запрос не был специфичным для сеанса или предназначался для формирования сеанса RTSP, он применяется к серверу RTSP, идентифицированному именем хоста в Request-URI.

17.5.5. Код 504 — Ошибка — Время ответа сервера истекло

Агент, действуя как прокси-сервер, не получил своевременный ответ от вышестоящего агента, указанного URI, или какого-либо другого вспомогательного сервера (например, DNS), к которому ему нужно было получить доступ при попытке выполнить запрос.

17.5.6. Код 505 — Версия RTSP не поддерживается

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

17.5.7. Код 551 — Опция не поддерживается

Тег функции, указанный в полях Require или Proxy-Require, не поддерживается. НЕОБХОДИМЫЙ заголовок ДОЛЖЕН быть возвращен с указанием функции, для которой нет поддержки.

17.5.8. Код 553 — Прокси недоступен

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

Примечание. Наличие кода состояния 553 не означает, что прокси-сервер должен использовать его при перегрузке. Некоторые прокси могут просто отказаться от подключения.

Объем ответа зависит от запроса. Если запрос относился к существующему сеансу RTSP, область ответа перегрузки относится к этому отдельному сеансу RTSP. Если запрос не относится к конкретной сессии или предназначен для формирования сеанса RTSP, он применяется ко всем таким запросам к этому прокси.

18. Определения полей заголовка

Метод (method)	Направление (direction)	Объект, цель (object)	Акроним (acronym)	Тело (Body)
DESCRIBE	C -> S	P,S	DES	r
GET_PARAMETER	C -> S, S -> C	P,S	GPR	R,r
OPTIONS	C -> S, S -> C	P,S	OPT
PAUSE	C -> S	P,S	PSE
PLAY	C -> S	P,S	PLY
PLAY_NOTIFY	S -> C	P,S	PNY	R
REDIRECT	S -> C	P,S	RDR
SETUP	C -> S	S	STP
SET_PARAMETER	C -> S, S -> C	P,S	SPR	R,r
TEARDOWN	C -> S	P,S	TRD
	S -> C	P	TRD

Таблица 8 — Обзор методов RTSP

Эта таблица представляет собой обзор методов RTSP, их направления и того, над какими объектами (P: представление, S: поток) они работают. «Тело» обозначает, разрешено ли методу переносить тело и в каком направлении; R = запрос, r = ответ. Примечание. Все сообщения об ошибках для состояний 4xx и 5xx могут содержать тело.

Общий синтаксис для полей заголовка описан в разделе 5.2. В этом разделе перечислены полный набор полей заголовка, а также примечания о значении и использовании. Определения синтаксиса для полей заголовка представлены в разделе 20.2.3. Приведены примеры каждого поля заголовка.

Информация о полях заголовка в отношении методов и обработки прокси представлена на рисунке 2, рисунке 3, рисунке 4 и рисунке 5.

Столбец «where» (где) описывает типы запросов и ответов, в которых может использоваться поле заголовка. Значения в этом столбце:

R: поле заголовка может появляться только в запросах;
r: поле заголовка может появляться только в ответах;
2xx, 4xx и т.д .: числовое значение или диапазон указывает коды ответов, с которыми может использоваться поле заголовка;
с: копируется из запроса в ответ.
G: поле заголовка является общим заголовком и может присутствовать как в запросах, так и в ответах.

Примечание. Общие заголовки не всегда используют значение «G» в столбце «where» (где). Это связано с различиями, когда заголовок может применяться в запросах по сравнению с ответами. Когда такие различия существуют, они выражаются в двух разных строках: один с «where» (где), означающим «R», и один с «R».

Столбец «прокси» описывает операции, которые прокси может выполнять над полем заголовка. Пустой столбец прокси указывает, что прокси НЕ ДОЛЖЕН вносить какие-либо изменения в этот заголовок, все разрешенные операции указаны явно:

a: Прокси может добавить или объединить поле заголовка, если оно отсутствует.
m: прокси может изменить существующее значение поля заголовка.
d: прокси может удалить значение поля заголовка.
r: прокси должен уметь читать поле заголовка; таким образом, это поле заголовка не может быть зашифровано.

Остальные столбцы относятся к наличию поля заголовка в методе. Названия методов, сокращенно, соответствуют Таблице 8:

с: условный; Требования к полю заголовка зависят от контекста сообщения.
m: поле заголовка является обязательным.
m*: поле заголовка ДОЛЖНО быть отправлено, но агенты должны быть готовы получать сообщения без этого поля заголовка.
o: поле заголовка не является обязательным.
*: Поле заголовка ДОЛЖНО присутствовать, если тело сообщения не пустое. Подробности смотрите в разделах 18.17, 18.19 и 5.3.
—: поле заголовка не применимо.

«Необязательно» означает, что агент МОЖЕТ включить поле заголовка в запрос или ответ. Поведение агента при получении таких заголовков варьируется; для некоторых он может игнорировать поле заголовка. В других случаях это запрос на обработку заголовка. Это регулируется методом и описанием заголовка. Примерами заголовков, которые требуют обработки, являются поля заголовков Require и Proxy-Require, обсуждаемые в разделах 18.43 и 18.37. «Обязательное» поле заголовка ДОЛЖНО присутствовать в запросе, и оно ДОЛЖНО быть понято агентом, принимающим запрос. Обязательное поле заголовка ответа ДОЛЖНО присутствовать в ответе, а поле заголовка ДОЛЖНО быть понято при обработке ответа. «Не применимо» означает, что поле заголовка НЕ ДОЛЖНО присутствовать в запросе. Если он помещен в запрос по ошибке, он ДОЛЖЕН игнорироваться агентом, получившим запрос. Аналогично, поле заголовка, помеченное как «неприменимо» для ответа, означает, что агент НЕ ДОЛЖЕН помещать поле заголовка в ответ, и агент ДОЛЖЕН игнорировать поле заголовка в ответе.

Агент RTSP ДОЛЖЕН игнорировать непонятные заголовки расширений.

Поля заголовка From и Location содержат URI. Если URI содержит запятую (‘) или точку с запятой (;), URI ДОЛЖЕН быть заключен в двойные кавычки («). Любые параметры URI содержатся в этих кавычках. Если URI не заключен в двойные кавычки, любые параметры, разделенные точкой с запятой параметры заголовка, а не параметры URI.

Рисунок 2 - Обзор полей заголовка RTSP (A-L), относящихся к методам DESCRIBE, OPTIONS, SETUP, PLAY, PAUSE и TEARDOWN — Рисунок 2 — Обзор полей заголовка RTSP (A-L), относящихся к методам DESCRIBE, OPTIONS, SETUP, PLAY, PAUSE и TEARDOWN

Рисунок 3 - Обзор полей заголовка RTSP (M-W), относящихся к методам DESCRIBE, OPTIONS, SETUP, PLAY, PAUSE и TEARDOWN — Рисунок 3 — Обзор полей заголовка RTSP (M-W), относящихся к методам DESCRIBE, OPTIONS, SETUP, PLAY, PAUSE и TEARDOWN

Рисунок 4 - Обзор полей заголовка RTSP (A-L), связанных с методами GET_PARAMETER, SET_PARAMETER, REDIRECT и PLAY_NOTIFY — Рисунок 4 — Обзор полей заголовка RTSP (A-L), связанных с методами GET_PARAMETER, SET_PARAMETER, REDIRECT и PLAY_NOTIFY

Рисунок 5 - Обзор полей заголовка RTSP (M-W), связанных с методами GET_PARAMETER, SET_PARAMETER, REDIRECT и PLAY_NOTIFY — Рисунок 5 — Обзор полей заголовка RTSP (M-W), связанных с методами GET_PARAMETER, SET_PARAMETER, REDIRECT и PLAY_NOTIFY

18.1. Accept (Приём)

Поле заголовка запроса «Accept» может использоваться для указания определенного описания презентации и типов медиа-параметров [RFC6838 #], которые являются приемлемыми для ответа на запрос метода DESCRIBE.

См. Раздел 20.2.3 для синтаксиса.

Символ звездочки «*» используется для группировки типов мультимедиа по диапазонам, где «* / *» обозначает все типы мультимедиа, а «type/*» обозначает все подтипы этого типа. Диапазон МОЖЕТ включать параметры типа носителя, которые обычно применимы к этому диапазону.

За каждым типом носителя или диапазоном МОЖЕТ следовать одна или несколько принимаемых параметров, начиная с параметра «q», чтобы указать относительный коэффициент качества. Первый параметр «q» (если есть) отделяет тип носителя или параметры диапазона от параметров «accept-params«. Коэффициенты качества позволяют пользователю или пользовательскому агенту указывать относительную степень предпочтения для этого типа носителя с использованием шкалы «qvalue» от 0 до 1 (раздел 5.3.1 [RFC7231 #]). Значением по умолчанию является q = 1.

Пример использования:

Accept: application/example ;q=0.7, application/sdp

Указывает, что запрашивающий агент предпочитает тип носителя «application/sdp» через рейтинг по умолчанию 1.0, но также принимает тип носителя «application/example» с рейтингом качества 0.7.

Если поле заголовка Accept отсутствует, предполагается, что клиент принимает все типы мультимедиа. Если присутствует поле заголовка Accept, и если сервер не может отправить ответ, который является приемлемым согласно комбинированному значению поля Accept, то сервер ДОЛЖЕН отправить ответ 406 (Не приемлемо).

18.2. Accept-Credentials

Поле заголовка запроса «Accept-Credentials» — это заголовок запроса, используемый для указания любому доверенному посреднику, как обрабатывать дополнительные защищенные соединения с прокси-серверами или серверами. Он НЕ ДОЛЖЕН включаться в запросы от сервера к клиенту. См. Раздел 19 для использования этого заголовка.

В запросе заголовок ДОЛЖЕН содержать метод (Пользователь, Прокси или Любой) для утверждения учетных данных, выбранных запрашивающей стороной. Метод НЕ ДОЛЖЕН быть изменен каким-либо прокси, если только он не является «Proxy» (Прокси), когда прокси МОЖЕТ изменить его на «user» (пользователь), чтобы взять на себя роль пользователя, одобряющего каждый последующий переход. Если метод «User» (Пользователь), заголовок содержит ноль или более учетных данных, которые принимает клиент. Заголовок может содержать нулевые учетные данные в первом запросе RTSP к серверу RTSP через прокси-сервер при использовании метода «User» (Пользователь). Это связано с тем, что клиент еще не получил никаких учетных данных для принятия. Каждое удостоверение ДОЛЖНО состоять из одного URI, идентифицирующего прокси-сервер или сервер, идентификатора алгоритма хеширования и хэша сертификата ASN.1 DER-encoded [RFC5280 #] этого агента в Base64, в соответствии с разделом 4 [RFC4648 #] и места установки битов заполнения в ноль. Все клиенты и прокси-серверы RTSP ДОЛЖНЫ реализовывать алгоритм SHA-256 [FIPS180-4] для вычисления хэша DER-кодированного сертификата. Алгоритм SHA-256 идентифицируется токеном «sha-256».

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

Пример:

Accept-Credentials:User "rtsps://proxy2.example.com/";sha-256;exaIl9VMbQMOFGClx5rXnPJKVNI=, "rtsps://server.example.com/";sha-256;lurbjj5khhB0NhIuOXtt4bBRH1M=

18.3. Accept-Encoding

Поле заголовка запроса «Accept-Encoding» аналогично полю «Accept», но оно ограничивает кодировки содержимого (см. Раздел 18.15), то есть кодировки преобразования тела сообщения, такие как сжатие gzip, которые являются приемлемыми в ответе.

Сервер проверяет, является ли кодирование контента приемлемым, в соответствии с полем Accept-Encoding, используя следующие правила:

Если кодирование контента является одним из кодировок контента, перечисленных в поле Accept-Encoding, то оно допустимо, если только оно не сопровождается значением «q«, равным 0. (Как определено в разделе 5.3.1 [RFC7231 #], q-значение 0 означает «не приемлемо».)
Специальный символ звёздочки «*» в поле Accept-Encoding соответствует любому доступному кодированию содержимого, явно не указанному в поле заголовка.
Если допустимы множественные кодировки контента, то предпочтительным является приемлемое кодирование контента с наибольшим ненулевым qvalue.
«Identity» (Идентификационное) контентное кодирование всегда допустимо, т. е. вообще не допускается преобразование, если только специально не отказано, потому что поле Accept-Encoding включает в себя «identity; q=0» или потому что поле включает «*;q=0» и явно не включает «идентификацию» контент-кодирования. Если значение поля Accept-Encoding пусто, то допустима только кодировка «identity».

Если в запросе присутствует поле Accept-Encoding, и если сервер не может отправить ответ, который является приемлемым в соответствии с заголовком Accept-Encoding, то сервер ДОЛЖЕН отправить ответ об ошибке с кодом состояния 406 (Not Acceptable).

Если в запросе нет поля Accept-Encoding, сервер МОЖЕТ предположить, что клиент примет любое кодирование содержимого. В этом случае, если «идентичность» является одной из доступных кодировок контента, то сервер ДОЛЖЕН использовать кодирование контента «идентичности», если только он не имеет дополнительной информации о том, что другое кодирование контента имеет смысл для клиента.

18.4. Accept-Language

Поле заголовка запроса «Accept-Language» аналогично Accept, но ограничивает набор естественных языков, предпочитаемых в качестве ответа на запрос. Обратите внимание, что указанный язык применяется к описанию презентации (тексту ответного сообщения) и любым фразам причины, но не к медиа-контенту.

Языковой тег идентифицирует естественный язык, на котором говорят, пишут или иным образом передают люди для передачи информации другим людям. Компьютерные языки явно исключены. Синтаксис и реестр языковых тегов RTSP 2.0 такие же, как те, которые определены в [RFC5646 #].

Каждому языковому диапазону МОЖЕТ быть присвоено соответствующее значение качества, которое представляет собой оценку предпочтения пользователя для языков, указанных в этом диапазоне. Значение качества по умолчанию равно «q=1». Например:

Accept-Language: da, en-gb;q=0.8, en;q=0.7

будет означать: «Я предпочитаю датский, но приму британский английский и другие типы английского». Языковой диапазон соответствует языковому тегу, если он точно равен полному тегу или если он точно равен префиксу тега, то есть первичному тегу в ABNF, так что символ, следующий за первичным тегом, равен «-». Специальный диапазон «*», если он присутствует в поле Accept-Language, соответствует каждому тегу, который не соответствует ни одному другому диапазону, присутствующему в поле Accept-Language.

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

В процессе выбора языка каждому языковому тегу присваивается квалификационный фактор, т. е. если язык, поддерживаемый клиентом, фактически поддерживается сервером и какой уровень «preference» (предпочтения) достигается языком. Значение качества (q-значение) самого длинного языкового диапазона в поле, которое соответствует языковому тегу, назначается в качестве квалификационного фактора для конкретного языкового тега. Если ни один диапазон языков в поле не соответствует тегу, назначенный языковой квалификационный коэффициент равен 0. Если в запросе отсутствует заголовок Accept-Language, сервер ДОЛЖЕН предположить, что все языки одинаково приемлемы. Если присутствует заголовок Accept-Language, то все языки, которым присвоен квалификационный коэффициент больше 0, являются приемлемыми.

18.5. Accept-Ranges

Поле общего заголовка Accept-Ranges позволяет указать формат, поддерживаемый в заголовке Range. Клиент ДОЛЖЕН включать заголовок в запросы SETUP, чтобы указать, какие форматы являются приемлемыми при получении в ответах PLAY и PAUSE и запросах REDIRECT. Сервер ДОЛЖЕН включать заголовок в ответы SETUP и 456 (поле заголовка недействительно для ресурса), чтобы указать форматы, поддерживаемые для ресурса, указанного в Request-URI. Заголовок МОЖЕТ быть включен в пары запроса и ответа GET_PARAMETER. Запрос GET_PARAMETER ДОЛЖЕН содержать заголовок сеанса, чтобы идентифицировать контекст сеанса, с которым связан запрос. Запросчик и ответчик будут указывать свои возможности относительно форматов диапазона соответственно.

Accept-Ranges: npt, smpte, clock

Синтаксис определен в разделе 20.2.3.

18.6. Allow (Разрешать)

В поле заголовка тела сообщения «Allow» перечислены методы, поддерживаемые ресурсом, идентифицированным Request-URI. Цель этого поля — сообщить получателю полный набор допустимых методов, связанных с ресурсом. Поле заголовка Allow ДОЛЖНО присутствовать в ответе 405 (метод не разрешен). Заголовок Allow ДОЛЖЕН также присутствовать во всех ответах OPTIONS, где содержимое заголовка не будет включать в себя точно такие же методы, которые перечислены в заголовке Public.

Заголовок тела сообщения Allow ДОЛЖЕН также быть включен в ответы методов SETUP и DESCRIBE, если методы, разрешенные для ресурса, отличаются от полного набора методов, определенных в этом примечании.

Пример использования:

Allow: SETUP, PLAY, SET_PARAMETER, DESCRIBE

18.7. Authentication-Info

Заголовок ответа «Authentication-Info» используется сервером для передачи некоторой информации об успешной аутентификации HTTP [RFC7235 #] в ответном сообщении. Определение заголовка содержится в [RFC7615 #], и любые применимые схемы аутентификации HTTP появляются в других RFC, таких как Digest [RFC7616 #]. Этот заголовок ДОЛЖЕН использоваться только в ответных сообщениях, связанных с запросами от клиента к серверу.

18.8. Authorization (Авторизация)

Клиент RTSP, который желает аутентифицировать себя на сервере, используя механизм аутентификации из HTTP [RFC7235 #], обычно (но не обязательно) после получения ответа 401, делает это путем включения поля заголовка запроса «Authorization» в запрос. Значение поля Authorization состоит из учетных данных, содержащих информацию об аутентификации агента пользователя для области запрашиваемого ресурса. Определение заголовка содержится в [RFC7235 #], и любые применимые схемы аутентификации HTTP появляются в других RFC, таких как Digest [RFC7616 #] и Basic [RFC7617 #]. Этот заголовок ДОЛЖЕН использоваться только в клиент-серверных запросах.

Если запрос аутентифицирован и определена область, те же учетные данные ДОЛЖНЫ быть действительными для всех других запросов в этой области (при условии, что сама схема аутентификации не требует иного, например, учетные данные, которые варьируются в зависимости от значения запроса или с использованием синхронизированных часов) , Каждый запрос клиент-сервер ДОЛЖЕН быть индивидуально авторизован путем включения заголовка Authorization с информацией.

Когда общий кэш (см. Раздел 16) получает запрос, содержащий поле Authorization, он НЕ ДОЛЖЕН возвращать соответствующий ответ в качестве ответа на любой другой запрос, если не выполнено одно из следующих конкретных исключений:

Если ответ включает в себя директиву кэша «max-age», кеш МОЖЕТ использовать этот ответ при ответе на последующий запрос. Но (если указанный максимальный возраст прошел), кеш-прокси ДОЛЖЕН сначала подтвердить его подлинность на исходном сервере, используя заголовки запроса из нового запроса, чтобы разрешить исходному серверу аутентифицировать новый запрос. (Это определенное поведение для max-age.) Если ответ включает в себя «max-age = 0», прокси-сервер ДОЛЖЕН всегда проверять его правильность перед повторным использованием.
Если ответ содержит директиву управления кэшем «must-revalidate», кеш МОЖЕТ использовать этот ответ при ответе на последующий запрос. Но если ответ устарел, все кэши ДОЛЖНЫ сначала подтвердить его на исходном сервере, используя заголовки запроса из нового запроса, чтобы разрешить исходному серверу аутентифицировать новый запрос.
Если ответ содержит директиву кеша «public», он МОЖЕТ быть возвращен в ответ на любой последующий запрос.

18.9. Bandwidth (Пропускная способность)

Поле заголовка запроса «Bandwidth» описывает предполагаемую полосу пропускания, доступную клиенту, выраженную в виде положительного целого числа и измеряемую в килобитах в секунду. Доступная для клиента полоса пропускания может изменяться во время сеанса RTSP, например, из-за мобильности, перегрузки и т. д.

Клиенты могут быть не в состоянии точно определить доступную пропускную способность, например, потому что первый переход не является узким местом. В этом случае локальная сеть (ЛВС) не является узким местом, а линия доступа к Интернету в ЛВС, если сервер находится не в той же ЛВС. Таким образом, скорости соединения сетей WLAN или Ethernet обычно не являются основой для оценки доступной полосы пропускания. Сотовые устройства или другие устройства, напрямую подключенные к модему или устройству, обеспечивающему подключение, могут более точно оценить пропускную способность узкого места и ее разумную долю для среды, контролируемой RTSP. Клиент также должен будет учитывать другой трафик, разделяющий узкое место. Например, путем назначения только определенной доли RTSP и его медиапотокам. РЕКОМЕНДУЕТСЯ, чтобы этот заголовок использовали только клиенты, которые имеют точную и явную информацию о узких местах пропускной способности.

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

Пример:

Bandwidth: 62360

18.10. Blocksize (Размер блока)

Поле заголовка запроса «Blocksize» отправляется от клиента на медиа-сервер, запрашивая у сервера определенный размер медиа-пакета. Этот размер пакета не включает заголовки нижнего уровня, такие как IP, UDP или RTP. Сервер может свободно использовать размер блока ниже запрашиваемого. Сервер МОЖЕТ усечь этот размер пакета до ближайшего кратного минимального размера блока, специфичного для медиа, или при необходимости переопределить его размером, специфичным для медиа. Размер блока ДОЛЖЕН быть положительным десятичным числом, измеренным в октетах. Сервер возвращает ошибку (4xx) только в том случае, если значение синтаксически неверно.

18.11. Cache-Control

Поле общего заголовка «Cache-Control» используется для указания директив, которым ДОЛЖНЫ подчиняться все механизмы кэширования в цепочке запросов / ответов.

Директивы кэша ДОЛЖНЫ передаваться через приложение-посредник или шлюз, независимо от их значения для этого приложения, поскольку директивы могут быть применимы ко всем получателям в цепочке запросов / ответов. Невозможно указать кэшированную директиву для конкретного кэша.

Cache-Control следует указывать только в запросе DESCRIBE, GET_PARAMETER, SET_PARAMETER и SETUP и его ответе. Примечание. Cache-Control не управляет только кэшированием ответов для сообщений RTSP, но также применяется к потоку мультимедиа, указанному в запросе SETUP. Запросы RTSP обычно не кэшируются; дополнительную информацию см. в разделе 16. Ниже приведены описания директив кэша, которые могут быть включены в заголовок Cache-Control.

no-cache: указывает на то, что медиапоток или ответ RTSP НЕ ДОЛЖНЫ кэшироваться где-либо. Это позволяет исходному серверу предотвращать кэширование даже с помощью кэшей, которые были настроены для возврата устаревших ответов на клиентские запросы. Примечание: нет функции безопасности, предотвращающей кеширование контента.

public: указывает на то, что медиапоток или ответ RTSP кэшируется любым кешем.

private: указывает, что медиапоток или ответ RTSP предназначен для одного пользователя и НЕ ДОЛЖЕН кэшироваться общим кешем. Частный (не общий) кэш может кэшировать медиапотоки.

no-transform: промежуточный кеш (прокси) может оказаться полезным для преобразования типа мультимедиа определенного потока. Прокси-сервер может, например, преобразовывать видеоформаты для экономии места в кеше или уменьшения объема трафика на медленном канале. Однако могут возникнуть серьезные эксплуатационные проблемы, когда эти преобразования были применены к потокам, предназначенным для определенных видов приложений. Например, приложения для медицинской визуализации, анализа научных данных и те, которые используют сквозную аутентификацию, все зависят от приема потока, который бит за битом идентичен исходному потоку мультимедиа или ответу RTSP. Следовательно, если ответ включает в себя директиву без преобразования, промежуточный кеш или прокси НЕ ДОЛЖЕН изменять кодировку потока или ответа. В отличие от HTTP, RTSP не обеспечивает частичное преобразование на этом этапе, например, позволяет переводить на другой язык.

only-if-cached: в некоторых случаях, например, во время крайне плохого сетевого соединения, клиент может захотеть, чтобы кеш возвращал только те потоки мультимедиа или ответы RTSP, которые он в данный момент сохранил, и не получал их от исходного сервера. Для этого клиент может включить в запрос директиву only-if-cached. Если кэш получает эту директиву, он ДОЛЖЕН либо ответить с использованием кэшированного медиа-потока, либо ответа, который согласуется с другими ограничениями запроса, или ответить с состоянием 504 (время ожидания шлюза). Однако, если группа кэшей работает как единая система с хорошей внутренней связью, такой запрос МОЖЕТ быть перенаправлен в эту группу кэшей.

max-stale: указывает, что клиент готов принять поток мультимедиа или ответ RTSP, срок действия которого истек. Если max-stale назначено значение, то клиент готов принять ответ, срок действия которого истек не более чем на указанное количество секунд. Если значение max-stale не назначено, тогда клиент готов принять устаревший ответ любого возраста.

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

must-revalidate: когда директива must-revalidate присутствует в ответе SETUP, полученном кешем, этот кеш НЕ ДОЛЖЕН использовать запись в кеш после того, как она устареет, чтобы ответить на последующий запрос, не проверив ее сначала с помощью исходного сервера. Таким образом, кэш требуется выполнять сквозную повторную проверку каждый раз, если, основываясь только на Expires исходного сервера, кэшированный ответ устарел.

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

max-age: когда промежуточный кеш с помощью директивы maxage = 0 вынужден повторно проверять свою собственную запись в кеше, и клиент предоставил свой собственный валидатор в запросе, предоставленный валидатор может отличаться от валидатора, который в настоящее время хранится в записе в кеше. В этом случае кеш МОЖЕТ использовать любой валидатор при создании собственного запроса, не влияя на семантическую прозрачность. Однако выбор валидатора может повлиять на производительность. Наилучшим подходом для промежуточного кэша является использование собственного валидатора при выполнении запроса. Если сервер отвечает 304 (не изменено), то кэш может вернуть клиенту свою теперь проверенную копию с ответом 200 (ОК). Однако если сервер отвечает новым телом сообщения и средством проверки кэша, промежуточный кеш может сравнить возвращенный валидатор с предоставленным в запросе клиента с использованием функции строгого сравнения. Если валидатор клиента равен серверу источника, то промежуточный кеш просто возвращает 304 (не изменено). В противном случае он возвращает новое тело сообщения с ответом 200 (ОК).

18.12. Connection (Соединение)

Поле общего заголовка «Connection» позволяет отправителю указать параметры, которые требуются для данного конкретного соединения. Он НЕ ДОЛЖЕН передаваться через прокси через дальнейшие соединения.

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

Заголовки сообщений, перечисленные в заголовке Connection, НЕ ДОЛЖНЫ включать сквозные заголовки, такие как Cache-Control.

RTSP 2.0 определяет опцию «close» (закрыть) соединения для отправителя, чтобы сообщить, что соединение будет закрыто после завершения ответа. Например, «Connection: close in either the request or the response-header fields» (Соединение: закрыть в полях заголовка или запроса) указывает, что соединение НЕ ДОЛЖНО рассматриваться как «persistent» (постоянное) (раздел 10.2) после завершения текущего запроса / ответа.

Использование опции соединения «close» (закрыть) в сообщениях RTSP ДОЛЖНО быть ограничено сообщениями об ошибках, когда сервер не может восстановиться и поэтому считает необходимым закрыть соединение. Причина в том, что у клиента есть возможность продолжать использовать соединение в течение неопределенного времени, пока оно отправляет действительные сообщения.

18.13. Connection-Credentials

Заголовок ответа «Connection-Credentials» используется для переноса цепочки учетных данных для любого следующего прыжка, который должен быть утвержден запрашивающей стороной. Он ДОЛЖЕН использоваться только в ответах сервер-клиент.

Заголовок Connection-Credentials в ответе RTSP ДОЛЖЕН, если он включен, содержать информацию о полномочиях (в форме списка сертификатов, обеспечивающих цепочку сертификации) следующего перехода, к которому посреднику необходимо безопасно подключиться. Заголовок ДОЛЖЕН включать в себя URI следующего перехода (прокси или сервер) и двоичную структуру с кодировкой Base64 (в соответствии с разделом 4 [RFC4648 #] и где биты заполнения установлены в ноль), содержащую последовательность, кодированную с помощью DER-encoded X.509v3 [RFC5280 #].

Двоичная структура начинается с числа сертификатов (NR_CERTS), включенных в 16-разрядное целое число без знака. Затем следует число NR_CERTS из 16-битных целых чисел без знака, обеспечивающих размер в октетах каждого сертификата с кодировкой DER. Затем следует номер NR_CERTS DER-кодированных сертификатов X.509v3 в последовательности (цепочке). Этот формат показан на рисунке 6. Сертификат прокси-сервера или сервера должен стоять первым в структуре. Каждый следующий сертификат должен непосредственно подтверждать предыдущий. Поскольку проверка сертификата требует, чтобы корневые ключи распространялись независимо, самозаверяющий сертификат, который указывает корневой центр сертификации, может быть опущен из цепочки, при условии, что удаленный конец должен уже иметь его для проверки его в любом случае.

Пример:

Connection-Credentials:"rtsps://proxy2.example.com/";MIIDNTCC...

Где MIIDNTCC ... — это кодировка Base64 следующей структуры:

Рисунок 6 - Пример формата сертификата заголовка Connection-Credentials — Рисунок 6 — Пример формата сертификата заголовка Connection-Credentials

18.14. Content-Base

Поле заголовка тела сообщения «Content-Base» может использоваться для указания базового URI для разрешения относительных URI в теле сообщения.

Content-Base: rtsp://media.example.com/movie/twister/

Если поле Content-Base отсутствует, базовый URI тела сообщения определяется либо его Content-Location (если этот Content-Location URI является абсолютным URI), либо URI, используемым для инициирования запроса, в том порядке приоритета. Однако обратите внимание, что базовый URI содержимого в теле сообщения может быть переопределен в этом теле сообщения.

18.15. Content-Encoding

Поле заголовка тела сообщения «Content-Encoding» используется в качестве модификатора медиа-типа. Когда оно присутствует, его значение указывает, какие дополнительные кодировки контента были применены к телу сообщения, и, следовательно, какие механизмы декодирования должны быть применены, чтобы получить тип мультимедиа, на который ссылается поле заголовка Content-Type. Content-Encoding прежде всего используется, чтобы позволить документу быть сжатым, не теряя идентичность его основного типа носителя.

Контент-кодирование является характеристикой тела сообщения, идентифицируемого Request-URI. Как правило, тело сообщения сохраняется с этой кодировкой и декодируется только перед рендерингом или аналогичным использованием. Однако прокси-сервер RTSP МОЖЕТ изменить кодирование контента, если известно, что новое кодирование приемлемо для получателя, если в сообщении отсутствует директива кэширования notransform.

Если кодирование содержимого тела сообщения не является «идентификатором», то сообщение ДОЛЖНО включать заголовок Content-Encoding тела сообщения, в котором перечислены используемые неидентификационные кодировки (и) содержимого.

Если кодирование содержимого тела сообщения в сообщении запроса неприемлемо для исходного сервера, сервер ДОЛЖЕН ответить кодом состояния 415 (неподдерживаемый тип носителя).

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

18.16. Content-Language

Поле заголовка тела сообщения «Content-Language» описывает естественный язык (и) предполагаемой аудитории для вложенного тела сообщения. Обратите внимание, что это может быть не эквивалентно всем языкам, используемым в теле сообщения.

Языковые теги упоминаются в разделе 18.4. Основной целью Content-Language является предоставление пользователю возможности идентифицировать и дифференцировать объекты в соответствии с предпочтительным языком пользователя. Таким образом, если основной текст предназначен только для датско-грамотной аудитории, соответствующее поле

Content-Language: da

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

Несколько языков МОГУТ быть перечислены для контента, который предназначен для нескольких аудиторий. Например, исполнение «Договора Вайтанги», представленное одновременно в оригинальной и маорийской версиях, потребовало бы

Content-Language: mi, en

Однако то, что в теле сообщения присутствует несколько языков, не означает, что оно предназначено для нескольких языковых аудиторий. В качестве примера можно привести языковой учебник для начинающих, например «Первый урок латыни», который явно предназначен для англо-грамотной аудитории. В этом случае Content-Language будет правильно включать только «en».

Content-Language МОЖЕТ применяться к любому типу медиа — он не ограничивается текстовыми документами.

18.17. Content-Length

Поле заголовка тела сообщения «Content-Length» содержит длину тела сообщения RTSP (т.е. после двойного CRLF, следующего за последним заголовком) в октетах битов. В отличие от HTTP, он ДОЛЖЕН быть включен во все сообщения, которые несут тело сообщения за частью заголовка сообщения RTSP. Если он отсутствует, предполагается значение по умолчанию, равное нулю. Любое значение Content-Length больше или равно нулю является допустимым значением.

18.18. Content-Location

Поле заголовка тела сообщения «Content-Location» МОЖЕТ использоваться для предоставления местоположения ресурса для тела сообщения, заключенного в сообщении, когда это тело доступно из местоположения, отдельного от URI запрашиваемого ресурса. Сервер ДОЛЖЕН предоставить Content-Location для варианта, соответствующего телу ответного сообщения; особенно в случае, когда с ресурсом связано несколько вариантов, и эти объекты на самом деле имеют отдельные местоположения, по которым к ним можно получить индивидуальный доступ, сервер ДОЛЖЕН предоставить Content-Location для конкретного возвращаемого варианта.

Например, если клиент RTSP выполняет запрос методом DESCRIBE для данного ресурса, например, «rtsp://a.example.com/movie/Plan9FromOuterSpace», то сервер может использовать дополнительную информацию, такую как заголовок User-Agent, чтобы определить возможности агента. Затем сервер вернет описание мультимедиа, предназначенное для этого класса агентов RTSP. Чтобы указать, какое конкретное описание получает агент, в Content-Location предоставляется идентификатор ресурса («rtsp://a.example.com/movie/Plan9FromOuterSpace/FullHD.sdp»), в то время как описание все еще является действительным ответом для универсального идентификатор ресурса, что позволяет выполнять как отладку, так и операции кеширования, как описано ниже.

Значение Content-Location не является заменой для исходного запрошенного URI; это только указание местоположения ресурса, соответствующего этому конкретному варианту на момент запроса. Будущие запросы МОГУТ указывать URI Content-Location в качестве URI запроса, если необходимо определить источник этого конкретного варианта. Это полезно, если агент RTSP хочет проверить, является ли вариант ресурса текущим с помощью условного запроса.

Кэш не может предполагать, что тело сообщения с Content-Location, отличным от URI, использованного для его получения, может использоваться для ответа на более поздние запросы по этому Content-Location URI. Тем не менее, Content-Location может использоваться для различения нескольких вариантов, извлеченных из одного запрошенного ресурса.

Если Content-Location является относительным URI, относительный URI интерпретируется относительно Request-URI.

Обратите внимание, что Content-Location может использоваться в некоторых случаях для получения базового URI для относительного URI, присутствующего в форматах описания сеанса. Это необходимо учитывать при использовании Content-Location. Самый простой способ избежать необходимости учитывать эту проблему — включать Content-Base всякий раз, когда включен Content-Location.

Также обратите внимание, что при использовании тегов мультимедиа в сочетании с Content-Location важно, чтобы разные версии имели разные MTag, даже если они предоставляются под разными URI Content-Location. Это связано с тем, что различные варианты содержимого все еще были предоставлены в ответ на один и тот же URI запроса.

Также обратите внимание, что, как и в большинстве случаев, URI, используемые в запросах DESCRIBE и SETUP, различаются: URI, предоставленный в ответе DESCRIBE Content-Location, не может напрямую использоваться в запросе SETUP. Вместо этого необходимы этапы получения URI медиаресурсов. Это обычно включает в себя объединение относительных URI описания мультимедиа, например, из атрибута a=control SDP, с base-URI для создания абсолютных URI, необходимых в запросе SETUP.

18.19. Content-Type (Тип содержимого)

Заголовок тела сообщения «Content-Type» указывает тип мультимедиа тела сообщения, отправляемого получателю. Обратите внимание, что типы контента, подходящие для RTSP, на практике могут быть ограничены описаниями презентаций и типами значений параметров.

18.20. CSeq

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

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

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

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

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

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

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

18.21. Date (Дата)

Поле общего заголовка «Date» представляет дату и время, когда сообщение было отправлено. Включение заголовка Date в сообщение RTSP следует этим правилам:

Сообщение RTSP, отправленное клиентом или сервером, содержащее тело, ДОЛЖНО включать заголовок Date, если у отправляющего хоста есть часы;
Клиентам и серверам РЕКОМЕНДУЕТСЯ включать заголовок Date во все другие сообщения RTSP, если отправляющий узел имеет часы;
Если на сервере нет часов, которые могут обеспечить разумное приближение текущего времени, его ответы НЕ ДОЛЖНЫ включать поле заголовка Date. В этом случае НЕОБХОДИМО следовать этому правилу: некоторые реализации сервера-источника могут не иметь доступных часов. Исходный сервер без часов НЕ ДОЛЖЕН присваивать ответу значения Expires или Last-Modified, если только эти значения не были связаны с ресурсом системы или пользователем с надежными часами. Он МОЖЕТ присваивать значение Expires, о котором известно, во время или до времени конфигурации сервера, что оно находится в прошлом (это позволяет «pre-expiration» (предварительное истечение) ответов без сохранения отдельных значений Expires для каждого ресурса).

Полученное сообщение, которое не имеет поля заголовка Date, ДОЛЖНО быть назначено получателем, если сообщение будет кэшировано этим получателем. Реализация RTSP без часов НЕ ДОЛЖНА кэшировать ответы без повторной проверки при каждом использовании. Кэш RTSP, особенно кеш общего пользования, ДОЛЖЕН использовать механизм, такой как сетевой протокол времени (NTP) [RFC5905 #], для синхронизации своих часов с надежным внешним стандартом.

Дата RTSP, полная дата, указанная в разделе 3.3 из [RFC5322 #], отправленная в заголовке даты, НЕ ДОЛЖНА представлять дату и время после генерации сообщения. Он ДОЛЖЕН представлять наилучшее имеющееся приближение даты и времени генерации сообщения, если только реализация не имеет средств для генерации достаточно точной даты и времени. Теоретически, дата должна представлять момент непосредственно перед генерацией тела сообщения. На практике, дата может быть сгенерирована в любое время во время создания сообщения, не затрагивая его семантическое значение.

Примечание. Формат даты RTSP 2.0 определен как формат полной даты в RFC 5322. Этот формат является более гибким, чем формат даты в RFC 1123 #, используемый RTSP 1.0. Таким образом, реализации должны использовать одиночные пробелы в качестве разделителей, как рекомендовано в RFC 5322, и поддерживать прием устаревшего формата.

Кроме того, обратите внимание, что синтаксис позволяет добавлять комментарии в конце даты.

18.22. Expires (Истекает)

Поле заголовка тела сообщения «Expires» дает дату и время, после которого описание или медиа-поток следует считать устаревшим. Интерпретация зависит от метода:

DESCRIBE response: заголовок Expires указывает дату и время, после которого описание презентации (тело) ДОЛЖНО считаться устаревшим.

SETUP response: заголовок Expires указывает дату и время, после которого медиапоток СЛЕДУЕТ считать устаревшим.

Устаревшая запись кэша не должна возвращаться кэшем (либо кэшем прокси-сервера, либо кэшем агента пользователя), если она не была сначала проверена исходным сервером (или промежуточным кэшем, который имеет свежую копию тела сообщения). См. Раздел 16 для дальнейшего обсуждения модели срока действия.

Наличие поля Expires не означает, что исходный ресурс изменится или перестанет существовать в, до или после этого времени.

Формат представляет собой абсолютную дату и время, определенные RTSP-датой. Примером его использования является

Expires: Wed, 23 Jan 2013 15:36:52 +0000

Клиенты и кеши RTSP 2.0 ДОЛЖНЫ обрабатывать другие недопустимые форматы дат, особенно те, которые содержат значение «0», как имевшие место в прошлом (то есть, уже истек).

Чтобы пометить ответ как «already expired» (уже истекший), исходный сервер должен использовать дату Expires, равную значению заголовка Date. Чтобы пометить ответ как «never expires» (никогда не истекает), исходный сервер ДОЛЖЕН использовать дату истечения срока действия приблизительно через один год с момента отправки ответа. Серверы RTSP 2.0 НЕ ДОЛЖНЫ отправлять даты окончания срока действия, которые будут продолжаться более одного года.

18.23. From (От)

Поле заголовка запроса «From«, если оно задано, ДОЛЖНО содержать адрес электронной почты в Интернете для человека-пользователя, который управляет запрашивающим пользовательским агентом. Адрес ДОЛЖЕН быть пригодным для использования машиной, как определено в «mailbox» (почтовом ящике) в [RFC1123 #].

Это поле заголовка МОЖЕТ использоваться для целей регистрации и в качестве средства для определения источника недопустимых или нежелательных запросов. Он НЕ ДОЛЖЕН использоваться в качестве небезопасной формы защиты доступа. Интерпретация этого поля заключается в том, что запрос выполняется от имени данного лица, которое принимает на себя ответственность за выполненный метод. В частности, агентам роботов СЛЕДУЕТ включать этот заголовок, чтобы с лицом, ответственным за управление роботом, можно было связаться, если возникнут проблемы на принимающей стороне.

Адрес электронной почты в Интернете в этом поле МОЖЕТ быть отдельным от хоста, отправившего запрос. Например, когда запрос передается через прокси, ДОЛЖЕН использоваться адрес исходного эмитента.

Клиенту НЕ СЛЕДУЕТ отправлять поле заголовка «From» без согласия пользователя, так как это может противоречить интересам пользователя в отношении конфиденциальности или политике безопасности их сайта. Настоятельно рекомендуется, чтобы пользователь мог отключить, включить и изменить значение этого поля в любое время до запроса.

18.24. If-Match

Поле заголовка запроса «If-Match» особенно полезно для обеспечения целостности описания презентации, независимо от того, как было получено описание презентации. Описание презентации может быть получено с помощью средств, внешних по отношению к RTSP (например, HTTP), или с помощью сообщения методом DESCRIBE. В случае извлечения описания презентации через RTSP реализация сервера гарантирует целостность описания между временем сообщения DESCRIBE и сообщением SETUP. Включая значение MTag, данное в описании сеанса или с ним, в часть заголовка If-Match запроса SETUP, клиент гарантирует, что настроенные ресурсы соответствуют описанию. Запрос SETUP с заголовком If-Match, для которого проверка валидации MTag не пройдена, ДОЛЖЕН генерировать ответ, используя 412 (Precondition Failed).

Эта проверка правильности также очень полезна, если сеанс был перенаправлен с одного сервера на другой.

18.25. If-Modified-Since

Поле заголовка запроса «If-Modified-Since» используется с методами DESCRIBE и SETUP, чтобы сделать их условными. Если запрошенный вариант не был изменен со времени, указанного в этом поле, описание не будет возвращено с сервера (DESCRIBE) или поток не будет настроен (SETUP). Вместо этого ответ 304 (Не измененный) ДОЛЖЕН быть возвращен без какого-либо тела сообщения.

Пример поля:

If-Modified-Since: Sat, 29 Oct 1994 19:43:31 GMT

18.26. If-None-Match

Заголовок запроса «If-None-Match» может использоваться с одним или несколькими тегами тела сообщения, чтобы сделать запросы метода DESCRIBE условными. Клиент, имеющий одно или несколько тел сообщений, ранее полученных из ресурса, может проверить, что ни один из этих объектов не является текущим, включив список связанных с ним тегов тела сообщения в поле заголовка If-None-Match. Цель этой функции — обеспечить эффективное обновление кэшированной информации с минимальным объемом транзакций. В особом случае значение звёздочки «*» соответствует любой текущей сущности ресурса.

Если какой-либо из тегов тела сообщения совпадает с тегом тела сообщения тела сообщения, которое было бы возвращено в ответе на аналогичный запрос DESCRIBE (без заголовка If-None-Match) для этого ресурса, или если задано «*» и любой текущий объект существует для этого ресурса, тогда сервер НЕ ДОЛЖЕН выполнять запрошенный метод, если только это не требуется, поскольку дата модификации ресурса не совпадает с той, которая указана в поле заголовка If-Modified-Since в запросе. Вместо этого, если метод запроса был DESCRIBE, сервер ДОЛЖЕН ответить 304 (не измененным) ответом, включая поля заголовка, связанные с кэшем (в частности, MTag) одного из сопоставленных тел сообщения. Для всех других методов запроса сервер ДОЛЖЕН ответить со статусом 412 (предварительное условие не выполнено).

См. Раздел 16.1.3, чтобы узнать, как определить, совпадают ли два тега тела сfообщения.

Если ни один из тегов тела сообщения не совпадает, то сервер МОЖЕТ выполнить запрошенный метод, как если бы поле заголовка If-None-Match не существовало, но ДОЛЖНО также игнорировать любые поля заголовка If-Modified-Since в запросе. То есть, если никакие теги тела сообщения не совпадают, сервер НЕ ДОЛЖЕН возвращать ответ 304 (не изменен).

Если запрос без поля заголовка If-None-Match приведет к чему-либо, кроме статуса 2xx или 304, то заголовок If-None-Match ДОЛЖЕН игнорироваться. (См. Раздел 16.1.4 для обсуждения поведения сервера, когда оба If-Modified-Since и If-None-Match появляются в одном запросе.)

Результат запроса с полем заголовка If-None-Match и полем заголовка If-Match не указан и ДОЛЖЕН рассматриваться как недопустимый запрос.

18.27. Last-Modified (Последнее изменение)

Поле заголовка тела сообщения «Last-Modified» указывает дату и время, когда исходный сервер полагает, что описание презентации или медиапоток были в последний раз изменены. Для метода DESCRIBE поле заголовка указывает дату и время последней модификации описания для метода SETUP медиапотока.

Исходный сервер НЕ ДОЛЖЕН отправлять дату Last-Modified, которая является более поздней, чем время отправления сообщения сервером. В таких случаях, когда последняя модификация ресурса будет указывать какое-то время в будущем, сервер ДОЛЖЕН заменить эту дату датой происхождения сообщения.

Исходный сервер ДОЛЖЕН получить значение Last-Modified тела сообщения как можно ближе ко времени, когда он генерирует значение Date своего ответа. Это позволяет получателю сделать точную оценку времени модификации тела сообщения, особенно если тело сообщения изменяется около времени, когда генерируется ответ.

Серверы RTSP ДОЛЖНЫ отправлять Last-Modified, когда это возможно.

18.28. Location (Место нахождения)

Поле заголовка ответа «Location» используется для перенаправления получателя в местоположение, отличное от Request-URI, для завершения запроса или идентификации нового ресурса. Для ответов 3rr местоположение ДОЛЖНО указывать предпочтительный URI сервера для автоматического перенаправления на ресурс. Поле-значение состоит из одного абсолютного URI.

Примечание. Поле заголовка Content-Location (раздел 18.18) отличается от Location тем, что Content-Location идентифицирует исходное местоположение тела сообщения, заключенного в запросе. Следовательно, ответ может содержать поля заголовка как для Location, так и для Content-Location. Также см. Раздел 16.2 для требований к кешу некоторых методов.

18.29. Media-Properties (Медиа-свойства)

Общий заголовок «Media-Properties» используется в ответах SETUP или запросах PLAY_NOTIFY для указания свойств мультимедиа, которые в настоящее время применимы к сеансу RTSP. PLAY_NOTIFY МОЖЕТ быть использован для изменения этих свойств в любой момент. Однако клиент ДОЛЖЕН получить обновление до любого действия, связанного с вступлением в силу новых свойств мультимедиа. Для агрегированных сеансов заголовок Media-Properties будет возвращаться в каждом ответе SETUP. Заголовок, полученный в последнем ответе, является заголовком, который применяется ко всему сеансу с этого момента до любого будущего обновления. Заголовок МОЖЕТ быть включен без значения в запросы GET_PARAMETER к серверу с включенным заголовком Session для запроса текущих свойств мультимедиа для сеанса. Ответчик ДОЛЖЕН включать свойства мультимедиа текущего сеанса.

Свойства мультимедиа, выраженные этим заголовком, являются свойствами, применимыми ко всем мультимедиа в сеансе RTSP. Для агрегированных сеансов заголовок выражал объединенные медиа-свойства. В результате агрегирование мультимедиа МОЖЕТ привести к изменению свойств мультимедиа и, таким образом, содержимого заголовка Media-Properties, содержащегося в последующих ответах SETUP.

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

Эта спецификация определяет следующие четыре группы и значения их свойств:

Random Access
Content Modifications
Retention
Supported Scale

18.29.1. Random Access (Произвольный доступ)

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

Только начало (Beginning-Only): поиск ограничен только началом.

Нет поиска (No-Seeking): поиск невозможен.

18.29.2. Content Modifications (Модификации контента)

Неизменный (Immutable): содержимое не будет изменено в течение времени жизни сеанса RTSP.

Динамический (Dynamic): содержимое может быть изменено на основе внешних методов или триггеров.

Прогрессирование времени (Time-Progressing): доступ к медиа происходит по мере того, как время настенных часов увеличивается.

18.29.3. Retention (Хранение)

Неограниченный (Unlimited): содержимое будет сохраняться в течение всего срока действия сеанса RTSP.

Ограниченное по времени (Time-Limited): содержимое будет храниться по крайней мере до указанного времени настенного часового пояса. Время должно быть указано в формате абсолютного времени, указанном в разделе 4.4.3.

Длительность времени (Time-Duration): каждая отдельная медиа-единица сохраняется как минимум в течение указанного времени. Это определение позволяет сохранять данные с помощью скользящего окна на основе времени. Продолжительность времени выражается как число с плавающей точкой в секундах. Значение 0.0 является действительным, так как это указывает на то, что в сеансе с прогрессирующим временем данные не сохраняются.

18.29.4. Supported Scale (Поддерживаемая шкала)

Шкалы (Scales): список в кавычках, разделенный запятыми, из одного или нескольких десятичных значений или диапазонов значений шкалы, поддерживаемых содержимым в произвольном порядке. Диапазон имеет начальное и конечное значение, разделенные двоеточием. Диапазон указывает, что контент поддерживает детальный выбор значений масштаба. Тонкая зернистость позволяет выполнять шаги, по крайней мере, не более одной десятой масштаба.

Считается, что контент поддерживает мелкозернистый выбор, когда сервер в ответ на заданное значение масштаба может создавать контент с фактическим масштабом, который составляет менее одной десятой единицы масштаба, то есть 0,1, от запрошенного значения. Отрицательные значения поддерживаются. Значение нуля «0» не имеет значения и НЕ ДОЛЖНО использоваться.

Примеры этого заголовка для контента по требованию и живого потока без записи:

On-demand: Media-Properties: Random-Access=2.5, Unlimited, Immutable, Scales="-20, -10, -4, 0.5:1.5, 4, 8, 10, 15, 20"

Live stream without recording/timeshifting: Media-Properties: No-Seeking, Time-Progressing, Time-Duration=0.0

18.30. Media-Range

Общий заголовок «Media-Range» используется для определения диапазона медиа во время отправки сообщения RTSP. Этот заголовок ДОЛЖЕН быть включен в ответ SETUP, ответы PLAY и PAUSE для медиа, которые являются прогрессирующими во времени, ответы PLAY и PAUSE после любого изменения для медиа, которые являются динамическими, и в запросы PLAY_NOTIFY, которые отправляются из-за Media-Property-Update. Заголовок Media-Range без каких-либо спецификаций диапазона МОЖЕТ быть включен в запросы GET_PARAMETER к серверу для запроса текущего диапазона. В этом случае сервер ДОЛЖЕН включать текущий диапазон на момент отправки ответа.

Заголовок ДОЛЖЕН включать спецификации диапазона для всех форматов времени, поддерживаемых для мультимедиа, как указано в заголовке Accept-Ranges (раздел 18.5) при настройке мультимедиа. Сервер МОЖЕТ включать в себя более одной спецификации диапазона любого заданного формата времени, чтобы указывать носитель, который имеет непостоянный диапазон. Спецификации диапазона ДОЛЖНЫ быть упорядочены с диапазоном с наименьшим значением или самым ранним временем начала, а затем с диапазонами с все более высокими значениями или более поздним временем запуска.

Для носителей, которые имеют свойство прогрессирования времени, значения заголовка Media-Range будут действительны только для определенного момента времени, когда он был выпущен. По мере того как настенный час прогрессирует, медиа-диапазон будет расти. Однако следует предположить, что время мультимедиа прогрессирует в прямой зависимости от времени настенных часов (за исключением перекоса часов), так что можно рассчитать достаточно точную оценку диапазона мультимедиа.

18.31. MTAG

Заголовок ответа «MTag» МОЖЕТ быть включен в ответы методов DESCRIBE, GET_PARAMETER или SETUP. Теги тела сообщения (раздел 4.6), возвращенные в ответе DESCRIBE, а теги в SETUP относятся к презентации, т. е. как к возвращенному описанию сеанса, так и к потоку мультимедиа. Это позволяет проверить, что во время запроса SETUP имеется правильное описание сеанса для медиаресурса. Тем не менее, он имеет тот недостаток, что изменение в любой из частей приводит к аннулированию всех частей.

Если MTag предоставляется как внутри тела сообщения, например, в атрибуте «a=mtag» в SDP, так и в ответном сообщении, то оба тега ДОЛЖНЫ быть идентичны. РЕКОМЕНДУЕТСЯ, чтобы MTag в первую очередь указывался в ответном сообщении RTSP, чтобы гарантировать, что кэши могут использовать MTag, не требуя проверки содержимого. Однако для описаний сеансов, которые распространяются вне RTSP, например, с использованием HTTP и т. д., необходимо будет включить тег тела сообщения в описание сеанса, как указано в Приложении D.1.9.

Запросы методами SETUP и DESCRIBE могут быть обусловлены MTag с использованием заголовков If-Match (раздел 18.24) и If-None-Match (раздел 18.26).

18.32. Notify-Reason

Заголовок ответа (опечатка в оригинальном документе — не ответа а запроса) «Notify-Reason» используется исключительно в методе PLAY_NOTIFY. Он указывает причину, по которой сервер отправил асинхронный запрос PLAY_NOTIFY (см. Раздел 13.5).

18.33. Pipelined-Requests

Общий заголовок 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 из входящих запросов в исходящие, чтобы обеспечить агрегирование запросов в постоянное соединение.

18.34. Proxy-Authenticate

Поле заголовка ответа «Proxy-Authenticate» ДОЛЖНО быть включено как часть ответа 407 (Proxy Authentication Required). Поле-значение состоит из запроса, который указывает схему аутентификации и параметры, применимые к прокси для этого Request-URI. Определение заголовка содержится в [RFC7235 #], и любые применимые схемы аутентификации HTTP появляются в других RFC, таких как Digest [RFC7616 #] и Basic [RFC7617 #].

Процесс аутентификации доступа HTTP описан в [RFC7235 #]. Этот заголовок ДОЛЖЕН использоваться только в ответных сообщениях, связанных с запросами клиент-сервер.

18.35. Proxy-Authentication-Info

Заголовок ответа Proxy-Authentication-Info используется прокси для передачи некоторой информации об успешной аутентификации прокси в ответе на сообщение в некоторых схемах аутентификации, таких как схема дайджеста [RFC7616 #]. Определение заголовка приведено в [RFC7615 #], а любые применимые схемы аутентификации HTTP появляются в других RFC. Этот заголовок ДОЛЖЕН использоваться только в ответных сообщениях, связанных с запросами клиент-сервер. Этот заголовок имеет хоп-хоп-область.

18.36. Proxy-Authorization

Поле заголовка запроса «Proxy-Authorization» позволяет клиенту идентифицировать себя (или своего пользователя) для прокси, который требует аутентификации. Значение поля Proxy-Authorization состоит из учетных данных, содержащих информацию об аутентификации агента пользователя для прокси или области запрашиваемого ресурса. Определение заголовка содержится в [RFC7235 #], и любые применимые схемы аутентификации HTTP появляются в других RFC, таких как Digest [RFC7616 #] и Basic [RFC7617 #].

Процесс аутентификации доступа HTTP описан в [RFC7235 #]. В отличие от авторизации, поле заголовка Proxy-Authorization применяется только к прокси следующего перехода. Этот заголовок ДОЛЖЕН использоваться только в клиент-серверных запросах.

18.37. Proxy-Require

Поле заголовка запроса «Proxy-Require» используется для указания функций, чувствительных к прокси, которые ДОЛЖНЫ поддерживаться прокси. Любые функции заголовка Proxy-Require, которые не поддерживаются прокси-сервером, ДОЛЖНЫ быть отрицательно подтверждены прокси-сервером клиента с использованием заголовка Unsupported. Прокси ДОЛЖЕН использовать код ответа 551 (опция не поддерживается) в ответе. Любой тег функции, включенный в Proxy-Require, не применяется к конечной точке (серверу или клиенту). Чтобы гарантировать, что функция поддерживается как прокси-серверами, так и серверами, этот тег необходимо также включить в заголовок Require.

См. Раздел 18.43 для более подробной информации о механике этого сообщения и примере использования. См. Обсуждение в разделе прокси (Раздел 15.1) о том, когда следует учитывать, что для функции требуется поддержка прокси.

Пример использования:

Proxy-Require: play.basic

18.38. Proxy-Supported

Поле общего заголовка с поддержкой прокси «Proxy-Supported» перечисляет все расширения, поддерживаемые прокси, используя теги функций. Заголовок содержит пересечение расширений, поддерживаемых прокси-серверами пересылки. Заголовок с поддержкой прокси МОЖЕТ быть включен прокси в любой запрос. Он ДОЛЖЕН быть добавлен любым прокси, если в запросе присутствует поддерживаемый заголовок. При наличии в запросе получатель ДОЛЖЕН копировать полученный заголовок с поддержкой прокси-сервера в ответе.

Поле заголовка «Поддерживаемые прокси» содержит список тегов функций, применимых к прокси, как описано в разделе 4.5. Список является пересечением всех тегов функций, понятных для прокси. Для достижения пересечения прокси-сервер, добавляющий заголовок Proxy-Supported, включает все теги прокси-функций, которые он понимает. Любой прокси, получающий запрос с заголовком, ДОЛЖЕН проверить список и удалить любые теги функций, которые он не поддерживает. Заголовок с поддержкой прокси, присутствующий в ответе, НЕ ДОЛЖЕН быть модифицирован прокси. Эти функциональные теги являются теми, которые в целом поддерживаются цепочками прокси, и не относятся к ресурсу запроса.

Пример:

C->P1: OPTIONS rtsp://example.com/ RTSP/2.0 Supported: foo, bar, blech User-Agent: PhonyClient/1.2

P1->P2: OPTIONS rtsp://example.com/ RTSP/2.0 Supported: foo, bar, blech Proxy-Supported: proxy-foo, proxy-bar, proxy-blech Via: 2.0 pro.example.com

P2->S: OPTIONS rtsp://example.com/ RTSP/2.0 Supported: foo, bar, blech Proxy-Supported: proxy-foo, proxy-blech Via: 2.0 pro.example.com, 2.0 prox2.example.com

S->C: RTSP/2.0 200 OK Supported: foo, bar, baz Proxy-Supported: proxy-foo, proxy-blech Public: OPTIONS, SETUP, PLAY, PAUSE, TEARDOWN Via: 2.0 pro.example.com, 2.0 prox2.example.com

18.39. Public

Поле заголовка ответа «Public» содержит список методов, поддерживаемых отправителем ответа. Этот заголовок применяется к общим возможностям отправителя, и его единственная цель — указать возможности отправителя получателю. Перечисленные методы могут или не могут быть применимы к Request-URI; поле заголовка Allow (раздел 18.6) МОЖЕТ использоваться для указания методов, разрешенных для конкретного URI.

Пример использования:

Public: OPTIONS, SETUP, PLAY, PAUSE, TEARDOWN

Если между отправителем и получателем ответа имеются прокси-серверы, каждый промежуточный прокси-сервер ДОЛЖЕН изменить поле заголовка Public, чтобы удалить любые методы, которые не поддерживаются этим прокси-сервером. Результирующее поле заголовка Public будет содержать пересечение методов отправителя и методов, разрешенных промежуточными прокси-серверами.

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

18.40. Range

Общий заголовок «Range» указывает временной диапазон в запросах и ответах PLAY (раздел 13.4), PAUSE (раздел 13.6), SETUP (раздел 13.3) и PLAY_NOTIFY (раздел 13.5). Он МОЖЕТ быть включен в запросы GET_PARAMETER от клиента к серверу только с форматом Range и не иметь значения для запроса текущей медиа-позиции, независимо от того, находится ли сеанс в состоянии Play или Ready во включенном формате. Сервер ДОЛЖЕН, если поддерживает формат диапазона, отвечать текущей точкой воспроизведения или точкой паузы в качестве начала диапазона. Если в предыдущем запросе PLAY использовалась явная точка остановки, то это значение должно быть включено в качестве точки остановки. Обратите внимание, что если в настоящий момент сервер находится под каким-либо манипулированием воспроизведением мультимедиа, влияющим на интерпретацию заголовка Range, например значением масштаба, отличным от 1, этот факт также необходимо включить в любой ответ GET_PARAMETER, включив заголовок Scale для предоставления полной информации.

Диапазон может быть указан в нескольких единицах. Эта спецификация определяет единицы измерения диапазона smpte (раздел 4.4.1), npt (раздел 4.4.2) и тактового генератора (раздел 4.4.3). Несмотря на то, что октетные диапазоны (байтовые диапазоны) (см. Раздел 2.1 [RFC7233 #]) и другие расширенные блоки МОГУТ использоваться, их поведение не определено, поскольку они обычно не имеют значения в RTSP. Серверы, поддерживающие заголовок Range, ДОЛЖНЫ понимать формат диапазона NPT и ДОЛЖНЫ понимать формат диапазона SMPTE. Если заголовок Range отправляется в непонятном формате времени, получателю СЛЕДУЕТ вернуть 456 (поле заголовка недействительно для ресурса) и включить заголовок Accept-Ranges, указывающий поддерживаемые форматы времени для данного ресурса.

Пример:

Range: clock=19960213T143205Z-

Заголовок Range содержит диапазон одного формата диапазона. Диапазон — это полуоткрытый интервал с начальной и конечной точкой, включая начальную точку, но исключая конечную точку. Диапазон может быть либо полностью задан с явными значениями начальной и конечной точек, либо иметь неявную начальную или конечную точку. Неявная начальная точка указывает точку паузы сеанса, а если точка паузы не установлена, начало содержимого. Неявная конечная точка указывает конец содержимого. Использование неявных начальной и конечной точек не допускается в одном и том же заголовке Range; однако пропуск заголовка Range имеет это значение, то есть от точки паузы (или начала) до конца содержимого.

Как уже отмечалось, заголовки Range определяют полуоткрытые интервалы. Диапазон A-B начинается точно в момент времени A, но заканчивается непосредственно перед B. Относится только время начала медиа-блока, такого как видео или аудио кадр. Например, предположим, что видеокадры генерируются каждые 40 мс. Диапазон от 10,0 до 10,1 будет включать видеокадр, начинающийся с 10,0 или более позднего времени, и будет включать видеокадр, начинающийся с 10,08, даже если он длится за пределами интервала. Диапазон 10.0-10.08, с другой стороны, исключил бы кадр в 10.08.

Обратите внимание на разницу между временной шкалой NPT «now» (сейчас) и неявным начальным значением. Неявные значения ссылаются на текущую точку паузы, а «now» (сейчас) — на текущее время. В сеансе с прогрессированием по времени с записью (сохранение в течение некоторого или полного времени) точка паузы может быть через 2 минуты в сеансе, в то время как теперь может быть через 1 час в сеансе.

По умолчанию интервалы диапазона увеличиваются, когда вторая точка больше первой.

Пример:

Range: npt=10-15

Однако интервалы диапазона также могут уменьшаться, если в заголовке Scale (см. Раздел 18.46) указано отрицательное значение масштаба. Например, это будет иметь место, когда желательно воспроизведение в обратном направлении.

Пример:

Scale: -1 Range: npt=15-10

Диапазоны уменьшения по-прежнему являются полуоткрытыми интервалами, как описано выше. Таким образом, для диапазона A-B A закрыто, а B открыто. В приведенном выше примере 15 закрыт, а 10 открыт. Исключением из этого правила является случай, когда B = 0 находится в убывающем диапазоне. В этом случае диапазон закрыт на обоих концах, так как в противном случае было бы невозможно достичь 0 при обратном воспроизведении для форматов, имеющих такое понятие, как NPT и SMPTE.

Пример:

Scale: -1 Range: npt=15-0

В этом диапазоне и 15, и 0 закрыты.

Уменьшающийся интервал диапазона без соответствующего отрицательного значения в заголовке Scale недопустим.

18.41. Referrer

Поле заголовка запроса «Referrer» позволяет клиенту указать для удобства сервера адрес (URI) ресурса, из которого был получен Request-URI. URI относится к описанию презентации, обычно получаемого через HTTP. Заголовок запроса Referrer позволяет серверу создавать списки обратных ссылок на ресурсы для интереса, ведения журналов, оптимизированного кэширования и т. д. Он также позволяет отслеживать устаревшие или опечатки для технического обслуживания. Поле Referrer НЕ ДОЛЖНО отправляться, если Request-URI был получен из источника, который не имеет своего собственного URI, такого как ввод с клавиатуры пользователя.

Если значение поля является относительным URI, его СЛЕДУЕТ интерпретировать относительно Request-URI. URI НЕ ДОЛЖЕН включать идентификатор фрагмента.

Поскольку источником ссылки может быть личная информация или может быть раскрыт другой частный источник информации, настоятельно рекомендуется, чтобы пользователь мог выбрать, отправлять ли поле Referrer или нет. Например, потоковый клиент может иметь тумблер для открытого / анонимного доступа, который соответственно разрешает / запрещает отправку информации о Referrer и From.

Клиенты НЕ ДОЛЖНЫ включать поле заголовка Referrer в (небезопасный) запрос RTSP, если ссылающаяся страница была передана по безопасному протоколу.

18.42. Request-Status

Заголовок запроса «Request-Status» используется для указания конечного результата для запросов, выполнение которых занимает время, например, PLAY (раздел 13.4). Он отправляется в PLAY_NOTIFY (раздел 13.5) с указанием конца потока, чтобы сообщить, как завершился запрос PLAY, в случае успеха или сбоя. Заголовок содержит ссылку на запрос, который он сообщает об использовании номера CSeq, и идентификатор сеанса, используемый в запросе, о котором сообщается. Это не гарантируется быть однозначным из-за того, что номер CSeq ограничен транспортным соединением. Агенты, отправляющие запросы, могут уменьшить проблему, используя монотонно увеличивающийся счетчик для всех используемых последовательных переносов. Заголовок содержит как числовой код состояния (в соответствии с разделом 8.1.1), так и понятную для восприятия фразу.

Пример:

Request-Status: cseq=63 status=500 reason="Media data unavailable"

Прокси, которые перенумеровывают заголовок CSeq, должны выполнить соответствующее переназначение параметра cseq в этом заголовке при пересылке запроса агенту следующего перехода.

18.43. Require

Поле заголовка запроса «Require» используется агентами, чтобы гарантировать, что другая конечная точка поддерживает функции, которые требуются в отношении этого запроса. Его также можно использовать для запроса, поддерживает ли другая конечная точка определенные функции; тем не менее, использование общего заголовка Supported (раздел 18.51) гораздо более эффективно для этой цели. В случае, если какой-либо из тегов функции, перечисленных в заголовке Require, не поддерживается сервером или клиентом, получающим запрос, он ДОЛЖЕН ответить на запрос с помощью кода ошибки 551 (Option Not Supported — Опция не поддерживается) и включает в себя заголовок Unsupported, в котором перечислены те теги функции, которые НЕ поддерживаются. Этот заголовок не относится к прокси; ту же функциональность в отношении прокси см. в заголовке Proxy-Require (раздел 18.37), за исключением прокси-серверов, модифицирующих медиа. Прокси-серверы, модифицирующие мультимедиа, из-за их характера обработки мультимедиа способом, очень похожим на сервер, должны также понимать функции сервера для правильного обслуживания клиента.

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

Пример (не полный):

C->S: SETUP rtsp://server.com/foo/bar/baz.rm RTSP/2.0 CSeq: 302 Require: funky-feature Funky-Parameter: funkystuff

S->C: RTSP/2.0 551 Option not supported CSeq: 302 Unsupported: funky-feature

В этом примере «funky-feature» — это тег функции, который указывает клиенту, что требуется вымышленное поле Funky-Parameter. Взаимосвязь между «funky-feature» и Funky-Parameter не передается через обмен RTSP, поскольку эти отношения являются неизменным свойством «funky-feature» и, следовательно, не должны передаваться при каждом обмене.

Прокси и другие промежуточные устройства ДОЛЖНЫ игнорировать этот заголовок. Если конкретное расширение требует, чтобы промежуточные устройства поддерживали его, расширение должно быть помечено в поле Proxy-Require (см. Раздел 18.37). См. Обсуждение в разделе прокси (Раздел 15.1) о том, когда следует учитывать, что для функции требуется поддержка прокси.

18.44. Retry-After

Поле заголовка ответа «Retry-After» можно использовать с ответом 503 (служба недоступна) или 553 (недоступен прокси), чтобы указать, как долго ожидаемая служба будет недоступна для запрашивающего клиента. Это поле МОЖЕТ также использоваться с любым ответом 3rr (Перенаправление), чтобы указать минимальное время, в течение которого пользовательский агент должен ждать перед отправкой перенаправленного запроса. Ответ, использующий 413 (тело сообщения запроса слишком велико), когда ограничение является временным, МОЖЕТ также включать заголовок Retry-After. Значением этого поля может быть либо RTSP-дата, либо целое число секунд (в десятичной дроби) после времени ответа.

Пример:

Retry-After: Fri, 31 Dec 1999 23:59:59 GMT Retry-After: 120

В последнем примере задержка составляет 2 минуты.

18.45. RTP-Info

Поле общего заголовка «RTP-Info» используется для установки специфичных для RTP параметров в ответах PLAY и GET_PARAMETER или запросах PLAY_NOTIFY и GET_PARAMETER. Для потоков, использующих RTP в качестве транспортного протокола, заголовок RTP-Info ДОЛЖЕН быть частью ответа 200 на PLAY.

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

Информация RTP МОЖЕТ быть включена в ответы SETUP для предоставления информации синхронизации при изменении транспортных параметров, см. Раздел 13.3. Заголовок RTP-Info и заголовок Range МОГУТ быть включены в запрос GET_PARAMETER от клиента к серверу без каких-либо значений для запроса текущей точки воспроизведения и соответствующей информации синхронизации RTP. Когда заголовок RTP-Info включен в Запрос, заголовок Range ДОЛЖЕН также быть включен. Ответ сервера ДОЛЖЕН включать заголовок Range и заголовок RTP-Info. Если сеанс находится в состоянии Play, то значение заголовка Range ДОЛЖНО быть заполнено текущей точкой воспроизведения и соответствующими значениями RTP-Info. Если сервер находится в другом состоянии, значения не включаются в заголовок RTP-Info. Заголовок включается в запросы PLAY_NOTIFY с Notify-Reason окончания потока, чтобы предоставить RTP-информацию о конце потока.

Заголовок может содержать следующие параметры:

url: Указывает URI потока, которому соответствуют следующие параметры RTP; этот URI ДОЛЖЕН быть тем же, который используется в запросе SETUP для этого медиапотока. Любой относительный URI ДОЛЖЕН использовать Request-URI в качестве базового URI. Этот параметр ДОЛЖЕН присутствовать.
ssrc: SSRC, к которому применяются метка времени и порядковый номер RTP. Этот параметр ДОЛЖЕН присутствовать.
seq: указывает порядковый номер первого пакета потока, который является прямым результатом запроса. Это позволяет клиентам корректно работать с пакетами при поиске. Клиент использует это значение для различения пакетов, которые возникли до поиска, от пакетов, которые возникли после поиска. Обратите внимание, что клиент может не принимать пакет с выраженным порядковым номером и вместо этого может принимать пакеты с более высоким порядковым номером из-за потери или переупорядочения пакета. Этот параметр РЕКОМЕНДУЕТСЯ присутствовать.
rtptime: ДОЛЖЕН указывать значение временной метки RTP, соответствующее начальному временному значению в заголовке ответа диапазона или, если явно не указано, подразумеваемую начальную точку. Клиент использует это значение, чтобы рассчитать отображение времени RTP на NPT или другую временную шкалу мультимедиа. Этот параметр ДОЛЖЕН присутствовать для обеспечения синхронизации между средами. Не существует требования, чтобы у любого принятого пакета RTP было то же значение метки времени RTP, что и в параметре, используемом для установления синхронизации.

Сопоставление меток времени RTP с метками времени формата NTP (настенные часы) доступно через RTCP. Однако этой информации недостаточно, чтобы сгенерировать отображение из меток времени RTP во время медиаданных (NPT и т. д.). Кроме того, чтобы гарантировать, что эта информация доступна в нужное время (сразу при запуске или после поиска) и что она доставляется надежно, это отображение помещается в канал управления RTSP.

Чтобы компенсировать дрейф для длинных, непрерывных презентаций, клиенты RTSP должны дополнительно сопоставить NPT с NTP, используя начальные отчеты отправителя RTCP для сопоставления, и более поздние отчеты для проверки отклонения от сопоставления.

Пример:

Range:npt=3.25-15 RTP-Info:url="rtsp://example.com/foo/audio" ssrc=0A13C760:seq=45102; rtptime=12345678,url="rtsp://example.com/foo/video" ssrc=9A9DE123:seq=30211;rtptime=29567112

Предположим, что Audio использует тактовую метку времени RTP 16 кГц, а Video — тактовую метку RTP 90 кГц. Затем синхронизация мультимедиа изображается следующим образом.

NPT 3.0---3.1---3.2-X-3.3---3.4---3.5---3.6 Audio------------PA-A Video------------V--------PV X: NPT time value = 3.25, from Range header. A: RTP timestamp value for Audio from RTP-Info header (12345678). V: RTP timestamp value for Video from RTP-Info header (29567112). PA: RTP audio packet carrying an RTP timestamp of 12344878, which corresponds to NPT = (12344878 - A) / 16000 + 3.25 = 3.2 PV: RTP video packet carrying an RTP timestamp of 29573412, which corresponds to NPT = (29573412 - V) / 90000 + 3.25 = 3.32

18.46. Scale (скорость просмотра)

Общий заголовок «Scale» указывает запрашиваемую или используемую скорость просмотра для воспроизводимого медиаресурса. Значение масштаба 1 указывает на нормальное воспроизведение с нормальной скоростью просмотра вперед. Если не 1, значение соответствует скорости относительно нормальной скорости просмотра. Например, значение 2 указывает вдвое больше нормальной скорости просмотра («ускоренная перемотка вперед»), а значение 0,5 обозначает половину нормальной скорости просмотра. Другими словами, значение 2 имеет увеличение времени контента в два раза больше времени воспроизведения. За каждую секунду прошедшего (настенного) времени будет предоставлено 2 секунды времени контента. Отрицательное значение указывает обратное направление. Для некоторых видов транспорта мультимедиа это может потребовать определенных соображений для последовательной работы; см. Приложение C.1 для описания того, как RTP справляется с этим.

Скорость передаваемых данных НЕ ДОЛЖНА быть изменена путем выбора другого значения шкалы. Результирующий битрейт должен быть достаточно близок к номинальному битрейту контента для масштаба = 1. Сервер должен активно манипулировать данными, когда это необходимо для удовлетворения ограничений битрейта. Реализация «скоростных» изменений зависит от сервера и типа носителя. Для видео сервер может, например, доставлять только ключевые кадры или выбранные кадры. Что касается звука, он может масштабировать звук по времени, сохраняя высоту тона, или, что менее желательно, доставлять фрагменты звука или полностью отключать звук.

Сервер и контент могут ограничивать диапазон значений скорости просмотра, которые он поддерживает. Поддерживаемые значения указываются заголовком Media-Properties (раздел 18.29). Клиент ДОЛЖЕН только указывать значения запроса, которые должны поддерживаться. Однако, поскольку значения могут изменяться по мере продвижения содержимого, запрошенное значение может перестать быть действительным, когда поступит запрос. Таким образом, неподдерживаемое значение в запросе не генерирует ошибку, а только заставляет сервер выбрать наиболее близкое значение. Ответ ДОЛЖЕН всегда содержать фактическое значение масштаба, выбранное сервером.

Если сервер не реализует возможность ускорения/замедления, он не возвращает заголовок Scale. Сервер, поддерживающий операции масштабирования для PLAY, ДОЛЖЕН указывать это с помощью тега функции «play.scale».

При указании отрицательной шкалы для обратного воспроизведения заголовок диапазона Range ДОЛЖЕН указывать уменьшающийся диапазон, как описано в разделе 18.40.

Пример игры в обратном направлении в 3,5 раза выше нормы:

Scale: -3.5 Range: npt=15-10

18.47. Seek-Style

Когда клиент отправляет запрос PLAY с заголовком Range для выполнения произвольного доступа к мультимедиа, клиент не знает, выберет ли сервер первые выборки мультимедиа или первую точку произвольного доступа до диапазона запроса. В зависимости от варианта использования клиент может иметь сильные предпочтения. Чтобы выразить это предпочтение и предоставить клиенту информацию о том, как сервер действовал на этом предпочтении, определяется общий заголовок Seek-Style.

Seek-Style — это общий заголовок, который МОЖЕТ быть включен в любой запрос PLAY, чтобы указать предпочтение клиента для любого медиапотока, который имеет свойства произвольного доступа. Сервер ДОЛЖЕН всегда включать заголовок в любой ответ PLAY для мультимедиа со свойствами произвольного доступа, чтобы указать, какая политика была применена. Сервер, который получает неизвестную политику стиля поиска, ДОЛЖЕН игнорировать ее и выбрать политику по умолчанию для сервера. Клиент, получающий неизвестную политику, ДОЛЖЕН игнорировать ее и использовать заголовок Range и любую информацию о синхронизации мультимедиа в качестве основы для определения того, что сделал сервер.

Эта спецификация определяет следующие политики поиска, которые могут быть запрошены (см. Также Раздел 4.7.1):

RAP: точка произвольного доступа (RAP — Random Access Point) — это запрос сервера найти ближайшую предыдущую точку произвольного доступа, которая существует в совокупности мультимедиа, и доставить из нее. При запросе RAP качество мультимедиа будет наилучшим из возможных, поскольку все мультимедиа будут доставлены из точки, в которой в мультимедийном декодере может быть установлено полное состояние мультимедиа.
CoRAP: Условная точка произвольного доступа (CoRAP) является вариантом вышеуказанного поведения RAP. Эта политика в первую очередь предназначена для случаев, когда существует большее расстояние между точками произвольного доступа в среде. CoRAP использует политику RAP, если выполняется условие, что точка произвольного доступа находится ближе к запрошенной начальной точке, чем к текущей точке паузы. В противном случае поиск не будет выполнен, и воспроизведение продолжится с текущей точки паузы. Эта политика предполагает, что состояние носителя, существующее до паузы, можно использовать, если доставка продолжается. Если клиент или сервер знают, что это не так, следует использовать политику RAP. Другими словами, в большинстве случаев, когда клиент запрашивает начальную точку до текущей точки паузы, действительная цепочка зависимостей декодирования от носителя, доставленного до паузы, и к запрошенному элементу мультимедиа не будет существовать. Если сервер выполнил поиск в точке произвольного доступа, сервер ДОЛЖЕН вернуть политику CoRAP в заголовок Seek-Style и отрегулировать заголовок Range, чтобы отразить положение выбранного RAP. В случае, если точка произвольного доступа находится дальше и сервер выбирает продолжение с текущей точки паузы, он ДОЛЖЕН включить политику «Next» (Далее) в заголовок стиля поиска и настроить начальную точку заголовка диапазона в соответствии с текущей точкой паузы.
First-Prior: политика первого приоритета начнет доставку с медиа-блока, у которого есть время воспроизведения, предшествующее запрошенному времени. Для дискретных носителей это будет включать только те носители, которые будут отображаться во время запроса. Для непрерывных носителей это носители, которые будут отображаться в течение запрошенного времени начала диапазона.
Next: Следующие медиа-единицы после предоставленного времени начала диапазона: для медиа с непрерывным кадром это будет означать первый следующий кадр после предоставленного времени, а для дискретных медиа — первый блок, который должен быть воспроизведен после предоставленного времени. Основное использование в этом случае — когда клиент знает, что у него есть все мультимедиа до определенной точки, и хотел бы продолжить доставку, чтобы можно было добиться полного непрерывного воспроизведения мультимедиа. Примером такого сценария может быть переключение с широковещательной / многоадресной доставки на одноадресную доставку. Эта политика ДОЛЖНА использоваться только по явному запросу клиента.

Обратите внимание, что эти выраженные предпочтения существуют для оптимизации времени запуска или качества носителя. Политика «Next» нарушает обычное определение заголовка Range, чтобы позволить клиенту запрашивать мультимедийные данные с минимальным перекрытием, хотя некоторые могут все еще происходить для агрегированных сеансов. RAP и First-Prior выполняют требование предоставления медиа из запрошенного диапазона и вперед. Однако, если не используется RAP, качество мультимедиа для многих медиакодеков, использующих методы прогнозирования, может быть серьезно ухудшено, если не будут доступны дополнительные данные, например, уже буферизованные или через другие побочные каналы.

18.48. Server

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

Пример:

Server: PhonyServer/1.0

Если ответ пересылается через прокси-сервер, прокси-приложение НЕ ДОЛЖНО изменять заголовок ответа Server. Вместо этого СЛЕДУЕТ включать поле Via (раздел 18.57). Если ответ сгенерирован прокси-сервером, прокси-приложение ДОЛЖНО вернуть заголовок ответа Server, как это было ранее возвращено сервером.

18.49. Session

Поле общего заголовка «Session» идентифицирует сеанс RTSP. Сеанс RTSP создается сервером в результате успешного запроса SETUP, а в ответе идентификатор сеанса передается клиенту. Сеанс RTSP существует до тех пор, пока не будет уничтожен TEARDOWN или REDIRECT или не истечет время ожидания сервером.

Идентификатор сеанса выбирается сервером (см. Раздел 4.3) и ДОЛЖЕН быть возвращен в ответе SETUP. Как только клиент получает идентификатор сеанса, он ДОЛЖЕН быть включен в любой запрос, связанный с этим сеансом. Это означает, что заголовок Session ДОЛЖЕН быть включен в запрос, используя следующие методы: PLAY, PAUSE, PLAY_NOTIFY и TEARDOWN. Это МОЖЕТ быть включено в SETUP, OPTIONS, SET_PARAMETER, GET_PARAMETER и REDIRECT. НЕ ДОЛЖЕН быть включен в ОПИСАНИЕ. Заголовок Session НЕ ДОЛЖЕН включаться в следующие методы, если эти запросы конвейерны и если идентификатор сеанса еще не известен: PLAY, PAUSE, TEARDOWN, SETUP, OPTIONS SET_PARAMETER и GET_PARAMETER.

В ответе RTSP заголовок сеанса ДОЛЖЕН быть включен в методы SETUP, PLAY, PAUSE и PLAY_NOTIFY, и он МОЖЕТ быть включен в методы TEARDOWN и REDIRECT. Если он включен в запрос следующих методов, он также ДОЛЖЕН быть включен в ответ: OPTIONS, GET_PARAMETER и SET_PARAMETER. НЕ ДОЛЖЕН быть включен в ОПИСАНИЕ ответов.

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

Идентификатор сеанса необходим для различения нескольких запросов доставки для одного и того же URI, поступающих от одного и того же клиента.

Ответ 454 (Session Not Found) ДОЛЖЕН быть возвращен, если идентификатор сеанса недействителен.

Заголовок МОЖЕТ включать параметр для периода ожидания сеанса. Если явно не указано, это значение устанавливается равным 60 секундам. Так как это влияет на то, как часто требуются средства поддержки сеанса, значения, меньшие 30 секунд, не рекомендуются. Однако значения, превышающие значения по умолчанию, могут быть полезны в приложениях RTSP, которые имеют неактивные, но установленные сеансы в течение более длительных периодов времени.

60-секундное значение было выбрано в качестве значения тайм-аута сеанса, так как оно приводит к появлению не слишком частых сообщений поддержки активности и низкой чувствительности к изменениям времени запроса / ответа. Если уменьшить значение тайм-аута до значения ниже 30 секунд, соответствующий тайм-аут запроса / ответа становится значительной частью тайм-аута сеанса. Значение 60 секунд также позволяет достаточно быстро восстанавливать выделенные ресурсы сервера в случае сбоя клиента.

18.50. Speed

Поле общего заголовка «Speed» запрашивает у сервера доставку определенного количества номинального времени мультимедиа на единицу времени доставки, в зависимости от способности сервера и желания обслуживать поток мультимедиа с заданной скоростью. Клиент запрашивает, чтобы скорость доставки находилась в заданном диапазоне с нижней и верхней границей. Сервер ДОЛЖЕН доставлять с максимально возможной скоростью в пределах диапазона, но не быстрее, чем верхняя граница, для которой базовый сетевой путь может поддерживать результирующие скорости передачи транспортных данных. Пока любое значение скорости в пределах данного диапазона может быть предоставлено, сервер НЕ ДОЛЖЕН изменять качество носителя. Только если сервер не может доставить носитель со скоростью, заданной нижней границей, он может снизить качество носителя.

Реализация функциональности Speed сервером НЕОБЯЗАТЕЛЬНА. Сервер может указать свою поддержку через тег функции play.speed. Отсутствие заголовка Speed в ответе свидетельствует о недостаточной поддержке этой функции.

Значения параметра скорости выражаются в виде положительного десятичного значения, например, значение 2,0 указывает, что данные должны доставляться в два раза быстрее, чем обычно. Нулевое значение скорости недопустимо. Диапазон указывается в форме «нижняя граница — верхняя граница». Значение нижней границы может быть меньше или равно верхней границе. Все скорости не могут быть поддержаны. Поэтому сервер МОЖЕТ изменить запрошенные значения до ближайших поддерживаемых. Фактическая поддерживаемая скорость ДОЛЖНА быть включена в ответ. Однако обратите внимание, что варианты использования могут различаться и что диапазоны значений скорости, такие как 0,7-0,8, 0,3-2,0, 1,0-2,5 и 2,5-2,5, имеют свое применение.

Пример:

Speed: 1.0-2.5

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

18.51. Supported

Общий заголовок «Supported» перечисляет все расширения, поддерживаемые клиентом или сервером с использованием тегов функций. Заголовок содержит расширения, поддерживаемые клиентом или сервером отправки сообщений. Заголовок Supported МОЖЕТ быть включен в любой запрос. Когда он присутствует в запросе, получатель ДОЛЖЕН ответить своим соответствующим заголовком Supported. Обратите внимание, что заголовок Supported также включен в ответы 4xx и 5xx.

Заголовок Supported содержит список тегов функций, описанных в разделе 4.5, которые понятны клиенту или серверу. Эти теги функций поддерживаются сервером или клиентом в целом и не относятся к ресурсу запроса.

Пример:

C->S: OPTIONS rtsp://example.com/ RTSP/2.0 Supported: foo, bar, blech User-Agent: PhonyClient/1.2

S->C: RTSP/2.0 200 OK Supported: bar, blech, baz

18.52. Terminate-Reason (Причина завершения сеанса)

Заголовок запроса «Terminate-Reason» позволяет серверу при отправке запроса методом REDIRECT или TEARDOWN указать причину завершения сеанса и любую дополнительную информацию. Эта спецификация определяет три причины для перенаправлений и может быть расширена в будущем:

Server-Admin: сервер должен быть выключен по какой-либо административной причине.
Session-Timeout: Сеанс клиента поддерживается в течение продолжительных периодов времени, и сервер определил, что ему необходимо восстановить ресурсы, связанные с этим сеансом.
Internal-Error: Произошла внутренняя ошибка, которую невозможно восстановить, что вынудило сервер прекратить сеанс.

Сервер может предоставить дополнительные параметры, содержащие информацию о перенаправлении. Эта спецификация определяет следующие.

time: обеспечивает время, когда сервер прекратит предоставлять какую-либо услугу.
user-msg: текстовая строка UTF-8 с сообщением от сервера пользователю. Это сообщение ДОЛЖНО быть отображено пользователю.

18.53. Timestamp (Отметка)

Общий заголовок «Timestamp» описывает, когда агент отправил запрос. Значение метки времени имеет значение только для агента и может использовать любую шкалу времени. Отвечающий агент ДОЛЖЕН повторить то же самое значение и МОЖЕТ, если у него есть точная информация об этом, добавить число с плавающей запятой, указывающее количество секунд, прошедших с момента получения запроса. Временная метка может использоваться агентом для вычисления времени обращения к отвечающему агенту, чтобы он мог настроить значение тайм-аута для повторных передач при работе по ненадежному протоколу. Это также устраняет неоднозначности повторной передачи для ненадежной транспортировки RTSP.

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

18.54. Transport

Общий заголовок «Transport» указывает, какой транспортный протокол должен использоваться, и настраивает его параметры, такие как адрес назначения, сжатие, время жизни многоадресной рассылки и порт назначения для одного потока. Он устанавливает те значения, которые еще не определены описанием презентации.

Заголовок запроса Transport МОЖЕТ содержать список вариантов транспорта, приемлемых для клиента, в форме нескольких записей спецификации транспорта. Транспортные спецификации разделены запятыми и перечислены в порядке убывания предпочтений. Каждая транспортная спецификация состоит из идентификатора транспортного протокола, за которым следует любое количество параметров, разделенных точками с запятой. Заголовок запроса Transport МОЖЕТ содержать несколько транспортных спецификаций, использующих один и тот же идентификатор транспортного протокола. Сервер ДОЛЖЕН возвратить заголовок ответа Transport в ответе, чтобы указать фактически выбранные значения, если они есть. Если спецификация транспорта не поддерживается, заголовок транспорта не возвращается, и ответ ДОЛЖЕН использовать код состояния 461 Unsupported Transport (Неподдерживаемый транспорт) (Раздел 17.4.25). В случае, если в запросе присутствовало более одной транспортной спецификации, сервер ДОЛЖЕН возвратить единственную транспортную спецификацию (transportspec), которая была фактически выбрана, если таковая имеется. Ожидается, что количество записей транспортных спецификаций будет ограничено, так как клиент получит руководство о том, какие конфигурации возможны из описания презентации.

Транспортный заголовок МОЖЕТ также использоваться в последующих запросах SETUP для изменения транспортных параметров. Сервер МОЖЕТ отказаться от изменения параметров существующего потока.

Идентификатор транспортного протокола для каждой транспортной спецификации определяет используемый транспортный протокол и любые связанные с ним правила. Каждый идентификатор транспортного протокола определяет параметры, которые должны быть выполнены; Могут возникнуть дополнительные необязательные параметры. Эта гибкость обеспечивается, поскольку параметры могут различаться и предоставлять различные параметры агенту RTSP. Транспортная спецификация может содержать только один из заданных параметров. Параметр состоит из имени и необязательно строки значения. Параметры МОГУТ быть заданы в любом порядке. Кроме того, спецификация транспорта может содержать только параметр типа одноадресной или многоадресной передачи. Идентификатор транспортного протокола и все параметры необходимо понимать в транспортной спецификации; в противном случае спецификацию перевозки ДОЛЖНЫ игнорировать. Прокси-сервер RTSP любого типа, который использует или изменяет спецификацию транспорта, например, прокси-сервер доступа или прокси-сервер безопасности, ДОЛЖЕН удалить спецификации с неизвестными параметрами, прежде чем пересылать сообщение RTSP. Если это не приводит к оставшейся спецификации транспорта, прокси ДОЛЖЕН отправить ответ 461 (Unsupported Transport) (раздел 17.4.25) без заголовка транспорта.

Заголовок 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), которые необходимо устранить, поскольку сервер RTSP можно использовать в качестве атакующего DoS в существующей многоадресной группе.
dest_addr с использованием информации описания сеанса: вся информация, включенная в транспортный заголовок, может поступать из описания сеанса, например, строк SDP «c =» и «m =». Это смягчает некоторые проблемы безопасности предыдущих методов, поскольку именно поставщик сеансов выбирает группу многоадресной рассылки и область действия. Клиент ДОЛЖЕН включать информацию, если она доступна в описании сеанса.
No dest_addr: поведение, когда в запросе нет явной многоадресной группы, не определено.

Прокси RTSP должен позаботиться. Если мультимедиа не требуется маршрутизировать через прокси, прокси должен будет ввести указатель назначения.

Ниже приведены параметры конфигурации, связанные с транспортом:

18.54.1 Общие параметры

unicast / multicast (одноадресная / многоадресная рассылка): этот параметр является взаимоисключающим указанием того, будет ли предпринята одноадресная или многоадресная доставка. ДОЛЖНО быть указано одно из двух значений. Клиенты, которые способны обрабатывать как одноадресную, так и многоадресную передачу, должны указать такую возможность, включив две полные транспортные спецификации с отдельными параметрами для каждого.

layers: количество многоадресных слоёв, которые будут использоваться для этого медиапотока. Слои отправляются по последовательным адресам, начиная с адреса dest_addr. Если параметр не включен, по умолчанию используется один слой.

dest_addr: общий параметр адреса назначения, который может содержать одну или несколько спецификаций адреса. Каждая комбинация протокола / профиля / более низкого транспорта должна иметь формат и интерпретацию своей спецификации адреса. Для RTP / AVP / UDP и RTP / AVP / TCP спецификация адреса представляет собой кортеж, содержащий адрес хоста и порт. Обратите внимание, что для каждой транспортной спецификации предназначен только один параметр назначения. Использование нескольких адресатов для распределения одного носителя по нескольким объектам не определено.

Клиент, отправляющий запрос RTSP, МОЖЕТ указать адрес назначения получателя потока с адресом хоста как часть кортежа. Когда адрес получателя указан, получатель может быть другой стороной, чем отправитель запроса. Чтобы не стать невольным исполнителем DoS-атаки с дистанционным управлением, сервер ДОЛЖЕН выполнить проверки безопасности (см. Раздел 21.2.1) и ДОЛЖЕН зарегистрировать такие попытки, прежде чем разрешить клиенту направить поток мультимедиа на адрес получателя, не выбранный сервером. Реализации не могут полагаться на 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. Аргумент предоставляет номер канала для использования в блоке $ (см. раздел 14 ) и ДОЛЖНЫ присутствовать. Этот параметр МОЖЕТ быть задан как интервал, например, interleaved = 4-5 в тех случаях, когда этого требует выбор транспорта для медиапотока, например, для RTP с RTCP. Номер канала, указанный в запросе, является лишь указанием от клиента к серверу, какой номер (а) канала использовать. Сервер МОЖЕТ установить любой действительный номер канала в ответе. Объявленные каналы являются двунаправленными, поэтому обе конечные стороны МОГУТ отправлять данные по данному каналу. Одним примером такого использования является второй канал, используемый для RTCP, где и сервер, и клиент отправляют пакеты RTCP по одному и тому же каналу.

Это позволяет обрабатывать RTP / RTCP аналогично тому, как это делается с UDP, т. е. Один канал для RTP, а другой — для RTCP.

MIKEY: этот параметр используется вместе со спецификациями транспорта, которые могут использовать MIKEY [RFC3830 #] для установления контекста безопасности. Пока только MIKEY могут использовать только профили RTP на основе SRTP SAVP и SAVPF, и это определено в Приложении C.1.4.1. Этот параметр может быть включен как в запрос, так и в ответные сообщения. Бинарное сообщение MIKEY ДОЛЖНО быть закодировано в Base64 [RFC4648 #] перед включением в часть значения параметра, где кодирование соответствует определению в Разделе 4 RFC 4648 и где биты заполнения установлены в ноль.

18.54.2 Multicast-specific

ttl: время жизни многоадресной рассылки для IPv4. При включении в запросы значение указывает значение TTL, которое клиент запрашивает у сервера. В ответ возвращается значение, фактически используемое сервером. Сервер должен будет рассмотреть, какие значения являются разумными, а также полномочия пользователя установить это значение. Соответствующие функции не нужны для IPv6, так как область действия является частью многоадресного адреса IPv6 [RFC4291 #].

18.54.3 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; обсуждение ниже ограничено синтаксическими проблемами. Клиенты могут указать следующие значения для параметра настройки:

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 (начальный и последующий).

Необходимо определить комбинацию транспортного протокола, профиля и нижнего транспортного уровня. Ряд комбинаций определен в Приложении С.

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

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

18.55. Unsupported

В заголовке ответа «Unsupported» перечислены функции, которые не поддерживаются отвечающим агентом RTSP. В случае, если функция была указана в поле Proxy-Require (раздел 18.37), если на пути между клиентом и сервером есть прокси, прокси-сервер ДОЛЖЕН отправить ответное сообщение с кодом состояния 551 (опция не поддерживается). Запрос НЕ ДОЛЖЕН быть перенаправлен.

См. Раздел 18.43 для примера использования.

18.56. User-Agent

Поле общего заголовка «User-Agent» содержит информацию о пользовательском агенте, который отправил запрос или дал ответ. Это для статистических целей, отслеживания нарушений протокола и автоматического распознавания пользовательских агентов для адаптации ответов, чтобы избежать определенных ограничений пользовательских агентов. Пользовательские агенты ДОЛЖНЫ включать это поле в запросы. Поле может содержать несколько токенов продукта и комментариев, идентифицирующих агента и любые субпродукты, которые составляют значительную часть пользовательского агента. Условно, токены продукта перечислены в порядке их значимости для идентификации приложения.

Пример:

User-Agent: PhonyClient/1.2

18.57. Via

Поле общего заголовка «Via» ДОЛЖНО использоваться прокси для указания промежуточных протоколов и получателей между пользовательским агентом и сервером по запросам, и между исходным сервером и клиентом по ответам. Это поле предназначено для отслеживания пересылки сообщений, исключения циклов запросов и определения возможностей протокола всех отправителей в цепочке запросов / ответов.

Каждое из нескольких значений в поле Via представляет каждый прокси-сервер, который перенаправил сообщение. Каждый получатель ДОЛЖЕН добавить свою информацию так, чтобы конечный результат был упорядочен в соответствии с последовательностью приложений пересылки. Поэтому сообщения, отправляемые клиентом или сервером, не включают заголовок Via. Первый прокси или другой промежуточный продукт добавляет заголовок и его информацию в поле. Любое дополнительное промежуточное звено добавляет дополнительные значения поля. В результате сервер видит цепочки промежуточных звеньев в запросе клиент-сервер, а клиент видит полную цепочку в ответном сообщении.

Прокси-серверы (например, прокси-сервер доступа (Access Proxy) или прокси-сервер транслятора (Translator Proxy)) по умолчанию НЕ ДОЛЖНЫ пересылать имена и порты хостов в частном / защищенном регионе. Эта информация ДОЛЖНА распространяться, только если она явно включена. Если этот параметр не включен, любой Via-получатель, проходящий через брандмауэр / NAT, должен быть заменен соответствующим псевдонимом для этого хоста.

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

18.58. WWW-Authenticate

Заголовок «WWW-Authenticate» указан в [RFC7235 #]; его использование зависит от используемых схем аутентификации, таких как Digest [RFC7616 #] и Basic [RFC7617 #]. Поле заголовка ответа WWW-Authenticate ДОЛЖНО быть включено в ответные сообщения 401 (неавторизованный). Поле-значение состоит по меньшей мере из одного запроса, который указывает схему (ы) аутентификации и параметры, применимые к Request-URI. Этот заголовок ДОЛЖЕН использоваться только в ответных сообщениях, связанных с запросами от клиента к серверу.

Процесс аутентификации доступа HTTP описан в [RFC7235 #] с некоторыми пояснениями в разделе 19.1. Пользовательским агентам рекомендуется проявлять особую осторожность при разборе значения поля WWW-Authenticate, так как оно может содержать более одного запроса или если предоставляется более одного поля заголовка WWW-Authenticate, содержимое запроса может содержать запятую. отдельный список параметров аутентификации.

19. Структура безопасности

Структура безопасности RTSP состоит из двух компонентов высокого уровня: чистые механизмы аутентификации, основанные на HTTP-аутентификации, и защита транспорта сообщений, основанная на TLS, которая не зависит от RTSP. Из-за сходства в синтаксисе и использовании между серверами RTSP и HTTP-серверами безопасность для HTTP используется в значительной степени.

19.1. RTSP и HTTP аутентификация

RTSP и HTTP используют общие схемы аутентификации; таким образом, они следуют той же схеме, что указана в [RFC7235 #]. RTSP использует соответствующие коды ошибок RTSP (401 и 407) и заголовки (WWWAuthenticate, Authorization, Proxy-Authenticate, Proxy-Authorization) путем импорта определений из [RFC7235 #]. Серверы ДОЛЖНЫ реализовывать обе схемы аутентификации Basic [RFC7617 #] и Digest [RFC7616 #]. Клиенты ДОЛЖНЫ реализовывать как базовую, так и дайджест-схему аутентификации, чтобы сервер, которому требуется аутентификация клиента, мог доверять наличию такой возможности. При реализации схемы дайджест-проверки подлинности ДОЛЖНЫ соблюдаться дополнительные соображения, указанные ниже в разделе 19.1.1.

Следует подчеркнуть, что использование только аутентификации HTTP не обеспечивает полную безопасность сообщений RTSP. Следовательно, TLS ДОЛЖЕН использоваться; см. раздел 19.2. Любое сообщение RTSP, содержащее заголовок авторизации, использующий базовую схему аутентификации, ДОЛЖНО использовать соединение TLS с включенной защитой конфиденциальности, т.е. без шифрования NULL.

В случаях, когда существует цепочка прокси между клиентом и сервером, каждый прокси может индивидуально запросить у клиента или предыдущего прокси-сервера аутентификацию. Это делается с использованием заголовков Proxy-Authenticate (раздел 18.34), Proxy-Authorization (раздел 18.36) и Proxy-Authentication-Info (раздел 18.35). Эти заголовки являются заголовками переходов за переходом и ограничиваются только текущим подключением и переходом. Таким образом, если цепочка прокси существует, прокси, соединяющийся с другим прокси, должен действовать как клиент, чтобы авторизоваться для следующего прокси. Заголовки WWW-Authenticate (раздел 18.58), Authorization (раздел 18.8) и Authentication-Info (раздел 18.7) являются сквозными и НЕ ДОЛЖНЫ изменяться прокси-серверами.

Этот механизм аутентификации работает только для клиент-серверных запросов, как определено в настоящее время. Это оставляет запрос от сервера к клиенту вне контекста связи на основе TLS более уязвимым для атак внедрения сообщений на клиенте. В зависимости от существующих методов сервер-клиент потенциальные риски различны: угон (REDIRECT), отказ в обслуживании (TEARDOWN и PLAY_NOTIFY) или атаки с неопределенными результатами (SET_PARAMETER).

19.1.1. Дайджест-аутентификация

В этом разделе описаны изменения и пояснения, необходимые для применения схемы аутентификации дайджеста HTTP к RTSP. Использование схемы RTSP практически полностью идентично использованию для HTTP [RFC7616 #]. Эти модификации основаны на процедурах, определенных для SIP 2.0 [RFC3261 #] (в разделе 22.4), но обновлены для использования RFC 7235 #, RFC 7616 # и RFC 7615 # вместо RFC 2617 #.

В дайджест-аутентификации используются два дополнительных заголовка, Authentication-Info и Proxy-Authentication-Info, которые определены в [RFC7615 #]. Правила дайджест-аутентификации соответствуют правилам, определенным в [RFC7616 #], с заменой «HTTP / 1.1» на «RTSP / 2.0» в дополнение к следующим различиям:

Используйте ABNF, указанный в ссылочных документах, с той разницей, что параметр URI использует формат URI запроса для RTSP, то есть элемент ABNF: Request-URI (см. Раздел 20.2.1). Параметр домена использует элемент RTSP-URI-Ref для абсолютных и относительных URI.
Если используются MTag, то может сработать пример процедуры выбора одноразового номера на основе ETag, основанный на замене ETag на MTag.
В качестве пояснения к вычислению значения A2 для обеспечения целостности сообщения в схеме дайджест-аутентификации разработчики должны предположить, когда тело объекта пусто (то есть, когда сообщения RTSP не имеют тела сообщения), что хеш тело сообщения преобразуется в хэш пустой строки или:
H (entity-body), пример MD5 ("") = "D41d8cd98f00b204e9800998ecf8427e".

19.2. RTSP через TLS

Агенты RTSP ДОЛЖНЫ реализовывать RTSP поверх TLS, как определено в этом разделе и в следующем разделе 19.3. RTSP ДОЛЖЕН следовать тем же рекомендациям в отношении использования TLS [RFC5246 #], как указано для HTTP; см. [RFC2818 #]. RTSP через TLS отделен от незащищенного RTSP как на уровне URI, так и на уровне порта. Вместо использования идентификатора схемы «rtsp» в URI идентификатор системы «rtsps» ДОЛЖЕН использоваться для сигнализации RTSP по TLS. Если в URI со схемой «rtsps» не указан порт, порт 322 ДОЛЖЕН использоваться для TLS через TCP / IP.

Когда клиент пытается установить небезопасный канал к серверу (используя URI «rtsp»), а политика для ресурса требует безопасного канала, сервер ДОЛЖЕН перенаправить клиента на защищенную службу, отправив код ответа 301 перенаправления вместе с правильным URI местоположения (используя схему «rtsps»). Пользователь или клиент МОЖЕТ обновить незащищенный URI до защищенного, изменив схему с «rtsp» на «rtsps». Сервер, реализующий поддержку «rtsps», ДОЛЖЕН это разрешить.

Следует отметить, что TLS допускает взаимную аутентификацию (при использовании как серверных, так и клиентских сертификатов). Тем не менее, одним из наиболее распространенных способов использования TLS является предоставление только аутентификации на стороне сервера (часто во избежание клиентских сертификатов). TLS затем используется в дополнение к HTTP-аутентификации, обеспечивая безопасность транспорта и аутентификацию сервера, а HTTP-аутентификация используется для аутентификации клиента.

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

Существует потенциальная уязвимость безопасности при повторном использовании состояний TCP и TLS для разных ресурсов (URI). Если два разных имени хоста указывают на один и тот же IP-адрес, может потребоваться повторное использование соединения TCP / TLS с этим сервером. В этом случае агент RTSP, имеющий соединение TCP / TLS, ДОЛЖЕН проверить, что сертификат сервера, связанный с соединением, имеет SubjectAltName, совпадающее с именем хоста, присутствующим в URI для ресурса, для которого должен быть выдан запрос RTSP.

В дополнение к этим рекомендациям в разделе 19.3 приведены дополнительные рекомендации по использованию TLS с прокси-серверами.

19.3. Безопасность и Прокси

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

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

Аутентификация HTTP основана на предположении о прокси и может обеспечивать аутентификацию прокси-пользователя и аутентификацию прокси-сервера / сервера в дополнение к аутентификации клиент-сервер.

Когда применяется TLS и используется прокси, клиент подключается к адресу прокси-сервера при подключении к любому серверу RTSP. Это подразумевает, что для TLS клиент будет аутентифицировать прокси-сервер, а не конечный сервер. Обратите внимание, что когда клиент проверяет сертификат сервера в TLS, он ДОЛЖЕН проверять идентификацию прокси-сервера (URI или, возможно, другую известную идентификацию) по идентификации прокси-сервера, как представлено в сообщении сертификата прокси-сервера.

Проблема заключается в том, что для прокси-сервера, принятого клиентом, ему необходимо предоставить информацию о том, на каких основаниях он должен принять сертификат следующего перехода. Правила для этого могут быть и у прокси, и у пользователя, и у пользователя должна быть возможность выбрать желаемое поведение. Для обработки этого случая используется заголовок Accept-Credentials (см. Раздел 18.2), где клиент может запросить прокси или прокси-серверы для ретрансляции цепи сертификатов, используемых для аутентификации любых промежуточных прокси-серверов, а также сервера. Предположение о том, что прокси-серверы рассматриваются как доверенные, дает пользователю возможность применять политики на каждом доверенном прокси-сервере в отношении того, должен ли он принимать следующего агента в цепочке. Однако следует отметить, что не все развертывания будут возвращать цепочку сертификатов, используемых для проверки подлинности любых промежуточных прокси-серверов, а также сервера. Оператор такого развертывания может захотеть скрыть свою топологию от клиента. Следует отметить, что клиент не имеет никакого представления о работе прокси. Даже если доверенному лицу доверяют, он все равно может вернуть неполную цепочку сертификатов.

Прокси ДОЛЖЕН использовать TLS для следующего перехода, если запрос RTSP включает URI «rtsps». TLS МОЖЕТ быть применен к промежуточным каналам (например, между клиентом и прокси или между прокси и прокси), даже если ресурс и конечный сервер не обязаны его использовать. Цепочка прокси, используемая клиентом для доступа к серверу и его сеансам TLS, ДОЛЖНА иметь соразмерную безопасность. Поэтому прокси-сервер ДОЛЖЕН при инициации соединения TLS следующего перехода использовать список шифрованных входящих соединений TLS, изменяемый только путем удаления любых наборов шифров, которые прокси-сервер не поддерживает. Если прокси-серверу не удается установить соединение TLS из-за несоответствия набора шифров между прокси-сервером и прокси-сервером следующего перехода, это указывается с помощью кода ошибки 472 (сбой при установлении безопасного соединения).

19.3.1. Accept-Credentials

Заголовок Accept-Credentials может использоваться клиентом для распространения простых политик авторизации для промежуточных прокси. Клиент включает заголовок Accept-Credentials, чтобы указать, как прокси обрабатывает сервер / следующий сертификат прокси. В настоящее время определены три метода:

Any (Любой): при значении «любой» прокси (или прокси) ДОЛЖНЫ принимать любой представленный сертификат. Конечно, это не рекомендуемый вариант использования, но он может быть полезен при определенных обстоятельствах (например, при тестировании).
Proxy (Прокси-сервер): для метода «прокси-сервер» прокси-сервер (или прокси-серверы) ДОЛЖЕН использовать свои собственные политики для проверки сертификата и принятия решения, принимать его или нет. Это удобно в тех случаях, когда у пользователя сильные доверительные отношения с прокси. Причины, по которым могут существовать сильные доверительные отношения, — персональный / корпоративный прокси-сервер или прокси-сервер имеет механизм конфигурации внешней политики.
User (Пользователь): для метода «пользователь» прокси (или прокси) ДОЛЖНЫ отправить клиенту информацию о следующем прыжке для авторизации. Затем клиент может решить, должен ли прокси-сервер принять сертификат. См. Раздел 19.3.2 для получения более подробной информации.

Если заголовок Accept-Credentials не включен в запрос RTSP от клиента, тогда метод «Прокси» ДОЛЖЕН использоваться по умолчанию. Если должен использоваться метод, отличный от «Proxy», тогда заголовок Accept-Credentials ДОЛЖЕН быть включен во все запросы RTSP от клиента. Это связано с тем, что нельзя предполагать, что прокси-сервер всегда сохраняет состояние TLS или предыдущее предпочтение пользователя между различными сообщениями RTSP (в частности, если интервал времени между сообщениями большой).

При использовании методов «Любой» и «Прокси» прокси будет применять политику, определенную для каждого метода. Если политика не принимает учетные данные следующего перехода, прокси-сервер ДОЛЖЕН ответить сообщением, используя код состояния 471 (учетные данные подключения не принимаются).

Запрос RTSP в направлении от сервера к клиенту НЕ ДОЛЖЕН включать заголовок Accept-Credentials. Что касается незащищенной связи, возможность для этих запросов зависит от наличия установленного клиентом соединения. Однако, если запрос от сервера к клиенту связан с сеансом, установленным по защищенному каналу TLS, он ДОЛЖЕН быть отправлен в защищенном соединении TLS. Это защищенное соединение ДОЛЖНО также быть тем, которое использовалось последним запросом клиент-сервер. Если такого транспортного соединения не существует в то время, когда сервер желает отправить запрос, сервер ДОЛЖЕН отклонить сообщение.

Дальнейшие политики МОГУТ быть определены и зарегистрированы, но это следует делать с осторожностью.

19.3.2. Утвержденная пользователем процедура TLS

Для метода «Пользователь» каждый прокси-сервер ДОЛЖЕН выполнить следующую процедуру для каждого запроса RTSP:

Установите сеанс TLS для следующего перехода, если он еще не существует (то есть, выполните квитирование TLS, но не отправляйте запрос RTSP).
Извлечь цепочку одноранговых сертификатов для сеанса TLS.
Проверьте наличие соответствующих идентификатора и хэша сертификата однорангового узла в заголовке Accept-Credentials. Если имеется, отправьте сообщение следующему прыжку и завершите эти процедуры. Если нет, перейдите к следующему шагу.
Прокси-сервер отвечает на запрос RTSP с кодом ответа 470 или 407. Код ответа 407 МОЖЕТ использоваться, когда прокси-сервер требует как пользователя, так и авторизации соединения от пользователя или клиента. В этом сообщении прокси-сервер ДОЛЖЕН включать заголовок Connection-Credentials, см. Раздел 18.13, с идентификацией и сертификатом следующего перехода.

Клиент ДОЛЖЕН при получении ответа 470 (Требуется авторизация соединения) или 407 (Требуется аутентификация прокси-сервера) с заголовком Connection-Credentials принять решение о том, принимать или не принимать сертификат (если он не может этого сделать, пользователь ДОЛЖЕН обратиться к пользователю). Использование IP-адресов в URI следующего сертификата и сертификатах, а не в именах доменов, очень затрудняет определение пользователем, должен ли он одобрить следующий переход. Прокси РЕКОМЕНДУЕТСЯ использовать доменные имена для идентификации себя в URI и в сертификатах. Если сертификат принят, клиент должен снова отправить запрос RTSP. В этом запросе клиент должен включить заголовок Accept-Credentials, включающий в себя хэш сертификата в кодировке DER для всех доверенных прокси в цепочке.

Пример:

C->P: SETUP rtsps://test.example.org/secret/audio RTSP/2.0 CSeq: 2 Transport: RTP/AVP;unicast;dest_addr="192.0.2.5:4588"/ "192.0.2.5:4589" Accept-Ranges: npt, smpte, clock Accept-Credentials: User

P->C: RTSP/2.0 470 Connection Authorization Required CSeq: 2 Connection-Credentials: "rtsps://test.example.org"; MIIDNTCCAp...

C->P: SETUP rtsps://test.example.org/secret/audio RTSP/2.0 CSeq: 3 Transport: RTP/AVP;unicast;dest_addr="192.0.2.5:4588"/ "192.0.2.5:4589" Accept-Credentials: User "rtsps://test.example.org";sha-256; dPYD7txpoGTbAqZZQJ+vaeOkyH4= Accept-Ranges: npt, smpte, clock

P->S: SETUP rtsps://test.example.org/secret/audio RTSP/2.0 CSeq: 3 Transport: RTP/AVP;unicast;dest_addr="192.0.2.5:4588"/ "192.0.2.5:4589" Via: RTSP/2.0 proxy.example.org Accept-Credentials: User "rtsps://test.example.org";sha-256; dPYD7txpoGTbAqZZQJ+vaeOkyH4= Accept-Ranges: npt, smpte, clock

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

20. Синтаксис

Синтаксис RTSP описан в расширенной форме Бэкуса-Наура (ABNF), как определено в RFC 5234 [RFC5234 #]. Он использует основные определения, представленные в RFC 5234.

Обратите внимание, что строки ABNF, например «Accept», нечувствительны к регистру, как указано в разделе 2.3 RFC 5234.

Синтаксис RTSP использует набор символов ISO 10646 в кодировке UTF-8 [RFC3629 #].

20.1. Базовый синтаксис

Значения заголовка RTSP можно сложить на несколько строк, если строка продолжения начинается с пробела или горизонтальной табуляции. Все линейные пробелы, включая складывание, имеют ту же семантику, что и SP. Получатель МОЖЕТ заменить любой линейный пробел одним SP перед интерпретацией значения поля или пересылкой сообщения в нисходящем направлении. Конструкция SWS используется, когда линейный пробел является необязательным, как правило, между токенами и разделителями.

Чтобы отделить имя заголовка от остальной части значения, используется двоеточие, которое по вышеприведенному правилу допускает пробел до, но без переноса строки и пробел после, включая разрыв строки. HCOLON определяет эту конструкцию.

OCTET = %x00-FF ; any 8-bit sequence of data
CHAR = %x01-7F ; any US-ASCII character (octets 1 — 127)
UPALPHA = %x41-5A ; any US-ASCII uppercase letter «A»..»Z»
LOALPHA = %x61-7A ; any US-ASCII lowercase letter «a»..»z»
ALPHA = UPALPHA / LOALPHA
DIGIT = %x30-39 ; any US-ASCII digit «0»..»9″
CTL = %x00-1F / %x7F ; any US-ASCII control character ; (octets 0 — 31) and DEL (127)
CR = %x0D ; US-ASCII CR, carriage return (13)
LF = %x0A ; US-ASCII LF, linefeed (10)
SP = %x20 ; US-ASCII SP, space (32)
HT = %x09 ; US-ASCII HT, horizontal-tab (9)
BACKSLASH = %x5C ; US-ASCII backslash (92)
CRLF = CR LF
LWS = [CRLF] 1*( SP / HT ) ; Line-breaking whitespace
SWS = [LWS] ; Separating whitespace
HCOLON = *( SP / HT ) «:» SWS
TEXT = %x20-7E / %x80-FF ; any OCTET except CTLs
tspecials = «(» / «)» / «<» / «>» / «@» / «,» / «;» / «:» / BACKSLASH / DQUOTE / «/» / «[» / «]» / «?» / «=» / «{» / «}» / SP / HT
token = 1*(%x21 / %x23-27 / %x2A-2B / %x2D-2E / %x30-39 / %x41-5A / %x5E-7A / %x7C / %x7E) ; 1*<any CHAR except CTLs or tspecials>
quoted-string = ( DQUOTE *qdtext DQUOTE )

qdtext = %x20-21 / %x23-5B / %x5D-7E / quoted-pair / UTF8-NONASCII ; No DQUOTE and no «\»
quoted-pair = «\\» / ( «\» DQUOTE )
ctext = %x20-27 / %x2A-7E / %x80-FF ; any OCTET except CTLs, «(» and «)»
generic-param = token [ EQUAL gen-value ]
gen-value = token / host / quoted-string

safe = «$» / «-» / «_» / «.» / «+»
extra = «!» / «*» / «’» / «(» / «)» / «,»
rtsp-extra = «!» / «*» / «’» / «(» / «)»

HEX = DIGIT / «A» / «B» / «C» / «D» / «E» / «F» / «a» / «b» / «c» / «d» / «e» / «f»
LHEX = DIGIT / «a» / «b» / «c» / «d» / «e» / «f» ; lowercase «a-f» Hex
reserved = «;» / «/» / «?» / «:» / «@» / «&» / «=»

unreserved = ALPHA / DIGIT / safe / extra
rtsp-unreserved = ALPHA / DIGIT / safe / rtsp-extra

base64 = *base64-unit [base64-pad]
base64-unit = 4base64-char
base64-pad = (2base64-char «==») / (3base64-char «=»)
base64-char = ALPHA / DIGIT / «+» / «/»
SLASH = SWS «/» SWS ; slash
EQUAL = SWS «=» SWS ; equal
LPAREN = SWS «(» SWS ; left parenthesis
RPAREN = SWS «)» SWS ; right parenthesis
COMMA = SWS «,» SWS ; comma
SEMI = SWS «;» SWS ; semicolon
COLON = SWS «:» SWS ; colon
MINUS = SWS «-» SWS ; minus/dash
LDQUOT = SWS DQUOTE ; open double quotation mark
RDQUOT = DQUOTE SWS ; close double quotation mark
RAQUOT = «>» SWS ; right angle quote
LAQUOT = SWS «<» ; left angle quote

TEXT-UTF8char = %x21-7E / UTF8-NONASCII
UTF8-NONASCII = UTF8-2 / UTF8-3 / UTF8-4
UTF8-1 = <As defined in RFC 3629>
UTF8-2 = <As defined in RFC 3629>
UTF8-3 = <As defined in RFC 3629>
UTF8-4 = <As defined in RFC 3629>
UTF8-tail = <As defined in RFC 3629>

POS-FLOAT = 1*12DIGIT [«.» 1*9DIGIT]
FLOAT = [«-«] POS-FLOAT

20.2. Определение протокола RTSP

20.2.1. Общие элементы протокола

RTSP-IRI = schemes «:» IRI-rest
IRI-rest = ihier-part [ «?» iquery ]
ihier-part = «//» iauthority ipath-abempty
RTSP-IRI-ref = RTSP-IRI / irelative-ref
irelative-ref = irelative-part [ «?» iquery ]
irelative-part = «//» iauthority ipath-abempty / ipath-absolute / ipath-noscheme / ipath-empty

iauthority = < As defined in RFC 3987 #>
ipath = ipath-abempty ; begins with «/» or is empty
/ ipath-absolute ; begins with «/» but not «//»
/ ipath-noscheme ; begins with a non-colon segment
/ ipath-rootless ; begins with a segment
/ ipath-empty ; zero characters

ipath-abempty = *( «/» isegment )
ipath-absolute = «/» [ isegment-nz *( «/» isegment ) ]
ipath-noscheme = isegment-nz-nc *( «/» isegment )
ipath-rootless = isegment-nz *( «/» isegment )
ipath-empty = 0<ipchar>

isegment = *ipchar [«;» *ipchar]
isegment-nz = 1*ipchar [«;» *ipchar]
/ «;» *ipchar
isegment-nz-nc = (1*ipchar-nc [«;» *ipchar-nc])
/ «;» *ipchar-nc
; non-zero-length segment without any colon «:»
; No parameter (; delimited) inside path.

ipchar = iunreserved / pct-encoded / sub-delims / «:» / «@»
ipchar-nc = iunreserved / pct-encoded / sub-delims / «@»
; sub-delims is different from RFC 3987 #
; not including «;»

iquery = < As defined in RFC 3987 #>
iunreserved = < As defined in RFC 3987 #>
pct-encoded = < As defined in RFC 3987 #>

RTSP-URI = schemes «:» URI-rest
RTSP-REQ-URI = schemes «:» URI-req-rest
RTSP-URI-Ref = RTSP-URI / RTSP-Relative
RTSP-REQ-Ref = RTSP-REQ-URI / RTSP-REQ-Rel
schemes = «rtsp» / «rtsps» / scheme
scheme = < As defined in RFC 3986 #>
URI-rest = hier-part [ «?» query ]
URI-req-rest = hier-part [ «?» query ]
; Note fragment part not allowed in requests
hier-part = «//» authority path-abempty

RTSP-Relative = relative-part [ «?» query ]
RTSP-REQ-Rel = relative-part [ «?» query ]
relative-part = «//» authority path-abempty / path-absolute / path-noscheme / path-empty

authority = < As defined in RFC 3986 #>
query = < As defined in RFC 3986 #>

path = path-abempty ; begins with «/» or is empty
/ path-absolute ; begins with «/» but not «//»
/ path-noscheme ; begins with a non-colon segment
/ path-rootless ; begins with a segment
/ path-empty ; zero characters

path-abempty = *( «/» segment )
path-absolute = «/» [ segment-nz *( «/» segment ) ]
path-noscheme = segment-nz-nc *( «/» segment )
path-rootless = segment-nz *( «/» segment )
path-empty = 0<pchar>

segment = *pchar [«;» *pchar]
segment-nz = ( 1*pchar [«;» *pchar]) / («;» *pchar)
segment-nz-nc = ( 1*pchar-nc [«;» *pchar-nc]) / («;» *pchar-nc)
; non-zero-length segment without any colon «:»
; No parameter (; delimited) inside path.

pchar = unreserved / pct-encoded / sub-delims / «:» / «@»
pchar-nc = unreserved / pct-encoded / sub-delims / «@»

sub-delims = «!» / «$» / «&» / «’» / «(» / «)»
/ «*» / «+» / «,» / «=»
; sub-delims is different from RFC 3986 # /RFC 3987 #
; not including «;»

smpte-range = smpte-type [EQUAL smpte-range-spec]; Смотри раздел 4.4
smpte-range-spec = ( smpte-time «-» [ smpte-time ] )
/ ( «-» smpte-time )
smpte-type = «smpte» / «smpte-30-drop»
/ «smpte-25» / smpte-type-extension
; other timecodes may be added
smpte-type-extension = «smpte» token
smpte-time = 1*2DIGIT «:» 1*2DIGIT «:» 1*2DIGIT
[ «:» 1*2DIGIT [ «.» 1*2DIGIT ] ]

npt-range = «npt» [EQUAL npt-range-spec]
npt-range-spec = ( npt-time «-» [ npt-time ] ) / ( «-» npt-time )
npt-time = «now» / npt-sec / npt-hhmmss / npt-hhmmss-comp
npt-sec = 1*19DIGIT [ «.» 1*9DIGIT ]
npt-hhmmss = npt-hh «:» npt-mm «:» npt-ss [ «.» 1*9DIGIT ]
npt-hh = 2*19DIGIT ; any positive number
npt-mm = 2*2DIGIT ; 0-59
npt-ss = 2*2DIGIT ; 0-59
npt-hhmmss-comp = npt-hh-comp «:» npt-mm-comp «:» npt-ss-comp
[ «.» 1*9DIGIT ] ; Compatibility format

npt-hh-comp = 1*19DIGIT ; any positive number
npt-mm-comp = 1*2DIGIT ; 0-59
npt-ss-comp = 1*2DIGIT ; 0-59

utc-range = «clock» [EQUAL utc-range-spec]
utc-range-spec = ( utc-time «-» [ utc-time ] ) / ( «-» utc-time )
utc-time = utc-date «T» utc-clock «Z»
utc-date = 8DIGIT
utc-clock = 6DIGIT [ «.» 1*9DIGIT ]

feature-tag = token

session-id = 1*256( ALPHA / DIGIT / safe )

extension-header = header-name HCOLON header-value
header-name = token
header-value = *(TEXT-UTF8char / LWS)

20.2.2. Синтаксис сообщения

RTSP-message = Request / Response ; RTSP/2.0 messages

Request = Request-Line
*((general-header
/ request-header
/ message-body-header) CRLF)
CRLF
[ message-body-data ]

Response = Status-Line
*((general-header
/ response-header
/ message-body-header) CRLF)
CRLF
[ message-body-data ]

Request-Line = Method SP Request-URI SP RTSP-Version CRLF

Status-Line = RTSP-Version SP Status-Code SP Reason-Phrase CRLF

Method = «DESCRIBE»
/ «GET_PARAMETER»
/ «OPTIONS»
/ «PAUSE»
/ «PLAY»
/ «PLAY_NOTIFY»
/ «REDIRECT»
/ «SETUP»
/ «SET_PARAMETER»
/ «TEARDOWN»
/ extension-method

extension-method = token

Request-URI = «*» / RTSP-REQ-URI
RTSP-Version = «RTSP/» 1*DIGIT «.» 1*DIGIT

message-body-data = 1*OCTET

Status-Code = «100» ; Continue
/ «200» ; OK
/ «301» ; Moved Permanently
/ «302» ; Found
/ «303» ; See Other
/ «304» ; Not Modified
/ «305» ; Use Proxy
/ «400» ; Bad Request
/ «401» ; Unauthorized
/ «402» ; Payment Required
/ «403» ; Forbidden
/ «404» ; Not Found
/ «405» ; Method Not Allowed
/ «406» ; Not Acceptable
/ «407» ; Proxy Authentication Required
/ «408» ; Request Timeout
/ «410» ; Gone
/ «412» ; Precondition Failed
/ «413» ; Request Message Body Too Large
/ «414» ; Request-URI Too Long
/ «415» ; Unsupported Media Type
/ «451» ; Parameter Not Understood
/ «452» ; reserved
/ «453» ; Not Enough Bandwidth
/ «454» ; Session Not Found
/ «455» ; Method Not Valid In This State
/ «456» ; Header Field Not Valid for Resource
/ «457» ; Invalid Range
/ «458» ; Parameter Is Read-Only
/ «459» ; Aggregate Operation Not Allowed
/ «460» ; Only Aggregate Operation Allowed
/ «461» ; Unsupported Transport
/ «462» ; Destination Unreachable
/ «463» ; Destination Prohibited
/ «464» ; Data Transport Not Ready Yet
/ «465» ; Notification Reason Unknown
/ «466» ; Key Management Error
/ «470» ; Connection Authorization Required
/ «471» ; Connection Credentials Not Accepted
/ «472» ; Failure to Establish Secure Connection
/ «500» ; Internal Server Error
/ «501» ; Not Implemented
/ «502» ; Bad Gateway
/ «503» ; Service Unavailable
/ «504» ; Gateway Timeout
/ «505» ; RTSP Version Not Supported
/ «551» ; Option Not Supported
/ «553» ; Proxy Unavailable
/ extension-code
extension-code = 3DIGIT
Reason-Phrase = 1*(TEXT-UTF8char / HT / SP)

rtsp-header = general-header
/ request-header
/ response-header
/ message-body-header

general-header = Accept-Ranges
/ Cache-Control
/ Connection
/ CSeq
/ Date
/ Media-Properties
/ Media-Range
/ Pipelined-Requests
/ Proxy-Supported
/ Range
/ RTP-Info
/ Scale
/ Seek-Style
/ Server
/ Session
/ Speed
/ Supported
/ Timestamp
/ Transport
/ User-Agent
/ Via
/ extension-header

request-header = Accept
/ Accept-Credentials
/ Accept-Encoding
/ Accept-Language
/ Authorization
/ Bandwidth
/ Blocksize
/ From
/ If-Match
/ If-Modified-Since
/ If-None-Match
/ Notify-Reason
/ Proxy-Authorization
/ Proxy-Require
/ Referrer
/ Request-Status
/ Require
/ Terminate-Reason
/ extension-header

response-header = Authentication-Info
/ Connection-Credentials
/ Location
/ MTag
/ Proxy-Authenticate
/ Proxy-Authentication-Info
/ Public
/ Retry-After
/ Unsupported
/ WWW-Authenticate
/ extension-header

message-body-header = Allow
/ Content-Base
/ Content-Encoding
/ Content-Language
/ Content-Length
/ Content-Location
/ Content-Type
/ Expires
/ Last-Modified
/ extension-header

20.2.3. Синтаксис заголовка

Accept = «Accept» HCOLON [ accept-range *(COMMA accept-range) ]

accept-range = media-type-range [SEMI accept-params]

media-type-range = ( «*/*» / ( m-type SLASH «*» ) / ( m-type SLASH m-subtype ) ) *( SEMI m-parameter )

accept-params = «q» EQUAL qvalue *(SEMI generic-param )

qvalue = ( «0» [ «.» *3DIGIT ] ) / ( «1» [ «.» *3(«0») ] )

Accept-Credentials = «Accept-Credentials» HCOLON cred-decision

cred-decision = («User» [LWS cred-info]) / «Proxy» / «Any» / (token [LWS 1*header-value]) ; Для будущих расширений

cred-info = cred-info-data *(COMMA cred-info-data)

cred-info-data = DQUOTE RTSP-REQ-URI DQUOTE SEMI hash-alg SEMI base64

hash-alg = «sha-256» / extension-alg

extension-alg = token

Accept-Encoding = «Accept-Encoding» HCOLON [ encoding *(COMMA encoding) ]

encoding = codings [SEMI accept-params]

codings = content-coding / «*»

content-coding = «identity» / token

Accept-Language = «Accept-Language» HCOLON language *(COMMA language)

language = language-range [SEMI accept-params]

language-range = language-tag / «*»

language-tag = primary-tag *( «-» subtag )

primary-tag = 1*8ALPHA

subtag = 1*8ALPHA

Accept-Ranges = «Accept-Ranges» HCOLON acceptable-ranges

acceptable-ranges = (range-unit *(COMMA range-unit))

range-unit = «npt» / «smpte» / «smpte-30-drop» / «smpte-25» / «clock» / extension-format

extension-format = token

Allow = «Allow» HCOLON Method *(COMMA Method)

Authentication-Info = «Authentication-Info» HCOLON auth-param-list

auth-param-list = <As the Authentication-Info element in RFC 7615 #>

Authorization = «Authorization» HCOLON credentials

credentials = <Определено в RFC 7235 #>

Bandwidth = «Bandwidth» HCOLON 1*19DIGIT

Blocksize = «Blocksize» HCOLON 1*9DIGIT

Cache-Control = «Cache-Control» HCOLON cache-directive *(COMMA cache-directive)

cache-directive = cache-rqst-directive / cache-rspns-directive

cache-rqst-directive = «no-cache»
/ «max-stale» [EQUAL delta-seconds]
/ «min-fresh» EQUAL delta-seconds
/ «only-if-cached»
/ cache-extension

cache-rspns-directive = «public»
/ «private»
/ «no-cache»
/ «no-transform»
/ «must-revalidate»
/ «proxy-revalidate»
/ «max-age» EQUAL delta-seconds
/ cache-extension

cache-extension = token [EQUAL (token / quoted-string)]

delta-seconds = 1*19DIGIT

Connection = «Connection» HCOLON connection-token *(COMMA connection-token)

connection-token = «close» / token

Connection-Credentials = «Connection-Credentials» HCOLON cred-chain

cred-chain = DQUOTE RTSP-REQ-URI DQUOTE SEMI base64

Content-Base = «Content-Base» HCOLON RTSP-URI

Content-Encoding = «Content-Encoding» HCOLON content-coding *(COMMA content-coding)

Content-Language = «Content-Language» HCOLON language-tag *(COMMA language-tag)

Content-Length = «Content-Length» HCOLON 1*19DIGIT

Content-Location = «Content-Location» HCOLON RTSP-REQ-Ref

Content-Type = «Content-Type» HCOLON media-type

media-type = m-type SLASH m-subtype *(SEMI m-parameter)

m-type = discrete-type / composite-type

discrete-type = «text» / «image» / «audio» / «video» / «application» / extension-token

composite-type = «message» / «multipart» / extension-token

extension-token = ietf-token / x-token

ietf-token = token

x-token = «x-» token

m-subtype = extension-token / iana-token

iana-token = token

m-parameter = m-attribute EQUAL m-value

m-attribute = token

m-value = token / quoted-string

CSeq = «CSeq» HCOLON cseq-nr

cseq-nr = 1*9DIGIT

Date = «Date» HCOLON RTSP-date

RTSP-date = date-time ;

date-time = <Определён в RFC 5322>

Expires = «Expires» HCOLON RTSP-date

From = «From» HCOLON from-spec

from-spec = ( name-addr / addr-spec ) *( SEMI from-param )

name-addr = [ display-name ] LAQUOT addr-spec RAQUOT

addr-spec = RTSP-REQ-URI / absolute-URI

absolute-URI = < Определён в RFC 3986 #>

display-name = *(token LWS) / quoted-string

from-param = tag-param / generic-param

tag-param = «tag» EQUAL token

If-Match = «If-Match» HCOLON («*» / message-tag-list)

message-tag-list = message-tag *(COMMA message-tag)

message-tag = [ weak ] opaque-tag

weak = «W/»

opaque-tag = quoted-string

If-Modified-Since = «If-Modified-Since» HCOLON RTSP-date

If-None-Match = «If-None-Match» HCOLON («*» / message-tag-list)

Last-Modified = «Last-Modified» HCOLON RTSP-date

Location = «Location» HCOLON RTSP-REQ-URI

Media-Properties = «Media-Properties» HCOLON [media-prop-list]

media-prop-list = media-prop-value *(COMMA media-prop-value)

media-prop-value = («Random-Access» [EQUAL POS-FLOAT])
/ «Beginning-Only»
/ «No-Seeking»
/ «Immutable»
/ «Dynamic»
/ «Time-Progressing»
/ «Unlimited»
/ («Time-Limited» EQUAL utc-time)
/ («Time-Duration» EQUAL POS-FLOAT)
/ («Scales» EQUAL scale-value-list)
/ media-prop-ext

media-prop-ext = token [EQUAL (1*rtsp-unreserved / quoted-string)]

scale-value-list = DQUOTE scale-entry *(COMMA scale-entry) DQUOTE

scale-entry = scale-value / (scale-value COLON scale-value)

scale-value = FLOAT

Media-Range = «Media-Range» HCOLON [ranges-list]

ranges-list = ranges-spec *(COMMA ranges-spec)

MTag = «MTag» HCOLON message-tag

Notify-Reason = «Notify-Reason» HCOLON Notify-Reas-val

Notify-Reas-val = «end-of-stream»
/ «media-properties-update»
/ «scale-change»
/ Notify-Reason-extension

Notify-Reason-extension = token

Pipelined-Requests = «Pipelined-Requests» HCOLON startup-id

startup-id = 1*8DIGIT

Proxy-Authenticate = «Proxy-Authenticate» HCOLON challenge-list

challenge-list = <Определено как WWW-Authenticate в RFC 7235 #>

Proxy-Authentication-Info = «Proxy-Authentication-Info» HCOLON auth-param-list

Proxy-Authorization = «Proxy-Authorization» HCOLON credentials

Proxy-Require = «Proxy-Require» HCOLON feature-tag-list

feature-tag-list = feature-tag *(COMMA feature-tag)

Proxy-Supported = «Proxy-Supported» HCOLON [feature-tag-list]

Public = «Public» HCOLON Method *(COMMA Method)

Range = «Range» HCOLON ranges-spec

ranges-spec = npt-range / utc-range / smpte-range / range-ext

range-ext = extension-format [EQUAL range-value]

range-value = 1*(rtsp-unreserved / quoted-string / «:» )

Referrer = «Referrer» HCOLON (absolute-URI / RTSP-URI-Ref)

Request-Status = «Request-Status» HCOLON req-status-info

req-status-info = cseq-info LWS status-info LWS reason-info

cseq-info = «cseq» EQUAL cseq-nr

status-info = «status» EQUAL Status-Code

reason-info = «reason» EQUAL DQUOTE Reason-Phrase DQUOTE

Require = «Require» HCOLON feature-tag-list

RTP-Info = «RTP-Info» HCOLON [rtsp-info-spec *(COMMA rtsp-info-spec)]

rtsp-info-spec = stream-url 1*ssrc-parameter

stream-url = «url» EQUAL DQUOTE RTSP-REQ-Ref DQUOTE

ssrc-parameter = LWS «ssrc» EQUAL ssrc HCOLON ri-parameter *(SEMI ri-parameter)

ri-parameter = («seq» EQUAL 1*5DIGIT) / («rtptime» EQUAL 1*10DIGIT) / generic-param

Retry-After = «Retry-After» HCOLON (RTSP-date / delta-seconds)

Scale = «Scale» HCOLON scale-value

Seek-Style = «Seek-Style» HCOLON Seek-S-values

Seek-S-values = «RAP»
/ «CoRAP»
/ «First-Prior»
/ «Next»
/ Seek-S-value-ext

Seek-S-value-ext = token

Server = «Server» HCOLON ( product / comment )*(LWS (product / comment))

product = token [SLASH product-version]

product-version = token

comment = LPAREN *( ctext / quoted-pair) RPAREN

Session = «Session» HCOLON session-id [ SEMI «timeout» EQUAL delta-seconds ]

Speed = «Speed» HCOLON lower-bound MINUS upper-bound

lower-bound = POS-FLOAT

upper-bound = POS-FLOAT

Supported = «Supported» HCOLON [feature-tag-list]

Terminate-Reason = «Terminate-Reason» HCOLON TR-Info

TR-Info = TR-Reason *(SEMI TR-Parameter)

TR-Reason = «Session-Timeout» / «Server-Admin» / «Internal-Error» / token

TR-Parameter = TR-time / TR-user-msg / generic-param

TR-time = «time» EQUAL utc-time

TR-user-msg = «user-msg» EQUAL quoted-string

Timestamp = «Timestamp» HCOLON timestamp-value [LWS delay]

timestamp-value = *19DIGIT [ «.» *9DIGIT ]

delay = *9DIGIT [ «.» *9DIGIT ]

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 #>

Unsupported = «Unsupported» HCOLON feature-tag-list

User-Agent = «User-Agent» HCOLON ( product / comment ) *(LWS (product / comment))

Via = «Via» HCOLON via-parm *(COMMA via-parm)

via-parm = sent-protocol LWS sent-by *( SEMI via-params )

via-params = via-ttl / via-maddr / via-received / via-extension

via-ttl = «ttl» EQUAL ttl

via-maddr = «maddr» EQUAL host

via-received = «received» EQUAL (IPv4address / IPv6address)

IPv4address = < Определён в RFC 3986 #>
IPv6address = < Определён в RFC 3986 #>

via-extension = generic-param

sent-protocol = protocol-name SLASH protocol-version SLASH transport-prot

protocol-name = «RTSP» / token

protocol-version = token

transport-prot = «UDP» / «TCP» / «TLS» / other-transport

other-transport = token

sent-by = host [ COLON port ]

WWW-Authenticate = «WWW-Authenticate» HCOLON challenge-list

20.3. Синтаксис расширения SDP

Этот раздел определяет в ABNF расширения SDP, определенные для RTSP. См. Приложение D для определения расширений в тексте.

control-attribute = «a=control:» *SP RTSP-REQ-Ref CRLF
a-range-def = «a=range:» ranges-spec CRLF
a-mtag-def = «a=mtag:» message-tag CRLF

21. Вопросы безопасности

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

В этом документе есть несколько глав и приложение, которые определяют решения безопасности для протокола. На эти разделы будут ссылаться при обсуждении угроз ниже. Однако читатель должен обратить особое внимание на структуру безопасности (раздел 19) и спецификацию того, как использовать SRTP и его управление ключами (приложение С.1.4) для достижения определенных аспектов безопасности мультимедиа.

21.1. Угрозы протокола сигнализации

Этот раздел посвящен вопросам, связанным с протоколом сигнализации. Из-за сходства в синтаксисе и использовании между серверами RTSP и серверами HTTP также применимы соображения безопасности, изложенные в [RFC7230 #], [RFC7231 #], [RFC7232 #], [RFC7233 #], [RFC7234 #] и [RFC7235 #].

В частности, обратите внимание на следующее:

Злоупотребление информацией журнала сервера (Abuse of Server Log Information). Сервер может сохранять личные данные о запросах пользователя, которые могут идентифицировать их модели потребления мультимедиа или интересующие их темы. Эта информация носит явно конфиденциальный характер, и в некоторых странах ее обработка может быть ограничена законодательством. Информация журнала должна быть надежно сохранена, и для ее анализа должны соблюдаться соответствующие рекомендации. См. Раздел 9.8 [RFC7230 #] для получения дополнительных указаний.

Передача конфиденциальной информации (Transfer of Sensitive Information). Нет оснований полагать, что информация, передаваемая в сообщении RTSP, такая как URI и содержимое заголовков, особенно заголовков Server, Via, Referrer и From, может быть менее чувствительной, чем при использовании в HTTP. , Поэтому все меры предосторожности, касающиеся защиты конфиденциальности данных и конфиденциальности пользователей, применяются к разработчикам клиентов RTSP, серверов и прокси-серверов. См. Разделы 9.3 ; 9.4 ; 9.5 ; 9.6 [RFC7231 #] для получения более подробной информации.

Методы RTSP, определенные в этом документе, в основном используются для установления и управления доставкой мультимедийных данных, представленных URI; таким образом, тела сообщений RTSP обычно менее чувствительны, чем в HTTP. Если тела HTTP могут содержать, например, ваши медицинские записи в RTSP, конфиденциальное видео вашей медицинской операции будет находиться в потоке мультимедиа по протоколу медиатранспорта, а не в сообщении RTSP. Тем не менее, необходимо принять к сведению, что потенциально конфиденциальная информация включена в RTSP. Защита мультимедийных данных является отдельной, может применяться непосредственно между клиентом и сервером и зависит от используемого протокола передачи мультимедиа. См. Раздел 21.2 для дальнейшего обсуждения. Эта возможность для разделения безопасности между контентом медиаресурса и протоколом сигнализации снижает риск раскрытия медиа контента при использовании защиты по скачкам для сигнализации RTSP с использованием прокси (Раздел 19.3).

Атаки на основе имен файлов и путей (Attacks Based On File and Path Names). Хотя URI RTSP являются непрозрачными дескрипторами, которые не обязательно имеют семантику файловой системы, ожидается, что многие реализации будут преобразовывать части Request-URI непосредственно в вызовы файловой системы. В таких случаях файловые системы ДОЛЖНЫ следовать мерам предосторожности, изложенным в Разделе 9.1 [RFC7231 #], таким как проверка «..» в компонентах пути.

Личная информация (Personal Information). Клиенты RTSP часто имеют доступ к той же информации, что и клиенты HTTP (имя пользователя, местоположение и т. д.) И поэтому должны быть одинаково чувствительными. См. Раздел 9.8 [RFC7230 #], разделы 9.3-9.7 [RFC7231 #] и раздел 8 [RFC7234 #] для получения дополнительных рекомендаций.

Проблемы конфиденциальности, связанные с заголовками Accept (Privacy Issues Connected to Accept Headers): поскольку в RTSP используются аналогичные заголовки «Accept», как и в HTTP, следует соблюдать те же предостережения, которые описаны в разделе 9.4 [RFC7231 #] в отношении их использования.

Установление полномочий (Establishing Authority): RTSP делится с HTTP вопросом о том, как клиент общается с авторитетным источником для потоков мультимедиа (Раздел 9.1 [RFC7230 #]). Используемые DNS-серверы, безопасность связи и любые возможности человека, находящегося посередине, и доверие к любым прокси-серверам RTSP — все это влияет на возможность получения клиентом неавторизованного ответа на запрос. Обеспечение получения клиентом авторитетного ответа является сложной задачей, хотя использование защищенной связи для передачи сигналов RTSP (rtsps) значительно упрощает его, поскольку сервер может предоставить подтверждение идентичности имени хоста при квитировании TLS.

Заголовки местоположения и спуфинг (Location Headers and Spoofing). Если один сервер поддерживает несколько организаций, которые не доверяют друг другу, тогда он ДОЛЖЕН проверить значения полей заголовка Content-Location в ответах, которые сгенерированы под управлением указанных организаций, чтобы убедиться, что они не пытаются признать недействительными ресурсы, на которые они не имеют полномочий (см. раздел 15.4 [RFC2616 #]).

В дополнение к рекомендациям в текущих спецификациях HTTP ([RFC7230 #], [RFC7231 #], [RFC7232 #], [RFC7233 #], [RFC7234 #] и [RFC7235 #] на момент написания этой статьи), а также к рекомендациям предыдущих соответствующих RFC [RFC2068 #] [RFC2616 #], будущие спецификации HTTP могут предоставить дополнительные рекомендации по вопросам безопасности.

Ниже приведены дополнительные соображения по реализации RTSP.

Перехват сеанса (Session Hijacking): поскольку между соединением транспортного уровня и сеансом RTSP нет или мало связи, злонамеренный клиент может выдавать запросы со случайными идентификаторами сеанса, которые могут повлиять на других клиентов ничего не подозревающего сервера. Чтобы смягчить это, сервер ДОЛЖЕН использовать большой, случайный и непоследовательный идентификатор сеанса, чтобы минимизировать возможность такого рода атак. Однако, если сигнализация RTSP не всегда защищена конфиденциальностью, например, с использованием TLS, злоумышленник на пути сможет перехватить сеанс. Другой способ предотвращения перехвата сеанса состоит в том, чтобы использовать аутентификацию клиента и разрешить только аутентифицированному клиенту, создающему сеанс, доступ к этому сеансу.

Аутентификация (Authentication): Серверы ДОЛЖНЫ реализовывать как базовую, так и дайджест-аутентификацию [RFC2617 #]. В средах, требующих более строгой защиты для управляющих сообщений, СЛЕДУЕТ использовать механизм транспортного уровня TLS [RFC5246 #].

Подозрительное поведение (Suspicious Behavior): при обнаружении случаев поведения, которое считается угрозой безопасности, серверам RTSP СЛЕДУЕТ возвращать код ошибки 403 (запрещено). Серверы RTSP ДОЛЖНЫ также знать о попытках проверить сервер на наличие слабых мест и точек входа и МОГУТ произвольно отключаться и игнорировать дальнейшие запросы от клиентов, которые считаются нарушающими локальную политику безопасности.

TLS через прокси (TLS through Proxies): если кто-то использует возможность подключения TLS в нескольких ветвях (раздел 19.3), ему действительно необходимо знать модель доверия. Эта процедура требует доверия ко всем прокси-серверам части пути к серверу. Прокси-серверы, с которыми соединяются, идентифицируются, при условии, что прокси-серверы, подключенные через него, хорошо себя ведут и выполняют доверительные отношения. Принятые прокси — это люди в середине и имеют доступ ко всему, что происходит через соединение TLS. Таким образом, важно учитывать, приемлема ли эта модель доверия в реальном приложении. Дальнейшее обсуждение фактической модели доверия находится в разделе 19.3. Важно отметить, какая разница в свойствах безопасности, если таковые имеются, может существовать в используемом протоколе медиатранспорта и его механизме безопасности. Использование SRTP и основанного на MIKEY установления ключа, определенного в Приложении C.1.4.1, позволяет устанавливать медиа-ключи сквозным образом без раскрытия ключей для прокси-серверов.

Исчерпание ресурсов (Resource Exhaustion): поскольку RTSP является протоколом с отслеживанием состояния и устанавливает использование ресурсов на сервере, существует явная возможность атаковать сервер, пытаясь перебазировать эти ресурсы для выполнения DoS-атаки. Эта атака может быть направлена как против текущих сессий, так и против других. Агенты RTSP должны будут иметь механизмы, позволяющие предотвратить одноранговое использование больших объемов ресурсов. Методы защиты от этого разнообразны и зависят от роли, возможностей и политик агента. Каждая реализация должна тщательно рассмотреть свои методы и политику, чтобы уменьшить эту угрозу. В разделе 10.7 приведены рекомендации по обработке соединений.

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

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

21.2. Угрозы доставки медиапотока

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

Множество общих угроз со стороны самой доставки медиапотока:

Концентрированная атака типа «отказ в обслуживании» (Concentrated Denial-of-Service Attack): протокол предоставляет возможность для дистанционной атаки DoS, где поток мультимедиа является молотком в этой DoS-атаке. См. Раздел 21.2.1.

Конфиденциальность мультимедиа (Media Confidentiality). Доставка мультимедиа может содержать контент любого типа, и, как правило, невозможно определить, насколько этот контент чувствителен с точки зрения конфиденциальности. Таким образом, строгое требование, чтобы любой протокол доставки мультимедиа предоставлял метод обеспечения конфиденциальности реального медиаконтента. В дополнение к конфиденциальности на уровне носителей становится критически важным, чтобы идентификаторы ресурсов, использованные в сигнализации, не подвергались злоумышленнику, поскольку они могут иметь понятные человеку имена или могут быть доступны злоумышленнику, что позволяет ему определять контент, полученный пользователем , Таким образом, протокол сигнализации также должен обеспечивать защиту конфиденциальности любой информации, связанной с медиаресурсом.

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

Объем многоадресной рассылки (Scope of Multicast): если RTSP используется для управления передачей мультимедиа в многоадресную сеть, необходимо учитывать объем доставки. RTSP поддерживает параметр заголовка транспорта TTL, чтобы указать эту область для IPv4. IPv6 имеет другой механизм для границы области. Однако такой контроль объема имеет риски, так как он может быть слишком большим и распространять носители за пределами предполагаемой области.

Ниже (раздел 21.2.2) включен специфический для протокола анализ соображений безопасности для транспорта мультимедиа на основе RTP. В этом разделе разъясняются требования к реализации функций безопасности для агентов RTSP, поддерживающих доставку мультимедиа по RTP.

21.2.1. Удаленная DoS-атака

Злоумышленник может инициировать потоки трафика на один или несколько IP-адресов, указав их в качестве пункта назначения в запросах SETUP. Хотя в этом случае может быть известен IP-адрес злоумышленника, это не всегда полезно для предотвращения новых атак или установления личности злоумышленника. Таким образом, сервер RTSP ДОЛЖЕН разрешать указанные клиентом пункты назначения для потоков трафика, инициируемых RTSP, только если сервер обеспечил, чтобы указанный адрес назначения принимал принимающую среду через различные механизмы безопасности. Механизмы безопасности, которые приемлемы в порядке возрастающей общности:

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

Серверу НЕ СЛЕДУЕТ разрешать установку поля назначения, если в системе не существует механизма, позволяющего авторизовать инициатора запроса направлять потоки получателю. Предпочтительно, чтобы эта авторизация выполнялась самим получателем мультимедиа (адресатом), а учетные данные передавались на сервер. Однако в некоторых случаях, например, когда адрес получателя является группой многоадресной рассылки или когда получатель не может связаться с сервером внеполосным способом, это может оказаться невозможным. В этих случаях сервер может выбрать другой метод, такой как список авторизации резидентного сервера, чтобы убедиться, что инициатор запроса имеет надлежащие учетные данные для запроса доставки потока получателю.

Одним из решений, которое выполняет необходимую проверку приема носителей, подходящих для одноадресной доставки, является метод обхода NAT, основанный на установлении интерактивного подключения (ICE) [RFC5245 #], описанном в [RFC7825 #]. Этот механизм использует случайные пароли и имя пользователя, так что вероятность непреднамеренного указания в качестве действительного места назначения носителя очень мала. Кроме того, сервер включает в свои утилиты обхода сеанса для NAT (STUN) [RFC5389 #] запросы куки-файла (состоящего из случайного материала), который адресат возвращает эхом; таким образом, решение также защищает от того, что злоумышленник вне пути сможет подделать проверки STUN. Это оставляет это решение уязвимым только для злоумышленников, которые могут видеть, что запросы STUN направляются к цели атаки и таким образом подделывают ответ.

Для доставки по групповым адресам необходимо другое решение, которое не указано в этом документе.

21.2.2. Анализ безопасности RTP

RTP является широко используемым медиатранспортным протоколом и был наиболее распространенным выбором для реализаций RTSP 1.0. Основной протокол RTP использовался в течение длительного времени, и он обладает хорошо известными свойствами безопасности, и необходимо пересмотреть соображения безопасности RTP (раздел 9 [RFC3550 #]). В перспективе использования RTP в контексте RTSP следует отметить следующие свойства:

Добавление потоков (Stream Additions): RTP поддерживает несколько одновременных потоков мультимедиа в каждом сеансе RTP. Поскольку некоторые варианты использования требуют поддержки несинхронизированного добавления и удаления медиапотоков и их идентификаторов, злоумышленник может легко вставить дополнительные медиапотоки в контекст сеанса, который, согласно схеме протокола, предназначен для воспроизведения. Другим вектором угрозы является один из DoS, истощающий ресурсы приемника сеанса RTP, например, при одновременном использовании большого количества идентификаторов SSRC. Сильное уменьшение этого состоит в том, чтобы гарантировать, что один криптографически аутентифицирует любой поток входящих пакетов в сеанс RTP. Слабые меры по снижению риска, такие как блокировка дополнительных потоков мультимедиа в контексте сеанса, легко приводят к уязвимости DoS, в дополнение к предотвращению определенных расширений RTP или случаев использования, которые полагаются на работу нескольких потоков мультимедиа, таких как повторная передача RTP [RFC4588 #].

Подделанная обратная связь (Forged Feedback): встроенный RTCP также предлагает большую поверхность атаки для пары различных типов атак. Одним из способов является отправка обратной связи RTCP отправителю мультимедиа, указывающей большие потери пакетов, и, таким образом, инициирование отклика адаптации битрейта мультимедиа от отправителя, что приводит к снижению качества мультимедиа и, возможно, к прекращению потока мультимедиа. Другая атака заключается в том, чтобы выполнить атаку с исчерпанием ресурсов на приемнике, используя множество идентификаторов SSRC для создания больших таблиц состояний и повышения требований к обработке, связанной с RTCP.

Расширения RTP / RTCP (RTP/RTCP Extensions): Расширения RTP и RTCP обычно предоставляют дополнительные, а иногда и чрезвычайно мощные инструменты для DoS-атак или прерывания обслуживания. Например, расширение RTCP сообщения управления кодом [RFC5104 #] обеспечивает как блокировку битрейта до низких значений, так и нарушение качества видео путем запроса внутрикадровых кадров.

Принимая во внимание вышеупомянутое общее обсуждение в Разделе 21.2 и конкретное обсуждение RTP в этом разделе, ясно, что необходимо поддерживать сильный механизм безопасности для защиты RTP. Следовательно, эта спецификация предъявляет следующие требования к функциям безопасности RTP для всех агентов RTSP, которые обрабатывают медиапотоки, и где передача медиапотока завершается с использованием RTP.

Агенты RTSP, поддерживающие RTP, ДОЛЖНЫ реализовать Secure RTP (SRTP) [RFC3711 #] и, таким образом, SAVP. Кроме того, SAVPF [RFC5124 #] ДОЛЖЕН также поддерживаться, если реализован AVPF. Эта спецификация не требует никаких дополнительных криптографических преобразований или значений конфигурации, кроме тех, которые определены как обязательные для реализации в RFC 3711 #, то есть AES-CM и HMAC-SHA1. Механизм управления ключами по умолчанию, который ДОЛЖЕН быть реализован, является тем, который определен в Установлении ключа MIKEY (Приложение C.1.4.1). Реализация MIKEY ДОЛЖНА реализовывать необходимые функции для режима MIKEY-RSA-R [RFC4738 #] и согласования параметров SRTP, необходимых для согласования поддерживаемых преобразований и параметров SRTP.

22. Соображения IANA

В этом разделе описан ряд реестров для RTSP 2.0, которые были созданы и поддерживаются IANA. Эти реестры отделены от любых реестров, существующих для RTSP 1.0. Для каждого реестра есть описание необходимого контента, процедур регистрации и записей, которые регистрирует этот документ. Для получения дополнительной информации о расширении RTSP см. Раздел 2.7. Кроме того, этот документ регистрирует три атрибута SDP.

Реестры или записи в реестрах, созданные для RTSP 1.0, не переносятся в RTSP 2.0: реестры и записи в RTSP 1.0 и RTSP 2.0 являются независимыми. Если какой-либо реестр или запись в реестре также требуется в RTSP 2.0, он ДОЛЖЕН следовать процедуре, определенной ниже, для выделения реестра или записи в реестре.

Разделы, описывающие, как зарегистрировать элемент, используют некоторые из политик регистрации, описанных в [RFC5226 #], а именно: «Первым прибыл первым обслужен», «Проверка эксперта», «Требуется спецификация» и «Действие по стандартам».

В случае, если для регистрации требуется контактное лицо, авторы (с Магнусом Вестерлундом <magnus.westerlund@ericsson.com> в качестве основного) являются контактными лицами для любых записей, созданных в этом документе.

IANA запросит следующую информацию для любого запроса на регистрацию:

Имя элемента для регистрации в соответствии с правилами, указанными в предполагаемом реестре
Указание того, кто имеет контроль над изменением этой функции (например, IETF, ISO, ITU-T, другие международные органы по стандартизации, консорциум, конкретная компания или группа компаний или физическое лицо)
Ссылка на дополнительное описание, если оно доступно, например (в порядке убывания предпочтения), RFC, опубликованный стандарт, опубликованная статья, подача заявки на патент, технический отчет, документированный исходный код или компьютерное руководство.
Для фирменных функций, контактную информацию (почтовый и электронный адрес)

22.1. Теги функций

22.1.1. Описание

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

Использование тегов функций объясняется в Разделе 11 и Разделе 13.1.

22.1.2. Регистрация новых тегов функций в IANA

Регистрация тегов объектов выполняется в порядке поступления заявок [RFC5226 #].

Запись реестра для тега функции содержит следующую информацию:

Имя тега функции
* Если владелец регистрации указывает, что эта функция является собственностью, IANA должна запросить часть имени поставщика с префиксом. Тогда имя будет префиксом поставщика, за которым следует «.» сопровождаемый остальной частью предоставленного имени функции.
* Если эта функция не является частной, то IANA не нужно собирать префикс для имени.
Описание из одного абзаца, что представляет тег функции
Применимость (сервер, клиент, прокси или некоторая комбинация)
Ссылка на спецификацию, если применимо

Имена тегов компонентов (включая префикс поставщика) могут содержать любые непробельные и неуправляемые символы. Для тегов объектов нет ограничений по длине.

Примеры тега вендора, описывающего частную функцию:

vendorA.specfeat01
vendorA.specfeat02

22.1.3. Зарегистрированные записи

Следующие теги функций определены в данной спецификации и тем самым зарегистрированы. Управление изменениями принадлежит IETF.

play.basic: реализация для операций доставки и воспроизведения в соответствии с базовой спецификацией RTSP, как определено в этой заметке. Применяется для клиентов, серверов и прокси. Смотрите Раздел 11.1.

play.scale: поддержка операций масштабирования для воспроизведения мультимедиа. Применяется только для серверов. Смотри раздел 18.46.

play.speed: поддержка скоростного функционала для доставки медиа. Применяется только для серверов. См. Раздел 18.50.

setup.rtp.rtcp.mux: Поддержка мультиплексирования RTP и RTCP, как описано в Приложении C.1.6.4. Применяется как для клиента, так и для серверов, а также для любого прокси-сервера медиа-кэширования.

Реестр IANA — это таблица с именем, описанием и ссылкой для каждого тега функции.

22.2. Методы RTSP

22.2.1. Описание

Методы описаны в разделе 13. Расширение протокола новыми методами обеспечивает совершенно новую функциональность.

22.2.2. Регистрация новых методов в IANA

Новый метод зарегистрирован через Стандартное действие [RFC5226 #], потому что новые методы могут радикально изменить поведение и цель протокола.
Спецификация для нового метода RTSP состоит из следующих элементов:

Имя метода, соответствующее правилам ABNF для методов.
Четкая спецификация того, что делает запрос с использованием метода и какие ответы ожидаются. В каких направлениях используется метод: C-> S, S-> C или оба. Как использование заголовков, если таковые имеются, изменяет поведение и эффект метода.
Список или таблица, в которых указывается, какие из IANA-зарегистрированных заголовков разрешено использовать с методом в запросе или / и ответе. Список или таблица ДОЛЖНЫ соответствовать формату таблиц в разделе 18.
Опишите, как метод относится к сетевым прокси.

22.2.3. Зарегистрированные записи

Эта спецификация, RFC 7826, регистрирует 10 методов: DESCRIBE, GET_PARAMETER, OPTIONS, PAUSE, PLAY, PLAY_NOTIFY, REDIRECT, SETUP, SET_PARAMETER и TEARDOWN. Начальная таблица реестра приведена ниже.

Method Directionality Reference
——————————————————
DESCRIBE C->S RFC 7826
GET_PARAMETER C->S, S->C RFC 7826
OPTIONS C->S, S->C RFC 7826
PAUSE C->S RFC 7826
PLAY C->S RFC 7826
PLAY_NOTIFY S->C RFC 7826
REDIRECT S->C RFC 7826
SETUP C->S RFC 7826
SET_PARAMETER C->S, S->C RFC 7826
TEARDOWN C->S, S->C RFC 7826

22.3. Коды состояния RTSP

22.3.1. Описание

Код состояния — это трехзначный номер, используемый для передачи информации в ответных сообщениях RTSP; см. Раздел 8. Пространство номеров ограничено, и следует соблюдать осторожность, чтобы не заполнить пространство.

22.3.2. Регистрация новых кодов статуса в IANA

Регистрация нового кода состояния соответствует политике IETF Review [RFC5226 #]. Новые функции RTSP, требующие кодов состояния, должны быть сначала зарегистрированы в диапазоне x50-x99. Только когда диапазон заполнен, регистрация должна производиться в диапазоне x00-x49, если только он не принимает расширение HTTP для RTSP. Это делается для того, чтобы любое расширение HTTP было принято в RTSP без необходимости перенумерации каких-либо связанных кодов состояния. Спецификация для нового кода состояния должна включать следующее:

Зарегистрированный номер.
Описание того, что означает код состояния и ожидаемое поведение отправителя и получателя кода.

22.3.3. Зарегистрированные записи

RFC 7826 (этот документ) регистрирует пронумерованный код состояния, определенный в записи ABNF «Status-Code» (Код состояния), за исключением «extension-code» (кода расширения) (который определяет синтаксис, разрешенный для будущих расширений) в Разделе 20.2.2.

22.4. Заголовки RTSP

22.4.1. Описание

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

22.4.2. Регистрация новых заголовков в IANA

Регистрация может быть произведена в соответствии с политикой экспертизы [RFC5226 #]. Рекомендуется предоставить спецификацию, предпочтительно RFC или другую спецификацию от Организации по разработке стандартов. Минимальная информация в запросе на регистрацию — это название заголовка и контактная информация.
Эксперт-рецензент проверяет, что запрос на регистрацию содержит следующую информацию:

o Название заголовка.
o Спецификация ABNF синтаксиса заголовка.
o Список или таблица, указывающие, когда может использоваться заголовок, охватывающий все методы, их запрос или ответ и направление (C-> S или S-> C).
o Как заголовок должен обрабатываться прокси.
o Описание назначения заголовка.

22.4.3. Зарегистрированные записи

Все заголовки, указанные в разделе 18 в RFC 7826, были зарегистрированы. Реестр включает в себя название заголовка и ссылку.

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

o x-wap-профиль, определенный в [TS-26234]. Заголовок запроса x-wap-profile содержит один или несколько абсолютных URL-адресов для профиля возможностей устройства запрашивающего агента.

o x-wap-profile-diff, определенный в [TS-26234]. Заголовок запроса x-wap-profile-diff содержит подмножество профиля возможностей устройства.

o x-wap-profile-warning определено в [TS-26234]. X-wap-profilewarning — это заголовок ответа, который содержит коды ошибок, объясняющие, в какой степени сервер смог сопоставить запрос терминала в отношении профилей возможностей устройства, как описано с использованием x-wap-profile и x-wap- заголовки профиля

o x-beforecbufsize определено в [TS-26234]. Этот заголовок ответа предоставляет агенту RTSP гипотетический размер буфера предварительного декодера согласно Приложению G Приложения 26 TS 26.234.

o x-initpredecbufperiod определен в [TS-26234]. Этот заголовок ответа предоставляет агенту RTSP период гипотетической буферизации предварительного декодера Приложения 26 к TS 26.234.

o x-initpostdecbufperiod определен в [TS-26234]. Этот заголовок ответа предоставляет агенту RTSP период буферизации постдекодера Приложения G TS 26.234.

o 3gpp-videopostdecbufsize, определенный в [TS-26234]. Этот заголовок ответа предоставляет агенту RTSP с определенным размером буфера постдекодера TS 26.234, пригодным для видеопотоков H.264 (AVC).

o 3GPP-Link-Char, определенный в [TS-26234]. Этот заголовок запроса предоставляет серверу RTSP характеристики линии связи клиента RTSP, определенные по радиоинтерфейсу. Информация, которая может быть предоставлена: гарантированный битрейт, максимальный битрейт и максимальная задержка передачи.

o 3GPP-адаптация, определенная в [TS-26234]. Этот общий заголовок является частью решения по адаптации скорости передачи битов, указанного для службы потоковой передачи с коммутацией пакетов (PSS). Он предоставляет серверу размеры буфера RTSP-клиента и целевые уровни буфера, а ответы используются для подтверждения поддержки и значений.

o Метрики 3GPP-QoE, определенные в [TS-26234]. Этот общий заголовок используется агентами PSS RTSP для согласования метрик качества взаимодействия, которые клиент должен собрать и сообщить серверу.

o Обратная связь 3GPP-QoE, определенная в [TS-26234]. Этот заголовок запроса используется клиентами RTSP, поддерживающими PSS, для отчета о фактических значениях показателей, собранных при измерении качества его опыта.

Использование «x-» НЕ РЕКОМЕНДУЕТСЯ, но вышеуказанные заголовки в списке были определены до пояснения.

22.5. Accept-Credentials

Механизм соединения TLS структуры безопасности имеет два регистрируемых объекта.

22.5.1. Политики Accept-Credentials

Этот реестр предназначен для политик для обработки прокси-сервером RTSP и проверки сертификатов TLS при установлении исходящего подключения TLS от имени клиента. В разделе 19.3.1 указаны три политики для обработки сертификатов. Дальнейшие политики могут быть определены; регистрация производится посредством действия по стандартизации [RFC5226 #].

Запрос на регистрацию должен содержать следующую информацию:

Название политики.
Текст, который описывает, как работает политика для обработки сертификатов.
Контактное лицо.

Эта спецификация регистрирует следующие значения:

Any — Любой: политика, требующая, чтобы прокси принял любой полученный сертификат.
Proxy — Прокси: политика, в которой прокси-сервер применяет свои собственные политики, чтобы определить, какие сертификаты принимаются.
User — Пользователь: политика, при которой сертификат должен быть перенаправлен по цепочке прокси клиенту, что позволяет пользователю принять или отклонить сертификат.

22.5.2. Принять-хэш-алгоритмы

Заголовок Accept-Credentials (см. Раздел 18.2) позволяет использовать другие алгоритмы для хеширования записей DER принятых объектов. Ожидается, что регистрация любого будущего алгоритма будет крайне редкой и может также вызвать проблемы взаимодействия. Поэтому планка регистрации новых алгоритмов намеренно установлена высоко.

Любая регистрация нового алгоритма хеширования требует Действия по Стандартам [RFC5226 #]. Регистрация должна соответствовать следующим требованиям:

Идентификатор алгоритма, отвечающий требованию ABNF «токен».
Обеспечить определение алгоритма.

Зарегистрированное значение:

Hash Alg. ID Reference
————————
sha-256 RFC 7826

22.6. Расширенные директивы кэша в Cache-Control

Существует несколько директив кеша, которые можно отправить в заголовке Cache-Control. Реестр для этих директив кэша был создан IANA. Новые регистрации в этом реестре требуют действия по стандартизации или одобрения IESG [RFC5226 #]. Запрос на регистрацию должен содержать следующую информацию.

Имя директивы кеша.
Определение значения параметра, если оно разрешено.
Спецификация, если это директива запроса или ответа.
Текст, который объясняет, как директива кеша используется для потоков мультимедиа, контролируемых RTSP.
Контактное лицо.

Эта спецификация регистрирует следующие значения:

no-cache:
public:
private:
no-transform:
only-if-cached:
max-stale:
min-fresh:
must-revalidate:
proxy-revalidate:
max-age:

Реестр содержит название директивы и ссылку.

22.7. Медиа Свойства

22.7.1. Описание

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

22.7.2. Правила регистрации

Регистрация нового свойства мультимедиа выполняется в соответствии с политикой «Требуется спецификация» [RFC5226 #]. Эксперт-рецензент проверяет, соответствует ли запрос на регистрацию следующим требованиям.

o Включено определение ABNF имени значения свойства мультимедиа, которое соответствует определению «media-prop-ext».

o Включено определение, к какой группе свойств мультимедиа оно принадлежит или определение новой группы.

o Приведено описание всех изменений в поведении RTSP в результате этих изменений.

o Контактное лицо для регистрации в списке.

22.7.3. Зарегистрированные ценности

Эта спецификация регистрирует десять значений, перечисленных в разделе 18.29. Реестр содержит группу свойств, имя свойства мультимедиа и ссылку.

22.8. Значения Notify-Reason

22.8.1. Описание

Значения Notify-Reason используются для указания причины отправки уведомления. У каждой причины есть свои правила относительно того, какие заголовки и информация могут или должны быть включены в уведомление. Необходимо указать новые способы уведомления для обеспечения возможности взаимодействия; таким образом, требуется спецификация каждого нового значения.

22.8.2. Правила регистрации

Регистрация новых значений «Уведомить-причина» осуществляется в соответствии с политикой «Требуется спецификация» [RFC5226 #]. Эксперт-рецензент проверяет, соответствует ли запрос следующим требованиям:

Включено определение ABNF имени значения Notify-Reason, которое соответствует определению «Notify-Reason-extension».
Описание того, какие заголовки должны быть включены в запрос и ответ, когда он должен быть отправлен, и любое влияние, которое он оказывает на состояние клиента сервера, становится понятным.
Контактное лицо для регистрации в списке.

22.8.3. Зарегистрированные ценности

Эта спецификация регистрирует три значения, определенные в ABNF Notify-Reasval, раздел 20.2.3:

end-of-stream: это значение Notify-Reason указывает конец медиапотока.

media-properties-update: это значение Notify-Reason позволяет серверу указывать, что свойства носителя изменились во время воспроизведения.

scale-change: Это значение Notify-Reason позволяет серверу уведомлять клиента об изменении масштаба носителя.

Реестр содержит имя, описание и ссылку.

22.9. Форматы заголовка диапазона

22.9.1. Описание

Заголовок Range (раздел 18.40) позволяет использовать разные форматы диапазона. Этим форматам диапазонов также необходим идентификатор, который будет использоваться в заголовке Accept-Ranges (раздел 18.5). Новые форматы диапазона могут быть зарегистрированы, но следует применять модерацию, поскольку это затрудняет совместимость.

22.9.2. Правила регистрации

Регистрация осуществляется в соответствии с политикой «Требуется спецификация» [RFC5226 #]. Эксперт-рецензент проверяет, удовлетворяет ли запрос следующим
требования:

Включено определение ABNF формата диапазона, которое соответствует определению «rangeext».
Определен идентификатор формата диапазона, используемый в заголовке Accept-Ranges в соответствии с определением «extension-format».
Правила того, как обрабатывать диапазон при использовании отрицательной шкалы, включены.
Контактное лицо для регистрации в списке.

22.9.3. Зарегистрированные ценности

Реестр содержит идентификатор формата заголовка диапазона, имя формата диапазона и ссылку. Эта спецификация регистрирует следующие значения.

npt: нормальное время воспроизведения

clock: UTC, формат абсолютного времени

smpte: временные метки SMPTE

smpte-30-drop: временные метки SMPTE 29,97 кадров / с (30 Гц с падением)

smpte-25: временные метки SMPTE 25 кадров / с

22.10. Заголовок Terminate-Reason

Заголовок Terminate-Reason (раздел 18.52) имеет два реестра расширений.

22.10.1. Причины перенаправления

Этот реестр содержит причины завершения сеанса, которые могут быть включены в заголовок «Причина завершения» (раздел 18.52). Регистрации следуют политике экспертизы [RFC5226 #]. Эксперт-рецензент проверяет, что запрос на регистрацию содержит следующую информацию:

Что значение следует за ABNF «конечная причина», то есть быть токеном.
Что в спецификации дано определение того, какие процедуры должны выполняться, когда клиент получает эту причину перенаправления.
Контактное лицо

Эта спецификация регистрирует три значения:

Session-Timeout
Server-Admin
Internal-Error

Реестр содержит название причины перенаправления и ссылку.

22.10.2. Параметры заголовка конечной причины

Этот реестр содержит параметры, которые могут быть включены в заголовок Terminate-Reason (раздел 18.52) в дополнение к причине. Регистрация осуществляется в соответствии с политикой «Требуется спецификация» [RFC5226 #]. Эксперт-рецензент проверяет, что запрос на регистрацию содержит следующее:

Имя параметра.
Параметр, соответствующий синтаксису, разрешенному спецификацией RTSP 2.0.
Ссылка на спецификацию.
Контактное лицо.

Эта спецификация регистрирует:

time
user-msg

Реестр содержит название прекращаемой причины и ссылку.

22.11. Параметры заголовка RTP-Info

22.11.1. Описание

Заголовок RTP-Info (раздел 18.45) содержит одну или несколько пар значений параметров с информацией о конкретной точке в потоке RTP. Расширения RTP или новые способы использования могут нуждаться в новых типах информации. Поскольку информация RTP, которая может потребоваться, вероятно, будет достаточно общей, и для максимизации функциональной совместимости новая регистрация выполняется в соответствии с политикой «Требуется спецификация».

22.11.2. Правила регистрации

Регистрации для новых значений RTP-Info следуют политике требуемой спецификации [RFC5226 #]. Эксперт-рецензент проверяет, что запрос на регистрацию содержит следующую информацию.

Определение ABNF, которое соответствует определению «универсального параметра».
Ссылка на спецификацию.
Контактное лицо для регистрации.

22.11.3. Зарегистрированные ценности

В этой спецификации регистрируются следующие пары значений параметров:

url
ssrc
seq
rtptime

Реестр содержит название параметра и ссылку.

22.12. Политика поиска стиля

22.12.1. Описание

Политика Seek-Style определяет, как агент RTSP ищет в медиа-контенте, когда ему предоставляется позиция в медиа-контенте. Новые правила поиска могут быть зарегистрированы; однако большое их количество существенно усложнит реализацию. Влияние неизвестных политик заключается в том, что сервер не будет учитывать неизвестные и будет использовать политику сервера по умолчанию.

22.12.2. Правила регистрации

Регистрация новых политик в стиле поиска соответствует политике «Требуется спецификация» [RFC5226 #]. Эксперт-рецензент проверяет, отвечает ли запрос на регистрацию следующим требованиям:

Имеет определение ABNF имени политики в стиле поиска, которое соответствует определению «Seek-S-value-ext».
Включает краткое описание.
Перечисляет контактное лицо для регистрации.
Включает в себя описание того, какие заголовки должны быть включены в запрос и ответ, когда он должен быть отправлен и какое влияние он оказывает на состояние сервер-клиент.

22.12.3. Зарегистрированные ценности

Эта спецификация регистрирует четыре значения (Имя — Краткое описание):

RAP — использование ближайшей точки произвольного доступа до или в запрошенной начальной позиции.
CoRAP — Условная точка произвольного доступа похожа на RAP, но только если RAP ближе к запрошенной начальной позиции, чем текущая точка паузы.
First-Prior — Политика первого приоритета начнет доставку с медиа-блока, у которого есть время воспроизведения, предшествующее запрошенной стартовой позиции.
Next — Следующие медиа-блоки после предоставленной стартовой позиции.

Реестр содержит название политики Seek-Style, описание и ссылку.

22.13. Реестры заголовков транспорта

Транспортный заголовок (раздел 18.54) содержит ряд параметров, которые имеют возможности для будущих расширений. Поэтому реестры для них определены ниже.

22.13.1. Идентификатор транспортного протокола

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

Регистрация для идентификатора транспортного протокола параметров следует политике Specification Required [RFC5226 #]. Эксперт-рецензент проверяет, отвечает ли запрос на регистрацию следующим требованиям:

Контактное лицо или организация с адресом и адресом электронной почты.
Определение значения, которое следует за синтаксическим определением ABNF «идентификатора транспорта». Раздел 20.2.3.
Описательный текст, который объясняет, как зарегистрированные значения используются в RTSP, какие базовые транспортные протоколы используются, и любые требуемые параметры заголовка транспорта.

Реестр содержит строку идентификатора протокола и ссылку.

Эта спецификация регистрирует следующие значения:

RTP / AVP: использование протокола RTP [RFC3550 #] для передачи мультимедиа в сочетании с «Профилем RTP для аудио- и видеоконференций с минимальным управлением» [RFC3551 #] по UDP. Использование объясняется в RFC 7826, Приложение C.1.

RTP / AVP / UDP: так же, как RTP / AVP.

RTP / AVPF: использование протокола RTP [RFC3550 #] для передачи мультимедиа в сочетании с «Расширенным профилем RTP для обратной связи на основе RTCP (RTP / AVPF)» [RFC4585 #] по UDP. Использование объясняется в RFC 7826, Приложение C.1.

RTP / AVPF / UDP: то же самое, что и RTP / AVPF.

RTP / SAVP: Использование протокола RTP [RFC3550 #] для передачи мультимедиа в сочетании с «Безопасным протоколом передачи в реальном времени (SRTP)» [RFC3711 #] по UDP. Использование объясняется в RFC 7826, Приложение C.1.

RTP / SAVP / UDP: то же самое, что и RTP / SAVP.

RTP / SAVPF: использование протокола RTP [RFC3550 #] для передачи мультимедиа в сочетании с «Расширенным безопасным профилем RTP для обратной связи на основе протокола управления передачей в реальном времени (RTCP) (RTP / SAVPF)» [RFC5124 #] по UDP. Использование объясняется в RFC 7826, Приложение C.1.

RTP / SAVPF / UDP: аналогично RTP / SAVPF.

RTP / AVP / TCP: использование протокола RTP [RFC3550 #] для передачи мультимедиа в сочетании с «профилем RTP для аудио- и видеоконференций с минимальным контролем» [RFC3551 #] через TCP. Использование объясняется в RFC 7826, Приложение C.2.2.

RTP / AVPF / TCP: использование протокола RTP [RFC3550 #] для передачи мультимедиа в сочетании с «Расширенным профилем RTP для обратной связи на основе протокола управления транспортировкой в реальном времени (RTCP) (RTP / AVPF)» [RFC4585 #] через TCP. Использование объясняется в RFC 7826, Приложение C.2.2.

RTP / SAVP / TCP: использование протокола RTP [RFC3550 #] для передачи мультимедиа в сочетании с «Безопасным транспортным протоколом в реальном времени (SRTP)» [RFC3711 #] по TCP. Использование объясняется в RFC 7826, Приложение C.2.2.

RTP / SAVPF / TCP: использование протокола RTP [RFC3550 #] для передачи мультимедиа в сочетании с «Расширенным защищенным профилем RTP для обратной связи на основе протокола управления транспортировкой в реальном времени (RTCP) (RTP / SAVPF)» [RFC5124 #] через TCP. Использование объясняется в RFC 7826, Приложение C.2.2.

22.13.2. Режимы транспорта

Транспортный режим — это параметр Транспортного заголовка (раздел 18.54). Он используется для определения общего вида транспорта мультимедиа. Зарегистрированное значение PLAY определяет режим PLAYBACK, в котором медиа-потоки передаются с сервера на клиент.

Регистрация для режима транспортных параметров выполняется в соответствии с политикой Стандартных действий [RFC5226 #]. Запрос на регистрацию должен соответствовать следующим требованиям:

Определение значения, которое следует за определением «токена» ABNF. Раздел 20.2.3.
Текст, который объясняет, как зарегистрированное значение используется в RTSP.

Эта спецификация регистрирует одно значение:

PLAY: см. RFC 7826.

Реестр содержит значение режима транспорта и ссылку.

22.13.3. Транспортные параметры

Транспортные параметры — это разные параметры, используемые в транспортной спецификации заголовка транспорта (раздел 18.54) для предоставления дополнительной информации, необходимой помимо идентификатора транспортного протокола для установления работающего транспорта.

Регистрация параметров, которые могут быть включены в заголовок транспорта, следует политике «Требуется спецификация» [RFC5226 #]. Эксперт-рецензент проверяет, отвечает ли запрос на регистрацию следующим требованиям:

Имя транспортного параметра после определения «токена» ABNF.
Определение значения, если параметр принимает значение, которое соответствует определению ABNF «trn-par-value», раздел 20.2.3.
Текст, который объясняет, как зарегистрированное значение используется в RTSP.

В этой спецификации регистрируются все транспортные параметры, определенные в разделе 18.54. Это копия этого списка:

unicast
multicast
interleaved
ttl
layers
ssrc
mode
dest_addr
src_addr
setup
connection
RTCP-mux
MIKEY

Реестр содержит имя транспортного параметра и ссылку.

22.14. Схемы URI

В этой спецификации обновляются две схемы URI: одна ранее зарегистрирована, «rtsp», а другая отсутствует в реестре, «rtspu» (ранее определенная только в RTSP 1.0 [RFC2326 #]). Одна новая схема URI, «rtsps», также зарегистрирована. Эти схемы URI зарегистрированы в существующем реестре («Схемы универсального идентификатора ресурса (URI)»), не созданном этой запиской. Регистрации следуют [RFC7595 #].

22.14.1. Схема URI «rtsp»

Имя схемы URI: rtsp

Статус: Постоянный

Синтаксис схемы URI: см. Раздел 20.2.1 RFC 7826 (этот документ).

Семантика схемы URI: схема rtsp используется для указания ресурсов, доступных посредством использования потокового протокола реального времени (RTSP). RTSP допускает различные операции с ресурсом, идентифицированным URI, но основной целью является потоковая доставка ресурса клиенту. Однако в настоящее время определены следующие операции: DESCRIBE, GET_PARAMETER, OPTIONS, PLAY, PLAY_NOTIFY, PAUSE, REDIRECT, SETUP, SET_PARAMETER и TEARDOWN.

Вопросы кодирования: IRI в этой схеме определены и должны быть закодированы как URI RTSP при использовании в RTSP. Эта кодировка выполняется в соответствии с RFC 3987 #.

Приложения / протоколы, которые используют это имя схемы URI: RTSP 1.0 (RFC 2326 #), RTSP 2.0 (RFC 7826).

Соображения по поводу совместимости. Расширения в синтаксисе URI, выполняемые между RTSP 1.0 и 2.0, могут создавать проблемы совместимости. Изменения:

Поддержка литералов IPv6 в принимающей части и будущих литералах IP через механизм, определенный в RFC 3986 #.
Новый относительный формат для использования в элементах RTSP, который не обязательно должен начинаться с «/».

Вышеуказанные изменения не должны влиять на совместимость, как подробно описано в разделе 4.2 RFC 7826 (этот документ).

Соображения безопасности: Все угрозы безопасности, определенные в Разделе 7 RFC 3986 #, также применимы к этой схеме. Они должны быть рассмотрены и учтены в любой реализации, использующей эту схему.

Контактное лицо: Магнус Вестерлунд, magnus.westerlund@ericsson.com

Автор / Смена контроллера: IETF

Ссылки: RFC 2326 #, RFC 3986 #, RFC 3987 # и RFC 7826

22.14.2. Схема URI «rtsps»

Имя схемы URI: rtsps

Статус: Постоянный

Синтаксис схемы URI: см. Раздел 20.2.1 RFC 7826 (этот документ).

Семантика схемы URI: схема rtsps используется для указания ресурсов, доступных посредством использования потокового протокола реального времени (RTSP) по TLS. RTSP допускает различные операции с ресурсом, идентифицированным URI, но основной целью является потоковая доставка ресурса клиенту. Однако в настоящее время определены следующие операции: DESCRIBE, GET_PARAMETER, OPTIONS, PLAY, PLAY_NOTIFY, PAUSE, REDIRECT, SETUP, SET_PARAMETER и TEARDOWN.

Приложения / протоколы, которые используют это имя схемы URI: RTSP 1.0 (RFC 2326 #), RTSP 2.0 (RFC 7826).

Соображения совместимости: схема RTSPS никогда не была официально определена для RTSP 1.0; тем не менее, он широко используется в реальных развертываниях RTSP 1.0. Поэтому в этом разделе обсуждаются предполагаемые изменения между неопределенной схемой RTSP 1.0 «rtsps» и определением RTSP 2.0.

Расширения в синтаксисе URI, выполняемые между RTSP 1.0 и 2.0, могут создавать проблемы взаимодействия. Изменения:

Поддержка литералов IPv6 в принимающей части и будущих литералах IP с помощью механизма, определенного в RFC 3986 #.
Новый относительный формат для использования в элементах RTSP, который не обязательно должен начинаться с «/».

Соображения безопасности: Все угрозы безопасности, определенные в Разделе 7 RFC 3986, также применимы к этой схеме. Они должны быть рассмотрены и учтены в любой реализации, использующей эту схему.

Контактное лицо: Магнус Вестерлунд, magnus.westerlund@ericsson.com

Автор / Смена контроллера: IETF

Ссылки: RFC 2326 #, RFC 3986 #, RFC 3987 # и RFC 7826

22.14.3. Схема URI «rtspu»

Имя схемы URI: rtspu

Статус: Постоянный

Синтаксис схемы URI: см. Раздел 3.2 RFC 2326 #.

Семантика схемы URI. Схема rtspu используется для указания ресурсов, доступных посредством использования потокового протокола реального времени (RTSP) по ненадежной передаче дейтаграмм. RTSP допускает различные операции с ресурсом, идентифицированным URI, но основной целью является потоковая доставка ресурса клиенту. Однако в настоящее время определены следующие операции: DESCRIBE, GET_PARAMETER, OPTIONS, REDIRECT, PLAY, PLAY_NOTIFY, PAUSE, SETUP, SET_PARAMETER и TEARDOWN.

Соображения по кодированию: эта схема не предназначена для использования с символами вне репертуара US-ASCII.

Приложения / протоколы, которые используют это имя схемы URI: RTSP 1.0 (RFC 2326 #).

Соображения совместимости: определение транспортного механизма RTSP через UDP имеет проблемы совместимости. Это делает использование этой схемы проблематичным.

Контактное лицо: Магнус Вестерлунд, magnus.westerlund@ericsson.com

Автор / Смена контроллера: IETF

Рекомендации: RFC 2326 #

22.15. Атрибуты SDP

Эта спецификация определяет три атрибута SDP [RFC4566 #], которые были зарегистрированы IANA.

Атрибут SDP («att-field»):

Имя атрибута: range (диапазон)
Полная форма: Media Range Attribute (атрибут Media Range)
Тип имени: att-field
Тип атрибута: сессионный и медиа уровень
Подлежит кодировке: нет
Назначение: RFC 7826
Ссылка: RFC 2326 #, RFC 7826
Значения: см. Определение ABNF.

Имя атрибута: control (контроль)
Полная форма: URI управления RTSP
Тип имени: att-field
Тип атрибута: сессионный и медиа уровень
Подлежит кодировке: нет
Назначение: RFC 7826
Ссылка: RFC 2326 #, RFC 7826
Значения: Абсолютные или Относительные URI.

Имя атрибута: mtag
Полная форма: Message Tag (тег сообщения)
Тип имени: att-field
Тип атрибута: сессионный и медиа уровень
Подлежит кодировке: нет
Назначение: RFC 7826
Ссылка: RFC 7826
Значения: см. Определение ABNF

22.16. Тип носителя Регистрация для текста / параметров

Название типа: text (текст)

Название подтипа: parameters (параметры)

Обязательные параметры:

Необязательные параметры: charset: параметр charset применяется для кодирования значений параметров. По умолчанию используется кодировка UTF-8, если параметр «кодировка» отсутствует.

Особенности кодирования: 8 бит

Соображения безопасности: этот формат может содержать параметры любого типа. У некоторых могут быть требования безопасности, такие как требования конфиденциальности, конфиденциальности или целостности. Формат не имеет встроенной защиты. Для использования транспорт может быть защищен между сервером и клиентом, используя TLS. Тем не менее, необходимо позаботиться о том, чтобы доверенным лицам также доверялись эти параметры в случае использования защиты по каждой передаче. Если они хранятся в виде файла в файловой системе, необходимо принять необходимые меры предосторожности в отношении требований к параметрам, включая безопасность объектов, таких как S / MIME [RFC5751 #].

Соображения по поводу совместимости: этот тип носителя был упомянут в качестве вымышленного примера в [RFC2326 #], но формально не указан.

Это привело к использованию этого типа носителя, который может не соответствовать его формальному определению.

Опубликованная спецификация: RFC 7826, Приложение F.

Приложения, которые используют этот тип мультимедиа: Приложения, которые используют RTSP и имеют дополнительные параметры, которые им нравится читать и устанавливать, используя методы RTSP GET_PARAMETER и SET_PARAMETER.

Дополнительная информация:

Магическое число (а): N / A

Расширение файла (ов): N / A

Код (ы) типов файлов для Macintosh: N / A

Персона и адрес электронной почты для связи для получения дополнительной информации: Магнус Вестерлунд (magnus.westerlund@ericsson.com)

Использование по назначению: общее

Ограничения на использование: Нет

Автор: Магнус Вестерлунд (magnus.westerlund@ericsson.com)

Сменить контроллер: IETF

Дополнительные примечания:

23. Ссылки

23.1. Нормативные ссылки

[FIPS180-4] National Institute of Standards and Technology (NIST), «Federal Information Processing Standards Publication: Secure Hash Standard (SHS)», DOI 10.6028/NIST.FIPS.180-4, August 2015, <http://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.180-4.pdf>.

[RFC768] Postel, J., «User Datagram Protocol», STD 6, RFC 768, DOI 10.17487/RFC0768, August 1980, <http://www.rfc-editor.org/info/rfc768>.

[RFC793] Postel, J., «Transmission Control Protocol», STD 7, RFC 793, DOI 10.17487/RFC0793, September 1981, <http://www.rfc-editor.org/info/rfc793>.

[RFC2119] Bradner, S., «Key words for use in RFCs to Indicate Requirement Levels», BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.

[RFC2460] Deering, S. and R. Hinden, «Internet Protocol, Version 6 (IPv6) Specification», RFC 2460, DOI 10.17487/RFC2460, December 1998, <http://www.rfc-editor.org/info/rfc2460>.

[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, «Hypertext Transfer Protocol — HTTP/1.1», RFC 2616,
DOI 10.17487/RFC2616, June 1999, <http://www.rfc-editor.org/info/rfc2616>.

[RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., Leach, P., Luotonen, A., and L. Stewart, «HTTP Authentication: Basic and Digest Access Authentication»,
RFC 2617, DOI 10.17487/RFC2617, June 1999, <http://www.rfc-editor.org/info/rfc2617>.

[RFC2818] Rescorla, E., «HTTP Over TLS», RFC 2818, DOI 10.17487/RFC2818, May 2000, <http://www.rfc-editor.org/info/rfc2818>.

[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, «RTP: A Transport Protocol for Real-Time Applications», STD 64, RFC 3550, DOI 10.17487/RFC3550,
July 2003, <http://www.rfc-editor.org/info/rfc3550>.

[RFC3551] Schulzrinne, H. and S. Casner, «RTP Profile for Audio and Video Conferences with Minimal Control», STD 65, RFC 3551, DOI 10.17487/RFC3551, July 2003,
<http://www.rfc-editor.org/info/rfc3551>.

[RFC3629] Yergeau, F., «UTF-8, a transformation format of ISO 10646», STD 63, RFC 3629, DOI 10.17487/RFC3629, November 2003, <http://www.rfc-editor.org/info/rfc3629>.

[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, «The Secure Real-time Transport Protocol (SRTP)», RFC 3711, DOI 10.17487/RFC3711, March 2004,
<http://www.rfc-editor.org/info/rfc3711>.

[RFC3830] Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and K. Norrman, «MIKEY: Multimedia Internet KEYing», RFC 3830, DOI 10.17487/RFC3830, August 2004,
<http://www.rfc-editor.org/info/rfc3830>.

[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, «Uniform Resource Identifier (URI): Generic Syntax», STD 66, RFC 3986, DOI 10.17487/RFC3986, January 2005,
<http://www.rfc-editor.org/info/rfc3986>.

[RFC3987] Duerst, M. and M. Suignard, «Internationalized Resource Identifiers (IRIs)», RFC 3987, DOI 10.17487/RFC3987, January 2005, <http://www.rfc-editor.org/info/rfc3987>.

[RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, «Randomness Requirements for Security», BCP 106, RFC 4086, DOI 10.17487/RFC4086, June 2005,
<http://www.rfc-editor.org/info/rfc4086>.

[RFC4291] Hinden, R. and S. Deering, «IP Version 6 Addressing Architecture», RFC 4291, DOI 10.17487/RFC4291, February 2006, <http://www.rfc-editor.org/info/rfc4291>.

[RFC7595] Thaler, D., Ed., Hansen, T., and T. Hardie, «Guidelines and Registration Procedures for URI Schemes», BCP 35, RFC 7595, DOI 10.17487/RFC7595, June 2015, <http://www.rfceditor.org/info/rfc7595>.

[RFC4566] Handley, M., Jacobson, V., and C. Perkins, «SDP: Session Description Protocol», RFC 4566, DOI 10.17487/RFC4566,
July 2006, <http://www.rfc-editor.org/info/rfc4566>.

[RFC4571] Lazzaro, J., «Framing Real-time Transport Protocol (RTP) and RTP Control Protocol (RTCP) Packets over Connection-Oriented Transport», RFC 4571, DOI 10.17487/RFC4571, July 2006, <http://www.rfc-editor.org/info/rfc4571>.

[RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, «Extended RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/AVPF)», RFC 4585,
DOI 10.17487/RFC4585, July 2006, <http://www.rfc-editor.org/info/rfc4585>.

[RFC4648] Josefsson, S., «The Base16, Base32, and Base64 Data Encodings», RFC 4648, DOI 10.17487/RFC4648, October 2006,
<http://www.rfc-editor.org/info/rfc4648>.

[RFC4738] Ignjatic, D., Dondeti, L., Audet, F., and P. Lin, «MIKEYRSA-R: An Additional Mode of Key Distribution in Multimedia Internet KEYing (MIKEY)», RFC 4738,
DOI 10.17487/RFC4738, November 2006, <http://www.rfc-editor.org/info/rfc4738>.

[RFC5124] Ott, J. and E. Carrara, «Extended Secure RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/SAVPF)», RFC 5124, DOI 10.17487/RFC5124, February 2008, <http://www.rfc-editor.org/info/rfc5124>.

[RFC5226] Narten, T. and H. Alvestrand, «Guidelines for Writing an IANA Considerations Section in RFCs», BCP 26, RFC 5226, DOI 10.17487/RFC5226, May 2008,
<http://www.rfc-editor.org/info/rfc5226>.

[RFC5234] Crocker, D., Ed. and P. Overell, «Augmented BNF for Syntax Specifications: ABNF», STD 68, RFC 5234, DOI 10.17487/RFC5234, January 2008,
<http://www.rfc-editor.org/info/rfc5234>.

[RFC5246] Dierks, T. and E. Rescorla, «The Transport Layer Security (TLS) Protocol Version 1.2», RFC 5246, DOI 10.17487/RFC5246, August 2008,
<http://www.rfc-editor.org/info/rfc5246>.

[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, «Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile», RFC 5280, DOI 10.17487/RFC5280, May 2008,
<http://www.rfc-editor.org/info/rfc5280>.

[RFC5322] Resnick, P., Ed., «Internet Message Format», RFC 5322, DOI 10.17487/RFC5322, October 2008,
<http://www.rfc-editor.org/info/rfc5322>.

[RFC5646] Phillips, A., Ed. and M. Davis, Ed., «Tags for Identifying Languages», BCP 47, RFC 5646, DOI 10.17487/RFC5646,
September 2009, <http://www.rfc-editor.org/info/rfc5646>.

[RFC5751] Ramsdell, B. and S. Turner, «Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Message Specification», RFC 5751, DOI 10.17487/RFC5751, January
2010, <http://www.rfc-editor.org/info/rfc5751>.

[RFC5761] Perkins, C. and M. Westerlund, «Multiplexing RTP Data and Control Packets on a Single Port», RFC 5761, DOI 10.17487/RFC5761, April 2010,
<http://www.rfc-editor.org/info/rfc5761>.

[RFC5888] Camarillo, G. and H. Schulzrinne, «The Session Description Protocol (SDP) Grouping Framework», RFC 5888, DOI 10.17487/RFC5888, June 2010,
<http://www.rfc-editor.org/info/rfc5888>.

[RFC6838] Freed, N., Klensin, J., and T. Hansen, «Media Type Specifications and Registration Procedures», BCP 13, RFC 6838, DOI 10.17487/RFC6838, January 2013,
<http://www.rfc-editor.org/info/rfc6838>.

[RFC7230] Fielding, R., Ed. and J. Reschke, Ed., «Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing», RFC 7230, DOI 10.17487/RFC7230, June 2014,
<http://www.rfc-editor.org/info/rfc7230>.

[RFC7231] Fielding, R., Ed. and J. Reschke, Ed., «Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content», RFC 7231, DOI 10.17487/RFC7231, June 2014,
<http://www.rfc-editor.org/info/rfc7231>.

[RFC7232] Fielding, R., Ed. and J. Reschke, Ed., «Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests», RFC 7232, DOI 10.17487/RFC7232, June 2014,
<http://www.rfc-editor.org/info/rfc7232>.

[RFC7233] Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed., «Hypertext Transfer Protocol (HTTP/1.1): Range Requests», RFC 7233, DOI 10.17487/RFC7233, June 2014,
<http://www.rfc-editor.org/info/rfc7233>.

[RFC7234] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, Ed., «Hypertext Transfer Protocol (HTTP/1.1): Caching», RFC 7234, DOI 10.17487/RFC7234, June 2014,
<http://www.rfc-editor.org/info/rfc7234>.

[RFC7235] Fielding, R., Ed. and J. Reschke, Ed., «Hypertext Transfer Protocol (HTTP/1.1): Authentication», RFC 7235, DOI 10.17487/RFC7235, June 2014,
<http://www.rfc-editor.org/info/rfc7235>.

[RFC7615] Reschke, J., «HTTP Authentication-Info and Proxy-Authentication-Info Response Header Fields», RFC 7615, DOI 10.17487/RFC7615, September 2015,
<http://www.rfc-editor.org/info/rfc7615>.

[RFC7616] Shekh-Yusef, R., Ed., Ahrens, D., and S. Bremer, «HTTP Digest Access Authentication», RFC 7616, DOI 10.17487/RFC7616, September 2015,
<http://www.rfc-editor.org/info/rfc7616>.

[RFC7617] Reschke, J., «The ’Basic’ HTTP Authentication Scheme», RFC 7617, DOI 10.17487/RFC7617, September 2015,
<http://www.rfc-editor.org/info/rfc7617>.

[RFC7825] Goldberg, J., Westerlund, M., and T. Zeng, «A Network Address Translator (NAT) Traversal Mechanism for Media Controlled by Real-Time Streaming Protocol (RTSP)»,
RFC 7825, DOI 10.17487/RFC7825, December 2016, <http://www.rfc-editor.org/info/rfc7825>.

[RTP-CIRCUIT-BREAKERS] Perkins, C. and V. Singh, «Multimedia Congestion Control: Circuit Breakers for Unicast RTP Sessions», Work in Progress, draft-ietf-avtcore-rtp-circuit-breakers-13, February 2016.

[SMPTE-TC] Society of Motion Picture and Television Engineers, «ST 12-1:2008 For Television — Time and Control Code», DOI 10.5594/SMPTE.ST12-1.2008, February 2008,
<http://ieeexplore.ieee.org/servlet/opac?punumber=7289818>.

[TS-26234] 3rd Generation Partnership Project (3GPP), «Transparent end-to-end Packet-switched Streaming Service (PSS); Protocols and codecs», Technical Specification 26.234,
Release 13, September 2015,
<http://www.3gpp.org/DynaReport/26234.htm>.

23.2. Информационные ссылки

[ISO.13818-6.1995]
International Organization for Standardization, «Information technology — Generic coding of moving pictures and associated audio information — part 6: Extension for DSM-CC», ISO Draft Standard 13818-6:1998, October 1998,
<http://www.iso.org/iso/home/store/catalogue_tc/catalogue_detail.htm?csnumber=25039>.

[ISO.8601.2000]
International Organization for Standardization, «Data elements and interchange formats — Information interchange — Representation of dates and times», ISO/IEC Standard
8601, December 2000.

[RFC791] Postel, J., «Internet Protocol», STD 5, RFC 791, DOI 10.17487/RFC0791, September 1981,
<http://www.rfc-editor.org/info/rfc791>.

[RFC1123] Braden, R., Ed., «Requirements for Internet Hosts — Application and Support», STD 3, RFC 1123, DOI 10.17487/RFC1123, October 1989,
<http://www.rfc-editor.org/info/rfc1123>.

[RFC2068] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., and T. Berners-Lee, «Hypertext Transfer Protocol — HTTP/1.1», RFC 2068, DOI 10.17487/RFC2068, January 1997,
<http://www.rfc-editor.org/info/rfc2068>.

[RFC2326] Schulzrinne, H., Rao, A., and R. Lanphier, «Real Time Streaming Protocol (RTSP)», RFC 2326, DOI 10.17487/RFC2326, April 1998,
<http://www.rfc-editor.org/info/rfc2326>.

[RFC2663] Srisuresh, P. and M. Holdrege, «IP Network Address Translator (NAT) Terminology and Considerations», RFC 2663, DOI 10.17487/RFC2663, August 1999,
<http://www.rfc-editor.org/info/rfc2663>.

[RFC2974] Handley, M., Perkins, C., and E. Whelan, «Session Announcement Protocol», RFC 2974, DOI 10.17487/RFC2974,
October 2000, <http://www.rfc-editor.org/info/rfc2974>.

[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, «SIP: Session Initiation Protocol», RFC 3261,
DOI 10.17487/RFC3261, June 2002,
<http://www.rfc-editor.org/info/rfc3261>.

[RFC3264] Rosenberg, J. and H. Schulzrinne, «An Offer/Answer Model with Session Description Protocol (SDP)», RFC 3264, DOI 10.17487/RFC3264, June 2002,
<http://www.rfc-editor.org/info/rfc3264>.

[RFC3339] Klyne, G. and C. Newman, «Date and Time on the Internet: Timestamps», RFC 3339, DOI 10.17487/RFC3339, July 2002,
<http://www.rfc-editor.org/info/rfc3339>.

[RFC4145] Yon, D. and G. Camarillo, «TCP-Based Media Transport in the Session Description Protocol (SDP)», RFC 4145, DOI 10.17487/RFC4145, September 2005,
<http://www.rfc-editor.org/info/rfc4145>.

[RFC4567] Arkko, J., Lindholm, F., Naslund, M., Norrman, K., and E. Carrara, «Key Management Extensions for Session Description Protocol (SDP) and Real Time Streaming
Protocol (RTSP)», RFC 4567, DOI 10.17487/RFC4567, July 2006, <http://www.rfc-editor.org/info/rfc4567>.

[RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R. Hakenberg, «RTP Retransmission Payload Format», RFC 4588, DOI 10.17487/RFC4588, July 2006,
<http://www.rfc-editor.org/info/rfc4588>.

[RFC4855] Casner, S., «Media Type Registration of RTP Payload Formats», RFC 4855, DOI 10.17487/RFC4855, February 2007,
<http://www.rfc-editor.org/info/rfc4855>.

[RFC4856] Casner, S., «Media Type Registration of Payload Formats in the RTP Profile for Audio and Video Conferences», RFC 4856, DOI 10.17487/RFC4856, February 2007, <http://www.rfc-editor.org/info/rfc4856>.

[RFC5104] Wenger, S., Chandra, U., Westerlund, M., and B. Burman, «Codec Control Messages in the RTP Audio-Visual Profile with Feedback (AVPF)», RFC 5104, DOI 10.17487/RFC5104,
February 2008, <http://www.rfc-editor.org/info/rfc5104>.

[RFC5245] Rosenberg, J., «Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols», RFC 5245, DOI 10.17487/RFC5245, April 2010, <http://www.rfc-editor.org/info/rfc5245>.

[RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, «Session Traversal Utilities for NAT (STUN)», RFC 5389, DOI 10.17487/RFC5389, October 2008,
<http://www.rfc-editor.org/info/rfc5389>.

[RFC5583] Schierl, T. and S. Wenger, «Signaling Media Decoding Dependency in the Session Description Protocol (SDP)», RFC 5583, DOI 10.17487/RFC5583, July 2009, <http://www.rfc-editor.org/info/rfc5583>.

[RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, «Network Time Protocol Version 4: Protocol and Algorithms Specification», RFC 5905, DOI 10.17487/RFC5905, June 2010, <http://www.rfc-editor.org/info/rfc5905>.

[RFC6298] Paxson, V., Allman, M., Chu, J., and M. Sargent, «Computing TCP’s Retransmission Timer», RFC 6298, DOI 10.17487/RFC6298, June 2011,
<http://www.rfc-editor.org/info/rfc6298>.

[Stevens98] Stevens, W., Fenner, B., and A. Rudoff, «Unix Networking Programming, Volume 1: The Sockets Networking API (3rd Edition)», 1998.

Приложение А. Примеры

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

A.1. Медиа по запросу (одноадресная передача)

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

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

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

Ниже приведен пример использования одного сеанса RTSP для управления несколькими потоками. Это также иллюстрирует использование совокупных URI. В файле контейнера также желательно не записывать какие-либо части URI, которые не сохраняются при распределении контейнера, такие как хост и большая часть элемента пути. Поэтому в этом примере также используется «*» и относительный URI в доставленном SDP.

Кроме того, это описание презентации (SDP) не может быть кэшировано, так как заголовок Expires установлен равным значению с датой, указывающей немедленное истечение срока его действия.

Клиент C запрашивает презентацию с медиа-сервера M. Фильм сохраняется в файле контейнера. Клиент получил URI RTSP к файлу контейнера.

C->M: DESCRIBE rtsp://example.com/twister.3gp RTSP/2.0 CSeq: 1 User-Agent: PhonyClient/1.2

M->C: RTSP/2.0 200 OK CSeq: 1 Server: PhonyServer/1.0 Date: Fri, 20 Dec 2013 10:20:32 +0000 Content-Type: application/sdp Content-Length: 271 Content-Base: rtsp://example.com/twister.3gp/ Expires: Fri, 20 Dec 2013 12:20:32 +0000 v=0 o=- 2890844256 2890842807 IN IP4 198.51.100.5 s=RTSP Session i=An Example of RTSP Session Usage e=adm@example.com c=IN IP4 0.0.0.0 a=control: * a=range:npt=00:00:00-00:10:34.10 t=0 0 m=audio 0 RTP/AVP 0 a=control: trackID=1 m=video 0 RTP/AVP 26 a=control: trackID=4

C->M: SETUP rtsp://example.com/twister.3gp/trackID=1 RTSP/2.0 CSeq: 2 User-Agent: PhonyClient/1.2 Require: play.basic Transport: RTP/AVP;unicast;dest_addr=":8000"/":8001" Accept-Ranges: npt, smpte, clock

M->C: RTSP/2.0 200 OK CSeq: 2 Server: PhonyServer/1.0 Transport: RTP/AVP;unicast; ssrc=93CB001E; dest_addr="192.0.2.53:8000"/"192.0.2.53:8001"; src_addr="198.51.100.5:9000"/"198.51.100.5:9001" Session: OccldOFFq23KwjYpAnBbUr Expires: Fri, 20 Dec 2013 12:20:33 +0000 Date: Fri, 20 Dec 2013 10:20:33 +0000 Accept-Ranges: npt Media-Properties: Random-Access=0.02, Immutable, Unlimited

C->M: SETUP rtsp://example.com/twister.3gp/trackID=4 RTSP/2.0 CSeq: 3 User-Agent: PhonyClient/1.2 Require: play.basic Transport: RTP/AVP;unicast;dest_addr=":8002"/":8003" Session: OccldOFFq23KwjYpAnBbUr Accept-Ranges: npt, smpte, clock

M->C: RTSP/2.0 200 OK CSeq: 3 Server: PhonyServer/1.0 Transport: RTP/AVP;unicast; ssrc=A813FC13; dest_addr="192.0.2.53:8002"/"192.0.2.53:8003"; src_addr="198.51.100.5:9002"/"198.51.100.5:9003"; Session: OccldOFFq23KwjYpAnBbUr Expires: Fri, 20 Dec 2013 12:20:33 +0000 Date: Fri, 20 Dec 2013 10:20:33 +0000 Accept-Range: NPT Media-Properties: Random-Access=0.8, Immutable, Unlimited

C->M: PLAY rtsp://example.com/twister.3gp/ RTSP/2.0 CSeq: 4 User-Agent: PhonyClient/1.2 Range: npt=30- Seek-Style: RAP Session: OccldOFFq23KwjYpAnBbUr

M->C: RTSP/2.0 200 OK CSeq: 4 Server: PhonyServer/1.0 Date: Fri, 20 Dec 2013 10:20:34 +0000 Session: OccldOFFq23KwjYpAnBbUr Range: npt=30-634.10 Seek-Style: RAP RTP-Info: url="rtsp://example.com/twister.3gp/trackID=4" ssrc=0D12F123:seq=12345;rtptime=3450012, url="rtsp://example.com/twister.3gp/trackID=1" ssrc=4F312DD8:seq=54321;rtptime=2876889

C->M: PAUSE rtsp://example.com/twister.3gp/ RTSP/2.0 CSeq: 5 User-Agent: PhonyClient/1.2 Session: OccldOFFq23KwjYpAnBbUr

# Пауза наступает через 0,87 секунды после начала игры

M->C: RTSP/2.0 200 OK CSeq: 5 Server: PhonyServer/1.0 Date: Fri, 20 Dec 2013 10:20:35 +0000 Session: OccldOFFq23KwjYpAnBbUr Range: npt=30.87-634.10

C->M: PLAY rtsp://example.com/twister.3gp/ RTSP/2.0 CSeq: 6 User-Agent: PhonyClient/1.2 Range: npt=30.87-634.10 Seek-Style: Next Session: OccldOFFq23KwjYpAnBbUr

M->C: RTSP/2.0 200 OK CSeq: 6 Server: PhonyServer/1.0 Date: Fri, 20 Dec 2013 10:22:13 +0000 Session: OccldOFFq23KwjYpAnBbUr Range: npt=30.87-634.10 Seek-Style: Next RTP-Info: url="rtsp://example.com/twister.3gp/trackID=4" ssrc=0D12F123:seq=12555;rtptime=6330012, url="rtsp://example.com/twister.3gp/trackID=1" ssrc=4F312DD8:seq=55021;rtptime=3132889

C->M: TEARDOWN rtsp://example.com/twister.3gp/ RTSP/2.0 CSeq: 7 User-Agent: PhonyClient/1.2 Session: OccldOFFq23KwjYpAnBbUr

M->C: RTSP/2.0 200 OK CSeq: 7 Server: PhonyServer/1.0 Date: Fri, 20 Dec 2013 10:31:53 +0000

А.2. Медиа по запросу с использованием конвейерной обработки

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

C->M: DESCRIBE rtsp://example.com/twister.3gp RTSP/2.0 CSeq: 1 User-Agent: PhonyClient/1.2

v=0 o=- 2890844256 2890842807 IN IP4 192.0.2.5 s=RTSP Session i=An Example of RTSP Session Usage e=adm@example.com c=IN IP4 0.0.0.0 a=control: * a=range:npt=00:00:00-00:10:34.10 t=0 0 m=audio 0 RTP/AVP 0 a=control: trackID=1 m=video 0 RTP/AVP 26 a=control: trackID=4

C->M: SETUP rtsp://example.com/twister.3gp/trackID=4 RTSP/2.0 CSeq: 3 User-Agent: PhonyClient/1.2 Require: play.basic Transport: RTP/AVP;unicast;dest_addr=":8002"/":8003" Accept-Ranges: npt, smpte, clock Pipelined-Requests: 7654

C->M: PLAY rtsp://example.com/twister.3gp/ RTSP/2.0 CSeq: 4 User-Agent: PhonyClient/1.2 Range: npt=0- Seek-Style: RAP Pipelined-Requests: 7654

M->C: RTSP/2.0 200 OK CSeq: 2 Server: PhonyServer/1.0 Transport: RTP/AVP;unicast; dest_addr="192.0.2.53:8000"/"192.0.2.53:8001"; src_addr="198.51.100.5:9000"/"198.51.100.5:9001"; ssrc=93CB001E Session: OccldOFFq23KwjYpAnBbUr Expires: Fri, 20 Dec 2013 12:20:32 +0000 Date: Fri, 20 Dec 2013 10:20:32 +0000 Accept-Ranges: npt Pipelined-Requests: 7654 Media-Properties: Random-Access=0.2, Immutable, Unlimited

M->C: RTSP/2.0 200 OK CSeq: 3 Server: PhonyServer/1.0 Transport: RTP/AVP;unicast; dest_addr="192.0.2.53:8002"/"192.0.2.53:8003; src_addr="198.51.100.5:9002"/"198.51.100.5:9003"; ssrc=A813FC13 Session: OccldOFFq23KwjYpAnBbUr Expires: Sat, 21 Dec 2013 10:20:32 +0000 Date: Fri, 20 Dec 2013 10:20:32 +0000 Accept-Range: NPT Pipelined-Requests: 7654 Media-Properties: Random-Access=0.8, Immutable, Unlimited

M->C: RTSP/2.0 200 OK CSeq: 4 Server: PhonyServer/1.0 Date: Fri, 20 Dec 2013 10:20:32 +0000 Session: OccldOFFq23KwjYpAnBbUr Range: npt=0-623.10 Seek-Style: RAP RTP-Info: url="rtsp://example.com/twister.3gp/trackID=4" ssrc=0D12F123:seq=12345;rtptime=3450012, url="rtsp://example.com/twister.3gp/trackID=1" ssrc=4F312DD8:seq=54321;rtptime=2876889 Pipelined-Requests: 7654

А.3. Защищенная медиа-сессия для контента по требованию

Этот пример в основном является приведенным выше примером (Приложение A.2), но теперь включает установление криптографических контекстов SRTP для получения защищенной доставки мультимедиа. Прежде всего, клиент пытается получить это небезопасно, но сервер перенаправляет на URI, указывающий требование использования безопасного соединения для сообщений RTSP. Клиент устанавливает соединение TCP / TLS и извлекает описание сеанса, чтобы определить, какие медиа-ресурсы необходимо настроить. В этом описании сеанса указывается защищенный носитель (SRTP). На следующем шаге клиент отправляет необходимые запросы SETUP, включая сообщения MIKEY. Это передается с запросом PLAY для инициирования доставки мультимедиа.

Примечание. Приведенные ниже сообщения MIKEY не являются действительными сообщениями MIKEY и представляют собой случайные данные в кодировке Base64, представляющие, куда будут отправляться сообщения MIKEY.

C->M: DESCRIBE rtsp://example.com/twister.3gp RTSP/2.0 CSeq: 1 User-Agent: PhonyClient/1.2

M->C: RTSP/2.0 301 Moved Permanently CSeq: 1 Server: PhonyServer/1.0 Date: Fri, 20 Dec 2013 10:25:32 +0000 Location: rtsps://example.com/twister.3gp

C->M: Establish TCP/TLS connection and verify server’s certificate that represents example.com. Used for all below RTSP messages.

C->M: DESCRIBE rtsps://example.com/twister.3gp RTSP/2.0 CSeq: 2 User-Agent: PhonyClient/1.2

M->C: RTSP/2.0 200 OK CSeq: 2 Server: PhonyServer/1.0 Date: Fri, 20 Dec 2013 10:25:33 +0000 Content-Type: application/sdp Content-Length: 271 Content-Base: rtsps://example.com/twister.3gp/ Expires: Fri, 20 Dec 2013 12:25:33 +0000

v=0 o=- 2890844256 2890842807 IN IP4 192.0.2.5 s=RTSP Session i=An Example of RTSP Session Usage e=adm@example.com c=IN IP4 0.0.0.0 a=control: * a=range:npt=00:00:00-00:10:34.10 t=0 0 m=audio 0 RTP/SAVP 0 a=control: trackID=1 m=video 0 RTP/SAVP 26 a=control: trackID=4

C->M: SETUP rtsps://example.com/twister.3gp/trackID=1 RTSP/2.0 CSeq: 3 User-Agent: PhonyClient/1.2 Require: play.basic Transport: RTP/SAVP;unicast;dest_addr=":8000"/":8001"; MIKEY=VGhpcyBpcyB0aGUgZmlyc3Qgc3RyZWFtcyBNSUtFWSBtZXNzYWdl Accept-Ranges: npt, smpte, clock Pipelined-Requests: 7654

C->M: SETUP rtsps://example.com/twister.3gp/trackID=4 RTSP/2.0 CSeq: 4 User-Agent: PhonyClient/1.2 Require: play.basic Transport: RTP/SAVP;unicast;dest_addr=":8002"/":8003"; MIKEY=TUlLRVkgZm9yIHN0cmVhbSB0d2lzdGVyLjNncC90cmFja0lEPTQ= Accept-Ranges: npt, smpte, clock Pipelined-Requests: 7654

C->M: PLAY rtsps://example.com/twister.3gp/ RTSP/2.0 CSeq: 5 User-Agent: PhonyClient/1.2 Range: npt=0- Seek-Style: RAP Pipelined-Requests: 7654

M->C: RTSP/2.0 200 OK CSeq: 3 Server: PhonyServer/1.0 Transport: RTP/SAVP;unicast; dest_addr="192.0.2.53:8000"/"192.0.2.53:8001"; src_addr="198.51.100.5:9000"/"198.51.100.5:9001"; ssrc=93CB001E; MIKEY=TUlLRVkgUmVzcG9uc2UgdHdpc3Rlci4zZ3AvdHJhY2tJRD0x Session: OccldOFFq23KwjYpAnBbUr Expires: Fri, 20 Dec 2013 12:25:34 +0000 Date: Fri, 20 Dec 2013 10:25:34 +0000 Accept-Ranges: npt Pipelined-Requests: 7654 Media-Properties: Random-Access=0.2, Immutable, Unlimited

M->C: RTSP/2.0 200 OK CSeq: 4 Server: PhonyServer/1.0 Transport: RTP/SAVP;unicast; dest_addr="192.0.2.53:8002"/"192.0.2.53:8003; src_addr="198.51.100.5:9002"/"198.51.100.5:9003"; ssrc=A813FC13; MIKEY=TUlLRVkgUmVzcG9uc2UgdHdpc3Rlci4zZ3AvdHJhY2tJRD00 Session: OccldOFFq23KwjYpAnBbUr Expires: Fri, 20 Dec 2013 12:25:34 +0000 Date: Fri, 20 Dec 2013 10:25:34 +0000 Accept-Range: NPT Pipelined-Requests: 7654 Media-Properties: Random-Access=0.8, Immutable, Unlimited

M->C: RTSP/2.0 200 OK CSeq: 5 Server: PhonyServer/1.0 Date: Fri, 20 Dec 2013 10:25:34 +0000 Session: OccldOFFq23KwjYpAnBbUr Range: npt=0-623.10 Seek-Style: RAP RTP-Info: url="rtsps://example.com/twister.3gp/trackID=4" ssrc=0D12F123:seq=12345;rtptime=3450012, url="rtsps://example.com/twister.3gp/trackID=1" ssrc=4F312DD8:seq=54321;rtptime=2876889; Pipelined-Requests: 7654

А.4. Медиа по запросу (одноадресная передача)

Альтернативный пример медиа по запросу с несколькими дополнительными настройками заключается в следующем. Клиент C запрашивает фильм, распространяемый с двух разных медиа-серверов A (audio.example.com) и V (video.example.com). Описание мультимедиа хранится на веб-сервере W. Описание мультимедиа содержит описания презентации и всех ее потоков, включая доступные кодеки и стек протоколов.

В этом примере клиент интересуется только последней частью фильма.

C->W: GET /twister.sdp HTTP/1.1 Host: www.example.com Accept: application/sdp

W->C: HTTP/1.1 200 OK Date: Wed, 23 Jan 2013 15:35:06 GMT Content-Type: application/sdp Content-Length: 278 Expires: Thu, 24 Jan 2013 15:35:06 GMT

v=0 o=- 2890844526 2890842807 IN IP4 198.51.100.5 s=RTSP Session e=adm@example.com c=IN IP4 0.0.0.0 a=range:npt=00:00:00-01:49:34 t=0 0 m=audio 0 RTP/AVP 0 a=control:rtsp://audio.example.com/twister/audio.en m=video 0 RTP/AVP 31 a=control:rtsp://video.example.com/twister/video

C->A: SETUP rtsp://audio.example.com/twister/audio.en RTSP/2.0 CSeq: 1 User-Agent: PhonyClient/1.2 Transport: RTP/AVP/UDP;unicast;dest_addr=":3056"/":3057", RTP/AVP/TCP;unicast;interleaved=0-1 Accept-Ranges: npt, smpte, clock

A->C: RTSP/2.0 200 OK CSeq: 1 Session: OccldOFFq23KwjYpAnBbUr Transport: RTP/AVP/UDP;unicast; dest_addr="192.0.2.53:3056"/"192.0.2.53:3057"; src_addr="198.51.100.5:5000"/"198.51.100.5:5001" Date: Wed, 23 Jan 2013 15:35:12 +0000 Server: PhonyServer/1.0 Expires: Thu, 24 Jan 2013 15:35:12 +0000 Cache-Control: public Accept-Ranges: npt, smpte Media-Properties: Random-Access=0.02, Immutable, Unlimited

C->V: SETUP rtsp://video.example.com/twister/video RTSP/2.0 CSeq: 1 User-Agent: PhonyClient/1.2 Transport: RTP/AVP/UDP;unicast; dest_addr="192.0.2.53:3058"/"192.0.2.53:3059", RTP/AVP/TCP;unicast;interleaved=0-1 Accept-Ranges: npt, smpte, clock

V->C: RTSP/2.0 200 OK CSeq: 1 Session: P5it3pMo6xHkjUcDrNkBjf Transport: RTP/AVP/UDP;unicast; dest_addr="192.0.2.53:3058"/"192.0.2.53:3059"; src_addr="198.51.100.5:5002"/"198.51.100.5:5003" Date: Wed, 23 Jan 2013 15:35:12 +0000 Server: PhonyServer/1.0 Cache-Control: public Expires: Thu, 24 Jan 2013 15:35:12 +0000 Accept-Ranges: npt, smpte Media-Properties: Random-Access=1.2, Immutable, Unlimited

C->V: PLAY rtsp://video.example.com/twister/video RTSP/2.0 CSeq: 2 User-Agent: PhonyClient/1.2 Session: P5it3pMo6xHkjUcDrNkBjf Range: smpte=0:10:00-

V->C: RTSP/2.0 200 OK CSeq: 2 Session: P5it3pMo6xHkjUcDrNkBjf Range: smpte=0:10:00-1:49:23 Seek-Style: First-Prior RTP-Info: url="rtsp://video.example.com/twister/video" ssrc=A17E189D:seq=12312232;rtptime=78712811 Server: PhonyServer/2.0 Date: Wed, 23 Jan 2013 15:35:13 +0000

C->A: PLAY rtsp://audio.example.com/twister/audio.en RTSP/2.0 CSeq: 2 User-Agent: PhonyClient/1.2 Session: OccldOFFq23KwjYpAnBbUr Range: smpte=0:10:00-

A->C: RTSP/2.0 200 OK CSeq: 2 Session: OccldOFFq23KwjYpAnBbUr Range: smpte=0:10:00-1:49:23 Seek-Style: First-Prior RTP-Info: url="rtsp://audio.example.com/twister/audio.en" ssrc=3D124F01:seq=876655;rtptime=1032181 Server: PhonyServer/1.0 Date: Wed, 23 Jan 2013 15:35:13 +0000

C->A: TEARDOWN rtsp://audio.example.com/twister/audio.en RTSP/2.0 CSeq: 3 User-Agent: PhonyClient/1.2 Session: OccldOFFq23KwjYpAnBbUr

A->C: RTSP/2.0 200 OK CSeq: 3 Server: PhonyServer/1.0 Date: Wed, 23 Jan 2013 15:36:52 +0000

C->V: TEARDOWN rtsp://video.example.com/twister/video RTSP/2.0 CSeq: 3 User-Agent: PhonyClient/1.2 Session: P5it3pMo6xHkjUcDrNkBjf

V->C: RTSP/2.0 200 OK CSeq: 3 Server: PhonyServer/2.0 Date: Wed, 23 Jan 2013 15:36:52 +0000

Даже несмотря на то, что аудио- и видеодорожка находятся на двух разных серверах, которые могут запускаться в несколько разное время и могут дрейфовать по отношению друг к другу с течением времени, клиент может выполнить начальную синхронизацию двух носителей, используя RTP-Info и Range, полученные в PLAY. ответы. Если два сервера синхронизированы по времени, пакеты RTCP также можно использовать для поддержания синхронизации.

А.5. Однопотоковые контейнерные файлы

Некоторые RTSP-серверы могут обрабатывать все файлы, как если бы они были «контейнерными файлами», однако другие серверы могут не поддерживать такую концепцию. Из-за этого клиенты должны использовать правила, изложенные в описании сеанса для Request-URI, а не предполагать, что согласованный URI всегда может использоваться повсеместно. Ниже приведен пример того, как многопотоковый сервер может ожидать обработки однопотокового файла:

C->S: DESCRIBE rtsp://foo.example.com/test.wav RTSP/2.0 Accept: application/x-rtsp-mh, application/sdp CSeq: 1 User-Agent: PhonyClient/1.2

S->C: RTSP/2.0 200 OK CSeq: 1 Content-base: rtsp://foo.example.com/test.wav/ Content-type: application/sdp Content-length: 163 Server: PhonyServer/1.0 Date: Wed, 23 Jan 2013 15:36:52 +0000 Expires: Thu, 24 Jan 2013 15:36:52 +0000

v=0 o=- 872653257 872653257 IN IP4 192.0.2.5 s=mu-law wave file i=audio test c=IN IP4 0.0.0.0 t=0 0 a=control: * m=audio 0 RTP/AVP 0 a=control:streamid=0

C->S: SETUP rtsp://foo.example.com/test.wav/streamid=0 RTSP/2.0 Transport: RTP/AVP/UDP;unicast; dest_addr=":6970"/":6971";mode="PLAY" CSeq: 2 User-Agent: PhonyClient/1.2 Accept-Ranges: npt, smpte, clock

S->C: RTSP/2.0 200 OK Transport: RTP/AVP/UDP;unicast; dest_addr="192.0.2.53:6970"/"192.0.2.53:6971"; src_addr="198.51.100.5:6970"/"198.51.100.5:6971"; mode="PLAY";ssrc=EAB98712 CSeq: 2 Session: NYkqQYKk0bb12BY3goyoyO Expires: Thu, 24 Jan 2013 15:36:52 +0000 Server: PhonyServer/1.0 Date: Wed, 23 Jan 2013 15:36:52 +0000 Accept-Ranges: npt Media-Properties: Random-Access=0.5, Immutable, Unlimited

C->S: PLAY rtsp://foo.example.com/test.wav/ RTSP/2.0 CSeq: 3 User-Agent: PhonyClient/1.2 Session: NYkqQYKk0bb12BY3goyoyO

S->C: RTSP/2.0 200 OK CSeq: 3 Server: PhonyServer/1.0 Date: Wed, 23 Jan 2013 15:36:52 +0000 Session: NYkqQYKk0bb12BY3goyoyO Range: npt=0-600 Seek-Style: RAP RTP-Info: url="rtsp://foo.example.com/test.wav/streamid=0" ssrc=0D12F123:seq=981888;rtptime=3781123

Обратите внимание на другой URI в команде SETUP, а затем переключитесь обратно на агрегатный URI в команде PLAY. Это имеет смысл, когда есть несколько потоков с совокупным управлением, но это не так интуитивно понятно в особом случае, когда число потоков равно одному. Однако сервер объявил агрегированный контрольный URI в SDP; следовательно, это законно.

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

C->S: PLAY rtsp://example.com/test.wav/streamid=0 RTSP/2.0 CSeq: 3 User-Agent: PhonyClient/1.2 Session: NYkqQYKk0bb12BY3goyoyO

А.6. Презентация медиа трансляции с использованием многоадресной передачи

Медиа-сервер М выбирает адрес и порт многоадресной рассылки. Здесь предполагается, что веб-сервер содержит только указатель на полное описание, в то время как медиа-сервер М поддерживает полное описание.

C->W: GET /sessions.html HTTP/1.1 Host: www.example.com

W->C: HTTP/1.1 200 OK Content-Type: text/html <html> ... <a href "rtsp://live.example.com/concert/audio"> Streamed Live Music performance </a> ... </html>

C->M: DESCRIBE rtsp://live.example.com/concert/audio RTSP/2.0 CSeq: 1 Supported: play.basic, play.scale User-Agent: PhonyClient/1.2

M->C: RTSP/2.0 200 OK CSeq: 1 Content-Type: application/sdp Content-Length: 183 Server: PhonyServer/1.0 Date: Wed, 23 Jan 2013 15:36:52 +0000 Supported: play.basic

v=0 o=- 2890844526 2890842807 IN IP4 192.0.2.5 s=RTSP Session t=0 0 m=audio 3456 RTP/AVP 0 c=IN IP4 233.252.0.54/16 a=control: rtsp://live.example.com/concert/audio a=range:npt=0-

C->M: SETUP rtsp://live.example.com/concert/audio RTSP/2.0 CSeq: 2 Transport: RTP/AVP;multicast; dest_addr="233.252.0.54:3456"/"233.252.0.54:3457";ttl=16 Accept-Ranges: npt, smpte, clock User-Agent: PhonyClient/1.2

M->C: RTSP/2.0 200 OK CSeq: 2 Server: PhonyServer/1.0 Date: Wed, 23 Jan 2013 15:36:52 +0000 Transport: RTP/AVP;multicast; dest_addr="233.252.0.54:3456"/"233.252.0.54:3457";ttl=16 ;ssrc=4D12AB92/0DF876A3 Session: qHj4jidpmF6zy9v9tNbtxr Accept-Ranges: npt, clock Media-Properties: No-Seeking, Time-Progressing, Time-Duration=0

C->M: PLAY rtsp://live.example.com/concert/audio RTSP/2.0 CSeq: 3 Session: qHj4jidpmF6zy9v9tNbtxr User-Agent: PhonyClient/1.2

M->C: RTSP/2.0 200 OK CSeq: 3 Server: PhonyServer/1.0 Date: Wed, 23 Jan 2013 15:36:52 +0000 Session: qHj4jidpmF6zy9v9tNbtxr Seek-Style: Next Range:npt=1256- RTP-Info: url="rtsp://live.example.com/concert/audio" ssrc=0D12F123:seq=1473; rtptime=80000

А.7. Переговоры о возможностях

В этом примере показано, как клиент и сервер определяют свою способность поддерживать специальную функцию, в данном случае «play.scale». Сервер по запросу клиента и включенному заголовку Supported узнает, что клиент поддерживает RTSP 2.0, а также поддерживает функцию масштабирования времени воспроизведения RTSP. Ответ сервера содержит следующую информацию, относящуюся к функции, для клиента; он поддерживает основные функции доставки мультимедиа (play.basic), расширенную функциональность масштабирования времени контента (play.scale) и одну проприетарную функцию «example.com» (com.example.flight). Клиент также изучает методы, поддерживаемые сервером (открытый заголовок) для указанного ресурса.

C->S: OPTIONS rtsp://media.example.com/movie/twister.3gp RTSP/2.0 CSeq: 1 Supported: play.basic, play.scale User-Agent: PhonyClient/1.2

S->C: RTSP/2.0 200 OK CSeq: 1 Public:OPTIONS,SETUP,PLAY,PAUSE,TEARDOWN,DESCRIBE,GET_PARAMETER Allow: OPTIONS, SETUP, PLAY, PAUSE, TEARDOWN, DESCRIBE Server: PhonyServer/2.0 Supported: play.basic, play.scale, com.example.flight

Когда клиент отправляет свой запрос SETUP, он сообщает серверу, что ему требуется поддержка функции play.scale для этого сеанса, включая заголовок Require.

C->S: SETUP rtsp://media.example.com/twister.3gp/trackID=1 RTSP/2.0 CSeq: 3 User-Agent: PhonyClient/1.2 Transport: RTP/AVP/UDP;unicast; dest_addr="192.0.2.53:3056"/"192.0.2.53:3057", RTP/AVP/TCP;unicast;interleaved=0-1 Require: play.scale Accept-Ranges: npt, smpte, clock User-Agent: PhonyClient/1.2

S->C: RTSP/2.0 200 OK CSeq: 3 Session: OccldOFFq23KwjYpAnBbUr Transport: RTP/AVP/UDP;unicast; dest_addr="192.0.2.53:3056"/"192.0.2.53:3057"; src_addr="198.51.100.5:5000"/"198.51.100.5:5001" Server: PhonyServer/2.0 Accept-Ranges: npt, smpte Media-Properties: Random-Access=0.8, Immutable, Unlimited

Приложение B. Состояние машины протокола RTSP

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

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

Приведенный ниже конечный автомат представляет собой информативное описание поведения протокола. В случае неоднозначности с более ранними частями этой спецификации, описание в более ранних частях имеет приоритет.

B.1. Состояния

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

Init: начальное состояние, сеанс не существует.

Ready: сессия готова начать воспроизводить.

Play: сеанс воспроизводится, т.е. отправляет данные медиапотока в направлении S-> C.

B.2. Переменные состояния

Это представление государственного автомата нуждается больше, чем его состояние для работы. Небольшое количество переменных также необходимо, и они объясняются ниже.

NRM: количество медиапотоков, которые являются частью этого сеанса.

RP: точка возобновления, точка на временной шкале представления, с которой будет возобновлен запрос на продолжение воспроизведения. Формат времени для переменной не обязателен.

В.3. Сокращения

Чтобы сделать таблицы состояний более компактными, используется ряд сокращений, которые поясняются ниже.

IFI: IF Implemented. (ЕСЛИ Выполнено)

MD: Медиа

PP: Pause Point, точка на временной шкале презентации, на которой презентация была приостановлена.

Prs: Презентация, полная мультимедийная презентация.

RedP: точка перенаправления, точка на временной шкале представления, в которой было указано REDIRECT.

SES: сессия.

В.4. Таблицы состояния

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

Столбец ответа указывает, какой тип ответных действий следует выполнить. Возможные действия, которые запрашиваются для события, включают в себя: коды ответа, например 200, заголовки, которые должны быть включены в ответ, установку переменных состояния или настройки других параметров, относящихся к сеансу. Новый столбец состояния сообщает, в какое состояние изменяется конечный автомат. Ответ на действительный запрос, удовлетворяющий реквизитам, обычно равен 2xx (УСПЕХ), если в столбце ответа не указано иное. Исключениям должен быть предоставлен ответ согласно столбцу ответов. Если запрос не соответствует требуемому, ошибочен или возникает какой-либо другой тип ошибки, необходимо отправить соответствующий код ответа. Если код ответа 4xx, состояние сеанса не изменяется. Код ответа 3rr приведет к тому, что сеанс будет завершен, и его состояние будет изменено на Init. Код ответа 304 не приводит к изменению состояния. Однако существуют ограничения на использование ответа 3rr. Ответ 5xx не приводит к какому-либо изменению состояния сеанса, кроме случаев, когда ошибка не может быть исправлена. Невосстановимая ошибка приводит к окончанию сеанса. В общем случае, если невозможно определить, была ли это неисправимая ошибка, клиент должен будет выполнить тестирование. В случае, если на следующий запрос после 5xx ответили 454 (Session Not Found), клиент знает, что сеанс завершен. Для любого сообщения запроса, на которое нельзя ответить в течение времени, определенного в Разделе 10.4, должен быть отправлен ответ 100.

Сервер истечет время сеанса после периода времени, указанного в ответе SETUP, если активность клиента не обнаружена. Следовательно, существует событие тайм-аута для всех состояний, кроме Init.

В случае, если NRM = 1, URI представления равен медиа URI или указанному URI представления. Для NRM> 1 URI представления должен отличаться от любого мультимедиа, являющегося частью сеанса. Это относится ко всем штатам.

Таблица 9 - События, не изменяющие состояние машины — Таблица 9 — События, не изменяющие состояние машины

Методы в таблице 9 не оказывают никакого влияния на конечный автомат или переменные состояния. Однако некоторые методы изменяют другие параметры, относящиеся к сеансу, например, SET_PARAMETER, который устанавливает параметры, указанные в его теле. Кроме того, все эти методы, которые разрешают заголовок сеанса, также обновляют таймер поддержания активности для сеанса.

Таблица 10 - Состояние Инициирование — Таблица 10 — Состояние Инициирование

Исходное состояние конечного автомата (таблица 10) может быть оставлено только путем обработки правильного запроса SETUP. Как видно из таблицы, две переменные состояния также задаются правильным запросом. Эта таблица также показывает, что в некоторых случаях правильная настройка может быть перенаправлена на другой URI или сервер с помощью ответа 3rr.

Таблица 11 - Состояние Готово — Таблица 11 — Состояние Готово

В состоянии готовности (таблица 11) некоторые действия зависят от количества медиапотоков (NRM) в сеансе, то есть агрегированного или неагрегированного управления. Запрос SETUP в состоянии готовности может либо добавить еще один поток мультимедиа в сеанс, либо, если поток мультимедиа (тот же URI) уже является частью сеанса, изменить транспортные параметры. TEARDOWN зависит как от Request-URI, так и от количества медиапотоков в сеансе. Если Request-URI является URI представления, весь сеанс прерывается. Если URI мультимедиа используется в запросе TEARDOWN и в сеансе существует более одного мультимедиа, сеанс останется, а в ответе будет возвращен заголовок сеанса. Если при выполнении TEARDOWN с медиа-URI в сеансе остается только один медиапоток, сеанс удаляется. Количество медиапотоков, оставшихся после разрыва медиапотока, определяет новое состояние.

Таблица 12 - Состояние Воспроизведение — Таблица 12 — Состояние Воспроизведение

Таблица состояний воспроизведения (таблица 12) содержит ряд запросов, для работы которых требуется URI представления (помеченный как Prs URI) (то есть URI представления должен использоваться в качестве Request-URI). Это связано с исключением неагрегированного управления потоком в сеансах с более чем одним медиапотоком.

Во избежание несоответствий между клиентом и сервером автоматические переходы между состояниями исключаются. Это можно увидеть, например, на событии «Конец мультимедиа», когда все мультимедиа закончили воспроизведение, но сеанс все еще остается в состоянии воспроизведения. Явный запрос PAUSE должен быть отправлен для изменения состояния на Ready. Может показаться, что существуют автоматические переходы в «Достигнут RedP» и «Достигнут PP». Тем не менее, они запрашиваются и подтверждаются, прежде чем они имеют место. Время, в которое произойдет переход, известно по параметрам времени заголовка Terminate-Reason и заголовку Range, соответственно. Если клиент отправляет запрос близко ко времени этих переходов, он должен быть готов к приему сообщений об ошибках, так как состояние может измениться или не измениться.

Приложение C. Медиа-Транспортные Альтернативы

Этот раздел определяет, как используются определенные комбинации протоколов, профилей и низших транспортных средств. Это включает использование параметров адреса источника и назначения заголовка транспорта: «src_addr» и «dest_addr».

C.1. RTP

В этом разделе определяется взаимодействие RTSP с протоколом RTP [RFC3550 #]. Он также определяет любые необходимые медиатранспортные сигналы в отношении RTP.

Доступные профили RTP и транспорты нижнего уровня описаны ниже вместе с правилами сигнализации доступных комбинаций.

С.1.1. AVP

Использование «профиля RTP для аудио- и видеоконференций с минимальным управлением» [RFC3551 #] при использовании RTP для передачи мультимедиа по различным транспортным протоколам нижнего уровня определяется ниже в отношении RTSP.

Один такой случай определен в этом документе: использование встроенных (чередующихся) двоичных данных, как определено в разделе 14. Использование этого метода указывается включением параметра «чередование».

При использовании встроенных двоичных данных «src_addr» и «dest_addr» НЕ ДОЛЖНЫ использоваться. Эта адресация и мультиплексирование используются, как определено с использованием номеров каналов и параметра чередования.

С.1.2. AVP / UDP

В этой части описывается отправка RTP [RFC3550 #] по UDP нижнего транспортного уровня [RFC768 #] в соответствии с профилем «Профиль RTP для аудио- и видеоконференций с минимальным управлением», определенным в [RFC3551 #]. Реализации RTP / AVP / UDP ДОЛЖНЫ реализовывать RTCP (Приложение C.1.6). Этот профиль требует одного или двух однонаправленных или двунаправленных потоков UDP на поток медиаданных. Первый поток UDP для RTP, а второй для RTCP. МОЖЕТ использоваться мультиплексирование RTP и RTCP (Приложение C.1.6.4), и в этом случае один поток UDP используется для обеих частей. Вложение данных RTP в сообщения RTSP в соответствии с разделом 14 НЕ ДОЛЖНО выполняться, когда сообщения RTSP транспортируются по ненадежным транспортным протоколам, таким как UDP [RFC768 #].

Потоки RTP / UDP и RTCP / UDP могут быть установлены с использованием параметров заголовка транспорта «src_addr» и «dest_addr».

В режиме RTSP PLAY передача RTP-пакетов от клиента к серверу не определена. Поведение в отношении таких пакетов RTP МОЖЕТ быть определено в будущем.

Параметры «src_addr» и «dest_addr» используются следующим образом для режима доставки и воспроизведения мультимедиа, то есть Mode = PLAY:

o Параметры «src_addr» и «dest_addr» ДОЛЖНЫ содержать 1 или 2 спецификации адреса. Обратите внимание, что две спецификации адреса МОГУТ быть предоставлены, даже если согласовано мультиплексирование RTP и RTCP.

o Каждая спецификация адреса для RTP / AVP / UDP или RTP / AVP / TCP ДОЛЖНА содержать либо:

и адрес, и номер порта, или
номер порта без адреса.

o Первая спецификация адреса, указанная в любом из параметров, применяется к потоку RTP. Вторая спецификация, если она присутствует, применяется к потоку RTCP, если только не согласовано мультиплексирование RTP и RTCP, где и RTP, и RTCP будут использовать первую спецификацию.

o Пакеты RTP / UDP от сервера к клиенту ДОЛЖНЫ быть отправлены на адрес и порт, заданные в первой спецификации адреса параметра «dest_addr».

o Пакеты RTCP / UDP от сервера к клиенту ДОЛЖНЫ быть отправлены на адрес и порт, заданные второй спецификацией адреса параметра «dest_addr», если только не согласовано мультиплексирование RTP и RTCP, в этом случае RTCP ДОЛЖЕН быть отправлен первая спецификация адреса. Если вторая пара не указана и мультиплексирование RTP и RTCP не согласовано, RTCP НЕ ДОЛЖЕН отправляться.

o Пакеты RTCP / UDP от клиента к серверу ДОЛЖНЫ быть отправлены на адрес и порт, заданные второй спецификацией адреса параметра «src_addr», если только не согласовано мультиплексирование RTP и RTCP, в этом случае RTCP ДОЛЖЕН быть отправлен первая спецификация адреса. Если вторая пара не указана и мультиплексирование RTP и RTCP не согласовано, RTCP НЕ ДОЛЖЕН отправляться.

o Пакеты RTP / UDP от клиента к серверу ДОЛЖНЫ быть отправлены на адрес и порт, указанные в первой спецификации адреса параметра «src_addr».

o пакеты RTP и RTCP ДОЛЖНЫ отправляться с соответствующего порта-получателя, т. е. пакеты RTCP с сервера должны отправляться из второй пары портов адреса параметров «src_addr», если только не согласовано мультиплексирование RTP и RTCP, в этом случае первый порт адреса пара используется.

С.1.3. AVPF / UDP

Профиль RTP «Расширенный профиль RTP для обратной связи на основе RTCP (RTP / AVPF)» [RFC4585 #] МОЖЕТ использоваться в качестве профилей RTP в сеансах с использованием RTP. Все, что определено для AVP, ДОЛЖНО также применяться к AVPF.

Использование AVPF указывается в используемом протоколе инициализации носителя. В случае SDP это обозначено медийными линиями («m =»), содержащими профиль RTP / AVPF. Этот SDP МОЖЕТ также содержать дополнительные относящиеся к AVPF атрибуты SDP, конфигурирующие сеанс AVPF относительно интервала сообщения и сообщений обратной связи, которые будут использоваться [RFC4585 #]. Эту конфигурацию ДОЛЖНЫ придерживаться.

С.1.4. SAVP / UDP

Профиль RTP «Безопасный транспортный протокол в реальном времени (SRTP)» [RFC3711 #] — это профиль RTP (SAVP), который МОЖЕТ использоваться в сеансах RTSP с использованием RTP. Все, что определено для AVP, ДОЛЖНО также применяться к SAVP.

Использование SRTP требует, чтобы был установлен контекст безопасности. Управление ключами по умолчанию, если не указано иное, ДОЛЖНО быть MIKEY в режиме RSA-R, как определено в Приложении C.1.4.1, и не в соответствии с процедурой, определенной в «Расширениях управления ключами для протокола описания сеанса (SDP) и протокола потоковой передачи в реальном времени ( RTSP) «[RFC4567]. Причина в том, что RFC 4567 отправляет начальное сообщение MIKEY в SDP, таким образом, как требующий использования метода DESCRIBE, так и принуждающий сервер сохранять состояние для клиентов, выполняющих DESCRIBE, в ожидании, что им может потребоваться управление ключами.

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

C.1.4.1. MIKEY Key Establishment

Этот метод использования MIKEY [RFC3830 #] для установления криптографического контекста SRTP инициируется в запросе SETUP клиента, а ответ сервера на SETUP содержит ответ MIKEY. Это гарантирует, что установление криптографического контекста происходит одновременно с установлением защищаемого медиапотока. Используя режим MIKEY RSA-R [RFC4738 #], клиент может быть инициатором и при этом разрешать серверу устанавливать параметры в соответствии с фактическим медиапотоком.

Установление криптографического контекста SRTP выполняется в соответствии со следующим процессом:

1. Клиент определяет, что SAVP или SAVPF должны использоваться из формата описания мультимедиа, например, SDP. Если никакой другой метод управления ключами явно не передан, тогда MIKEY ДОЛЖЕН использоваться, как определено в данном документе. Использование SRTP с RTSP определяется только для MIKEY с ключами, установленными, как определено в этом разделе. Будущие документы могут определить, как реализация RTSP обрабатывает SDP, что указывает на некоторый другой ключевой механизм, который будет использоваться. Потребность в такой спецификации включает в себя [RFC4567], который не определен для использования в RTSP 2.0 в этом документе.

2. Клиент ДОЛЖЕН установить соединение TLS для сообщений RTSP, напрямую или по узлам, с сервером. Если используется защита по протоколу TLS, то метод User ДОЛЖЕН быть указан в заголовке Accept-Credentials. Обратите внимание, что использование прыжка за прыжком позволяет прокси-серверу вставлять себя как человека посередине. Это также может происходить при обмене MIKEY, когда прокси-сервер предоставляет один из своих сертификатов, а не сервер в заголовке Connection-Credentials. Следовательно, клиент ДОЛЖЕН проверять сертификат сервера.

3. Клиент извлекает сертификат сервера из прямого соединения TLS или переходов между заголовками из заголовка Connection-Credentials. Затем клиент проверяет, что сертификат сервера действителен и принадлежит серверу.

4. Клиент формирует сообщение MIKEY Initiator, используя режим RSA-R в одноадресном режиме, как указано в [RFC4738 #]. Клиент ДОЛЖЕН использовать один и тот же сертификат для TLS и MIKEY, чтобы сервер мог связать их вместе. Сертификат клиента ДОЛЖЕН быть включен в сообщение MIKEY. Клиент ДОЛЖЕН указывать свои возможности SRTP в сообщении.

5. Сообщение MIKEY из предыдущего шага кодируется в base64 [RFC4648 #] и становится значением параметра MIKEY, включенного в спецификацию (и) транспорта, которая указывает профиль на основе SRTP (SAVP, SAVPF) в запросе SETUP.

6. Любой прокси, имеющий параметр MIKEY, ДОЛЖЕН переслать его без изменений. Прокси, который требуется для понимания спецификаций транспорта, должен понимать SAVP / SAVPF с MIKEY, чтобы включить ключ по умолчанию для потоков мультимедиа, защищенных SRTP. Если такой прокси-сервер не поддерживает SAVP / SAVPF с MIKEY, он отбрасывает всю спецификацию транспорта. Большинство типов прокси могут легко поддерживать SAVP и SAVPF с MIKEY. Если клиент обнаруживает прокси, не поддерживающий SAVP / SAVPF с MIKEY, клиент должен попытаться обойти этот прокси.

7. После получения запроса SETUP серверу необходимо принять решение о том, какую спецификацию транспорта использовать, если клиент включил несколько. При определении того, какие транспортные спецификации поддерживаются и предпочтительны, сервер ДОЛЖЕН декодировать сообщение MIKEY, чтобы принять во внимание встроенные параметры SRTP. Если для всех транспортных спецификаций требуется SRTP, но не включен параметр MIKEY или другой поддерживаемый метод ввода, сервер ДОЛЖЕН ответить 403 (Запрещено).

8. После генерации ответа могут произойти следующие результаты:
* Выбрана транспортная спецификация, не использующая SRTP и MIKEY. Таким образом, ответ не будет содержать никаких параметров MIKEY.
* Транспортная спецификация, использующая SRTP и MIKEY, выбрана, но при обработке MIKEY обнаружена ошибка. В этом случае ДОЛЖЕН использоваться код ответа об ошибке RTSP 466 (Ошибка управления ключами). MIKEY сообщение, описывающее ошибку, МОЖЕТ быть включено.
* Транспортная спецификация с использованием SRTP и MIKEY выбрана, и может быть создано ответное сообщение MIKEY. Сервер ДОЛЖЕН использовать один и тот же сертификат для TLS и MIKEY, чтобы клиент мог связать их вместе. Если используется другой сертификат, он ДОЛЖЕН быть включен в сообщение MIKEY. РЕКОМЕНДУЕТСЯ, чтобы тип кеша ключа конверта был установлен в ‘Cache’, и чтобы один ключ конверта повторно использовался для всех сообщений MIKEY клиенту. Это сообщение включено в часть параметра MIKEY единственной выбранной транспортной спецификации в ответе SETUP. Сервер установит параметры SRTP как предпочтительные для этого медиапотока в пределах поддерживаемого клиентом диапазона.
9. Сервер передает ответ SETUP обратно клиенту.

10. Клиент получает ответ SETUP и, если код ответа указывает на успешный запрос, он декодирует сообщение MIKEY и устанавливает криптографический контекст SRTP из параметров в ответе MIKEY.

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

С.1.5. SAVPF / UDP

Профиль RTP «Расширенный безопасный профиль RTP для обратной связи на основе протокола управления транспортом в реальном времени (RTCP) (RTP / SAVPF)» [RFC5124 #] — это профиль RTP (SAVPF), который МОЖЕТ использоваться в сеансах RTSP с использованием RTP. Все, что определено для AVPF, ДОЛЖНО также применяться к SAVPF.

Использование SRTP требует, чтобы был установлен криптографический контекст. Механизм по умолчанию для установления этой ассоциации безопасности заключается в использовании MIKEY [RFC3830 #] с RTSP, как определено в Приложении C.1.4.1.

C.1.6. Использование RTCP с RTSP

RTCP имеет несколько применений, когда RTP реализован для передачи медиа, как описано ниже. Таким образом, RTCP ДОЛЖЕН поддерживаться, если агент RTSP обрабатывает RTP.

C.1.6.1. Медиа синхронизация

RTCP обеспечивает синхронизацию медиа и компенсацию смещения тактовой частоты. Начальная синхронизация медиа доступна из заголовка RTP-Info. Однако, чтобы иметь возможность обрабатывать любой сдвиг тактовой частоты между медиапотоками, необходим RTCP.

C.1.6.2. RTSP сессия Keep-Alive

Трафик RTCP от клиента RTSP к серверу RTSP ДОЛЖЕН функционировать как keep-alive. Это требует, чтобы сервер RTSP, поддерживающий RTP, использовал полученные пакеты RTCP в качестве указателей на то, что клиент желает, чтобы соответствующий сеанс RTSP был поддержан.

C.1.6.3. Битрейт Адаптация

Отчеты приемника RTCP и любые дополнительные отзывы от клиента ДОЛЖНЫ использоваться для адаптации скорости передачи битов, используемой по транспорту, для всех случаев, когда RTP передается по UDP. Отправитель RTP без зарезервированных ресурсов НЕ ДОЛЖЕН использовать больше, чем его справедливая доля доступных ресурсов. Это может быть определено путем сравнения на коротких и средних (несколько секунд) использованных битрейтах и адаптации его так, чтобы отправитель RTP отправлял с битрейтом, сопоставимым с тем, что отправитель TCP достигнет в среднем по тому же пути.

Чтобы механизм адаптации реализации имел четко определенный внешний конверт, все реализации, использующие одноадресный транспортный протокол, не контролируемый перегрузкой, такой как UDP, ДОЛЖНЫ реализовать «Управление перегрузкой мультимедиа: прерыватели цепи для сеансов одноадресной передачи RTP» [RTP-CIRCUIT-BREAKERS].

C.1.6.4. RTP и RTCP мультиплексирование

RTSP может использоваться для согласования использования мультиплексирования RTP и RTCP, как описано в [RFC5761]. Это позволяет серверам и клиенту сократить объем ресурсов, необходимых для сеанса, требуя только один базовый транспортный поток на поток мультимедиа вместо двух при использовании RTP и RTCP. Это уменьшает потребление серверного порта, а также необходимое состояние и поддержание работоспособности при работе через NAT [RFC2663].

Контент должен быть подготовлен с некоторым учетом мультиплексирования RTP и RTCP, главным образом гарантируя, что используемые типы полезной нагрузки RTP не конфликтуют с теми, которые используются для типов пакетов RTCP. Эта опция, вероятно, нуждается в явной поддержке со стороны контента, если только типы полезной нагрузки RTP не могут быть переназначены сервером, и это правильно отражено в описании сеанса. Кроме того, поддержка этой функции должна быть недорогой и выгодной.
Рекомендуется, чтобы, если контент и сервер поддерживали мультиплексирование RTP и RTCP, это указывалось в описании сеанса, например, с использованием атрибута SDP «a = rtcp-mux». Если сообщение SDP содержит атрибут «a = rtcp-mux» для медиапотока, сервер ДОЛЖЕН поддерживать мультиплексирование RTP и RTCP. Если это указано или иным образом желательно клиентом, он может включить параметр транспорта «RTCPmux» в любую спецификацию транспорта, где он хочет использовать «RTCPmux». Сервер укажет, поддерживает ли он «RTCP-mux». Серверы и клиенты ДОЛЖНЫ поддерживать мультиплексирование RTP и RTCP.

Для обмена возможностями определен тег функции RTSP для мультиплексирования RTP и RTCP: «setup.rtp.rtcp.mux».

Чтобы минимизировать риск сбоя согласования при использовании мультиплексирования RTP и RTCP, здесь приведены некоторые рекомендации. Если описание сеанса включает в себя явное указание поддержки («a = rtcp-mux» в SDP), тогда агент RTSP может безопасно создать запрос SETUP со спецификацией транспорта только с одной спецификацией адреса параметра «dest_addr». Если такого явного указания не предоставлено, то даже если тег функции «setup.rtp.rtcp.mux» предоставляется в поддерживаемом заголовке сервером RTSP или тег функции, включенный в заголовок «Обязательный» в запросе SETUP, медиаресурс может не поддерживать мультиплексирование RTP и RTCP. Таким образом, чтобы максимизировать вероятность успешного согласования, агент RTSP рекомендуется включать две спецификации адреса параметра «dest_addr» в первый или первый набор (если используется конвейерная обработка) запросов (-ов) SETUP для любого агрегата медиаресурсов. Таким образом, сервер RTSP может принимать мультиплексирование RTP и RTCP и использовать только первую спецификацию адреса или, если нет, использовать обе спецификации. Агент RTSP после получения ответа для успешного согласования использования мультиплексирования RTP и RTCP может затем высвободить ресурсы, связанные со второй спецификацией адреса.

С.2. RTP через TCP

Транспортировка RTP через TCP может осуществляться двумя способами: через независимые соединения TCP с использованием [RFC4571] или с чередованием в соединении RTSP. В обоих случаях протокол ДОЛЖЕН быть «rtp», а нижний уровень ДОЛЖЕН быть TCP. Профиль может быть любым из указанных выше: AVP, AVPF, SAVP или SAVPF.

С.2.1. Чередование RTP через TCP

Использование встроенных (чередующихся) двоичных данных, транспортируемых по соединению RTSP, возможно, как указано в разделе 14. При использовании этой объявленной комбинации чередующихся двоичных данных сообщения RTSP ДОЛЖНЫ передаваться по TCP. TLS может использоваться или не использоваться. Если используется TLS, и сообщения RTSP, и двоичные данные будут защищены TLS.

Однако следует учитывать, что это приведет к тому, что все медиапотоки будут проходить через любой прокси. Использование независимых TCP-соединений может избежать этой проблемы.

С.2.2. RTP через независимый TCP

В этом разделе отправка RTP [RFC3550 #] по транспортному TCP нижнего уровня [RFC793 #] в соответствии с «Кадрами пакетов транспортного протокола реального времени (RTP) и протокола управления RTP (RTCP) по транспорту, ориентированному на соединение» [RFC4571] описано. В этом разделе приведены рекомендации по использованию RTP через TCP в SIP / SDP [RFC4145] для работы с RTSP.

Клиент кодирует поддержку RTP через независимый TCP, указав опцию транспорта RTP / AVP / TCP без чередующегося параметра в строке транспорта запроса SETUP. Эта опция транспорта ДОЛЖНА включать параметр «одноадресная передача».

Если клиент желает использовать RTP с RTCP, в параметр «dest_addr» необходимо включить две спецификации адреса. Если клиент желает использовать RTP без RTCP, в параметр «dest_addr» включается одна спецификация адреса. Если клиент желает мультиплексировать RTP и RTCP в одном транспортном потоке (см. Приложение C.1.6.4), одна или две спецификации адреса включаются в параметр dest_addr в дополнение к транспортному параметру RTCP-mux. Две спецификации адреса разрешены для облегчения успешного согласования, когда сервер или контент не могут поддерживать мультиплексирование RTP и RTCP. Правила заказа портов dest_addr следуют правилам для RTP / AVP / UDP.

Если клиент желает играть активную роль в инициировании TCP-соединения, он МОЖЕТ установить «активный» параметр настройки (см. Раздел 18.54) на транспортной линии или МОЖЕТ опустить параметр настройки, так как по умолчанию активен. Если клиент сигнализирует об активной роли, порты в спецификациях адресов в параметре «dest_addr» ДОЛЖНЫ быть установлены на 9 (порт сброса).

Если клиент желает играть пассивную роль в инициировании TCP-соединения, он ДОЛЖЕН установить параметр настройки на транспортной линии как «пассивный». Если клиент может взять на себя активную или пассивную роль, он ДОЛЖЕН установить параметр настройки на транспортной линии как «actpass». В любом случае значение порта спецификации адреса параметра «dest_addr» для RTP ДОЛЖНО быть установлено на номер порта TCP, на котором клиент ожидает получить соединение TCP для RTP, а значение порта спецификации адреса «dest_addr» для RTCP ДОЛЖНО быть установите номер порта TCP, на котором клиент ожидает получить соединение TCP для RTCP. В случае, когда клиент желает мультиплексировать RTP и RTCP в одном транспортном потоке, включается параметр «RTCP-mux» и включаются одна или две спецификации адреса параметра «dest_addr», как упоминалось ранее в этом разделе.

После получения запроса RTP / AVP / TCP SETUP без чередования, если сервер решит принять эту запрошенную опцию, ответ 2xx ДОЛЖЕН содержать опцию транспорта, которая задает RTP / AVP / TCP (без использования параметра чередования и одноадресной передачи). параметр). Значение параметра «dest_addr» ДОЛЖНО быть отражено из значения параметра в клиентском запросе, если не был указан адрес назначения (только порт); в этом случае сервер МОЖЕТ включать адрес источника TCP-соединения RTSP с неизменным номером порта.

Кроме того, ответ сервера ДОЛЖЕН установить параметр настройки на транспортной линии, чтобы указать роль, которую сервер будет играть в настройке соединения. Допустимые значения: «активный» (если клиент установил настройку «пассивный» или «actpass») и «пассивный» (если клиент установил настройку «активный» или «actpass»).

Если сервер устанавливает настройку на «пассивный», то «src_addr» в ответе ДОЛЖЕН указывать порты, на которых сервер желает получить TCP-соединение для RTP, и (если клиент запросил TCP-соединение для RTCP, указав два «dest_addr» «спецификация адреса) соединение TCP / RTCP. Если сервер устанавливает настройку на «активный», порты, указанные в спецификациях адресов «src_addr», ДОЛЖНЫ быть установлены на 9. Сервер МОЖЕТ использовать параметр «ssrc», следуя указаниям в разделе 18.54. Сервер устанавливает только одну спецификацию адреса в случае, если клиент указал только одну спецификацию адреса, или если мультиплексирование RTP и RTCP было запрошено и принято сервером. Порядок портов для «src_addr» соответствует правилам для RTP / AVP / UDP.

Серверы ДОЛЖНЫ поддерживать принятие пассивной роли и МОГУТ поддерживать принятие активной роли. Серверы с общедоступным IP-адресом играют пассивную роль, что позволяет клиентам, находящимся за NAT и брандмауэрами, с большей вероятностью успешно подключиться к серверу, активно подключаясь к нему. Поэтому клиентам РЕКОМЕНДУЕТСЯ принять активное участие.
После отправки (получения) ответа 2xx для метода SETUP для не чередующегося потока мультимедиа RTP / AVP / TCP активная сторона ДОЛЖНА инициировать соединение TCP как можно скорее. Клиент НЕ ДОЛЖЕН отправлять запрос PLAY до установления всех соединений TCP, согласованных с использованием SETUP для сеанса. Если сервер получает запрос PLAY в сеансе, который еще не установил все соединения TCP, он ДОЛЖЕН ответить, используя код ошибки 464 (передача данных еще не готова) (раздел 17.4.28).
Как только происходит запрос PLAY для медиаресурса, транспортируемого по RTP / AVP / TCP без перемежения, медиа начинает передаваться с сервера на клиент по TCP-соединению RTP, а пакеты RTCP передаются в двустороннем режиме по TCP-соединению RTCP. Если не согласовано мультиплексирование RTP и RTCP; в этом случае RTP и RTCP будут передаваться по общему TCP-соединению. Как и в случае RTP / UDP, трафик клиент-сервер в сеансе TCP только для RTP не указывается в этой заметке. Пакеты, которые передаются по этим соединениям, ДОЛЖНЫ быть сформированы с использованием протокола, определенного в [RFC4571], а не с помощью кадрирования, определенного для перемежения RTP по соединению RTSP, определенному в разделе 14.

Успешный запрос PAUSE для носителей, передаваемых по RTP / AVP / TCP, приостанавливает поток пакетов по соединениям, не закрывая соединения. Успешный запрос TEARDOWN сигнализирует о том, что TCP-соединения для RTP и RTCP должны быть закрыты клиентом RTSP как можно скорее.

Последующие запросы SETUP с использованием URI, уже настроенного в сеансе RTSP с использованием транспортной спецификации RTP / AVP / TCP, могут быть неоднозначными следующим образом: желает ли клиент открыть новое соединение TCP для RTP или RTCP для URI, или клиент желает продолжить использование существующих TCP-соединений? Клиент ДОЛЖЕН использовать параметр «соединение» (определенный в разделе 18.54) на транспортной линии, чтобы прояснить свое намерение (установив «соединение» на «новое», если нужны новые соединения, и установив «соединение» на «существующее»). если будут использоваться существующие соединения). После ответа 2xx на запрос SETUP для нового соединения стороны должны закрыть ранее существовавшие соединения, ожидая подходящего периода для получения любых случайных пакетов RTP или RTCP.

Использование SRTP, то есть профилей SAVP или SAVPF, требует установления ассоциации безопасности. Механизм по умолчанию для установления этой ассоциации безопасности заключается в использовании MIKEY [RFC3830 #] с RTSP, как определено в Приложении C.1.4.1.

Ниже, переписанная версия примера «Носитель по требованию» (Приложение A.1) показывает использование RTP / AVP / TCP без чередования:

C->M: DESCRIBE rtsp://example.com/twister.3gp RTSP/2.0 CSeq: 1 User-Agent: PhonyClient/1.2

M->C: RTSP/2.0 200 OK CSeq: 1 Server: PhonyServer/1.0 Date: Wed, 23 Jan 2013 15:36:52 +0000 Content-Type: application/sdp Content-Length: 227 Content-Base: rtsp://example.com/twister.3gp/ Expires: Thu, 24 Jan 2013 15:36:52 +0000

v=0 o=- 2890844256 2890842807 IN IP4 198.51.100.34 s=RTSP Session i=An Example of RTSP Session Usage e=adm@example.com c=IN IP4 0.0.0.0 a=control: * a=range:npt=00:00:00-00:10:34.10 t=0 0 m=audio 0 RTP/AVP 0 a=control: trackID=1

C->M: SETUP rtsp://example.com/twister.3gp/trackID=1 RTSP/2.0 CSeq: 2 User-Agent: PhonyClient/1.2 Require: play.basic Transport: RTP/AVP/TCP;unicast;dest_addr=":9"/":9"; setup=active;connection=new Accept-Ranges: npt, smpte, clock

M->C: RTSP/2.0 200 OK CSeq: 2 Server: PhonyServer/1.0 Transport: RTP/AVP/TCP;unicast; dest_addr=":9"/":9"; src_addr="198.51.100.5:53478"/"198.51.100:54091"; setup=passive;connection=new;ssrc=93CB001E Session: OccldOFFq23KwjYpAnBbUr Expires: Thu, 24 Jan 2013 15:36:52 +0000 Date: Wed, 23 Jan 2013 15:36:52 +0000 Accept-Ranges: npt Media-Properties: Random-Access=0.8, Immutable, Unlimited

C->M: TCP Connection Establishment x2

C->M: PLAY rtsp://example.com/twister.3gp/ RTSP/2.0 CSeq: 4 User-Agent: PhonyClient/1.2 Range: npt=30- Session: OccldOFFq23KwjYpAnBbUr

M->C: RTSP/2.0 200 OK CSeq: 4 Server: PhonyServer/1.0 Date: Wed, 23 Jan 2013 15:36:54 +0000 Session: OccldOFFq23KwjYpAnBbUr Range: npt=30-623.10 Seek-Style: First-Prior RTP-Info: url="rtsp://example.com/twister.3gp/trackID=1" ssrc=4F312DD8:seq=54321;rtptime=2876889

С.3. Обработка скачков времени медиа-часов в медиа-уровне RTP

RTSP позволяет медиа-клиентам управлять выбранными несмежными секциями медиа-презентаций, визуализируя эти потоки с медиа-уровнем RTP [RFC3550 #]. Происходят два случая: первый случай, когда новый запрос PLAY заменяет старый текущий запрос, а новый запрос приводит к скачку на носителе. Это должно создавать непрерывный поток мультимедиа на уровне RTP. Клиент также может сразу же выполнить заполненный запрос PLAY с новым запросом PLAY. Это приведет к некоторому разрыву в медиа-слое. Приведенный ниже текст рассмотрит оба случая.

Запрос PLAY, который заменяет текущий запрос PLAY, позволяет медиа-уровню, визуализирующему поток RTP, делать это непрерывно, не подвергаясь влиянию скачков времени медиа-часов. Метки времени RTP для нового диапазона носителей устанавливаются так, чтобы они стали непрерывными с предыдущим диапазоном носителей в предыдущем запросе. Порядковый номер RTP для первого пакета в новом диапазоне будет следующим за последним пакетом в предыдущем диапазоне, то есть будет монотонно увеличиваться. Цель состоит в том, чтобы позволить слою рендеринга мультимедиа работать без перебоев или переконфигурирования между скачками медиа-часов. Это должно быть возможно во всех случаях замещенных запросов PLAY для мультимедиа, которое имеет свойства произвольного доступа. В этом случае необходимо соблюдать осторожность, чтобы выровнять кадры или подобные медиа-зависимые структуры.

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

Для сеансов RTSP со средами, в которых отсутствуют свойства произвольного доступа, таких как прямые потоки, любой скачок медиа-часов обычно является результатом соответственно длинной паузы доставки. Отметка времени RTP будет увеличена прямо пропорционально продолжительности приостановленной доставки. Отметим также, что в этом случае порядковый номер RTP должен быть следующим номером пакета. Если нет, то в отчете о потере пакетов RTCP будет указываться как потеря всех пакетов, не полученных между точкой приостановки и последующим возобновлением. Это может запустить механизмы предотвращения заторов. Допустимое исключение из приведенной выше рекомендации по монотонно увеличивающемуся порядковому номеру RTP — живые медиапотоки, которые, вероятно, ретранслируются. В этом случае, когда клиент возобновляет доставку, он получит носитель, который в данный момент доставляется на сам сервер. Для этого типа базовой доставки потоков в реальном времени нескольким пользователям по одноадресной передаче отдельная перезапись порядковых номеров RTP становится довольно обременительной. Для решений, которые уже кэшируют носители или выполняют сдвиг во времени, перезапись должна налагать лишь незначительную нагрузку.

Цель при обработке скачков во времени медиа-часов состоит в том, что предоставленный поток является непрерывным без пробелов в метке времени RTP или порядковом номере. Однако, когда доставка по какой-то причине была остановлена, временная метка RTP при возобновлении ДОЛЖНА представлять продолжительность остановки доставки. Порядковый номер RTP ДОЛЖЕН, как правило, быть следующим числом, т. Е. Монотонно увеличивающимся по модулю 65536. Для медиаресурсов со свойствами Time-Progressing и Time-Duration = 0.0 сервер МОЖЕТ создавать медиапотоки RTP с скачками порядкового номера RTP в них из-за клиент сначала останавливает доставку, а затем возобновляет ее (PAUSE, а затем PLAY). Однако серверы, использующие это исключение, должны учитывать итоговые отчеты приемника RTCP, которые, вероятно, содержат отчеты о потерях для всех пакетов, которые были частью разрыва. Клиент не может полагаться на тот факт, что сервер возобновит выравнивание при возобновлении воспроизведения, даже если это РЕКОМЕНДУЕТСЯ. Заголовок RTP-Info предоставит информацию о том, как работает сервер в каждом случае.

Нельзя предполагать, что клиент RTSP может связываться с агентом мультимедиа RTP, так как оба могут быть независимыми процессами. Если временная метка RTP показывает тот же разрыв, что и NPT, медиа-агент будет предполагать, что в презентации есть пауза. Если переход в NPT достаточно велик, временная метка RTP может пролонгироваться, и медиаагент может полагать, что последующие пакеты будут дубликатами только что воспроизведенных пакетов. Наличие скачка метки времени RTP также повлияет на измерения RTCP, основанные на этом.

В качестве примера предположим, что частота меток времени RTP составляет 8000 Гц, интервал пакетирования составляет 100 мс, а начальный номер последовательности и метка времени равны нулю.

C->S: PLAY rtsp://example.com/fizzle RTSP/2.0 CSeq: 4 Session: ymIqLXufHkMHGdtENdblWK Range: npt=10-15 User-Agent: PhonyClient/1.2

S->C: RTSP/2.0 200 OK CSeq: 4 Session: ymIqLXufHkMHGdtENdblWK Range: npt=10-15 RTP-Info: url="rtsp://example.com/fizzle/audiotrack" ssrc=0D12F123:seq=0;rtptime=0

Последующий поток данных RTP изображен ниже:

S -> C: RTP packet - seq = 0, rtptime = 0, NPT time = 10s S -> C: RTP packet - seq = 1, rtptime = 800, NPT time = 10.1s . . . S -> C: RTP packet - seq = 49, rtptime = 39200, NPT time = 14.9s

По завершении запрошенной доставки сервер отправляет PLAY_NOTIFY.

S->C: PLAY_NOTIFY rtsp://example.com/fizzle RTSP/2.0 CSeq: 5 Notify-Reason: end-of-stream Request-Status: cseq=4 status=200 reason="OK" Range: npt=-15 RTP-Info:url="rtsp://example.com/fizzle/audiotrack" ssrc=0D12F123:seq=49;rtptime=39200 Session: ymIqLXufHkMHGdtENdblWK

C->S: RTSP/2.0 200 OK CSeq: 5 User-Agent: PhonyClient/1.2

По завершении игрового диапазона клиент выполняет запрос PLAY из нового NPT.

C->S: PLAY rtsp://example.com/fizzle RTSP/2.0 CSeq: 6 Session: ymIqLXufHkMHGdtENdblWK Range: npt=18-20 User-Agent: PhonyClient/1.2

S->C: RTSP/2.0 200 OK CSeq: 6 Session: ymIqLXufHkMHGdtENdblWK Range: npt=18-20 RTP-Info: url="rtsp://example.com/fizzle/audiotrack" ssrc=0D12F123:seq=50;rtptime=40100

Последующий поток данных RTP изображен ниже:

S->C: RTP packet - seq = 50, rtptime = 40100, NPT time = 18s S->C: RTP packet - seq = 51, rtptime = 40900, NPT time = 18.1s . . . S->C: RTP packet - seq = 69, rtptime = 55300, NPT time = 19.9s

В этом примере сначала воспроизводятся NPT с 10 по 15, затем клиент просит сервер пропустить и воспроизвести NPT с 18 по 20. Первый сегмент представлен в виде пакетов RTP с порядковыми номерами от 0 до 49 и временными метками от 0 до 39 200. Второй сегмент состоит из RTP-пакетов с порядковыми номерами от 50 до 69 с временными метками от 40 100 до 55 200. Хотя в NPT есть промежуток, в пространстве порядковых номеров потока данных RTP нет промежутка.

Разрыв метки времени RTP присутствует в приведенном выше примере из-за времени, которое требуется для выполнения второго запроса воспроизведения, в данном случае 12,5 мс (100/8000).

С.4. Обработка временных меток RTP после PAUSE

Во время взаимодействия PAUSE / PLAY в сеансе RTSP продолжительность времени, на которое была прервана передача RTP, ДОЛЖНА отражаться в метке времени RTP каждого потока RTP. Длительность может быть рассчитана для каждого потока RTP как время, прошедшее с того момента, когда последний пакет RTP был отправлен до получения запроса PAUSE, и когда первый пакет RTP был отправлен после получения последующего запроса PLAY. Продолжительность включает в себя всю задержку и время обработки, необходимое для выполнения запроса.

RFC 3550 [RFC3550 #] утверждает, что: «метка времени RTP для каждого блока [пакета] будет связана с временем настенного таймера, в которое блок становится текущим на временной шкале виртуального представления».

Чтобы удовлетворить требованиям [RFC3550 #], пространство меток времени RTP должно непрерывно увеличиваться с реальным временем. Хотя это не является оптимальным для хранимых носителей, требуется, чтобы RTP и RTCP работали, как предполагалось. Использование непрерывного пространства меток времени RTP позволяет использовать одну и ту же модель меток времени как для хранимых, так и для живых носителей, а также дает лучшую возможность интегрировать оба типа носителей под единым управлением.

В качестве примера предположим, что тактовая частота составляет 8000 Гц, интервал пакетирования составляет 100 мс, а начальный порядковый номер и временная метка равны нулю.

C->S: PLAY rtsp://example.com/fizzle RTSP/2.0 CSeq: 4 Session: ymIqLXufHkMHGdtENdblWK Range: npt=10-15 User-Agent: PhonyClient/1.2

S->C: RTSP/2.0 200 OK CSeq: 4 Session: ymIqLXufHkMHGdtENdblWK Range: npt=10-15 RTP-Info: url="rtsp://example.com/fizzle/audiotrack" ssrc=0D12F123:seq=0;rtptime=0

Последующий поток данных RTP изображен ниже:

S -> C: RTP packet - seq = 0, rtptime = 0, NPT time = 10s S -> C: RTP packet - seq = 1, rtptime = 800, NPT time = 10.1s S -> C: RTP packet - seq = 2, rtptime = 1600, NPT time = 10.2s S -> C: RTP packet - seq = 3, rtptime = 2400, NPT time = 10.3s

Затем клиент отправляет запрос PAUSE:

C->S: PAUSE rtsp://example.com/fizzle RTSP/2.0 CSeq: 5 Session: ymIqLXufHkMHGdtENdblWK User-Agent: PhonyClient/1.2

S->C: RTSP/2.0 200 OK CSeq: 5 Session: ymIqLXufHkMHGdtENdblWK Range: npt=10.4-15

По истечении 20 секунд клиент отправляет запрос PLAY. Кроме того, серверу требуется 15 мс для обработки запроса:

C->S: PLAY rtsp://example.com/fizzle RTSP/2.0 CSeq: 6 Session: ymIqLXufHkMHGdtENdblWK User-Agent: PhonyClient/1.2

S->C: RTSP/2.0 200 OK CSeq: 6 Session: ymIqLXufHkMHGdtENdblWK Range: npt=10.4-15 RTP-Info: url="rtsp://example.com/fizzle/audiotrack" ssrc=0D12F123:seq=4;rtptime=164400

Последующий поток данных RTP изображен ниже:

S -> C: RTP packet - seq = 4, rtptime = 164400, NPT time = 10.4s S -> C: RTP packet - seq = 5, rtptime = 165200, NPT time = 10.5s S -> C: RTP packet - seq = 6, rtptime = 166000, NPT time = 10.6s

Сначала воспроизводятся NPT с 10 по 10.3, затем сервер получает паузу. Через 20 секунд сервер получает сообщение PLAY, обработка которого занимает 15 мс. Продолжительность времени, на которое сеанс был приостановлен, отражается в метке времени RTP пакетов RTP, отправленных после этого запроса PLAY.

Клиент может использовать заголовок RTSP Range и RTP-Info для отображения времени NPT презентации с отметкой времени RTP.

Примечание: в RFC 2326 [RFC2326 #] этот вопрос не был четко определен и обычно неправильно понимался. Однако для RTSP 2.0 ожидается, что это будет обрабатываться правильно, и обработка исключений не потребуется.

Отметим далее: может потребоваться сброс некоторых состояний для обеспечения правильного декодирования мультимедиа и обычной обработки буфера дрожания при выдаче запроса PLAY.

С.5. Интеграция RTSP / RTP

Для определенных типов данных потребуется тесная интеграция между уровнем RTSP и уровнем RTP. Это никоим образом не исключает вышеуказанные ограничения. Комбинированные медиа-клиенты RTSP / RTP должны использовать поле RTP-Info, чтобы определить, были ли отправлены входящие пакеты RTP до или после поиска, или до, или после PAUSE.

С.6. Масштабирование с помощью RTP

Для масштабирования (см. Раздел 18.46) временные метки RTP должны соответствовать времени рендеринга. Например, при воспроизведении видео, записанного со скоростью 30 кадров в секунду, со шкалой два и скоростью (раздел 18.50), равной единице, сервер будет сбрасывать каждый второй кадр, чтобы поддерживать и доставлять видеопакеты с нормальным интервалом между отметками времени 3000 на кадр, но NPT будет увеличиваться на 1/15 секунды для каждого видеокадра.

Примечание. Приведенное выше масштабирование предъявляет требования к медиа-кодеку или медиа-потоку для его поддержки. Например, движение JPEG или другое не предсказывающее кодирование видео может легче обрабатывать приведенный выше пример.

С.7. Поддержание синхронизации NPT с временными метками RTP

Клиент может поддерживать правильное отображение NPT, отмечая значение метки времени RTP первого пакета, прибывающего после изменения положения. Параметр последовательности заголовка RTP-Info (раздел 18.45) предоставляет первый порядковый номер следующего сегмента.

С.8. Непрерывный Аудио

Для непрерывного аудио серверу СЛЕДУЕТ установить бит маркера RTP в начале обслуживания нового запроса PLAY или при скачках по временной шкале. Это позволяет клиенту выполнить адаптацию задержки воспроизведения.

С.9. Несколько источников в сеансе RTP

Обратите внимание, что в потоке мультимедиа МОЖЕТ быть отправлено более одного SSRC. Если это произойдет, все источники будут отображаться одновременно.

С.10. Использование SSRC и сообщения RTCP BYE во время сеанса RTSP

Сообщение RTCP BYE указывает на конец использования данного SSRC. Если все источники покидают сеанс RTP, в большинстве случаев можно предположить, что он закончился. Следовательно, клиент или сервер НЕ ДОЛЖНЫ отправлять сообщение RTCP BYE до тех пор, пока не завершится использование SSRC. Сервер ДОЛЖЕН продолжать использовать SSRC, пока сеанс RTP не будет завершен. Продление использования SSRC позволяет использовать установленный контекст синхронизации, связанный с этим SSRC, для синхронизации последующих запросов PLAY, даже если ответ PLAY запаздывает.

Конфликт SSRC с SSRC, который передает мультимедиа, также имеет последствия, так как обычно он заставляет отправителя мультимедиа изменить свой SSRC в соответствии со спецификацией RTP [RFC3550 #]. Однако сервер RTSP может подождать и посмотреть, изменится ли клиент, и таким образом разрешить конфликт, чтобы минимизировать влияние. Как отправитель мультимедиа, изменение SSRC приведет к потере контекста синхронизации и потребует от любого получателя дождаться отчетов отправителя RTCP для всех носителей, требующих синхронизации, прежде чем сможет воспроизводиться синхронизировано. По этим причинам клиент, присоединяющийся к сеансу, должен позаботиться о том, чтобы не выбирать те же SSRC, которые сервер указывает в параметре заголовка транспорта ssrc. Любой SSRC, указанный в заголовке транспорта, ДОЛЖЕН быть исключен. Клиент, обнаруживший коллизию до отправки любых сообщений RTP или RTCP, ДОЛЖЕН также выбрать новый SSRC.

С.11. Будущие дополнения

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

При добавлении нового протокола или профиля для использования с RTSP необходимо учитывать следующее:

o Протокол или профиль должны определить тег имени, представляющий его. Этот тег должен быть «токеном» ABNF, чтобы его можно было использовать в спецификации заголовка транспорта.

o Необходимо определить полезные комбинации протокола, профилей и транспорта нижнего уровня для этого расширения. Для каждой комбинации объявите необходимые параметры для использования в заголовке транспорта.

o Для новых медиа-протоколов необходимо рассмотреть взаимодействие с RTSP. Одним из важных факторов будет синхронизация медиа. Для переноса этой информации может потребоваться наличие новых заголовков, похожих на информацию RTP.

o Необходимо провести обсуждение относительно контроля перегрузки для носителей, особенно если используется транспорт без встроенного контроля перегрузки.
См. Раздел «Соображения IANA» (раздел 22) для получения информации о том, как зарегистрировать новые атрибуты.

Приложение D. Использование SDP для описания сеансов RTSP

Протокол описания сеанса (SDP, [RFC4566 #]) может использоваться для описания потоков или представлений в RTSP. Это описание обычно возвращается в ответ на запрос DESCRIBE по URI от сервера к клиенту или принимается по HTTP от сервера к клиенту.

В этом приложении описывается, как файл SDP определяет работу сеанса RTSP. Таким образом, стоит указать, что интерпретация SDP выполняется в контексте приемника SDP, который является конфигурируемым. Это то же самое, что и в SAP [RFC2974]; это отличается от предложения / ответа SDP [RFC3264], где каждый SDP интерпретируется в контексте агента, предоставляющего его.

SDP, как есть, не предоставляет механизма, с помощью которого клиент может различать без руководства человека несколько потоков мультимедиа, которые должны быть воспроизведены одновременно, и набор альтернатив (например, два аудиопотока, на которых говорят на разных языках). Расширение SDP, указанное в «Структуре группирования протокола описания сеанса (SDP)» [RFC5888], в некоторой степени обеспечивает такую функциональность. В Приложении D.4 описано использование группировки линий связи SDP для RTSP.

D.1. Определения

Термины «уровень сеанса», «уровень носителя» и другие имена и значения ключей / атрибутов, используемые в этом приложении, должны использоваться, как определено в SDP [RFC4566 #]:

D.1.1. Контрольный URI

Атрибут «a = control» используется для передачи управляющего URI. Этот атрибут используется как для описания сеанса, так и для описания носителя. Если используется для отдельных медиа, он указывает URI, который будет использоваться для управления этим конкретным медиа потоком. Если найдено на уровне сеанса, атрибут указывает URI для совокупного контроля (презентационный URI). URI уровня сеанса ДОЛЖЕН отличаться от любого URI уровня мультимедиа. Наличие атрибута управления на уровне сеанса ДОЛЖНО интерпретироваться как поддержка агрегированного управления. Атрибут управления ДОЛЖЕН присутствовать на медиа уровне, если только презентация не содержит только один медиа поток; в этом случае атрибут МОЖЕТ присутствовать только на уровне сеанса и затем также применяться к этому единственному медиапотоку.

ABNF для атрибута определен в разделе 20.3.

Пример:

a=control:rtsp://example.com/foo

Этот атрибут МОЖЕТ содержать относительные или абсолютные URI в соответствии с правилами и соглашениями, изложенными в RFC 3986 [RFC3986 #]. Реализации ДОЛЖНЫ искать базовый URI в следующем порядке:

1. поле RTSP Content-Base;

2. поле RTSP Content-Location;

3. Запрос RTSP-URI.

Если этот атрибут содержит только звездочку (*), тогда URI ДОЛЖЕН рассматриваться как пустой встроенный URI; таким образом, он унаследует весь базовый URI.

Примечание: RFC 2326 # был очень неясен в обработке относительных URI, и несколько реализаций RTSP 1.0 на момент публикации этого документа не выполняли обработку RFC 3986 # для определения результирующего URI; вместо этого обычна простая конкатенация. Чтобы полностью избежать этой проблемы, рекомендуется использовать абсолютные URI в SDP.

Обработка URI для SDP из контейнерных файлов требует особого рассмотрения. Например, предположим, что файл контейнера имеет URI: «rtsp: //example.com/container.mp4». Далее предположим, что этот URI является базовым URI и что существует абсолютный URI медиа-уровня: «rtsp: //example.com/container.mp4/trackID=2». Относительный URI медиа-уровня, который разрешается в соответствии с RFC 3986 [RFC3986 #] к указанному выше указанному медиа-URI, является «container.mp4 / trackID = 2». Обычно нежелательно включать или изменять SDP, хранящийся в файле контейнера, с помощью локального имени сервера файла контейнера. Чтобы избежать этого, можно изменить базовый URI, используемый для включения завершающей косой черты, например, «rtsp: //example.com/container.mp4/». В этом случае относительный URI для носителя должен быть только «trackID = 2». Однако это также будет означать, что использование «*» в SDP приведет к URI элемента управления, включая завершающий слеш, т.е. «rtsp: //example.com/container.mp4/».

Примечание. Использование TrackID в приведенном выше примере — это не стандартизированная форма, а один пример из нескольких похожих строк, таких как TrackID, Track_ID, StreamID, которые используются различными поставщиками серверов для указания определенного фрагмента мультимедиа в файле контейнера.

D.1.2. Медиа потоки

Поле «m =» используется для перечисления потоков. Ожидается, что все указанные потоки будут отображаться с соответствующей синхронизацией. Если сеанс находится в режиме многоадресной передачи, указанный номер порта СЛЕДУЕТ использовать для приема. Клиент МОЖЕТ попытаться переопределить порт назначения через заголовок транспорта. Серверы МОГУТ разрешить это: в ответе будет указано, разрешено ли это. Если сеанс одноадресный, то номера портов — это те, которые РЕКОМЕНДУЕТСЯ сервером клиенту, какие порты получателя использовать; клиент ДОЛЖЕН по-прежнему включать свои порты получателя в запрос SETUP. Клиент МОЖЕТ игнорировать эту рекомендацию. Если у сервера нет предпочтений, он ДОЛЖЕН установить значение номера порта в ноль.

Строки «m =» содержат информацию о том, какой транспортный протокол, профиль и, возможно, нижний уровень должны использоваться для медиапотока. Необходимо определить комбинацию транспорта, профиля и нижнего уровня, например RTP / AVP / UDP, для использования с RTSP. Определенные в настоящее время комбинации обсуждаются в Приложении C; другие комбинации МОГУТ быть указаны.

Пример:

m=audio 0 RTP/AVP 31

D.1.3. Тип (ы) полезной нагрузки

Тип или типы полезных данных указываются в строке «m =». В случае, если тип полезной нагрузки является статическим типом полезной нагрузки из RFC 3551 [RFC3551 #], никакой другой информации может не потребоваться. В случае, если это динамический тип полезной нагрузки, атрибут медиа «rtpmap» используется для указания, что такое медиа. «Имя кодирования» в атрибуте «rtpmap» может быть одним из указанных в [RFC4856], типом носителя, зарегистрированным в IANA в соответствии с [RFC4855], или экспериментальным кодированием, указанным в SDP [RFC4566 #]). Специфичные для кодека параметры указаны не в этом поле, а в атрибуте «fmtp», описанном ниже.

Выбор используемых типов типов полезной нагрузки RTP может потребоваться для учета мультиплексирования RTP и RTCP [RFC5761], если это должно поддерживаться сервером.

D.1.4. Специфичные для формата параметры

Специфичные для формата параметры передаются с использованием медиа-атрибута «fmtp». Синтаксис атрибута «fmtp» зависит от кодировки, к которой относится атрибут. Обратите внимание, что некоторые специфичные для формата параметры могут быть указаны вне параметров «fmtp», например, например, атрибут «ptime» для большинства аудиокодировок.

D.1.5. Направленность медиапотока

Атрибуты SDP «a = sendrecv», «a = recvonly» и «a = sendonly» предоставляют инструкции о направлении потока медиапотоков в течение сеанса. При использовании RTSP SDP может быть доставлен клиенту с использованием RTSP DESCRIBE или нескольких внешних методов RTSP, таких как HTTP, FTP и электронная почта. На основании этого SDP применяется к тому, как клиент RTSP будет видеть полный сеанс. Таким образом, медиапотокам, доставленным с сервера RTSP клиенту, будет присвоен атрибут «a = recvonly».

«a = recvonly» в SDP, предоставленном клиенту RTSP, указывает, что доставка мультимедиа будет происходить только в направлении от сервера RTSP к клиенту. SDP, предоставляемый клиенту RTSP, в котором отсутствуют какие-либо атрибуты направленности («a = recvonly», «a = sendonly», «a = sendrecv»), будет интерпретироваться как наличие «a = sendrecv». На момент написания статьи не существует режима RTSP, подходящего для трафика мультимедиа в направлении от клиента RTSP к серверу. Таким образом, все RTSP SDP ДОЛЖНЫ иметь атрибут «a = recvonly» при использовании режима PLAY, определенного в этом документе. Если будущие режимы определены для медиа в направлении клиент-сервер, то использование «a = sendonly» или «a = sendrecv» может стать подходящим для указания предполагаемых медиа-направлений.

D.1.6. Диапазон представления

Атрибут «a = range» определяет общий диапазон времени сохраненного сеанса или отдельного носителя. Живые сеансы, которые нельзя найти, могут быть указаны, как указано ниже; тогда как продолжительность сеансов в реальном времени может быть определена из параметров SDP «t =» и «r =».

Атрибут является атрибутом как сеанса, так и уровня носителя. Для презентаций, которые содержат медиапотоки одинаковой продолжительности, атрибут диапазона ДОЛЖЕН использоваться только на уровне сеанса. В случае различной длины атрибут диапазона ДОЛЖЕН быть задан на уровне мультимедиа для всех мультимедиа и НЕ ДОЛЖЕН быть задан на уровне сеанса. Если атрибут присутствует как на уровне мультимедиа, так и на уровне сеанса, ДОЛЖНЫ использоваться значения уровня мультимедиа.

Примечание: обычно указывается одна и та же длина для всех носителей, даже если на всех носителях нет доступных носителей в течение полного времени. Однако для этого требуется, чтобы сервер принимал запросы PLAY в этом диапазоне.

Серверы ДОЛЖНЫ позаботиться о предоставлении значений RTSP Range (см. Раздел 18.40), которые согласуются с тем, что представлено в SDP для контента. Нет оснований для нединамического контента, например, медиаклипы, предоставляемые по требованию, имеют несовместимые значения. Несовместимые значения между SDP и фактическими значениями для содержимого, обрабатываемого сервером, могут привести к некоторой ошибке, например 457 «Неверный диапазон», в случае, если клиент использует запросы PLAY с заголовком Range. Если содержимое имеет динамическую длину и невозможно предоставить правильное значение в SDP, серверу рекомендуется описать это как содержимое, которое нельзя найти (см. Ниже). Сервер МОЖЕТ переопределить это свойство в ответ на запрос PLAY, используя правильные значения в заголовке Range.

Сначала указывается единица измерения, а затем диапазон значений. Единицы измерения и их значения определены в Разделе 4.4.1, Разделе 4.4.2 и Разделе 4.4.3 и МОГУТ быть расширены дополнительными форматами. Любой открытый диапазон (start-), то есть без диапазона останова, имеет неопределенную длительность и ДОЛЖЕН рассматриваться как контент, который нельзя найти, если только это свойство не переопределено. Несколько экземпляров, несущих разные форматы часов, МОГУТ быть включены на уровне сеанса или носителя.

ABNF для атрибута определен в разделе 20.3.

Примеры:

a=range:npt=0-34.4368 a=range:clock=19971113T211503Z-19971113T220300Z Non-seekable stream of unknown duration: a=range:npt=0-

D.1.7. Время доступности

Поле «t =» определяет, когда SDP является действительным. Для контента по требованию сервер ДОЛЖЕН указать значение времени окончания, для которого он гарантирует, что описание является действительным, и время начала, равное или предшествующее времени, в которое был получен запрос DESCRIBE. Также МОЖЕТ указывать время начала и окончания 0, что означает, что сеанс всегда доступен.

Для сеансов живого типа, то есть конкретного времени начала, неизвестного времени окончания, которое, вероятно, недоступно для поиска, поля «t =» и «r =» ДОЛЖНЫ использоваться для указания времени начала события. Время остановки ДОЛЖНО быть дано так, чтобы живое событие закончилось в это время, но все еще не было ненужным в будущем.

D.1.8. Информация о соединении

В SDP, используемом с RTSP, поле «c =» содержит адрес назначения для медиапотока. Если указан адрес многоадресной рассылки, клиент ДОЛЖЕН использовать этот адрес в любом запросе SETUP в качестве адреса назначения, включая любые дополнительные параметры, такие как TTL. Для одноадресных потоков по запросу и некоторых многоадресных потоков адрес получателя МОЖЕТ быть указан клиентом через запрос SETUP, переопределяя любой указанный адрес. Чтобы идентифицировать потоки без фиксированного адреса назначения, когда клиент должен указать адрес назначения, поле «c =» ДОЛЖНО быть установлено в нулевое значение. Для адресов типа «IP4» это значение ДОЛЖНО быть «0.0.0.0»; и для типа «IP6» это значение ДОЛЖНО быть «0: 0: 0: 0: 0: 0: 0: 0» (также может быть записано как «::»), т. е. неуказанный адрес согласно RFC 4291 [ RFC4291 #].

D.1.9. Тег сообщения

Необязательный атрибут «a = mtag» идентифицирует версию описания сеанса. Это непрозрачно для клиента. Запросы SETUP могут включать этот идентификатор в поле If-Match (см. Раздел 18.24), чтобы разрешить установление сеанса, только если это значение атрибута все еще соответствует значению текущего описания. Значение атрибута непрозрачно и может содержать любой символ, допустимый в значениях атрибута SDP.

ABNF для атрибута определен в разделе 20.3.

Пример:

a=mtag:"158bb3e7c7fd62ce67f12b533f06b83a"

Можно утверждать, что поле «o =» обеспечивает идентичную функциональность. Однако это делается таким образом, чтобы на серверы, которые должны поддерживать несколько типов описания сеанса, кроме SDP, накладывали ограничения на один и тот же фрагмент мультимедийного содержимого.

D.2. Совокупный контроль недоступен

Если презентация не поддерживает агрегированное управление, атрибут «a = control» сеансового уровня не указывается. Для SDP с указанием нескольких разделов мультимедиа каждый раздел будет иметь собственный управляющий URI, указанный с помощью атрибута «a = control».

Пример:

v=0 o=- 2890844256 2890842807 IN IP4 192.0.2.56 s=I came from a web page e=adm@example.com c=IN IP4 0.0.0.0 t=0 0 m=video 8002 RTP/AVP 31 a=control:rtsp://audio.example.com/movie.aud m=audio 8004 RTP/AVP 3 a=control:rtsp://video.example.com/movie.vid

Обратите внимание, что позиция URI элемента управления в описании подразумевает, что клиент устанавливает отдельные сеансы управления RTSP для серверов audio.example.com и video.example.com.

Рекомендуется, чтобы файл SDP содержал полную информацию об инициализации медиа, даже если он доставлен медиа клиенту средствами, отличными от RTSP. Это необходимо, так как нет механизма для указания того, что клиент должен запрашивать более подробную информацию о потоке мультимедиа через DESCRIBE.

D.3. Доступен совокупный контроль

В этом сценарии сервер имеет несколько потоков, которыми можно управлять в целом. В этом случае есть как атрибут уровня a = control медиа-уровня, который используется для указания потоковых URI, так и атрибут a = control уровня сеанса, который используется в качестве Request-URI для совокупного управления , Если URI медиа-уровня является относительным, он преобразуется в абсолютные URI согласно Приложению D.1.1 выше.

Пример:

C->M: DESCRIBE rtsp://example.com/movie RTSP/2.0 CSeq: 1 User-Agent: PhonyClient/1.2

M->C: RTSP/2.0 200 OK CSeq: 1 Date: Wed, 23 Jan 2013 15:36:52 +0000 Expires: Wed, 23 Jan 2013 16:36:52 +0000 Content-Type: application/sdp Content-Base: rtsp://example.com/movie/ Content-Length: 227

v=0 o=- 2890844256 2890842807 IN IP4 192.0.2.211 s=I contain i=<more info> e=adm@example.com c=IN IP4 0.0.0.0 a=control:* t=0 0 m=video 8002 RTP/AVP 31 a=control:trackID=1 m=audio 8004 RTP/AVP 3 a=control:trackID=2

В этом примере клиенту рекомендуется установить один сеанс RTSP на сервере, и он использует URI rtsp: //example.com/movie/trackID=1 и rtsp: //example.com/movie/trackID=2 настроить видео и аудио потоки соответственно. URI rtsp: //example.com/movie/, который разрешается из «*», контролирует всю презентацию (фильм).
Клиент не обязан выдавать запросы SETUP для всех потоков в агрегатном объекте. Серверы должны позволять клиенту запрашивать только подмножество потоков.

D.4. Группировка медиа-линий в СДП

Для некоторых типов носителей желательно выразить взаимосвязь между различными компонентами мультимедиа, например, для синхронизации губ или масштабируемого видеокодека (SVC) [RFC5583]. Эта взаимосвязь выражается на уровне SDP путем группировки мультимедийных линий, как описано в [RFC5888], и может подвергаться RTSP.

Для RTSP, главным образом, важно знать, как обрабатывать сгруппированные медиа, полученные с помощью SDP, т. Е. Если медиа находятся под совокупным контролем (см. Приложение D.3) или если совокупный контроль недоступен (см. Приложение D.2).

РЕКОМЕНДУЕТСЯ, чтобы сгруппированные мультимедиа обрабатывались совокупным контролем, чтобы дать клиенту возможность контролировать либо всю презентацию, либо отдельную мультимедиа.

D.5. RTSP Внешний SDP Доставка

Есть некоторые соображения, которые необходимо учитывать, когда описание сеанса доставляется клиенту вне RTSP, например, через HTTP или электронную почту.

Прежде всего, SDP должен содержать абсолютные URI, поскольку относительный в большинстве случаев не будет работать, так как доставка не будет корректно пересылать базовый URI.

Запись информации о доступности сеанса SDP, то есть «t =» и «r =», должна быть тщательно рассмотрена. Когда SDP выбирается методом DESCRIBE, вероятность того, что он действителен, очень высока. Однако то же самое гораздо менее определенно для SDP, распространяемых с использованием других методов. Поэтому издатель SDP должен позаботиться о том, чтобы следовать рекомендациям о доступности в спецификации SDP [RFC4566 #] в Разделе 4.2.

Приложение E. Примеры использования RTSP

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

E.1. Воспроизведение хранимого контента по требованию

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

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

Эту информацию не нужно отправлять с использованием RTSP; другие внешние протоколы могут использоваться для передачи описаний транспортных представлений. Два хороших примера — использование HTTP [RFC7230 #] или электронной почты для извлечения или получения описаний презентаций, таких как SDP [RFC4566 #]

Настройка (Setup): настройка некоторых или всех медиапотоков в презентации.

Сама установка состоит из выбора протокола для передачи мультимедиа и необходимых параметров для протокола, таких как адреса и порты.

Контроль передачи (Control of Transmission): после того, как необходимые медиапотоки были установлены, клиент может запросить сервер начать передачу контента. Клиенту должно быть разрешено запускать или останавливать передачу контента в произвольные моменты времени.

Клиент также должен иметь возможность начать передачу в любой момент времени презентации.

Синхронизация (Synchronization): для протоколов медиа-транспорта, таких как RTP [RFC3550 #], может быть полезно переносить информацию синхронизации в RTSP. Это может быть связано либо с отсутствием межсредовой синхронизации в самом протоколе, либо с потенциальной задержкой до установления синхронизации (что имеет место для RTP при использовании RTCP).

Прекращение (Termination): завершить установленные контексты.

Для этого варианта использования есть ряд предположений о том, как это работает. Это:

Содержимое по требованию (On-Demand content): содержимое хранится на сервере и может быть доступно в любое время в течение периода времени, когда он должен быть доступен.

Независимые сеансы (Independent sessions). Сервер способен одновременно обслуживать несколько клиентов, в том числе из одного и того же фрагмента контента, в разные моменты времени презентации.

Одноадресный транспорт (Unicast Transport): контент для каждого отдельного клиента передается им с использованием одноадресного трафика.

Также возможно перенаправить медиа-трафик в другое место назначения, чем у агента, управляющего трафиком. Однако разрешение этого без соответствующих механизмов проверки того, что получатель одобряет это, позволяет распределенной DoS (DDoS).

E.2. Одноадресное распространение живого контента

Этот вариант использования аналогичен приведенному выше случаю содержимого по требованию (см. Приложение E.1), различие заключается в природе самого содержимого. Живой контент постоянно распространяется по мере его поступления из источника; то есть основное отличие от запроса заключается в том, что каждый начинает распространять контент до того, как его конец станет доступным для сервера.

Во многих случаях потребитель живого контента заинтересован только в том, чтобы потреблять то, что действительно происходит «сейчас»; то есть очень похоже на трансляцию ТВ. Однако в этом случае предполагается, что пользователям не существует широковещательного или многоадресного канала, и вместо этого сервер функционирует как узел распространения, отправляя один и тот же контент нескольким получателям, используя одноадресный трафик между сервером и клиентом. Этот одноадресный трафик и транспортные параметры индивидуально согласовываются для каждого получающего клиента.

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

В некоторых случаях сервер, предоставляющий оперативный контент, может сохранять часть или весь контент, чтобы позволить клиентам приостанавливать поток и возобновлять его с точки приостановки, или «перематывать» и непрерывно воспроизводить с точки, предшествующей точке непосредственного воспроизведения. Следовательно, этот вариант использования не обязательно исключает воспроизведение с точки, отличной от текущей точки потока, воспроизведение с масштабами, отличными от 1,0, и т. д.

E.3. Воспроизведение по требованию с использованием многоадресной рассылки

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

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

E.4. Приглашение сервера RTSP на конференцию

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

В этом сценарии использования предполагается, что существует многоадресная рассылка или фокус конференции, который перераспределяет медиа всем участникам.
Этот вариант использования предназначен для обработки следующего сценария: руководитель или участник конференции (далее называемый «контроллер») имеет некоторый предварительно сохраненный контент на сервере RTSP, которым он хочет поделиться с группой. Контроллер устанавливает сеанс RTSP на потоковом сервере для этого контента и извлекает описание сеанса для контента. Назначением для мультимедийного контента является общая многоадресная группа или фокус конференции.

По желанию контроллера он / она может запускать и останавливать передачу мультимедиа в конференц-группу.

Есть несколько проблем с этим вариантом использования, которые не решены этой основной спецификацией для RTSP:

DoS: чтобы сервер RTSP не был неосознанным участником атаки DoS, сервер должен быть в состоянии проверить, что получатель принимает медиа. Такого механизма проверки одобрения полученных СМИ еще не существует; вместо этого можно использовать только политики, которые можно настроить для работы в контролируемых средах.
Распространение описания презентации всем участникам группы:

Чтобы медиа-приемник мог правильно декодировать контент, информация о конфигурации медиа должна надежно распространяться среди всех участников. Это, скорее всего, потребует поддержки со стороны внешнего протокола.

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

E.5. Живой контент с использованием многоадресной рассылки

Этот вариант использования в своей простейшей форме вообще не требует использования RTSP; это то, для чего предназначены многоадресные конференции, объявленные с помощью SAP [RFC2974] и SDP. Однако в тех случаях, когда требуются более сложные функции, такие как управление доступом к многоадресному сеансу, RTSP может использоваться для установления сеанса.

Клиент, желающий присоединиться к сеансу мультикастинга в режиме реального времени с криптографическим (шифрованием) контролем доступа, может использовать RTSP следующим образом. Источник сеанса объявляет сеанс и предоставляет всем заинтересованным URI RTSP. Клиент подключается к серверу и запрашивает описание презентации, позволяя настроить прием медиа. На этом этапе клиент может использовать защищенный транспорт и любой желаемый уровень аутентификации; например, для выставления счетов или контроля доступа. Линия RTSP также позволяет распределять нагрузку между несколькими серверами.

Если бы это были единственные цели, их можно было бы достичь, просто используя HTTP. Однако для случаев, когда отправителю нравится отслеживать каждого отдельного получателя сеанса и, возможно, использовать сеанс в качестве побочного канала для распространения обновлений ключа или другой информации на основе для получателя, и полный набор получателей не известное до начала сеанса, установление состояния, которое обеспечивает RTSP, может быть выгодным. В этом случае клиент установит сеанс RTSP для этой многоадресной группы с сервером RTSP. Сервер RTSP не будет передавать какие-либо мультимедийные данные, а вместо этого будет указывать на группу многоадресной рассылки. Клиент и сервер смогут поддерживать сеанс в течение всего времени, пока получатель участвует в сеансе, что позволяет, например, серверу выдавать обновления клиенту.

Этот вариант использования, скорее всего, не сможет быть реализован без каких-либо расширений механизма push-обмена между серверами. Здесь метод PLAY_NOTIFY (см. Раздел 13.5) с подходящим расширением может дать явные преимущества.

Приложение F. Формат текста для параметров

Ресурс типа «текст / параметры» состоит из 1) списка параметров (для запроса) или 2) списка параметров и связанных значений (для ответа или установки параметра). Каждая запись в списке представляет собой одну строку текста. Параметры отделяются от значений двоеточием. Имя параметра ДОЛЖНО использовать только видимые символы US-ASCII, в то время как значения являются текстовыми строками UTF-8. Форма регистрации типа носителя находится в разделе 22.16.

Существует потенциальная проблема совместимости для этого формата. Он был назван в RFC 2326 #, но не определен, даже если используется в примерах, которые намекают на синтаксис. Этот формат соответствует цели, и его синтаксис поддерживает предоставленные примеры. Однако, это идет дальше, допуская UTF-8 в части значения; таким образом, использование строк UTF-8 может не поддерживаться. Однако, поскольку отдельные параметры не определены, внедряющему приложению необходимо иметь внешнее соглашение или в любом случае использовать тег функции, чтобы определить, поддерживает ли конечная точка параметры.

Грамматика ABNF [RFC5234 #] для содержимого «текст / параметры»:

file = *((parameter / parameter-value) CRLF)
parameter = 1*visible-except-colon
parameter-value = parameter *WSP «:» value
visible-except-colon = %x21-39 / %x3B-7E ; VCHAR — «:»
value = *(TEXT-UTF8char / WSP)
TEXT-UTF8char = <as defined in Section 20.1>
WSP = <See RFC 5234> ; Space or HTAB
VCHAR = <See RFC 5234>
CRLF = <See RFC 5234>

Приложение G. Требования к ненадежной транспортировке RTSP

Это приложение предоставляет руководство для тех, кто хочет реализовать сообщения RTSP по ненадежным транспортам, как это определено в RTSP 1.0 [RFC2326 #]. RFC 2326 определил схему URI «rtspu» и предоставил некоторую базовую информацию для передачи сообщений RTSP по UDP. Информация предоставляется здесь, так как была, по крайней мере, одна коммерческая реализация, и совместимость с ней должна поддерживаться.

Следующие пункты должны быть рассмотрены для совместимой реализации:

Запросы должны быть подтверждены получателем. Если подтверждения нет, отправитель может повторно отправить то же сообщение после истечения времени ожидания в один конец (RTT). Любые повторные передачи из-за отсутствия подтверждения должны иметь тот же порядковый номер, что и исходный запрос.
RTT можно оценить, как в TCP (RFC 6298) [RFC6298], с начальным значением приема-передачи 500 мс. Реализация может кэшировать последнее измерение RTT в качестве начального значения для будущих соединений.
Заголовок метки времени (раздел 18.53) используется, чтобы избежать проблемы неоднозначности повторной передачи [Stevens98].
Зарегистрированный порт по умолчанию для RTSP через UDP для сервера — 554.
Сообщения RTSP могут передаваться по любому транспортному протоколу нижнего уровня, который является чистым 8-битным.
Сообщения RTSP уязвимы для битовых ошибок и не должны подвергаться им.
Проверка подлинности источника или, по крайней мере, проверка того, что сообщения RTSP поступают от одного и того же объекта, становится чрезвычайно важной, поскольку перехват сеанса может быть существенно проще для транспорта сообщений RTSP с использованием ненадежного протокола, такого как UDP, чем для TCP.

Существует два заголовка RTSP, которые в первую очередь предназначены для ненадежной обработки сообщений RTSP и которые будут поддерживаться:

CSeq: см. раздел 18.20. Следует отметить, что заголовок CSeq также требуется для сопоставления запросов и ответов независимо от того, используется ли надежный или ненадежный транспорт.
Отметка времени: см. раздел 18.53

Приложение H. Вопросы обратной совместимости

Этот раздел содержит примечания по вопросам обратной совместимости с клиентами или серверами, реализуемыми в соответствии с RFC 2326 [RFC2326 #]. Обратите внимание, что не существует требования для реализации RTSP 1.0; на самом деле, этот документ рекомендует против этого, поскольку это трудно сделать совместимым способом.

Сервер, реализующий RTSP 2.0, ДОЛЖЕН включать RTSP-версию «RTSP / 2.0» во все ответы на запросы, содержащие значение RTSP-версии «RTSP / 2.0». Если сервер получает запрос RTSP 1.0, он МОЖЕТ ответить ответом RTSP 1.0, если он решит поддерживать RFC 2326 #. Если сервер решит не поддерживать RFC 2326 #, он ДОЛЖЕН ответить кодом состояния 505 (версия RTSP не поддерживается). Сервер НЕ ДОЛЖЕН отвечать на запрос RTSP 1.0 ответом RTSP 2.0.

Клиенты, реализующие RTSP 2.0, МОГУТ использовать запрос OPTIONS с RTSP-версией «RTSP / 2.0», чтобы определить, поддерживает ли сервер RTSP 2.0. Если сервер отвечает либо RTSP-версией «RTSP / 1.0», либо кодом состояния 505 (версия RTSP не поддерживается), клиенту придется использовать запросы RTSP 1.0, если он решит поддерживать RFC 2326 #.

H.1. Запрос на воспроизведение в состоянии воспроизведения

Поведение на сервере при получении Play в состоянии Play изменилось (Раздел 13.4). В RFC 2326 # новый запрос PLAY будет поставлен в очередь до завершения текущего воспроизведения. Любой новый запрос PLAY теперь вступает в силу, немедленно заменяя предыдущий запрос.

H.2. Использование постоянных соединений

Некоторые реализации сервера RFC 2326 # поддерживают взаимно-однозначное отношение между соединением и сеансом RTSP. Такие реализации требуют, чтобы клиенты использовали постоянное соединение для связи с сервером, и когда клиент закрывает свое соединение, сервер может удалить сеанс RTSP. Это стоит отметить, если клиент RTSP 2.0, также поддерживающий 1.0, подключается к серверу 1.0.

Приложение I. Изменения

В этом приложении кратко перечислены различия между RTSP 1.0 [RFC2326 #] и RTSP 2.0 для информационных целей. Для разработчиков RTSP 2.0 рекомендуется внимательно прочитать это примечание и не полагаться на приведенный ниже список изменений для адаптации от RTSP 1.0 к RTSP 2.0, поскольку RTSP 2.0 не предназначен для обратной совместимости с RTSP 1.0 [RFC2326 #] кроме механизма согласования версий.

I.1. Краткий обзор

Следующие элементы протокола были удалены в RTSP 2.0 по сравнению с RTSP 1.0:

методы RECORD и ANNOUNCE и все связанные с ними функциональные возможности (включая коды состояния 201 (Создано) и 250 (Недостаточно места на диске));
использование UDP для передачи сообщений RTSP (из-за отсутствия интереса и из-за неправильной спецификации);
использование метода PLAY для поддержания активности в состоянии Play.

Следующие элементы протокола были добавлены или изменены в RTSP 2.0 по сравнению с RTSP 1.0:
o сеанс RTSP TEARDOWN от сервера к клиенту;

поддержка IPv6;
расширенные реестры IANA (например, параметры транспортных заголовков, транспортный протокол, профиль, низкий транспортный режим и режим);
конвейеризация запросов для быстрого запуска сеанса;
полностью переработанный конечный автомат;
Сообщения RTSP теперь используют URI, а не URL;
включил большую часть связанного текста HTTP ([RFC2616 #]) в эту заметку, по сравнению с простой ссылкой на разделы в HTTP, чтобы избежать двусмысленности;
метод REDIRECT был расширен и разнообразен для различных ситуаций;
Включает новый раздел о том, как настроить различные альтернативы медиатранспорта и их профили в дополнение к протоколам нижнего уровня. Это привело к тому, что приложение о взаимодействии RTP было перемещено в новый раздел, а не в часть, которая описывает RTP. Этот раздел также содержит рекомендации, которые следует учитывать при написании рекомендаций по использованию новых протоколов и профилей;
Добавлен метод асинхронного уведомления PLAY_NOTIFY. Этот метод используется сервером RTSP для асинхронного уведомления клиентов об изменениях сеанса в состоянии воспроизведения. В ограниченной степени это сопоставимо с некоторыми реализациями ANNOUNCE в RTSP 1.0, не предназначенными для записи.

I.2. Подробный список изменений

Приведенные ниже изменения были внесены в RTSP 1.0 (RFC 2326 #) при определении RTSP 2.0. Обратите внимание, что этот список не отражает незначительные изменения в формулировке или исправление опечаток.

o Раздел о минимальной реализации был удален. Вместо этого основная часть спецификации определяет ядро RTSP 2.0.

o Транспортный заголовок был изменен следующими способами:

* ABNF был изменен, чтобы определить, что расширения возможны и что неизвестные параметры приводят к тому, что серверы игнорируют транспортную спецификацию.
* Чтобы предотвратить проблемы обратной совместимости, любое расширение или новый параметр требует использования тега функции в сочетании с заголовком Require.
* Устранены синтаксические неоднозначности с параметром Mode.
* Синтаксическая ошибка с «;» для многоадресной и одноадресной передачи была решена.
* Были определены два новых параметра адресации: src_addr и dest_addr. Они заменяют параметры «port», «client_port», «server_port», «destination» и «source».
* Включена поддержка явных адресов IPv6 во всех адресных полях.
* Для обработки определений URI, которые содержат «;» или «,», был введен формат URI в кавычках, и он необходим.
* Реестры IANA для параметров транспортного заголовка, транспортного протокола, профиля, нижнего транспорта и режима определены.
* Текст параметра с чередованием заголовка транспорта стал более строгим и использует формальные уровни требований. Было также разъяснено, что чередующиеся каналы являются симметричными и что именно сервер устанавливает номера каналов.
* Было выяснено, что клиент не может запрашивать у сервера использование определенного RTP SSRC, используя запрос с транспортным параметром SSRC.
* Было уточнено определение синтаксиса для SSRC, требующее 8HEX. Он также был расширен, чтобы разрешить множественные значения для клиентов, поддерживающих эту версию.
* Уточнен текст параметров «dest_addr» заголовка транспорта, касающийся мер предосторожности, которые должен выполнять сервер.

o Форматы диапазона были изменены следующим образом:

* Формату NPT был присвоен начальный идентификатор NPT, который теперь должен использоваться.
* Все форматы теперь поддерживают исходные открытые форматы типа «npt = -10», а также форматируют только диапазоны «Range: smpte» для использования с запросами GET_PARAMETER.
* Нотация npt-hhmmss теперь более точно соответствует ISO 8601.

o Обработка сообщений RTSP была изменена следующими способами:

* Сообщения RTSP теперь используют URI, а не URL.
* Было пояснено, что сообщение 4xx из-за отсутствующего заголовка CSeq должно быть возвращено без заголовка CSeq.
* Код ответа 300 (множественный выбор) был удален.
* Добавлены правила обработки сообщений RTSP о превышении времени ожидания.
* Расширенные правила конвейерной обработки, позволяющие быстро запускать сеанс.
* Определена порядковая нумерация и обработка порядковых номеров по доверенности, включая случаи, когда ответы приходят не в порядке.

o Ссылки HTTP были обновлены до первых RFC 2616 и 2617, а затем до RFC 7230-7235. Большая часть текста была скопирована, а затем изменена, чтобы соответствовать RTSP в этой спецификации. Заголовки Public и Content-Base также были импортированы из RFC 2068, чтобы они были определены в спецификации RTSP. Известные эффекты на RTSP из-за HTTP-разъяснений:

Заголовок Content-Encoding может включать кодирование типа «identity».

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

o Был включен раздел IANA, содержащий ряд реестров и их правила. Это позволит нам использовать IANA для отслеживания расширений RTSP.

o Транспорт сообщений RTSP претерпел следующие изменения:

* Использование UDP для передачи сообщений RTSP устарело из-за отсутствия интереса и из-за неправильной спецификации.
* Правила прохождения TCP-соединений были уточнены. Теперь стало ясно, что серверы не должны закрывать TCP-соединение, если они не использовались в течение значительного времени.
* Также были добавлены строгие рекомендации, почему серверы и клиенты должны использовать постоянные соединения.
* Теперь на серверах есть требование обрабатывать непостоянные соединения, поскольку это обеспечивает отказоустойчивость.
* Добавлена формулировка об использовании Connection: Close for RTSP.
* Указано использование TLS для сообщений RTSP, включая схему для подтверждения подключения TLS прокси к следующему прыжку.

o Были внесены следующие изменения, связанные с заголовком:

* Добавлен заголовок ответа Accept-Ranges. Этот заголовок разъясняет, какие форматы диапазона могут использоваться для ресурса.
* Исправлены недостающие определения для заголовка Cache-Control. Также добавлено определение синтаксиса отсутствующих дельта-секунд для параметров max-stale и min-fresh.
* Поставьте требование к заголовку CSeq, чтобы значение увеличивалось на единицу для каждого нового запроса RTSP. Рекомендация начать с 0 также была добавлена.
* Добавлено требование, чтобы заголовок Date использовался для всех сообщений с телом сообщения, и Сервер всегда должен включать его.
* Удалена возможность использования заголовка Range с заголовком Scale, чтобы указать, когда его нужно активировать, поскольку он не может работать так, как определено. Также добавлено правило, согласно которому отсутствие заголовка Scale в ответе указывает на отсутствие поддержки заголовка. Теги функции для масштабированного воспроизведения были определены.
* На заголовок Speed теперь нужно ответить, чтобы указать поддержку и фактическую скорость, которая будет использоваться. Тег функции определен. Также были добавлены заметки о контроле заторов.
* Поддерживаемый заголовок был заимствован из SIP [RFC3261 #], чтобы помочь с согласованием функций в RTSP.
* Уточнено, что заголовок Timestamp может использоваться для разрешения неоднозначностей при повторной передаче.
* Текст заголовка сеанса был расширен с объяснением поддержки активности и используемых методов. SET_PARAMETER теперь рекомендуется использовать, если требуется только поддержка активности в RTSP.
* Было разъяснено, как форматы заголовка Range используются для указания точек паузы в ответе PAUSE.
* Уточнено, что относительные URI RTP-Info используют Request-URI в качестве базового URI. Также поясняется, что используемый URI должен быть тем, который использовался в запросе SETUP. URI теперь также должны быть в кавычках. Заголовок также выражает SSRC для предоставленной метки времени RTP и значений порядкового номера.
* Добавлен текст, который требует, чтобы Range всегда присутствовал в ответах PLAY. Уточнил, что следует отправлять в случае прямых трансляций.
* Таблица заголовков была обновлена с использованием структуры, заимствованной из SIP. Эти таблицы передают гораздо больше информации и должны дать хороший обзор доступных заголовков.
* Было пояснено, что любое сообщение с телом сообщения должно иметь заголовок Content-Length. Это имело место в RFC 2326 #, но могло быть неправильно истолковано.
* ETag изменил свое название на MTag.
* Для разрешения функциональности вокруг MTag из HTTP были добавлены заголовки MTag и If-None-Match с необходимыми пояснениями относительно работы RTSP.
* Импортирован заголовок Public из HTTP (RFC 2068 [RFC2068 #]), поскольку он был удален из HTTP из-за отсутствия использования. Public используется довольно часто в RTSP.
* Уточнены правила для заполнения заголовка Public, чтобы он был пересечением возможностей всех агентов RTSP в цепочке.
* Добавлен заголовок Media-Range для отображения текущей доступности медиа-диапазона.
* Добавлен заголовок Notify-Reason для указания причины при отправке запросов PLAY_NOTIFY.
* Был определен новый заголовок Seek-Style для направления и информирования о том, как должна / была выполнена любая операция поиска.

o Синтаксис протокола был изменен следующим образом:

* Все определения ABNF обновляются в соответствии с правилами, определенными в RFC 5234 [RFC5234 #], и собраны в отдельный раздел (Раздел 20).
* ABNF для заголовков User-Agent и Server были исправлены.
* Некоторые определения во введении относительно сеанса RTSP были изменены.
* Протокол полностью поддерживает IPv6.
* Правило CHAR было изменено, чтобы исключить NULL.

o Коды состояния были изменены следующими способами:

* Использование кода состояния 303 (см. «Другое») устарело, поскольку его нет смысла использовать в RTSP.
* Никогда не определенный код состояния 411 «Требуемая длина» был полностью удален.
* При отправке ответа 451 (Параметр не понят) и 458 (Параметр доступен только для чтения) тело ответа должно содержать ошибочные параметры.
* Добавлена информация о возможности получения кода состояния перенаправления 3rr. Это включает в себя получение 3rr в результате запроса в пределах установленного сеанса. Это обеспечивает разъяснение предыдущего неуказанного поведения.
* Удалены коды состояния 201 (Создано) и 250 (Недостаточно места на диске), так как они относятся только к записи, что не рекомендуется.
* Определено несколько новых кодов состояния: 464 (передача данных еще не готова), 465 (причина уведомления неизвестна), 470 (требуется авторизация соединения), 471 (учетные данные не приняты) и 472 (сбой при установлении безопасного соединения).

o Следующие функциональные возможности устарели из протокола:

* Использование Queued Play.
* Использование метода PLAY для поддержания активности в состоянии Play.
* Методы RECORD и ANNOUNCE и все связанные с ними функции. Часть синтаксиса была удалена.
* Возможность использовать синхронизированное выполнение методов с параметром time в заголовке Range.
* Описание того, как работает rtspu, не является частью базовой спецификации и требует внешнего описания. Упоминается только то, что оно существует, и предъявляются некоторые требования к транспортировке.

o Следующие изменения были внесены в отношении методов:

* Метод OPTIONS был разъяснен в отношении использования заголовков Public и Allow.
* Добавлен текст, поясняющий использование SET_PARAMETER для поддержания активности и использования без тела.
* Метод PLAY теперь разрешен для конвейерной передачи с конвейерной передачей одного или нескольких запросов SETUP после инициализации, которая генерирует сеанс для агрегированного управления.
* REDIRECT был расширен и разнообразен для различных ситуаций.
* Добавлен новый метод PLAY_NOTIFY. Этот метод используется сервером RTSP для асинхронного уведомления клиентов об изменениях сеанса.

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

o Настройка и использование независимых TCP-соединений для транспорта RTP.

o Добавлен новый раздел с описанием доступных механизмов определения поддерживаемых функций, который называется «Обработка возможностей». Переименованные теги-опции для тегов функций.

o Добавлен раздел «Участники» с людьми, которые внесли фактический текст в спецификацию.

o Добавлен раздел «Варианты использования», в котором описаны основные варианты использования RTSP.

o Уточнено использование диапазона a = и как указать живой контент, который нельзя найти с помощью этого заголовка.

o Текст, определяющий специальное поведение PLAY для живого контента.

o Особенности безопасности RTSP были уточнены:

* Была уточнена авторизация на основе HTTP, требующая как базовой, так и дайджест-поддержки
* Поддержка TLS была обязательной
* Если реализован RTP, то должен поддерживаться SRTP и определенный обмен ключами на основе MIKEY.
* Обсуждены различные незначительные меры по смягчению или изменения протокола.

Благодарности

Этот меморандум определяет версию 2.0 RTSP, которая является пересмотром предлагаемого стандарта версии 1.0 RTSP, определенного в [RFC2326 #]. Авторами RFC 2326 # являются Хеннинг Шульцринне, Ануп Рао и Роберт Ланфьер.

И RTSP версии 1.0, и RTSP версии 2.0 заимствуют формат и описания из HTTP / 1.1.

Роберт Спаркс и особенно Элвин Дэвис представили очень ценные и подробные обзоры в Последнем звонке IETF, которые значительно улучшили документ и решили многие проблемы, особенно в отношении согласованности.

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

Rahul Agarwal, Claudio Allocchio, Jeff Ayars, Milko Boic, Torsten Braun, Brent Browning, Bruce Butterfield, Steve Casner, Maureen Chesire, Jinhang Choi, Francisco Cortes, Elwyn Davies, Spencer Dawkins, Kelly Djahandari, Martin Dunsmuir, Adrian Farrel, Stephen Farrell, Ross Finlayson, Eric Fleischman, Jay Geagan, Andy Grignon, Christian Groves, V. Guruprasad, Peter Haight, Mark Handley, Brad Hefta-Gaub, Volker Hilt, John K. Ho, Patrick Hoffman, Go Hori, Philipp Hoschka, Anne Jones, Ingemar Johansson, Jae-Hwan Kim, Anders Klemets, Ruth Lang, Barry Leiba, Stephanie Leif, Jonathan Lennox, Eduardo F. Llach, Chris Lonvick, Xavier Marjou, Thomas Marshall, Rob McCool, Martti Mela, David Oran, Joerg Ott, Joe Pallas, Maria Papadopouli, Sujal Patel, Ema Patki, Alagu Periyannan, Colin Perkins, Pekka Pessi, Igor Plotnikov, Pete Resnick, Peter Saint-Andre, Holger Schmidt, Jonathan Sergent, Pinaki Shah, David Singer, Lior Sion, Jeff Smith, Alexander Sokolsky, Dale Stammen, John Francis Stracke, Geetha Srikantan, Scott Taylor, David Walker, Stephan Wenger, Dale R. Worley, and Byungjo Yoon, and especially Flemming Andreasen.

Авторы

Следующие люди внесли письменный вклад, который был включен в спецификацию:

o Том Маршалл (Tom Marshall) предоставил текст об использовании кодов состояния 3rr.

o Томас Чжэн предоставил текст об использовании Range в ответах PLAY и предложил более раннюю версию метода PLAY_NOTIFY.

o Шон Шиди предоставил текст о поведении тайм-аута сообщений и соединений RTSP, код состояния 463 (пункт назначения запрещен) и предложил более раннюю версию метода PLAY_NOTIFY.

o Грег Шервуд предложил более раннюю версию метода PLAY_NOTIFY.

o Фредрик Линдхольм предоставил текст о структуре безопасности RTSP.

o Джон Лаззаро предоставил текст для RTP через Независимый TCP.

o Аравинд Нарасимхан внес свой вклад, переписав «Альтернативы медиатранспорту» (Приложение C) и внеся редакционные улучшения в ряде мест в спецификации.

o Торбьерн Эйнарссон сделал некоторые редакционные улучшения текста.

Адреса авторов

Henning Schulzrinne
Columbia University
1214 Amsterdam Avenue
New York, NY 10027
United States of America
Email: schulzrinne@cs.columbia.edu

Anup Rao
Cisco
United States of America
Email: anrao@cisco.com

Rob Lanphier
San Francisco, CA
United States of America
Email: robla@robla.net

Magnus Westerlund
Ericsson
Faeroegatan 2
Stockholm SE-164 80
Sweden
Email: magnus.westerlund@ericsson.com

Martin Stiemerling (editor)
University of Applied Sciences Darmstadt
Haardtring 100
64295 Darmstadt
Germany
Email: mls.ietf@gmail.com
URI: http://www.stiemerling.org

Аннотация

Оглавление

Статус этой заметки

Уведомление об авторских правах

1. Введение

2. Обзор протокола

2.1. Описание презентации

2.2. Учреждение Сессии

2.3. Контроль доставки медиа

2.4. Манипуляции с параметрами сеанса

2.5. Доставка Медиа

2.5.1. Манипуляции с доставкой медиа

2.6. Сессии «Обслуживание» и «Завершение»

2.7. Расширение RTSP

3. Документ Соглашения

3.1. Условные обозначения

3.2. Терминология

4. Параметры протокола

4.1. Версия RTSP

4.2. RTSP IRI и URI

4.3. Идентификаторы сеанса

4.4. Форматы медиа-времени

4.4.1. SMPTE-Относительные метки времени

4.4.2. Нормальное время воспроизведения

4.4.3. Абсолютное Время

4.5. Теги функций

4.6. Теги сообщения

4.7. Медиа Свойства

4.7.1. Случайный доступ и поиск

4.7.2. Удержание

4.7.3. Модификации контента

4.7.4. Поддерживаемые коэффициенты масштабирования

4.7.5. Отображение на атрибуты

Пример по требованию

Пример динамического по требованию

Пример Live

Пример Live с записью

5. Сообщение RTSP

5.1. Типы сообщений

5.2. Заголовки сообщений

5.3. Тело сообщения

5.4. Длина сообщения

6. Поля общего заголовка

7. Запрос

7.1. Строка запроса

7.2. Поля заголовка запроса

8. Ответ

8.1. Status-Line

8.1.1. Код состояния и фраза причины

8.2. Заголовки ответа

9. Тело сообщения

9.1. Поля заголовка Тела сообщения

9.2. Тело сообщения

9.3. Согласование формата сообщения

10. Соединения

10.1. Надежность и благодарность

10.2. Использование подключений

10.3. Закрытие соединения

10.4. Отключение соединений и сообщений RTSP

10.5. Показ живучести

10.6. Использование IPv6

10.7. Контроль перегрузки

11. Возможность обработки

11.1. Feature Tag: play.basic

12. Поддержка конвейеризации

13. Определения методов

13.1. OPTIONS — ОПЦИИ

13.2. DESCRIBE — ОПИСАНИЯ

13.3. SETUP — НАСТРОИТЬ

13.3.1. Изменение параметров транспорта

13.4. PLAY — ВОСПРОИЗВЕДЕНИЕ

13.4.1. Общее использование

13.4.2. Агрегированные сессии

13.4.3. Обновление текущих запросов PLAY

13.4.4. Воспроизведение медиа по запросу

13.4.5. Воспроизведение динамических носителей по требованию

13.4.6. Воспроизведение Live Media

13.4.7. Воспроизведение вживую с записью

13.4.8. Воспроизведение вживую с Time-Shift

13.5. PLAY_NOTIFY