RTSP 2.0 | Метод PLAY_NOTIFY

Методы RTSP 2.0 — это указание того, что должно быть выполнено на ресурсе, идентифицированном Request-URI на основании синтаксиса строки запроса RTSP, определённой как:

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

Методы RTSP 2.0 перечислены в таблице 2.

 

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

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

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

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

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

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

 

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

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

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

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

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

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

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

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

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

 

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

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

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

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

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

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

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

 

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

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

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

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

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

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

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

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

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

 

Ссылки на документы

Скачать оригинальный документ на английском языке RFC 7826 — Real-Time Streaming Protocol Version 2.0

Читать полную версию документа на русском языке RFC 7826 — Потоковый протокол в реальном времени (RTSP), версия 2.0