ГОСТ Р 59801-2021 Телевидение вещательное цифровое. Расширенные технические требования к передаче транспортных потоков служб DVB по сетям с IP-протоколами. Часть 2. Потоковый протокол реального времени при воспроизведении служб DVB

ФЕДЕРАЛЬНОЕ АГЕНТСТВО

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

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

СТАНДАРТ РОССИЙСКОЙ

ФЕДЕРАЦИИ

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

Расширенные технические требования к передаче транспортных потоков служб DVB по сетям с IP-протоколами

Часть 2

Потоковый протокол реального времени при воспроизведении служб DVB

[ETSI TS 102 034 V2.1.1 (2016-04). NEQ]

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

Москва Российский институт стандартизации 2021

Предисловие

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

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

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

• 4 Настоящий документ разработан с учетом основных нормативных положений стандарта Европейского института по стандартизации в области телекоммуникаций (ETSI) ETSI TS 102 034 V2.1.1 (2016-04) «Телевидение вещательное цифровое. Передача транспортных потоков MPEG-2 основных служб DVB по основным сетям IP» [ETSI TS 102 034 V2.1.1 (2016-04) «Digital Video Broadcasting (DVB); Transport of MPEG-2 TS Based DVB Services over IP Based Networks». NEQ]

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

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

©Оформление. ФГБУ «РСТ». 2021

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

Содержание

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

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

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

• 4 Потоковый протокол реального времени (RTSP)

• 4.1 Использование RTSP для служб DVB

• 4.2 Профили и методы RTSP при unicast-передаче

• 4.3 Коды состояний RTSP

• 4.4 Методы RTSP при multicast-передаче

ГОСТ Р 59801—2021

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

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

Расширенные технические требования к передаче транспортных потоков служб DVB по сетям с IP-протоколами

Часть 2

Потоковый протокол реального времени при воспроизведении служб DVB

Digital video broadcasting. Extended technical requirements for transmitting DVB service transport streams over networks with IP protocols. Part 2. Real-time streaming protocol when playing DVB services

Дата введения — 2022—06—01

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

• 8 настоящем стандарте представлено описание расширенного набора стандартизованных спецификаций для развертывания служб DVB по двунаправленным IP-сетям с применением технологий IPv4 и IPv6 и определены возможности использования потокового протокола реального времени (RTSP) для HNED при воспроизведении служб DVB.

Настоящий стандарт рассматривает использование протокола RTSP на уровне приложений и определяет требования к протоколу RTSP для управления доставкой служб CoD. LMB и MBwTM.

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

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

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

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

ГОСТ Р S3528 Телевидение вещательное цифровое. Требования к реализации протокола высокоскоростной передачи информации DSM-CC. Основные параметры

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

ГОСТ Р 54995 Телевидение вещательное цифровое. Требования к кодированию аудио- и видеосигналов для приложений вещания, основанных на транспортных потоках MPEG-2. Общие технические требования

ГОСТ Р 55697 Телевидение вещательное цифровое. Сервисная информация. Общие технические требования

ГОСТ Р 56170 Телевидение вещательное цифровое. Домашняя мультимедийная платформа. Класс 1.2. Основные параметры

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

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

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

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

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

    • 3.1.1 домен (domain): Автономная часть сети или распределенной системы.

    • 3.1.2 интернет-протокол. IP (Internet protocol; IP): Межсетевой протокол пакетной передачи, который работает:

• - с 32-битовыми адресами (версия IPv4) и со 128-битовыми адресами (версия IPv6), обеспечивая адресацию и маршрутизацию пакетов в сети:

• - без установления соединения, не обеспечивая сохранение порядка следования пакетов и не гарантируя доставку пакетов.

• 3.1.3 клиент DNS (DNS dient): Служба [программа (или модуль в программе)], предназначенная для получения IP-адреса удаленного компьютера при наличии его доменного адреса.

• 3.1.4 оконечное устройство домашней сети; HNED (Home Network End Device; HNED): Устройство. которое подключено к IP-сети через интерфейс IPI-1. является отправителем потока или приемником потока и обеспечивает функции навигации и визуализацию контента DVB-IPT.

• 3.1.5 пользователь (user): Оконечная система, которая может передавать или принимать информацию от других таких же оконечных систем с использованием сети и которая может функционировать как клиент, сервер, так и как клиент и сервер одновременно.

• 3.1.6 поставщик контента (content provider): Организация, владеющая или имеющая лицензию на продажу контента или активов контента.

• 3.1.7 потоковый протокол реального времени; RTSP (Real Time Streaming Protocol; RTSP): Прикладной протокол, предназначенный для использования в системах, работающих с мультимедийными данными.

• 3.1.8 предложение провайдера служб (SP offering): Набор потоков или служб, предлагаемых провайдером служб для конечного пользователя.

• 3.1.9 провайдер службы: SP (Service Provider. SP): Объект, предоставляющий службу пользователю.

• 3.1.10 провайдер службы интернет; ISP (Internet Service Provider. ISP): Сторона, предлагающая пользователю службу доступа в Интернет.

• 3.1.11 провайдер службы контента: CSP (Content Service Provider; CSP): Объект, который приобретает. лицензирует контент у провайдеров контента и упаковывает контент в службу.

• 3.1.12 профиль (profile): Группа конфигураций, обеспечивающих возможности HNED.

• 3.1.13 служба DVB-IPTV (service DVB-IPTV): Одна или несколько программ, передаваемых no IP. под управлением провайдера службы.

Примечание — Программы для прямого потребления могут быть доступны при передаче по расписанию (Live Media Broadcast; LMB). no требованию или для локального хранения, а также при работе службы загрузки контента (Content Download Services: CDS).

• 3.1.14 транспортный поток с полной SI (traffic flow with full service information): Транспортный поток co встроенной служебной информацией, за исключением таблицы сетевой информации NIT.

• 3.1.15 транспортный поток с дополнительной SI (traffic flow with additional service information): Транспортный поток c PSI MPEG (таблицы PAT и PMT).

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

AL-FEC — уровень приложения прямого исправления ошибок (Application Layer Forward Error Correction);

любой источник multicast-доставки (Any Source Multicast);

базовый формат медиафайла (Base Media File Format);

гражданский адрес (Civic Address);

служба загрузки контента (Content Download Service);

идентификатор контента (Content Identifier);

контент no запросу (Content on Demand);

защита контента (Content Protection);

циклический избыточный код, использующий алгоритм нахождения контрольной суммы и предназначенный для проверки целостности данных (Cyclic Redundancy Check);

альянс домашних цифровых сетей, совокупность стандартных технологий, создающих возможность обмена медиаконтентами в домашней сети для совместимых устройств (Digital Living Network Alliance);

система наименований доменов в сети Интернет (Domain Name System);

динамическое управление службой (Dynamic Service Management);

декларация типа документа (Document Type Declaration);

домашняя сеть цифрового телевизионного вещания (DVB Home Network);

цифровое телевизионное вещание по каналам с IP-протоколами;

спутниковое цифровое телевизионное вещание (Digital Video Broadcasting — Satellite);

транспортный протокол (DVB SD&S);

быстрая смена каналов (Fast Channel Change);

доставка файлов при однонаправленной передаче (File Delivery over Unidirectional Transport);

служба обновления встроенного программного обеспечения (Firmware Update Service);

метод GET протокола HTTP, который используется для запроса содержимого ресурса;

утилита компрессии и декомпрессии файлов, использующая алгоритм Deflate (GnuZIP);

домашняя сеть (Home Network);

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

таблица нотификации (извещений] IP-протокола (IP/МАС Notification Table);

интернет-протокол, версия 4 (Internet Protocol version 4);

интернет-протокол, версия 6 (Internet Protocol version 6);

инфраструктура IP-протокола (Internet Protocol Infrastructure);

IP телевидения (Internet Protocol TeleVision);

вещание медиа (Live Media Broadcast);

управление доступом к среде (Media Access Control);

вещание медиа в режиме Trick (Media Broadcast with Trick Modes);

промежуточное программное обеспечение;

расширение многоуровневой интернет-почты (Multipurpose Internet Mail Extensions);

обнаружение multicast слушателей (Multicast Listener Discovery);

описание медиапреэентации (Media Presentation Description);

метод запроса, поддерживаемый HTTP;

PT — тип полезной нагрузки (Payload Type);

Pull — режим получения информации по запросу;

Push — режим многоадресной (multicast) передачи информации,

RAMS — быстрое приобретение в режиме сеансов RTP multicast (Rapid Acquisition of Multicast RTP Sessions);

RET — повторная передача (RETransmission);

RMS — служба удаленного управления и встроенные программы (Remote Management and Firmware);

RR — отчет получателя (Receiver Report);

RTT — интервал времени от отправления запроса до получения ответа (round trip time);

SD&S — обнаружение и выбор службы (Service Discovery and Selection);

SR — отчет отправителя (Sender Report);

SRM — сообщение об обновлении системы (System Renewability Message):

SRV — отчет получателя DNS (SeRVice, specific DNS RR);

SSRC — источник синхронизации (Synchronization Source);

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

TISPAN — интегрированные службы и протоколы телекоммуникаций и Интернета для расширенных сетей (Telecommunications and Internet converged Services and Protocols for Advanced Networking);

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

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

URN — универсальное имя ресурса (Uniform Resource Name);

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

multicast — режим передачи [доставки, загрузки, источника передачи (рассылки)) служб, сеансов. потоков, каналов, протоколов, файлов подмножеству получателей (адресов);

trick — различные режимы проигрывания мультимедиа (быстрый доступ к объектам среды мультимедиа);

unicast — режим передачи (доставки, загрузки, источника передачи) служб, сеансов, потоков. каналов, протоколов, файлов только одному получателю (адресу).

• 4 Потоковый протокол реального времени (RTSP)

В настоящем стандарте рассмотрены процессы взаимодействия, сигнализации и управления между провайдером служб и интерфейсом IPI-1 оконечного устройства домашней сети (HNED) при использовании потокового протокола реального времени (RTSP). Применение протокола RTSP обеспечивает пользователю возможность управления службой «контент по требованию» (CoD) и управление доставкой служб вещания медиа LMB и MBwTM. При необходимости интерфейс оконечного устройства домашней сети IPI-1 может применяться для доставки контента и метаданных в сеть DVB-HN с целью использования локального контента и управления локальным контентом и устройствами, работающими в составе DVB-HN. В общем случае протоколы, необходимые для транспортирования элементов предоставляемых служб через сети IP. не зависят от физических уровней. Поэтому настоящий стандарт не нормирует технологии физического уровня. HNED с интерфейсом IPI-1 соответствует требованиям, установленным к коммуникационным протоколам канального уровня, уровня IP (сетевого) и транспортного уровня. Протоколы HTTP. TCP, UDP и IP доступны для HNED как сетевые и транспортные протоколы. Информация процесса обнаружения и выбора multicast-служб передается в пакетах IP в соответствии с транспортным протоколом DVBSTP. Для unicast-передачи служб в режиме pull информация о механизме SD&S транспортируется через HTTP. Точка входа в процесс SD&S может быть реализована с использованием механизма DNS. RTSP применяется для доставки и управления службой CoD. а также для управления доставкой службы вещания LMB. Аудио-, видеопотоки и потоки служебной информации мультиплексируются в транспортный лоток MPEG-2. Полученные пакеты мультиплекса MPEG-2 инкапсулируются непосредственно в UDP или в RTP/UDP для потоковой доставки с маркировкой па* кетов DSCP в соответствии с ГОСТ Р 54994. RTCP формируется, и клиентам передается информация о статистике передачи. IGMP и MLD применяются для соединения с multicast-потоками и для выхода из multicast-потоков. Протокол DHCP используют для настройки HNED на IP-адрес. Служба часов реального времени и служба часов точного сетевого времени реализованы посредством соответственно протоколов SNTP или NTP по ГОСТ Р 54994. Для передачи сообщения об обновлении системы (SRM) при unicast-доставке используют протокол HTTP, при multicast-доставке — протоколы-FLUTE и объявления сеанса (Session Announcement Protocol. SAP). Повышение надежности доставки для транспорта RTP обеспечено использованием AL-FEC или путем повторных передач (RET). Уменьшение времени отклика при переключении служб LMB происходит благодаря быстрой смене канала на уровне сервера или при использовании сопутствующего потока.

• 4.1 Использование RTSP для служб DV8

  • 4.1.1 Выбор службы

Доступ HNED к необходимой информации запрашиваемой службы обеспечивается средствами протокола RTSP.

8 зависимости от количества потоков, образующих службу, в записях SD&S может быть несколько URL протокола RTSP. Если в потоках FEC присутствуют URL управления, то в этом случае совокупный URUBroadcastDiscovery/ServiceList/SingleService/ServiceLocation/RTSPURL применяют для всей службы. за исключением потока повторной передачи. В тех случаях, когда служба образована единственным потоком. URL используют для всех сообщений RTSP [SETUP (настройка). PLAY (воспроизведение). TEARDOWN (демонтаж) и т. д.). При необходимости извлечения описания этот URL следует применять для передачи сообщения DESCRIBE.

Когда служба образована несколькими потоками. URL применяют при передаче сообщений SETUP для каждого потока в отдельности. С целью управления каждым потоком в отдельности URL могут быть использованы при формировании сообщений PLAY. PAUSE (запрос временной остановки вещания).

Ниже перечислены поля URL-управлений:

• - RTSPURL@RTSPControlURL — для управления основным потоком аудио-, видеоданных;

• - FECBaseLayer@RTSPControlURL — для управления потоком базового уровня FEC;

• - FECEnhancementLayer@RTSPControlURL — для управления потоком улучшенного уровня FEC;

• - UnicastRET@RTSPControlURL — для сообщений управления RTSP (SETUP) при unicast-передаче потока RET.

Для получения описания механизма SD&S HNED прослушивает групповой адрес и номер порта, с помощью которых пользователь может выбрать службу. После выбора службы HNED могут использовать ассоциированные URL RTSP для доступа к службе (если URL указывает, что управление сеансом основано на RTSP).

Когда служба использует RET или AL-FEC при установке сеанса, может возникнуть необходимость получения дополнительной информации относительно описания сеанса посредством методов RTSP, перечисленных в 4.2.4.4. При выборе службы HNED может использовать связанные URL-адреса RTSP для доступа к службе. URL-адреса указывают, основан ли элемент управления сеансом на RTSP. В этом случае HNED должен применять RTSP для доступа к соответствующей услуге. Когда служба использует повторную передачу или AL-FEC, может потребоваться получить дополнительную информацию об описании сеанса для настройки сеанса.

Для разрешения переноса дополнительного URL-улрааления RTSP с целью оказания помощи службам AL-FEC и/или RET использовано поле RTSPURLType. В таблице 1 приведены определения полей RTSPURLType.

Таблица 1 — Определения полей типа RTSPURLType

Определения базовых типов XML представлены в таблице 2.

Таблица 2 — Определения базовых типов XML

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

• 4.1.2 Транспорт сеанса

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

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

• 4.1.3 Информация о службах

HNED использует информацию о службах для информирования пользователя о виде и доступности служб, об их местонахождении и об условиях получения к ним доступа. Эта информация должна постоянно обновляться. При возможности сервер RTSP может асинхронно отправлять служебную информацию HNED с помощью метода RTSP-ANNOUNCE.

Доступ к информации о службе HNED может получить в том случае, когда сервер RTSP асинхронно отправляет HNED информацию о службе при использовании метода ANNOUNCE (см. таблицу 3). Альтернативно HNED может получить информацию о службе после передачи серверу запроса при использовании метода DESCRIBE (см. таблицу 3). Этот прием может применяться в случае кратковременного соединения между HNED и сервером RTSP.

При использовании AL-FEC или RET параметры описания сеанса для служб LMB должны быть включены в элемент IPMulticastAddress типа ServiceLocation службы SD&S. присутствующий в элементе RTSPURL SD&S. или/и в информацию, доступную через URL протокола RTSP. Оба элемента находятся в записи обнаружения (открытия) вещательной передачи.

Для служб LMB адрес URL протокола RTSP может быть доступен через разрешение CRID в соответствии с BCG или альтернативно непосредственно в элементе ProgramURL структуры XML tva:onDemandProgram.

Для служб CoD и MBwTM при описании сеанса должен быть использован URL RTSP. Этот URL RTSP может быть доступен:

• - в разрешении CRID;

• • элементе ProgramURL структуры XML tva:onDemandProgram.

Из перечисленных вариантов использование разрешения CRID (при его наличии) является наиболее целесообразным.

Когда HNED использует адрес URL RTSP при описании сеанса для служб LMB, CoD или MBwTM, устройство HNED должно выдать сообщение DESCRIBE RTSP.

Методы ANNOUNCE и DESCRIBE используют для передачи служебной информации в HNED.

В настоящем стандарте рассмотрены меры безопасности, предусмотренные в протоколах RTSP и HTTP. Дополнительные требования к мерам безопасности и аутентификации для DVB-IPTV в настоящем стандарте не установлены.

• 4.2 Профили и методы RTSP при unicast-передаче

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

• - прямая трансляция в СМИ (LMB);

• • медиатрансляция с режимами трюков (MBwTM);

• - контент по запросу (CoD).

Каждый профиль RTSP содержит подмножество методов и заголовков, определенных в протоколе RTSP. Взаимосвязь между профилями RTSP выглядит следующим образом: профиль «Трансляция в прямом эфире» — это подмножество профиля «Трансляция в прямом эфире СМИ (LMB) с режимами трюков», который, в свою очередь, является подмножеством профиля «Контент по требованию» (CoD).

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

Профиль RTSP CoD в дополнение к возможностям профиля RTSP MBwTM обеспечивает возможность инициировать начало и остановку презентации как независимых событий. Это означает, что данный профиль поддерживает операции «пауза», «ускоренная перемотка», и другие операции, а также может получить доступ к медиа на интервалах времени по выбору пользователей. Поэтому доставка потоков медиапрофиля RTSP CoD осуществляется только в режиме unicast-передачи.

• 4.2.1 Перечень методов протокола RTSP

В таблице 3 представлен перечень методов (команд) протокола RTSP, которые поддерживают интерфейс IPI-1 для режима unicast-доставки.

Таблица 3 — Методы RTSP для режима unicast-доставки

• 4.2.2 Использование методов RTSP в DVB

В таблице 4 представлен перечень методов RTSP, поддерживаемых интерфейсом IPI-1 для режима multicast-доставки профилей RTSP MBwTM и CoD.

Таблица 4 — Методы RTSP, поддерживаемые интерфейсом IPI-1 для режима multicast-доставки профилей RTSP MBwTM и СоО

Клиент RTSP DVB. поддерживающий повторную передачу (RET), или сервер FCC должны принимать описания сеансов в формате SDP. Типом описания MIME SDP является application/sdp. в описании SDP используется формат UTF-8. HNED в заголовке Accept может включать application/sdp. указывающий на поддержку SDP.

Метод ANNOUNCE может быть использован для асинхронного обновления служебной информации в HNED. В профиле вещания LMB метод ANNOUNCE применяется для обновления имени службы.

Клиент DVB RTSP должен поддерживать прием описаний в формате XML. Для профилей вещания LMB и MBwTM метод ANNOUNCE должен содержать структуру XML Broadcastoffering.

Элемент записи Broadcastoffering обнаружения вещательной передачи используют в тех случаях, когда SP предлагает несколько служб вещания, которые непрерывно транслируют транспортные потоки MPEG-2. Предоставляемые службы сгруппированы в перечни служб ServiceLists. каждый из которых представлен экземпляром сложного типа IPServiceList, который, в свою очередь, является списком служб IP.

Элемент Broadcastoffering используют в двух формах:

• - в форме TS Full SI. в которой элемент SI может отсутствовать, и. следовательно, полная служебная информация DVB, определенная в ГОСТ Р 55697, предоставляется внутри транспортного потока в местоположениях, указанных в записи;

• - форме TS Optional SI. в которой элемент SI должен и может присутствовать в транспортном потоке (опционально) в указанном местоположении.

При multicast-передаче значение PayloadID должно быть равно 2.

В RTSP для контента по требованию метод ANNOUNCE должен содержать структуру XML ANNOUNCE. CoDAnnounceDescribe должен присутствовать только в документах, используемых как часть методов DESCRIBE. 8 таблице 5 представлен перечень полей структуры CoDAnnounceDescribe.

Таблица 5 — Перечень полей структуры CoDAnnounceDescribe

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

В таблице 6 представлена семантика полей RTSPAnnounceDescribe.

Таблица 6 — Семантика полей RTSPAnnounceDescribe

Клиент RTSP DVB, поддерживающий повторную передачу (RET) или сервера FCC. должен понимать описания сеансов в формате SDP. Типом описания MIME SDP является application/sdp, а в описании SDP используется UTF-8. HNED может включать applicatiorVsdp в заголовке Accept, чтобы указать на поддержку протокола SDP.

Клиент RTSP DVB должен поддерживать прием описаний в формате XML. обеспечиваемых методом ANNOUNCE, описаны в данном пункте. Тил MIME для описаний XML должен быть text/xml. формат описания XML — UTF-8. HNED должен всегда включать text/xml с использованием заголовка Accept.

Клиент RTSP DVB. поддерживающий повторную передачу, должен понимать описание сеанса в формате SDP. Типом описания MIME является application/sdp. В описании SDP используется UTF-8. HNED может включать application/sdp в заголовке Accept чтобы указать на поддержку протокола SDP.

В методе GET_PARAMETER (запрос указанных параметров у сервера) тип MIME в заголовке за-проса Content-Type или ответа GET.PARAMETER должен быть texVparameters. Контент в заголовке Content-Encoding должен быть выполнен в формате UTF-8.

В запросе каждое наименование параметра должно сопровождаться двоеточием (<:») и отделяться пробелом. Каждое наименование параметра может находиться в отдельной строке, альтернативно все наименования могут быть размещены в одной строке. Ожидается, что параметры в ответе будут возвращаться по одному в строке в следующей форме:

parameter = name : * (VCHAR) CR.

Таблица 7 содержит необходимый набор параметров GET.PARAMETER. которые должны поддерживаться интерфейсом IPI-1 методом GET_PARAMETER.

Таблица 7 — Набор параметров метрда GET.PARAMETER

В методе SETUP HNED запрос SETUP не должен передаваться более одного раза для одного и того же потока или мультимедийного сеанса перед выпуском запроса TEARDOWN.

• 4.2.3 Заголовки полей RTSP

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

Таблица 8 — Перечень полей заголовков RTSP. генерируемых HNED

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

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

Таблица 9 — Перечень полей заголовков запросов RTSP. анализируемых HNED {рекомендуемый)

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

Параметры заголовка Transport, необходимого при прямой инкапсуляции UDP (без RTP). и дополнительные параметры транспортного заголовка RTSP Transport — transport-protocol/profile/lower-transport должны принимать значения:

• - MP2T/H2221/UDP:

• - RAW/RAW/UDP.

• 4.3 Коды состояний RTSP

Коды состояния протокола RTSP в ответах на запросы, которые должен интерпретировать HNEO, соответствуют приведенным в таблице 10.

Таблица 10 — Коды состояния протокола RTSP а ответах на запросы

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

• 4.4 Методы RTSP при multicast-передаче

RTSP может быть использован для присоединения HNED к multicast LMB.

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

Протоколы MLD или IGMP должны быть использованы совместно с RTSP для передачи в сеть IP сообщений о передаче мультимедийных потоков при multicast-рассылке. Во время настройки мультимедийного сеанса HNED выдает соответствующее сообщение для присоединения к данной multicast-рассылке. При выходе из режима multicast-рассылки HNED выдает сообщение IGMP LEAVE (IPv4) или сообщение Multicast Listener Done (IPv6). Для таких сообщений на интерфейсе IPI-1 следует использовать протокол IGMP (версия 3) или протокол MLDv2.

Параметрами конфигурации транспорта должны быть destination (назначение) и source (источник) (см. таблицу 9). Они должны использовать либо IGMP (версия 3), либо MLDv2. IGMP (версии 3) должен сигнализировать адрес multicast-рассылки. MLDv2 может применяться для сигнализации исходного адреса multicast-рассылки (SSM) источника. В тех случаях, когда RTSP не указывает способ доставки (unicast или multicast), по умолчанию мультимедийный лоток доставляется в режиме multicast. Для режима multicast-доставки в таблице 11 представлены методы RTSP, поддерживаемые интерфейсом IPI-1.

Таблица 11 —Методы RTSP для режима mutlicast-доставки. поддерживаемые интерфейсом IPM

УДК 621.397.132.129:006.354 ОКС 33.170

Ключевые слова: телевидение вещательное цифровое. DVB-IPTV. провайдер, транспортный поток

MPEG-2. домашняя сеть. RTSP. HNED. вещание медиа, контент. SD&S. XML

Редактор Л. С. Зиминова Технический редактор В.Н. Прусакова Корректор ЕЛ- Дульнева Компьютерная верстка И.Ю. Литовкиной

Сдано в набор 28.10 2021 Подписано а лечат» 24.11.2021. Формат 60*844. Гарнитура Ариал.

Усл. печ. л. 2.32. Уч-изд. п. 2,10.

Подготовлено на основе электронном версии, предоставленной разработчиком стандарта

Создано в единичном исполнении в ФГБУ кРСТ» . 117418 Москва. Нахимовский пр-т. д. 3t. к. 2. www.gos6nfo.ru [email protected]