Товары в корзине: 0 шт Оформить заказ
Стр. 1 

22 страницы

623.00 ₽

Купить ГОСТ Р 57870.4-2017 — бумажный документ с голограммой и синими печатями. подробнее

Распространяем нормативную документацию с 1999 года. Пробиваем чеки, платим налоги, принимаем к оплате все законные формы платежей без дополнительных процентов. Наши клиенты защищены Законом. ООО "ЦНТИ Нормоконтроль"

Наши цены ниже, чем в других местах, потому что мы работаем напрямую с поставщиками документов.

Способы доставки

  • Срочная курьерская доставка (1-3 дня)
  • Курьерская доставка (7 дней)
  • Самовывоз из московского офиса
  • Почта РФ

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

 Скачать PDF

Оглавление

1 Область применения

2 Нормативные ссылки

3 Термины, определения и сокращения

4 Идентификация контента и иной информации

     4.1 Общие положения

     4.2 Протокол

     4.3 Транспорт протокола

5 Служба разрешения материала

     5.1 Общие положения

     5.2 Протокол разрешения материала

     5.3 Запрос протокола разрешения материала

     5.4 Протоколы обновления сервера разрешения материала

6 Системные часы

     6.1 Общие положения

     6.2 Обзор протокола

     6.3 Синтаксис сообщений синхронизации системных часов

     6.4 Транспорт протокола системных часов

7 Синхронизация временной шкалы

     7.1 Общие положения

     7.2 Протокол

     7.3 Транспорт протокола

8 Переключающие события

     8.1 Общие положения

     8.2 Протокол

     8.3 Транспорт протокола

9 Временные шкалы в полях адаптации транспортного потока .

     9.1 Общие положения

     9.2 Временная шкала данных частного характера в поле адаптации транспортного потока (TSAP)

     9.3 Внешняя медиа-информация с привязкой ко времени (TEMI)

10 Управление соединением и сеансом воспроизведения

11 Обнаружение

     11.1 Общие положения

     11.2 Требования к UPnP™ устройству для ТВ-устройства.

 
Дата введения01.08.2018
Добавлен в базу01.01.2019
Актуализация01.01.2021

Этот ГОСТ находится в:

Организации:

31.10.2017УтвержденФедеральное агентство по техническому регулированию и метрологии1584-ст
РазработанАНО НТЦИ
ИзданСтандартинформ2017 г.

Digital video broadcasting (DVB). Companion screens and streams. Part 4. Protocols. Discovery

Стр. 1
стр. 1
Стр. 2
стр. 2
Стр. 3
стр. 3
Стр. 4
стр. 4
Стр. 5
стр. 5
Стр. 6
стр. 6
Стр. 7
стр. 7
Стр. 8
стр. 8
Стр. 9
стр. 9
Стр. 10
стр. 10
Стр. 11
стр. 11
Стр. 12
стр. 12
Стр. 13
стр. 13
Стр. 14
стр. 14
Стр. 15
стр. 15
Стр. 16
стр. 16
Стр. 17
стр. 17
Стр. 18
стр. 18
Стр. 19
стр. 19
Стр. 20
стр. 20
Стр. 21
стр. 21
Стр. 22
стр. 22

ФЕДЕРАЛЬНОЕ АГЕНТСТВО ПО ТЕХНИЧЕСКОМУ РЕГУЛИРОВАНИЮ И МЕТРОЛОГИИ

ГОСТР

57870.4-

2017

НАЦИОНАЛЬНЫЙ

СТАНДАРТ

РОССИЙСКОЙ

ФЕДЕРАЦИИ

ТЕЛЕВИДЕНИЕ ВЕЩАТЕЛЬНОЕ ЦИФРОВОЕ

Вспомогательные дисплеи и потоки

Часть 4

Протоколы. Обнаружение

(ETSI TS 103 286-2 VI.1.1 (2015-05), NEQ)

(ETSI TS 103 286-3 VI.1.1 (2015-05), NEQ)

Издание официальное

Москва

Стандартинформ

2017

Предисловие

1    РАЗРАБОТАН Автономной некоммерческой организацией «Научно-технический центр информатики» (АНО «НТЦИ»)

2    ВНЕСЕН Техническим комитетом по стандартизации ТК 480 «Связь»

3    УТВЕРЖДЕН И ВВЕДЕН В ДЕЙСТВИЕ Приказом Федерального агентства по техническому регулированию и метрологии от 31 октября 2017 г. № 1584-ст

4    Настоящий стандарт разработан с учетом основных нормативных положений разделов 6—12 стандартов Европейского института по стандартизации в области телекоммуникаций (ETSI) ЕТСИ ТС 103 286-2 VI.1.1 (2015-05) «Телевидение вещательное цифровое. Вспомогательные дисплеи и потоки. Часть 2. Идентификация контента и синхронизация медиаданных» (ETSI TS 103 286-2 VI.1.1 (2015-05) «Digital Video Broadcasting (DVB) — Companion Screens and Streams — Part 2: Content Identification and Media Synchronization», NEQ) и ЕТСИ ТС 103 286-3 VI .1.1 (2015-05) «Телевидение вещательное цифровое. Вспомогательные дисплеи и потоки. Часть 3. Обнаружение» (ETSI TS 103 286-3 VI.1.1 (2015-05) «Digital Video Broadcasting (DVB) — Companion Screens and Streams — Part 3: Discovery», NEQ)

5 ВВЕДЕН ВПЕРВЫЕ

Правила применения настоящего стандарта установлены в статье 26 Федерального закона от 29 июня 2015 г. № 162-ФЗ «О стандартизации в Российской Федерации». Информация об изменениях к настоящему стандарту публикуется в ежегодном (по состоянию на 1 января текущего года) информационном указателе «Национальные стандарты», а официальный текст изменений и поправок—в ежемесячном информационном указателе «Национальные стандарты». В случае пересмотра (замены) или отмены настоящего стандарта соответствующее уведомление будет опубликовано в ближайшем выпуске ежемесячного информационного указателя «Национальные стандарты». Соответствующая информация, уведомление и тексты размещаются также в информационной системе общего пользования — на официальном сайте Федерального агентства по техническому регулированию и метрологии в сети Интернет (www.gost.ru)

© Стандартинформ, 2017

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

5.4.7 BOSH/XMPP протокол

Объект mimeTYPE должен иметь формат "ext/event-stream". Компонент протокола URL явно не определен, но обычно должен быть "http" или "https".

Свойство protocolSpecificData должно присутствовать и содержать XML-строфу в формате base64, которая должна быть отправлена от клиента к серверу, чтобы подписаться на обновления.

Возвращенный элемент тела сообщения должен содержать объект JSON для обновления информации материала или объект JSON для обновления syncTimelinelnformation.

Представление JSON в теле элемента должно быть закодировано в формате base64, чтобы избежать риска повреждения XML-документа.

6 Системные часы

6.1    Общие положения

Для компенсации задержек в сети связи между ТВ-устройством и CSA в процедуре синхронизации временной шкалы с привязкой к системным часам производится обмен временными метками, обеспечивая тем самым синхронизацию ТВ-устройства и CSA. Синхронизация системных часов обеспечивает соответствие показаний системных часов ТВ-устройства и CSA.

В данном разделе описаны протокол, используемый для синхронизации системных часов через интерфейс WC, и требования для включения оконечных узлов службы синхронизации системных часов в элементарную функцию ТВ-устройства — сервер системных часов (WC сервер). В разделе также описаны предполагаемые протокол взаимодействия и роль элементарной функции CSA— клиента системных часов (WC клиент).

Элементарная функция ТВ-устройства WC сервера должна реализовывать системные часы и поддерживать службу синхронизации системных часов.

Системные часы ТВ-устройства должны быть монотонными, энергонезависимыми (на время отключения питания от ТВ-устройства) и выполнять свою роль в синхронизации системных часов. Часы должны быть стабильными в пределах допусков практической реализации (например, на основе кварцевого генератора).

6.2    Обзор протокола
6.2.1    Введение в протокол

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

-    значение времени, используемое для оценки смещения между системными часами WC сервера и системными часами WC клиента;

-точность измерения, представляющую максимальную величину точности, обеспечиваемую в процессе считывания WC сервером значения из системных часов;

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

6.2.2    Значения времени и оценка смещения системных часов

WC клиент записывает значение времени Т1 в момент, когда сообщение с запросом подготовлено и направлено на WC сервер, и значение времени Т4 в момент, когда принимает сообщение с ответом. Аналогично WC сервер должен записывать значения Т2 и ТЗ своих собственных системных часов в момент, когда ответное сообщение подготовлено и отправлено. Процесс синхронизации системных часов показан на рисунке 1.

Если предположить, что сообщение с запросом и ответное сообщение занимают равное количество времени для передачи между WC клиентом и WC сервера, для WC клиента возможно оценить смещение offset (в) между часами WC клиента и часами WC сервера:

в = ((ТЗ + Т2) - (Т4 + Т1))/2.    (1)

(2)

Также для WC клиента возможно оценить общее время, потраченное на сообщения запроса и ответа, известное как время запроса туда-обратно round_trip_time (S)\

S = (T4- Т1) - (ТЗ - Т2).

ГОСТ P 57870.4—2017

WC сервер

WC клиент

72


73


Последующий ответ


77 — исходное значение времени; 72 — значение времени приема; 73 — значение времени передачи;

74 — значение времени ответа

Рисунок 1 — Процесс синхронизации системных часов


Границы неопределенности оценки смещения (известные как дисперсии) больше или равны плюс или минус половине времени запроса туда-обратно.

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

6.2.3 Точность измерения

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

Если принять наименьшее регулярное приращение системных часов за N тактов при номинальной скорости М тактов в секунду, то показания системных часов в любой момент времени ограничены точностью в пределах N/M секунд.

(3)

Если процесс снятия показаний занимает р секунд, то точность измерения measurement precision (mp) рассчитывается по формуле

mp = р + N/M.

6.2.4 Максимальная ошибка частоты

По ряду причин WC могут изменять частоту с течением времени (отклонение от номинальной частоты).

Ошибка частоты измеряется в миллионных частях (ppm). Ошибка частоты N ppm означает, что период времени 7секунд может быть неточным на ±7- N11 ООО ООО секунд.

Опорный генератор устройства характеризуется максимальной ожидаемой погрешностью частоты F ppm для установленных условий эксплуатации устройства.

Система, где используется процесс управления синхронизацией (например, клиент NTP), может намеренно смещать тактовую частоту. Максимальное смещение частоты, которое может быть достигнуто с помощью такого процесса, равно ± L ppm и также должно учитываться при определении максимальной погрешности частоты.

(4)

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

ppm = max(F, L).

6.3 Синтаксис сообщений синхронизации системных часов

Синтаксис сообщений синхронизации системных часов приведен в таблице 2.

9

Таблица 2 — Синтаксис сообщений синхронизации системных часов

Синтаксис

Значение

Число битов

Идентификатор

wall_clock_sync_message {

version

0

8

uimsbf

message_type

8

uimsbf

precision

8

tcimsbf

reserved

0

8

bslbf

max_freq_error originate_timevalue {

32

uimsbf

originate timevalue secs

32

uimsbf

originate timevalue nanos

}

receive timevalue {

32

uimsbf

receive timevalue secs

32

uimsbf

rece i ve_ti meva 1 u e_n a n os

32

uimsbf

transmit timevalue {

transmit timevalue secs

32

uimsbf

transmit timevalue nanos

}

}

32

uimsbf

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

Таблица 3 — Значения поля message_type

Поле message_type

Значение

0

Запрос от CSA

1

Ответ от ТВ-устройства, без возможности последующего ответа

2

Ответ от ТВ-устройства, последующий ответ ожидается

3

Последующий ответ от ТВ-устройства

4 ... 255

Зарезервировано

6.4 Транспорт протокола системных часов

Сообщение синхронизации WC должно быть передано в качестве полезной нагрузки одиночного UDP пакета.

WC сервер должен обслуживать оконечный узел службы синхронизации системных часов. WC сервер должен прослушивать сообщения запроса протокола синхронизации системных часов от CSA на IP-адресе и номере порта, соответствующих оконечному узлу службы.

Оконечный узел службы синхронизации системных часов должен представляться в виде URL формата "udp://<ip-address>:<port-number>", где <ip-address> и <port-number> являются IP-адресом и номером порта, на котором WC сервер представляет оконечный узел службы.

7 Синхронизация временной шкалы

7.1 Общие положения

Синхронизация временной шкалы представляет собой процесс, с помощью которого элементарная функция CSA SC и элементарная функция MSAS ТВ-устройства обмениваются информацией о метках времени через интерфейс TLS для того, чтобы координировать синхронизацию процесса презентации контента по расписанию.

ГОСТ P 57870.4—2017
7.2    Протокол

MSAS должен обеспечить нескольким CSA возможность сохранять открытые сеансы с оконечными узлами служб TLS одновременно. MSAS должен обеспечить CSA возможность иметь несколько открытых сеансов с одним оконечным узлом службы TLS.

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

7.3    Транспорт протокола

Элементарная функция MSAS ТВ-устройства должна содержать оконечный узел службы TLS. Данная функция реализуется серверной частью протокола WebSocket версии 13. Оконечным узлом службы, предоставляемым функцией MSAS, в сообщении СМ является WebSocket URL сервера WebSocket.

8    Переключающие события

8.1    Общие положения

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

8.2    Протокол

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

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

8.3    Транспорт протокола

ТВ-устройство, которое предоставляет оконечный узел службы ТЕ, должно реализовывать серверную часть протокола WebSocket версии 13. Оконечным узлом службы ТЕ, предоставляемым ТВ-устройством, является WebSocket URL.

9    Временные шкалы в полях адаптации транспортного потока

9.1    Общие положения

В данном разделе определены два процесса передачи временной шкалы в заголовке адаптации пакетов транспортного потока:

-    процесс, при котором временные шкалы несут байты данных частного характера в полях адаптации транспортного потока (TSAP) (см. 9.2);

-    процесс, опубликованный MPEG в апреле 2014 года в качестве информационной технологии (см. 9.3).

9.2    Временная шкала данных частного характера в поле адаптации транспортного потока
(TSAP)
9.2.1 Общие положения

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

11

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

9.2.2    Селектор временной шкалы для временной шкалы TSAP

Формат селектора временной шкалы для поля tsap_timeline должен соответствовать следующему шаблону:

tsap-timeline-selector = "urn:dvb:css:timeline:tsap:" component-tag timeline-id

9.2.3    Соотношение c PTS

Информация временной шкалы кодируется с использованием tsap_timeline в соответствии с моментом презентации медиаданных, указанным PTS, расположенной в первом заголовке PES, который начинается в полезной нагрузке, передаваемой в текущем или последующем пакете транспортного потока с таким же PID. В заголовке PES должно содержаться значение PTS.

9.2.4    Синтаксис

Синтаксис поля tsap_timeline должен соответствовать таблице 4.

Таблица 4 — Синтаксис поля tsap_timeline

Синтаксис

Значение

Число битов

Идентификатор

tsap_timeline {

data field tag

0x04

8

uimsbf

data field length

8

uimsbf

timeline type

2

uimsbf

reserved zero

0x00

5

running_status

1

continuityjndicator

1

bslbf

reserved

0x7F7

7

timeline id

8

uimsbf

if (timeline_type == 1) {

tick rate

32

uimsbf

timeline ticks

32

uimsbf

}

for (i=0; i<N; i++) {

reserved n

8

}

}

9.2.5 Интерпретация данных временной шкалы

ТВ-устройство должно декодировать данные временной шкалы с timeline_type, равным 1.

Значение такта временной шкалы и скорость тактов должны быть определены из последних полученных данных временной шкалы, согласно которой timeline_id соответствует значению, указанному в timelineSelector, и которая переносится в байтах данных частного характера поля адаптации adaptation_ field для пакетов TS, определенных тегом компонент, указанным в timelineSelector.

Поле UnitsPerTick временной шкалы должно быть равно 1, поле unitsPerSecond временной шкалы должно быть равно значению поля tick_rate.

9.3 Внешняя медиа-информация с привязкой ко времени (TEMI)
9.3.1    Общие положения

Дескрипторы полей адаптации для синхронизированной внешней медиа-информации (TEMI) определяют процесс для передачи временной шкалы в поле адаптации пакета транспортного потока, который в свою очередь содержит поток PES с PTS, объявленной в заголовке PES. Данный пункт определяет селектор временной шкалы и требования, которым ТВ-устройство должно соответствовать, если оно поддерживает использование временной шкалы TEMI.

9.3.2    Селектор временной шкалы для временной шкалы MPEG TEMI

Формат селектора временной шкалы MPEG TEMI должен соответствовать следующему шаблону:

temi-timeline-selector = "urn:dvb:css:timeline:temi:" component-tag ":" timeline-id

12

ГОСТ P 57870.4—2017

9.3.3 Интерпретация дескриптора temi_timeline_descriptor

Если поле has_timestamp дескриптора temi_timeline_descriptor равно 1 или 2, то величина такта временной шкалы берется из поля media_timestamp, а тактовая скорость определяется из поля timescale.

Поле unitsPerTick временной шкалы должно быть равно 1, поле unitsPerSecond временной шкалы должно быть равно значению поля tick_rate.

Если поле has_timestamp не равно 1 или 2, то тактовая скорость временной шкалы и значение такта не определены.

ТВ-устройство может игнорировать значение полей has_ntp, has_ptp и has_timecode.

Если поле paused равно 1, то тактовая скорость не изменяется, но ТВ-устройство должно рассчитывать метки времени, как будто презентация приостановлена.

10 Управление соединением и сеансом воспроизведения

ТВ-устройство и CSA, задействованные в синхронизированном воспроизведении, обычно используют интерфейс WC совместно с интерфейсами СИ, TLS или ТЕ. При определенных обстоятельствах они могут также использовать все четыре интерфейса параллельно. В таблице 5 приведена комбинация активных состояний соединений сети CSS.

Таблица 5 — Комбинации активных состояний соединений сети CSS

CSS-WC

соединение

CSS-CII

соединение

CSS-TLS

соединение

CSS-TE

соединение

Описание

Не установлено

Не важно

Не важно

Не важно

Без синхронного воспро-изведения

Установлено

Не установлено

Не важно

Не важно

Установлено

Установлено

Не важно

Не важно

Сеанс синхронного воспроизведения возможен

11 Обнаружение

11.1    Общие положения

11.1.1    Введение

Протокол Universal Plug and Play (UPnP™) является принятым протоколом для поиска и идентификации UPnP™ устройств в сети. UPnP ™ используется для передачи информации, чтобы позволить CSA обнаружить и ассоциироваться с ТВ-устройством, как показано на рисунке 2, и таким образом установить связь.

11.1.2 Архитектура UPnP™ устройства

UPnP™ реализует модель клиент—сервер. В терминологии UPnP™ клиенты называются контрольными точками, а серверы — UPnP™ устройствами. Функциональность UPnP™ устройств и контрольных точек абстрагируется от транспортного механизма. Функциональность приводится в протоколах управления устройствами (DCP), которые определяют набор действий (RPC методы) и событий.

13

Транспортный механизм описан в архитектуре UPnP™ устройства (UDA). Компоненты, которые составляют UDA, показаны на рисунке 3. UDA описывает:

-    как контрольные точки могут обнаружить UPnP™ устройства в сети без предварительного знания IP-адреса устройства с помощью простого протокола обнаружения устройства (SSDP), который реализуется через UDP;

-    какие возможности обнаруженных UPnP™ устройств реализованы посредством загрузки документа описания XML-устройства и документа описания XML-протокола управления службами с помощью HTTP;

-    как контрольные точки взаимодействуют с открытой функциональностью, вызывая действия с использованием запросов SOAP через HTTP;

-    как контрольные точки получают события, используя GENA через TCP.

В DCP описаны специфические функции каждого домена. DCP определяются как службы UPnP™ в UPnP™ устройстве.

DCP

SSDP

GENA

SOAP DDD/SCP

HTTP

UDP

TCP

Рисунок 3 — Схема стека UPnP™

11.1.3 Управление приложением UPnP™

Служба DCP управления приложением UPnP™ используется для установления связи между CSA и ТВ-устройством. ТВ-устройство включает UPnP™ устройство, которое в свою очередь включает службу управления приложением, CSA реализует контрольную точку управления приложением. Этот процесс показан на рисунке 4.

Рисунок 4 —Типовая реализация контрольных точек управления приложением во вспомогательном устройстве и службы управления приложением UPnP™ в ТВ-устройстве

11.1.4 Отображение интерфейса CSS-М при управлении приложением

CSA действует как контрольная точка управления приложением. Это позволяет CSA обнаружить ТВ-устройство, которое включает UPnP™ устройство, реализующее службу управления приложением DCP. Этот процесс показан на рисунке 5.

ГОСТ P 57870.4—2017

Рисунок 5 — CSA и ТВ-устройство, реализующее управление приложением UPnP™

и связи приложения СИ

11.1.5 Поведение CSA

Определение WebSocket адреса СМ от CSA к ТВ-устройству достигается за счет последовательности команд, приведенных на рисунке 6:

1)    обнаружение ТВ-устройства в домашней сети путем выдачи M-Search;

2)    выбор ТВ-устройства с помощью фильтрации ответов M-Search;

3)    загрузка DDD выбранного ТВ-устройства;

4)    выполнение действий для:

а)    определения существования или отсутствия приложения с matchingProtocolName путем вызова действия GetAppIDList 0;

б)    получения информации о приложении, которое содержит адрес WebSocket и runnngState, путем вызова действия GetAppInfoByIDsO;

5)    установление WebSocket соединения CSS-CII.

15

ТВ-устройство

CSA

Рисунок 6 — Последовательность команд между CSA и ТВ-устройством для установления WebSocket

соединения СИ

11.2 Требования к UPnP™ устройству для ТВ-устройства

ТВ-устройство должно реализовать UPnP™ устройство, которое в свою очередь реализует службу управления приложениями DCP.

Реализованное UPnP™ устройство должно соответствовать архитектуре UPnP™ устройств или последней версии UDA.

Интерфейс СМ должен быть представлен в качестве приложения в службе управления приложением.

Приложение должно предоставлять элемент <apptoApplnfo> в XML-документе описания приложения, где:

-    matchingProtocolName должен быть определен как "CSS-CM.TVDevice.CSS.DVB.org_v1";

-    протокол должен быть определен как "WebSocket";

-    значение атрибута требования протокола должно быть определено как "1";

-    connectionAddress должен быть действительным адресом WebSocket;

ГОСТ P 57870.4—2017

-    connectionAddress должен указывать на оконечный узел WebSocket и должен передавать протокол СИ.

Приложение всегда должно иметь значение runningState, равное "Running".

Приложение не должно быть остановлено, когда вызывается действие StopAppO- Эта функция должна возвращать код ошибки 710.

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

-    runningStatus;

-    apptoAppInfo.

17

ГОСТ P 57870.4—2017

Содержание

1    Область применения..................................................................1

2    Нормативные ссылки..................................................................1

3    Термины, определения и сокращения....................................................2

4    Идентификация контента и иной информации.............................................3

4.1    Общие положения ................................................................3

4.2    Протокол........................................................................3

4.3    Транспорт протокола..............................................................4

5    Служба разрешения материала.........................................................4

5.1    Общие положения ................................................................4

5.2    Протокол разрешения материала....................................................4

5.3    Запрос протокола разрешения материала.............................................5

5.4    Протоколы обновления сервера разрешения    материала.................................6

6    Системные часы.....................................................................8

6.1    Общие положения ................................................................8

6.2    Обзор протокола..................................................................8

6.3    Синтаксис сообщений синхронизации системных    часов.................................9

6.4    Транспорт протокола системных часов...............................................10

7    Синхронизация временной шкалы......................................................10

7.1    Общие положения ...............................................................10

7.2    Протокол.......................................................................11

7.3    Транспорт протокола.............................................................11

8    Переключающие события.............................................................11

8.1    Общие положения ...............................................................11

8.2    Протокол.......................................................................11

8.3    Транспорт протокола.............................................................11

9    Временные шкалы в полях адаптации транспортного    потока................................11

9.1    Общие положения ...............................................................11

9.2    Временная шкала данных частного характера    в поле адаптации транспортного потока (TSAP). . 11

9.3    Внешняя медиа-информация с привязкой ко времени (TEMI)............................12

10 Управление соединением и сеансом воспроизведения....................................13

11 Обнаружение......................................................................13

11.1    Общие положения..............................................................13

11.2    Требования к UPnP™ устройству для ТВ-устройства..................................16

УДК 621.397.132.129:006.354    ОКС    33.170    ОКП    657400

Ключевые слова: протокол, обнаружение, синхронизация, интерфейс, системные часы, временная шкала, вспомогательное устройство, ТВ-устройство, метка времени

18

НАЦИОНАЛЬНЫЙ СТАНДАРТ РОССИЙСКОЙ ФЕДЕРАЦИИ

ТЕЛЕВИДЕНИЕ ВЕЩАТЕЛЬНОЕ ЦИФРОВОЕ Вспомогательные дисплеи и потоки Часть 4 Протоколы. Обнаружение

Digital video broadcasting (DVB). Companion screens and streams. Part 4. Protocols. Discovery

Дата введения — 2018—08—01

1    Область применения

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

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

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

2    Нормативные ссылки

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

ГОСТ Р 52210-2004 Телевидение вещательное цифровое. Термины и определения

ГОСТ Р 52591-2006 Система передачи данных пользователя в цифровом телевизионном формате. Основные параметры

ГОСТ Р 54994-2012 Телевидение вещательное цифровое. Передача служб DVB по сетям с IP протоколами. Общие технические требования

Примечание — При пользовании настоящим стандартом целесообразно проверить действие ссылочных стандартов в информационной системе общего пользования — на официальном сайте Федерального агентства по техническому регулированию и метрологии в сети Интернет или по ежегодному информационному указателю «Национальные стандарты», который опубликован по состоянию на 1 января текущего года, и по выпускам ежемесячного информационного указателя «Национальные стандарты» за текущий год. Если заменен ссылочный стандарт, на который дана недатированная ссылка, то рекомендуется использовать действующую версию этого стандарта с учетом всех внесенных в данную версию изменений. Если заменен ссылочный стандарт, на который дана датированная ссылка, то рекомендуется использовать версию этого стандарта с указанным выше годом утверждения (принятия). Если после утверждения настоящего стандарта в ссылочный стандарт, на который дана датированная ссылка, внесено изменение, затрагивающее положение, на которое дана ссылка, то это положение рекомендуется применять без учета данного изменения. Если ссылочный стандарт отменен без замены, то положение, в котором дана ссылка на него, рекомендуется применять в части, не затрагивающей эту ссылку.

Издание официальное

3 Термины, определения и сокращения

3.1    В настоящем стандарте применены термины по ГОСТ Р 52210, ГОСТ Р 52591, ГОСТ Р 54994, а также следующие термины с соответствующими определениями:

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

3.1.2    вспомогательныйдисплей,вспомогательноеустройство:Устройствос1Р-подключением, такое как мобильный телефон, планшет, ноутбук.

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

3.1.4    материал: Уникальный фрагмент или сегмент финального редакционного контента. Может включать (но не ограничиваясь ими): разовые ТВ-программы, серии из телесериалов, рекламу, трейлеры и пр.

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

3.1.6    переключающее событие: Уведомление о временной точке в трансляции.

3.1.7    приложение вспомогательного дисплея (Companion Screen Application; CSA): Приложение, выполняемое на вспомогательном устройстве и обеспечивающее доступ к услугам, дополняющим основной контент, который пользователь просматривает на ТВ-устройстве.

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

3.1.9    телевизионное устройство (ТВ-устройство): Телевизионное устройство или устройство типа сет-топ-бокс, подключенное к домашней сети, принимающее и воспроизводящее DVB-трансляцию, IP-ТВ услугу или иной контент по расписанию.

3.1.10    тег (tag): Язык разметки или дескриптор.

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

3.2 В настоящем стандарте применены следующие сокращения:

ТВ — телевидение, телевизионный;

ТВ-устройство — телевизионное устройство;

ASCII — американский стандарт кодировки символов (American standard code for information interchange);

API — интерфейс программирования приложений (Application Programming Interface);

BOSH — двунаправленные потоки (данных) через синхронный HTTP (Bidirectional-streams Over Synchronous HTTP);

CORS — совместное использование ресурсов между разными источниками (Cross Origin Resource Sharing);

СИ — идентификация контента и иной информации (Content Identification and other Information);

CIS — сервер информации о корреляции (Correlation Information Server);

CSA — приложение вспомогательного дисплея (Companion Screen Application);

CSS — вспомогательные дисплеи и потоки (Companion Screens and Streams);

DA — обнаружение и взаимодействие (Discovery and Association);

DCP — протокол управления устройством (Device Control Protocol);

DDD — документ описания устройства (Device Description Document);

DVB — телевидение вещательное цифровое (Digital Video Broadcasting);

ETSI — Европейский институт по стандартизации в области телекоммуникаций (European Telecommunications Standards Institute);

GENA — архитектура уведомлений общих событий (General Event Notification Architecture);

GZIP — утилита сжатия и декомпрессии файлов (GNU Zip);

HTTP — протокол передачи гипертекста (HyperText Transfer Protocol);

HTTPS — протокол передачи гипертекста с поддержкой шифрования (HyperText Transfer Protocol Secure);

2

ГОСТ P 57870.4—2017

IP — межсетевой протокол (Internet Protocol);

JSON — текстовый формат обмена данными, основанный на языке JavaScript (JavaScript Object Notation);

LP — прокси-соединение (Link Proxy);

Ml — информация о материале (Material Information);

MIME — многоцелевые расширения интернет-почты (Multipurpose Internet Mail Extensions);

MPEG — экспертная группа по движущемуся изображению; стандарт сжатия видео- и аудиоданных (Moving Picture Experts Group);

MRS — услуга [служба] разрешения материала (Material Resolution Service);

MSAS — сервер приложения синхронизации медиаданных (Media Synchronization Application Server);

NTP — протокол сетевого времени (Network Time Protocol);

PES — пакетизированный элементарный поток (Packetized Elementary Stream);

PID — идентификатор пакета (Packet Identifier);

PTS — временная отметка предоставления пакета (Presentation Time Stamp);

REST — передача состояния представления (REpresentational State Transfer);

SC — клиент синхронизации (Synchronization Client);

SCP — протокол управления сеансом (Session Control Protocol);

SCPD — описание протокола управления услугой (Service Control Protocol Description);

SOAP — простой протокол доступа к объектам (Simple Object Access Protocol);

STB — сет-топ-бокс (Set Top Box);

TCP — протокол управления передачей (Transmission Control Protocol);

ТЕ — переключающее событие (Trigger Event);

TEMI — внешняя медиа-информация с привязкой ко времени (Timed External Media Information);

TLS — синхронизация временной шкалы (TimeLine Synchronization)

TS — транспортный поток (Transport Stream);

TSAP — данные частного характера в поле адаптации транспортного потока (TS Adaptation Private (data));

UDP — протокол пользовательских датаграмм (User Datagram Protocol);

UPnP™ — набор сетевых протоколов, публикуемых форумом UPnP (Universal Plug and Play);

URI — унифицированный идентификатор ресурса (Uniform Resource Identifier);

URL — универсальный указатель ресурса (Universal Resource Locator);

XML — расширяемый язык разметки (extensible Markup Language);

XMPP — расширяемый протокол обмена сообщениями и информацией о присутствии (extensible Messaging and Presence Protocol);

WC — системные часы (Wall Clock).

4 Идентификация контента и иной информации

4.1    Общие положения

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

4.2    Протокол

ТВ-устройство должно обеспечить подключение к оконечному узлу службы СИ нескольким CSA одновременно.

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

Когда CSA успешно подключается к оконечному узлу службы СИ, ТВ-устройство должно направить сообщение идентификации контента и иной информации (СИ).

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

3

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

ТВ-устройство может игнорировать любые сообщения, полученные по протоколу СМ от CSA, которые не описаны в данном разделе.

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

4.3 Транспорт протокола

ТВ-устройство должно реализовать оконечный узел службы CSS-CM, которая реализует серверную часть протокола WebSocket версии 13. Оконечные узлы службы, предоставляемые ТВ-устройством, в сообщении СИ являются WebSocket URL сервера WebSocket. WebSocket URL определяет хост, порт, безопасность и имя ресурса оконечного узла службы.

Все сообщения, отправленные CSA и ТВ-устройством, должны быть в формате кадра данных WebSocket с полезной нагрузкой в текстовом формате.

Если оконечный узел службы СИ в данный момент не доступен, ТВ-устройство должно отклонить запрос на соединение ответом с кодом ответа HTTP 403 "Запрещено".

Если ТВ-устройство достигло предела числа одновременных подключений к оконечному узлу службы СИ, которое оно может обработать, то ТВ-устройство должно отклонить запрос на соединение, возвращая код ответа HTTP 503 "Сервис не доступен".

CSA должно подписаться на идентификацию контента и иной информации путем установления соединения с оконечным узлом службы СИ в качестве клиента протокола WebSocket.

ТВ-устройство может проверить заголовок "Origin", если он присутствует в заголовке HTTP запроса от CSA по протоколу WebSocket для установления соединения. На основе значения заголовка "Origin" ТВ-устройство может решить отказать в установлении соединения и ответить с кодом ответа 403 "Forbidden".

ТВ-устройство может возвращать HTTP коды ответа 400 и 500 (включая код 403 "Forbidden" и 503 "Service Unavailable") и по другим причинам, которые не рассматриваются в настоящем стандарте.

CSA должно отключаться при закрытии соединения в соответствии с процедурой протокола WebSocket.

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

ТВ-устройство и CSA должны корректно обрабатывать неожиданное закрытие соединения в случае, если WebSocket кадра закрытия не отправлен, или не принят, или если базовое соединение с TCP соединителем разорвано, например из-за тайм-аута.

5 Служба разрешения материала

5.1    Общие положения

Идентификатор контента может быть передан службой разрешения материала как информация материала, потенциально включая информацию временной шкалы. Ниже приведены способы, с помощью которых CSA запрашивает MRS о разрешении передачи и структуре возвращаемой информации.

5.2    Протокол разрешения материала

Для взаимодействия с MRS должен использоваться протокол REST API через HTTP 1.1 или HTTPS (в частности, HTTP 1.1 через TLS).

URL MRS должен указывать, какой протокол следует использовать.

В нормальном режиме кодом ответа HTTP должен быть код состояния "200 ОК". Другие коды состояния также могут быть возвращены, и они должны быть обработаны соответствующим образом. Следует отметить, что успешные коды (2хх), коды перенаправления (Зхх) и коды не-модификации (304) могут быть возвращены и должны поддерживаться.

Могут быть возвращены коды ошибок клиента (4хх) и коды ошибок сервера (5хх). Поведение сервера в этих случаях не определено, но рекомендуется, чтобы оно было таким же, как если бы идентификатор контента не был получен от ТВ-устройства.

4

ГОСТ P 57870.4—2017

5.3 Запрос протокола разрешения материала

5.3.1    Общие требования протокола разрешения материала

CSA должно выдавать запросы GET к URL MRS_REST_API согласно 5.2.

CSA должно включать поле "Accept: application/json" в заголовок запроса.

CSA должно поддерживать GZIP и IDENTITY (для не упакованных в архив GZIP в формате JSON) кодирования ответов и включать поле "Accept-Encoding" в заголовок запроса, а также параметры GZIP и IDENTITY.

CSA должно поддерживать метки объекта ETags для запроса.

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

CSA должно включать в запрос заголовок "Origin".

5.3.2    URL протокола разрешения материала

URL, формирующий запрос MRS HTTP REST, должен быть построен путем конкатенации трех частей в следующем порядке:

-    mrsUrl, возвращаемый ТВ-устройством;

-    фиксированная строка "/vl.l/MRS";

-    один параметр протокола разрешения материала согласно 5.3.3.

Формат запроса MRS HTTP REST приведен в таблице 1.

Таблица 1 — Формат запроса MRS HTTP REST

MRS-REST-API

mrsUrl "/vl.l/MRS""?" parameter'-" value

mrsUrl

См. примечание 1

parameter

"contentld"

value

См. примечание 2

Примечания

1    mrsURL является сформированным URL, полученным от ТВ-устройства. Он не должен заканчиваться символом "Г.

2    Поскольку значение value может включать в себя зарезервированные или недопустимые символы в соответствии с синтаксисом URI, значением value может быть символ "Escape" или символ "%", кодированный согласно синтаксису URI.

5.3.3    Параметр протокола разрешения материала

Параметром name для идентификатора контента должна быть строка "ContentID", а параметром value должен быть идентификатор контента.

Параметр value должен быть представлен в виде строки ASCII-символов. Значение параметра должно соответствовать кодировке URI. В частности, если какие-либо символы параметра value попадают в зарезервированный набор символов (независимо от контекста), они должны быть закодированы с помощью символа "%" и двух последующих шестнадцатеричных цифр в верхнем регистре. Символы, попадающие в незарезервированный набор символов, не должны быть закодированы.

5.3.4    Ответ протокола разрешения материала

HTTP-заголовки ответа MRS должны включать в себя заголовок "Expires".

HTTP-заголовки ответа MRS должны также включать в себя заголовки CORS, как определено в таблице 2.

Таблица 2 — Заголовки CORS

Поле заголовка CORS

Рекомендуемое значение

Примечание

Access-Control-Allow-

Origin

н*н

Значения, отличные от "*", могут ограничить доступность возвращаемых данных в зависимости от среды выполнения CSA

Access-Control-Allow-

Method

"GET"

В настоящем стандарте определен только метод GET

Тело ответа MRS представляет собой JSON-документ, состоящий из объекта ответа MRS, описываемого корневым объектом схемы JSON. Пример шаблона для объекта JSON:

{


"response",

H <| -j H

<string>,

<zeroOrPositivelnteger>,

[■■■],

[■■■],

[... ], (optional)

[... ] (optional)


"type"

"version"

"rev"

"repolling Interval" "materials"

"syncTimelinelnformation"

"updateMaterial"

" u pd ateTi me I i n eSy n c"


}


5.4 Протоколы обновления сервера разрешения материала
5.4.1 Общие положения

Информация материала (Ml) или ее части, возвращаемые MRS, могут измениться во время просмотра контента и поэтому могут потребовать обновления.

Если массив updateMaterial присутствует и заполнен, то это означает, что обновления могут происходить, но не обязательно для материалов, определенных в свойствах материалов. Если массив updateTimelineSync присутствует и заполнен, это означает, что обновления могут происходить, но не обязательно для информации временной шкалы синхронизации, определенной в свойстве syncTimelinelnformation.

Свойства updateMaterial и updatedTimelineSync являются массивами размещений, из которых могут быть получены или извлечены обновления. Размещение кодируется как URL и частично идентифицирует используемый протокол обновления. Для каждого размещения также передается М1МЕ-тип, который завершает идентификацию протокола обновления. Данные массивы могут также содержать размещение MIME-типов для других механизмов, которые не определены в настоящем стандарте.

CSA осуществляет механизм длительного опроса, определенный в 5.4.4. CSA должно реализовывать механизм веб-сокета, определенный в 5.4.5, и механизм событий передачи сервера, определенный в 5.4.6. CSA может реализовать механизм BOSH/XMPP, определенный в 5.4.7.

Если массивы присутствуют, то элемент массива 0 должен содержать размещение и идентификацию службы длительного опроса, как определено в 5.4.4. Все другие элементы массива являются опциональными.

Порядок элементов в массиве указывает на порядок размещений, где самый высокий индекс указывает на наиболее предпочтительный вариант. CSA должно использовать элементы массива в порядке убывания, начиная с самого старшего элемента. CSA может игнорировать любой элемент массива, чей URL и mimeTYPE оно не распознает или не поддерживает. Если CSA не удается установить соединение, используя данный элемент массива, то CSA должно продолжать попытки, используя остальные элементы в порядке убывания. После того как CSA устанавливает успешное соединение, оно должно продолжать его использовать для обновления, за исключением случаев:

-    возникновения состояния ошибки;

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

6

Окончание таблицы 2

Поле заголовка CORS

Рекомендуемое значение

Примечание

Access-Control-Allow-

Headers

"X-Requested-With, Origin, If-Modified-Since, Accept, If-None-Match, Content-Type"

Позволяет получить доступ к ключевым полям заголовка в определенной среде выполнения CSA

Access-Control-Max-Age

60

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


ГОСТ P 57870.4—2017

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

5.4.2    Синтаксис JSON для обновления элемента массива

Объекты, входящие в состав массива updateMaterial и массива updateTimelineSync, должны соответствовать следующему шаблону:

{

"шТ    :    <url>,

"mimeType"    :    <string>,

"protocolSpecificData"    :    <string> (optional)

}

5.4.3    JSON ответ с обновлением

Объект JSON, возвращаемый протоколами обновления, передает изменения в материал или в информацию временной шкалы синхронизации. Объект JSON должен соответствовать 5.3.4, но все его свойства, кроме свойства "type", являются опциональными. Он должен иметь дополнительные свойства, которые определены в настоящем пункте. Свойство "type" должно иметь значение "update".

Объект JSON должен иметь дополнительные свойства в соответствии со следующим шаблоном:

"updateVersionNo"    : <integerAsString>,

"patchData"    : <jsonPatchSyncTimelinelnformation> (опционально)

5.4.4    Длительный опрос

Длительный опрос является обычным запросом, посылаемым на определенный URL, когда ответ соответствует 5.3.4, а объект JSON в ответе соответствует семантике, определенной в 5.4.3, в зависимости от обстоятельств.

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

Когда соединение закрывается неожиданно или в результате завершения получения обновления, новый запрос выдается не ранее, чем указано в наименьшем из значений в свойстве repolllnterval объекта JSON в ответах, или в обновлениях (считая с начала последнего запроса), или в заголовке "Expires" последнего успешного HTTP ответа.

Объект mimeTYPE должен иметь формат application/json для массива updateMaterial или формат application/json-patch для массива updateTimelineSync. Компонент протокола URL должен быть "http" или "https".

5.4.5    Протокол WebSocket

Объект mimeTYPE должен иметь формат application/json для массива updateTimelineSync. Компонент протокола URL должен быть "ws" или "wss". Данный URL должен ссылаться на серверную часть протокола WebSocket версии 13.

Все отправленные сообщения должны быть кадрами данных WebSocket (в соответствии с требованиями спецификации протокола WebSocket) с полезной нагрузкой в текстовом формате.

CSA не должно направлять никаких данных на сервер через WebSocket.

Сервер может посылать ответы с обновлениями в соответствии с 5.4.3.

5.4.6    Протокол событий передачи сервера

Объект mimeTYPE должен иметь формат "ext/event-stream". Компонент протокола URL должен быть "http" или "https".

Тип события, которое фиксируется строкой "event:" потока событий, должен быть установлен в "Mlupdate" (т.е. строка "event: Mlupdate" должна предшествовать данным события) для обновлений материала или в "TSupdate" (т.е. строка "event:TSupdate" должна предшествовать данным события) для обновления синхронизации временной шкалы.

Данные должны быть посланы как поле данных с именем (т.е. строка "data:" должна предшествовать данным события).

Данные события должны быть объектом JSON для событий "Mlupdate" и объектом JSON Patch для событий "TSupdate". Для того чтобы обеспечить правильную передачу, кодировка объекта JSON не должна включать в себя символы конца строки.

7