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

Аннотация

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

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

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

Оглавление

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-Относительные метки времени Society of Motion Picture and Television Engineers (SMPTE) Timestamps
4.4.2. Нормальное время воспроизведения Normal Play Time (NPT)
4.4.3. Абсолютное Время
4.5. Функции Тегов
4.6. Теги сообщения
4.7. Медиа Свойства
4.7.1. Случайный доступ и поиск
4.7.2. Удержание
4.7.3. Модификации контента
4.7.4. Поддерживаемые коэффициенты масштабирования
4.7.5. Отображение на атрибуты
5. Сообщение RTSP
5.1. Типы сообщений
5.2. Заголовки сообщений
5.3. Тело сообщения
5.4. Длина сообщения
6. Поля общего заголовка
7. Запрос
7.1. Строка запроса
7.2. Поля заголовка запроса
8. Ответ
8.1. Линия Состояния
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. ОПИСАНИЯ
13.3. УСТАНОВКИ
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
13.5.1. Конец потока
13.5.2. Медиа-свойства-Update
13.5.3. Масштабное изменение
13.6. PAUSE (Приостановить)
13.7. TEARDOWN (Срывать)
13.7.1. Клиент на сервер
13.7.2. Сервер к клиенту
13.8. GET_PARAMETER
13.9. SET_PARAMETER
13.10. REDIRECT
14. Встроенные (чередующиеся) двоичные данные
15. Прокси
15.1. Прокси и расширения протокола
15.2. Мультиплексирование и демультиплексирование сообщений
16. Кеширование
16.1. Модель проверки
16.1.1. Дата последнего изменения
16.1.2. Валидаторы кэша тегов тела сообщения
16.1.3. Слабые и сильные валидаторы
16.1.4. Правила использования тегов тела сообщения и даты последнего изменения
16.1.5. Не проверяющие условия
16.2. Аннулирование после обновлений или удалений
17. Определения кода статуса
17.1. Информационный 1xx
17.1.1. Код 100 Продолжение
17.2. Коды Успеха 2xx
17.2.1. Код 200 ОК
17.3. Коды Перенаправлений 3xx
17.3.1. Код 300
17.3.2. Код 301 перемещено навсегда
17.3.3. Код 302 найдено
17.3.4. Код 303 См. Другое
17.3.5. Код 304 Не модифицировано
17.3.6. Код 305 Использовать прокси
17.4. Ошибки клиента 4xx
17.4.1. Ошибка 400, неверный запрос
17.4.2. Код 401 Неавторизованный
17.4.3. Код 402 Требуется оплата
17.4.4. Код 403 Запрещено
17.4.5. Код 404 Не Найдено
17.4.6. Код 405 Метод не разрешен
17.4.7. Код 406 Недопустимо
17.4.8. Код 407 Требуется прокси-аутентификация
17.4.9. Код 408 Время ожидания запроса
17.4.10. Код 410 Ушел
17.4.11. Код 412 Не выполнено предварительное условие
17.4.12. Код 413 Слишком большое тело сообщения запроса
17.4.13. Код 414 URI запроса слишком длинный
17.4.14. Код 415 неподдерживаемый тип носителя
17.4.15. Код 451 Параметр не понят
17.4.16. Код 452 Неверный идентификатор конференции
17.4.17. Код 453 Недостаточно пропускной способности
17.4.18. Код 454 сессия не найдена
17.4.19. Код 455 Метод не действителен в этом состоянии
17.4.20. Код 456 Поле заголовка недопустимо для ресурса
17.4.21. Код 457 Неверный диапазон
17.4.22. Код 458 Параметр только для чтения
17.4.23. Код 459 Совокупная операция не разрешена
17.4.24. Код 460 разрешена только совокупная операция
17.4.25. Код 461 неподдерживаемый транспорт
17.4.26. Код 462 пункт назначения недоступен
17.4.27. Код 463 Пункт назначения запрещен
17.4.28. Код 464 Транспорт данных еще не готов
17.4.29. Код 465 Причина уведомления неизвестна
17.4.30. Код 466 Ошибка управления ключами
17.4.31. Код 470 Требуется авторизация соединения
17.4.32. Код 471 учетные данные не принимаются
17.4.33. Код 472 Не удалось установить безопасное соединение
17.5. Ошибки сервера 5xx
17.5.1. Код 500 — Внутренняя ошибка сервера
17.5.2. Код 501 Не реализовано
17.5.3. Код 502 Неверный шлюз
17.5.4. Код 503 Сервис недоступен
17.5.5. Код 504 Ошибка Время ответа сервера истекло
17.5.6. Код 505 Версия RTSP не поддерживается
17.5.7. Код 551 Опция не поддерживается
17.5.8. Код 553 Прокси недоступен
18. Определения полей заголовка
18.1. Accept
18.2. Accept-Credentials
18.3. Accept-Encoding
18.4. Accept-Language
18.5. Accept-Ranges
18.6. Allow (Разрешать)
18.7. Authentication-Info (Информация Аутентификации)
18.8. Authorization (Авторизация)
18.9. Bandwidth (Пропускная способность)
18.10. Blocksize (Размер блока)
18.11. Cache-Control (Управление кэшем)
18.12. Connection (Соединение)
18.13. Connection-Credentials
18.14. Content-Base
18.15. Content-Encoding
18.16. Content-Language
18.17. Content-Length
18.18. Content-Location
18.19. Content-Type
18.20. CSeq
18.21. Date
18.22. Истекает
18.23. От
18.24. If-Match
18.25. If-Modified-Since
18.26. If-None-Match
18.27. Последнее изменение
18.28. Место нахождения
18.29. Медиа-недвижимость
18.30. Медиа-Range
18.31. MTAG
18.32. Уведомлять-Reason
18.33. Конвейерные-запросы
18.34. Proxy-Authenticate
18.35. Proxy-Authentication-Info
18.36. Proxy-Authorization
18.37. Proxy-Require
18.38. Proxy-Supported
18.39. Общественный
18.40. Range (Спектр, диапазон)
18.41. Referrer
18.42. Request-Status
18.43. Require (Требование)
18.44. Retry-After
18.45. RTP-Info
18.46. Scale (Шкала, масштаб)
18.47. Seek-Style
18.48. Сервер
18.49. Сессия
18.50. Скорость
18.51. Supported (Поддерживаемый)
18.52. Terminate-Reason
18.53. Отметка
18.54. Транспорт
18.55. Unsupported (Не поддерживаемый)
18.56. User-Agent
18.57. С помощью
18.58. WWW-Authenticate
19. Структура безопасности
19.1. RTSP и HTTP аутентификация
19.1.1. Дайджест-аутентификация
19.2. RTSP через TLS
19.3. Безопасность и Прокси
19.3.1. Accept-Credentials
19.3.2. Утвержденная пользователем процедура TLS
20. Синтаксис
20.1. Базовый синтаксис
20.2. Определение протокола RTSP
20.2.1. Общие элементы протокола
20.2.2. Синтаксис сообщения
20.2.3. Синтаксис заголовка
20.3. Синтаксис расширения SDP
21. Вопросы безопасности
21.1. Угрозы протокола сигнализации
21.2. Угрозы доставки медиапотока
21.2.1. Удаленная DoS-атака
21.2.2. Анализ безопасности RTP
22. Соображения IANA
22.1. Теги функций
22.1.1. Описание
22.1.2. Регистрация новых тегов функций в IANA
22.1.3. Зарегистрированные записи
22.2. Методы RTSP
22.2.1. Описание
22.2.2. Регистрация новых методов в IANA
22.2.3. Зарегистрированные записи
22.3. Коды состояния RTSP
22.3.1. Описание
22.3.2. Регистрация новых кодов статуса в IANA
22.3.3. Зарегистрированные записи
22.4. Заголовки RTSP
22.4.1. Описание
22.4.2. Регистрация новых заголовков в IANA
22.4.3. Зарегистрированные записи
22.5. Accept-Credentials
22.5.1. Принять-Учетные Политики
22.5.2. Принять-хэш-алгоритмы
22.6. Расширения директивы Cache-Control Cache
22.7. Медиа Свойства
22.7.1. Описание
22.7.2. Правила регистрации
22.7.3. Зарегистрированные ценности
22.8. Значения уведомлений-причин
22.8.1. Описание
22.8.2. Правила регистрации
22.8.3. Зарегистрированные ценности
22.9. Форматы заголовка диапазона
22.9.1. Описание
22.9.2. Правила регистрации
22.9.3. Зарегистрированные ценности
22.10. Заголовок Terminate-Reason
22.10.1. Причины перенаправления
22.10.2. Параметры заголовка конечной причины
22.11. Параметры заголовка RTP-Info
22.11.1. Описание
22.11.2. Правила регистрации
22.11.3. Зарегистрированные ценности
22.12. Политика поиска стиля
22.12.1. Описание
22.12.2. Правила регистрации
22.12.3. Зарегистрированные ценности
22.13. Реестры заголовков транспорта
22.13.1. Идентификатор транспортного протокола
22.13.2. Режимы транспорта
22.13.3. Транспортные параметры
22.14. Схемы URI
22.14.1. Схема URI «rtsp»
22.14.2. Схема URI «rtsps»
22.14.3. Схема URI «rtspu»
22.15. Атрибуты SDP
22.16. Тип носителя Регистрация для текста / параметров
23. Ссылки
23.1. Нормативные ссылки
23.2. Информационные ссылки
Приложение А. Примеры
A.1. Медиа по запросу (одноадресная передача)
А.2. Медиа по запросу с использованием конвейерной обработки
А.3. Защищенная медиа-сессия для контента по требованию
А.4. Медиа по запросу (одноадресная передача)
А.5. Однопотоковые контейнерные файлы
А.6. Live Media Presentation с использованием многоадресной передачи
А.7. Переговоры о возможностях
Приложение B. Состояние машины протокола RTSP
B.1. Состояния
B.2. Переменные состояния
В.3. Сокращения
В.4. Таблицы состояния
Приложение C. Медиа-Транспортные Альтернативы
C.1. RTP
С.1.1. AVP
С.1.2. AVP / UDP
С.1.3. AVPF / UDP
С.1.4. SAVP / UDP
С.1.5. SAVPF / UDP
С.2. RTP через TCP
С.2.1. Чередование RTP через TCP
С.2.2. RTP через независимый TCP
С.3. Обработка скачков времени медиа-часов в медиа-уровне RTP
С.4. Обработка временных меток RTP после PAUSE
С.5. Интеграция RTSP / RTP
С.6. Масштабирование с помощью RTP
С.7. Поддержание синхронизации NPT с временными метками RTP
С.8. Непрерывный Аудио
С.9. Несколько источников в сеансе RTP
С.10. Использование SSRC и сообщения RTCP BYE во время сеанса RTSP
С.11. Будущие дополнения
Приложение D. Использование SDP для описания сеансов RTSP
D.1. Определения
D.1.1. Контрольный URI
D.1.2. Медиа потоки
D.1.3. Тип (ы) полезной нагрузки
D.1.4. Специфичные для формата параметры
D.1.5. Направленность медиапотока
D.1.6. Диапазон представления
D.1.7. Время доступности
D.1.8. Информация о соединении
D.1.9. Тег сообщения
D.2. Совокупный контроль недоступен#C-2-RTP-over-TCP
D.3. Доступен совокупный контроль
D.4. Группировка медиа-линий в СДП
D.5. RTSP Внешний SDP Доставка
Приложение E. Примеры использования RTSP
E.1. Воспроизведение хранимого контента по требованию
E.2. Одноадресное распространение живого контента
E.3. Воспроизведение по требованию с использованием многоадресной рассылки
E.4. Приглашение сервера RTSP на конференцию
E.5. Живой контент с использованием многоадресной рассылки
Приложение F. Формат текста для параметров
Приложение G. Требования к ненадежной транспортировке RTSP
Приложение H. Вопросы обратной совместимости
H.1. Запрос на воспроизведение в состоянии воспроизведения
H.2. Использование постоянных соединений
Приложение I. Изменения
I.1. Краткий обзор
I.2. Подробный список изменений
Благодарности
Авторы
Адреса авторов

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

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

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

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

Copyright (c) 2016 IETF Trust и лица, указанные в качестве авторов документа. Все права защищены.

На данный документ распространяется действие ПП 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)Реализация СервераРеализация Клиента
DESCRIBEC -> SP: presentation, S: streamРекомендуемаРекомендуема
GET_PARAMETERC -> SПредставление, ПотокНеобязательнаНеобязательна
S -> CПредставление, ПотокНеобязательнаНеобязательна
OPTIONSC -> SПредставление, ПотокОбязательнаОбязательна
S -> CПредставление, ПотокНеобязательнаНеобязательна
PAUSEC -> SПредставление, ПотокОбязательнаОбязательна
PLAYC -> SПредставление, ПотокОбязательнаОбязательна
PLAY_NOTIFYS -> CПредставление, ПотокОбязательнаОбязательна
REDIRECTS -> CПредставление, ПотокНеобязательнаНеобязательна
SETUPC -> SПотокОбязательнаОбязательна
SET_PARAMETERC -> SПредставление, ПотокОбязательнаОбязательна
S -> CПредставление, ПотокНеобязательнаНеобязательна
TEARDOWNC -> SПредставление, ПотокОбязательнаОбязательна
S -> CПредставлениеОбязательнаОбязательна

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

Таблица 7 - Обзор методов RTSP
Таблица 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.

Вынуждая ответ DE