Общие заголовки RTSP 2.0 — это заголовки, которые могут использоваться как в запросах, так и в ответах. Общие заголовки RTSP 2.0 перечислены в таблице 1
Поле общего заголовка «RTP-Info» используется для установки специфичных для RTP параметров в ответах методов PLAY и GET_PARAMETER или запросах PLAY_NOTIFY и GET_PARAMETER. Для потоков, использующих RTP в качестве транспортного протокола, заголовок RTP-Info ДОЛЖЕН быть частью ответа 200 на PLAY.
Исключение RTP-Info в ответе PLAY для RTP-транспортируемых мультимедиа приведет к тому, что клиенту потребуется синхронизировать медиапотоки с использованием RTCP. Это может оказать негативное влияние, так как RTCP может быть потерян и не должен быть особенно своевременным в своем прибытии. Кроме того, это влияет на функциональность, которая сообщает клиенту, по какому пакету был произведен поиск.
Информация RTP МОЖЕТ быть включена в ответы SETUP для предоставления информации синхронизации при изменении транспортных параметров, см. Раздел 13.3 из RFC 7826. Заголовок RTP-Info и заголовок Range МОГУТ быть включены в запрос GET_PARAMETER от клиента к серверу без каких-либо значений для запроса текущей точки воспроизведения и соответствующей информации синхронизации RTP. Когда заголовок RTP-Info включен в Запрос, заголовок Range ДОЛЖЕН также быть включен. Ответ сервера ДОЛЖЕН включать заголовок Range и заголовок RTP-Info. Если сеанс находится в состоянии Play, то значение заголовка Range ДОЛЖНО быть заполнено текущей точкой воспроизведения и соответствующими значениями RTP-Info. Если сервер находится в другом состоянии, значения не включаются в заголовок RTP-Info. Заголовок включается в запросы PLAY_NOTIFY с Notify-Reason окончания потока, чтобы предоставить RTP-информацию о конце потока.
Заголовок может содержать следующие параметры:
Параметр «url»
Указывает URI потока, которому соответствуют следующие параметры RTP; этот URI ДОЛЖЕН быть тем же, который используется в запросе SETUP для этого медиапотока. Любой относительный URI ДОЛЖЕН использовать Request-URI в качестве базового URI. Этот параметр ДОЛЖЕН присутствовать.
Параметр «ssrc»
SSRC, к которому применяются метка времени и порядковый номер RTP. Этот параметр ДОЛЖЕН присутствовать.
Параметр «seq»
Указывает порядковый номер первого пакета потока, который является прямым результатом запроса. Это позволяет клиентам корректно работать с пакетами при поиске. Клиент использует это значение для различения пакетов, которые возникли до поиска, от пакетов, которые возникли после поиска. Обратите внимание, что клиент может не принимать пакет с выраженным порядковым номером и вместо этого может принимать пакеты с более высоким порядковым номером из-за потери или переупорядочения пакета. Этот параметр РЕКОМЕНДУЕТСЯ присутствовать.
Параметр «rtptime»
ДОЛЖЕН указывать значение временной метки RTP, соответствующее начальному временному значению в заголовке ответа диапазона или, если явно не указано, подразумеваемую начальную точку. Клиент использует это значение, чтобы рассчитать отображение времени RTP на NPT или другую временную шкалу мультимедиа. Этот параметр ДОЛЖЕН присутствовать для обеспечения синхронизации между средами. Не существует требования, чтобы у любого принятого пакета RTP было то же значение метки времени RTP, что и в параметре, используемом для установления синхронизации.
Сопоставление меток времени RTP с метками времени формата NTP (настенные часы) доступно через RTCP. Однако этой информации недостаточно, чтобы сгенерировать отображение из меток времени RTP во время медиаданных (NPT и т. д.). Кроме того, чтобы гарантировать, что эта информация доступна в нужное время (сразу при запуске или после поиска) и что она доставляется надежно, это отображение помещается в канал управления RTSP.
Чтобы компенсировать дрейф для длинных, непрерывных презентаций, клиенты RTSP должны дополнительно сопоставить NPT с NTP, используя начальные отчеты отправителя RTCP для сопоставления, и более поздние отчеты для проверки отклонения от сопоставления.
Пример:
Range:npt=3.25-15
RTP-Info:url="rtsp://example.com/foo/audio" ssrc=0A13C760:seq=45102;
rtptime=12345678,url="rtsp://example.com/foo/video"
ssrc=9A9DE123:seq=30211;rtptime=29567112
Предположим, что Audio использует тактовую метку времени RTP 16 кГц, а Video — тактовую метку RTP 90 кГц. Затем синхронизация мультимедиа изображается следующим образом.
NPT 3.0---3.1---3.2-X-3.3---3.4---3.5---3.6
Audio------------PA-A
Video------------V--------PV
X: NPT time value = 3.25, from Range header.
A: RTP timestamp value for Audio from RTP-Info header (12345678).
V: RTP timestamp value for Video from RTP-Info header (29567112).
PA: RTP audio packet carrying an RTP timestamp of 12344878, which corresponds to NPT = (12344878 - A) / 16000 + 3.25 = 3.2
PV: RTP video packet carrying an RTP timestamp of 29573412, which corresponds to NPT = (29573412 - V) / 90000 + 3.25 = 3.32
Синтаксис поля общего заголовка RTP-Info в RTSP 2.0
RTP-Info = "RTP-Info" HCOLON [rtsp-info-spec *(COMMA rtsp-info-spec)]
rtsp-info-spec = stream-url 1*ssrc-parameter
stream-url = "url" EQUAL DQUOTE RTSP-REQ-Ref DQUOTE
ssrc-parameter = LWS "ssrc" EQUAL ssrc HCOLON ri-parameter *(SEMI ri-parameter)
ri-parameter = ("seq" EQUAL 1*5DIGIT) / ("rtptime" EQUAL 1*10DIGIT) / generic-param
Ссылки
Скачать оригинальный документ на английском языке RFC 7826 — Real-Time Streaming Protocol Version 2.0
Читать полную версию документа на русском языке RFC 7826 — Потоковый протокол в реальном времени (RTSP), версия 2.0
Ссылка на синтаксис
