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

(утв. и введен в действие Приказом Росстандарта от 26.10.2021 № 1309-ст)

Утвержден и введен в действие Приказом Федерального агентства

Дата введения

Предисловие

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

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

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

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

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

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

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

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

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

ГОСТ Р 53528 Телевидение вещательное цифровое. Требования к реализации протокола высокоскоростной передачи информации 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 client): Служба [программа (или модуль в программе)], предназначенная для получения 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): Одна или несколько программ, передаваемых по IP, под управлением провайдера службы.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

INT — таблица нотификации [извещений] IP-протокола (IP/MAC Notification Table);

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

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

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

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

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

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

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

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

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

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

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

POST — метод запроса, поддерживаемый 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 для служб DVB

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

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

В зависимости от количества потоков, образующих службу, в записях SD&S может быть несколько URL протокола RTSP. Если в потоках FEC присутствуют URL управления, то в этом случае совокупный URL/BroadcastDiscovery/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 (контент расширенного типа)	Поле содержит URL, пользуясь которым, можно получить доступ к описанию службы. Когда служба состоит из одного потока, для управления этим потоком URL используется во всех сообщениях RTSP (SETUP, PLAY, TEARDOWN и т.д.). Формат соответствует определениям, приведенным в таблице 2	Обязательное, если SP решил использовать RTSP
RTSPControlURL	URL используют в сообщениях RTSP (SETUP, PLAY, PAUSE и т.д.) для управления основным аудио-, видеопотоком, когда для этого основного аудио-, видеопотока применяют AL-FEC или RET	Опциональное, но обязательное, если RTSP используют с RET или FEC

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

Наименование	Определение
BroadcastSystemType	Идентификатор системы вещания. Этот тип может принимать любое из значений (ANALOG, ID_DVB_C, ID_DVB_S ID_DVB_T, ID_DVB_C2, ID_DVB_S2, ID_DVB_T2, ID_ISDB_C, ID_ISDB_S, ID_ISDB_T, ID_ATSC_T»)
CPSystemIDType	Идентификатор системы защиты контента от копирования (ID System CP)
CPSystemSRMID	Идентификатор SRM System CP системы защиты контента
DomainType	Описывает тип «domain name» (доменное имя)
EnhancementServiceType	Содержит список серверов расширения служб LMB. Нормированы только RET и FCC
Genre	Описывает жанр контента, который кодируется числом в диапазоне значений от 0 до 15, указанном в поле content_nibble_level_1 дескриптора content_descriptor/
Hexadecimal3bit	3-битовое число, представленное одной шестнадцатеричной цифрой
Hexadecimal4bit	4-битовое, представленное шестнадцатеричной цифрой
Hexadecimal8bit	8-битовое число, представленное как одна или две шестнадцатеричные цифры
Hexadecimal16bit	16-битовое число, представленное от одной до четырех шестнадцатеричных цифр
Hexadecimal32bit	32-битовое число, представленное в виде восьми шестнадцатеричных цифр
Integer6bit	6-разрядное десятичное число в диапазоне значений от 0 до 63 без идентификатора номера
IPorDomainType	Тип модульного блока, который может содержать либо IP-адрес (см. IPType), либо доменное имя (см. DomainType)
IPType	Адрес IPv4 в форме a.b.c.d (десятичные значения, разделенные точками) или шестнадцатеричный адрес IPv6, разделенный двоеточием. Выражения RegEx для форматов IPv4 и IPv6 показаны в расширениях (см. примечание 1)
ISO-3166-1 (1997)	Список трехсимвольных кодов стран, разделенных запятой
ISO 639-2	Трехбуквенный код языка. Может быть использован для переноса специальных значений
OrigNetId	Десятичный идентификатор original_network_id
PrimarySISource	Указывает, содержится ли основная информация SI в XML, где этот тип принимает значение XML, или в потоке, где этот тип принимает значение Stream
PullURL	Используется для указания полного URL, из которого можно извлечь информацию о механизме SD&S, включая схему протокола, полномочия и путь. HNED должно добавить к этому запрос URL
RTSP	Используется, если необходим URL RTSP
Service	Имя службы. Рекомендуется обеспечивать соответствие правилам для имен DNS в Интернете
ServiceID	Service_id, как определено в ГОСТ Р 55697. Это значение должно быть десятичным (см. примечание 2)
ServiceType	Шестнадцатеричное восьмибитовое значение (см. Hexadecimal8bit), кодирующее type службы
StreamingType	Используется ли RTP со значением rtp или потоковое UDP со значением udp
TransportProtocolType	Строка, которая может быть использована для сигнализации типа транспорта и типа FEC
TSId	Идентификатор Transport_stream_id согласно ГОСТ Р 55697
Usage	Указывает на используемую службу IPService. Этот элемент является строкой и может быть Main, SD, HD, PiP, FCC, 3D или DSMService. Это означает, что другие службы IP поддерживают один и тот же контент и что они будут отображаться как субслужбы IP этой службы. Значение DSMService является обязательным для тех служб, которые являются частью группы DSM и где DSM активирован в HNED
Version	Число, передающее версию таблицы или записи. Это значение будет увеличиваться при изменении таблицы или записи по модулю 256. Это значение должно быть в шестнадцатеричном формате
Примечания 1 Регулярное выражение RegEx, применяемое в качестве соответствия шаблону для сопоставления адреса IPv6 в определении IPType в настоящей таблице, способно проверять параметры для 128-битовой структуры. 2 ServiceID не следует путать с текстовым идентификатором службы по определению в ГОСТ Р 56170.

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

Метод RTSP	Направление передачи	Применение нормы IETF	Применение нормы DVB
ANNOUNCE	H \rightarrow S	Допускается	Допускается
ANNOUNCE	S \rightarrow H	Допускается	Обязательно
DESCRIBE	H \rightarrow S	Обязательно	Обязательно
GET_PARAMETER	H \rightarrow S	Допускается	Обязательно
GET_PARAMETER	S \rightarrow H	Допускается	Допускается
OPTIONS	H \rightarrow S	Будет применяться	Будет применяться
OPTIONS	S \rightarrow H	Допускается	Допускается
PAUSE	H \rightarrow S	Обязательно	Будет применяться
PLAY	H \rightarrow S	Будет применяться	Будет применяться
REDIRECT	S \rightarrow H	Допускается	Будет применяться
SETUP	H \rightarrow S	Будет применяться	Будет применяться
TEARDOWN	H \rightarrow S	Будет применяться	Будет применяться
Примечание — H - HNED, S — сервер.

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

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

Метод RTSP	Направление передачи	Применение нормы IETF	Применение нормы DVB
ANNOUNCE	H \rightarrow S	Опциональное	Опциональное
ANNOUNCE	S \rightarrow H	Опциональное	Рекомендуемое
DESCRIBE	H \rightarrow S	Рекомендуемое	Рекомендуемое
GET_PARAMETER	H \rightarrow S	Опциональное	Рекомендуемое
GET_PARAMETER	S \rightarrow H	Опциональное	Опциональное
OPTIONS	H \rightarrow S	Обязательное	Обязательное
OPTIONS	S \rightarrow H	Опциональное	Опциональное
PAUSE	H \rightarrow S	Рекомендуемое	Обязательное
PLAY	H \rightarrow S	Обязательное	Обязательное
REDIRECT	S \rightarrow H	Опциональное	Обязательное
SETUP	H \rightarrow S	Обязательное	Обязательное
TEARDOWN	H \rightarrow S	Обязательное	Обязательное
Примечание — H - HNED, S — сервер.

Клиент 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. В таблице 5 представлен перечень полей структуры CoDAnnounceDescribe.

Таблица 5

Перечень полей структуры CoDAnnounceDescribe

Наименование	Описание	Указание применения
ContentDescription	Описание элемента с использованием формата TVAnytime	Обязательное
FECInfo	Подробная информация о FEC доступна для этого элемента контента (при его наличии)	Обязательное, если FEC доступен для этого элемента
RETInfo	Сведения о RET доступны для этого элемента контента	Обязательное, если для этого элемента доступен RET, а ServerErrorEnhancementServiceInfo отсутствует
ServerBasedEnhancementServiceInfo	Сведения о службе расширения на базовом сервере, доступные для этого элемента контента	Обязательное, если для этого элемента доступен сервер FCC
RTSPControlURL	URL RTSP, используемый для управления этим элементом контента	Обязательное, если для RTSP используется отдельный controlURL
Streaming	Атрибут должен указывать формат потоковой передачи (при его наличии)	Опционально

Наименование	Определение семантики	Указание применения
ContentDescription	Использует тип tva — BasicContentDescription	Обязательное
RETInfo	Использует тип dvb — RETInfoType. Этот тип используют для сигнализации наличия службы однократной повторной передачи RTP (RET) и повторной multicast-передачи служб RTP. Передает параметры, необходимые для использования службы RET со следующими исключениями: - элемент MulticastRET и связанные с ним атрибуты не определены для RET CoD и не будут присутствовать в качестве информации о сеансе в Describe RTSP; - атрибуты элемента RTCPReporting не определены для RET CoD и не будут использоваться для служб CoD: dvb-enable-bye, dvb-t-wait-min, dvb-t-wait-max, dvb-ssrcbitmask, dvb-rsi-mc-ret и dvb-ssrc-upstream-client; - атрибут RTCPReporting @ Destination Address в контексте RET CoD переопределяется таким образом, что, если указан IP-адрес, на который HNED отправляет свои отчеты RTCP, это значение должно соответствовать адресу IP сервера CoD (=адрес IP источника в исходных пакетах потока RTP); - когда предложением службы является расширенный элемент CoD с RET при использовании в определениях атрибутов для RET LMB, выражение «RET LMB» должно быть заменено на «RET», а выражение «original MC» — на выражение «original»	Обязательное, если доступна RET и не представлен ServerBasedEnhancementServiceInfo
ServerBasedEnhancedServiceInfo	Базовый тип dvb:ServerBasedEnhancedServiceInfo используют для сигнализации о наличии службы расширения на базовом сервере, который передает параметры, необходимые для использования этой службы	Обязательное, если доступен сервер FCC
@RTSPControlURL	Элемент должен быть идентичен описанному в таблице 5 с уточнением, что сеансы unicast-рассылки с использованием агрегатного URL RET разрешены при мультиплексировании сеанса	Опциональное
@Streaming	Атрибут должен указывать формат потоковой передачи, основанный на DVB, — StreamingType в соответствии с атрибутом с таким же именем, приведенным в таблице 5	Опциональное

Клиент RTSP DVB, поддерживающий повторную передачу (RET) или сервера FCC, должен понимать описания сеансов в формате SDP. Типом описания MIME SDP является application/sdp, а в описании SDP используется UTF-8. HNED может включать application/sdp в заголовке 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 должен быть text/parameters. Контент в заголовке Content-Encoding должен быть выполнен в формате UTF-8.

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

parameter = name : * (VCHAR) CR.

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

Наименование параметров метода GET_PARAMETER	Результат	Описание
Stream-state		Параметр извлекает текущее состояние потока. Возможные возвращаемые значения: проигрывание, пауза, остановка
Position	NPT	Параметр извлекает значение текущего времени в мультимедийном сеансе CoD. Position (позиция) указывает количество секунд от начала мультимедийного сеанса в формате NPT

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

Заголовок запроса RTSP	Указание по применению норм IETF (примечание 2)	Указание по применению норм DVB (примечание 2)	Уточнение по применению норм DVB (примечание 1)
Accept	О	М	Должен поддерживаться тип медиа: text/xml. Другие типы являются опциональными
Accept-Language	О	М	Уточнения отсутствуют
Bandwidth	О	М	Уточнения отсутствуют
Content-Encoding	Р	Р	Уточнения отсутствуют
Content-Length	Р	Р	Уточнения отсутствуют
Content-Type	Р	Р	Поддерживается тип контента: text/xml и text/parameters
Cseq	Р	Р	Порядковый номер должен отображаться 32-разрядным числом без знака
Timestamp	О	НП для LMB. Р для CoD	Уточнения отсутствуют
If-Modified-Since	О	М	Уточнения отсутствуют
Proxy-Required	Р	Р	Уточнения отсутствуют
Range	О	М	Уточнения отсутствуют
Require	Р	Р	Уточнения отсутствуют
Scale	О	НП для LMB. М для CoD	Необходимо поддерживать следующие масштабные коэффициенты: - 4 — быстрая перемотка назад; - 2 — перемотка назад; - 0 — пауза; - 1 — нормальное проигрывание; - 2 — перемотка вперед; - 4 — быстрая перемотка вперед
Session	Р	Р	Уточнения отсутствуют
Transport	Р	Р	HNED может предоставлять несколько вариантов транспорта, которые может выбирать сервер RTSP. HNED должен поддерживать транспорт RTP/AVP/UDP для потоковой передачи RTP. Он должен поддерживать MP2T/H2221/UDP и RAW/RAW/UDP для прямой потоковой передачи UDP. Параметры конфигурации транспорта должны быть предоставлены HNED для помощи в настройке посредников: unicast, multicast и client_port
User-Agent	О	М	Рекомендуется формат заголовка User-Agent: User-Agent = «User-Agent» «:» deviceID « HNED V1.0»
Примечания 1 Значения условных обозначений: М — обязательный, О — опциональный, Р — рекомендуемый, НП — неприменяемый. 2 В графе «Указания по применению IETF» представлены заголовки запросов, необходимые для поддержки в соответствии со спецификацией RTSP. В столбце «Указания по применению DVB» представлены заголовки запросов, которые должны поддерживаться в соответствии с требованиями DVB. 3 Допускается формирование HNED заголовков запросов RTSP, не приведенных в таблице 9.

Заголовок запроса RTSP	Указания по применению норм IETF	Указания по применению норм DVB	Уточнения по применению норм DVB
Allow	О	М	Уточнения отсутствуют
Connection	Р	Р	Уточнения отсутствуют
Content-Encoding	Р	Р	Уточнения отсутствуют
Content-Language	Р	Р	Уточнения отсутствуют
Content-Length	Р	Р	Уточнения отсутствуют
Content-Type	Р	Р	Уточнения отсутствуют
Cseq	Р	Р	Порядковый номер должен отображаться 32-разрядным числом без знака
Expires	О	М	Уточнения отсутствуют
Last-Modified	О	М	Уточнения отсутствуют
Location	О	О	Уточнения отсутствуют
Public	О	М	Уточнения отсутствуют
Range	О	О	Уточнения отсутствуют
RTP-Info	О	М для потока RTP. НП для потока UDP	Уточнения отсутствуют
Scale	О	НП для LMB. М для MBwTM и CoD	Следует поддерживать следующие масштабные коэффициенты: - 4 — быстрая перемотка назад; - 2 — перемотка назад; - 0 — пауза; - 1 — нормальное проигрывание; - 2 — перемотка вперед; - 4 — быстрая перемотка вперед
Retry-After	О	М	Уточнения отсутствуют
Server	О	М	Содержание этого заголовка не изменяется на сервере RTSP
Session	О	О	Предполагается, что сервер RTSP использует с этим заголовком параметр временной отметки
Transport	О	О	Транспортный поток RTP/AVP/UDP должен поддерживаться для потоковой передачи RTP. MP2T/H2221/UDP и RAW/RAW/UDP должны поддерживаться для прямой потоковой передачи UDP. HNED должен поддерживать следующие параметры конфигурации транспорта: unicast, multicast, destination, port, client_port, source и server_port. Эти параметры могут помочь посредникам в пересылке соответствующего мультимедийного потока
Timestamp	О	М	Уточнения отсутствуют
Unsupported	О	О	Уточнения отсутствуют
Примечания 1 Перечень условных обозначений: М — обязательный, О — опциональный, Р — рекомендуемый, НП — не применять. 2 В графе IETF представлены заголовки запросов, требуемые для поддержки в соответствии со спецификацией RTSP IETF: RFC 2326. В графах указания по DVB представлены заголовки запросов, которые должны поддерживаться для DVB. 3 HNED может генерировать заголовки запросов RTSP, не приведенные в таблице 9.

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

Код состояния	Описание
200	Запрос одобрен (Ok)
275	Запрос отправлен (Request forwarded)
300	Множественный выбор (Multiple Choices)
301	Изменился навсегда (Moved Permanently)
302	Изменился временно (Moved Temporarily)
304	Не изменился (Not Modified)
400	Неверный запрос (Bad Reques)
401	Неавторизованный (Unauthorized)
403	Запрещено (Forbidden)
404	Не обнаружена (Not Found)
405	Метод не разрешен (Method Not Allowed)
406	Недопустимо (Not Acceptable)
408	Окончание времени запроса (Time-out)
410	Завершен (Gone)
411	Требуется указать длину пакета (Length Required)
412	Условие не выполнено (Precondition Failed)
413	Размер объекта запроса превышает допустимый (Request Entity Too Larg)
414	Размер запроса URI превышает допустимый (Request-URI Too Large)
415	Неподдерживаемый тип медиа (Unsupported Media Type)
451	Параметр не понят (Parameter Not Understood)
453	Недостаточная величина пропускной способности (Not Enough Bandwidth)
454	Сеанс не найден (Session Not Found)
455	В таком состоянии метод недействителен (Method Not Valid in This State)
456	Поле заголовка не соответствует ресурсу (Header Field Not Valid for Resource)
457	Недопустимый диапазон (Invalid Range)
459	Агрегирование не разрешено (Aggregate operation not allowed)
460	Разрешено только агрегирование (Only aggregate operation allowed)
461	Неподдерживаемый транспорт (Unsupported transport)
462	Пункт назначения недостижим (Destination unreachable)
463	Требуется указать место назначения (Destination require)
500	Внутренняя ошибка сервера (Internal Server Error)
501	Не реализовано (Not Implemented)
503	Служба недоступна (Service Unavailable)
505	Версия RTSP не поддерживается (RTSP Version not supported)
551	Опция не поддерживается (Option not supported)
Примечания 1 Коды специфических ответов будут приниматься только со специфическим профилем. 2 HNED должно использовать наиболее значимую цифру кода состояния, чтобы определить его состоятельность в том случае, если данный код состояния неизвестен HNED.

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

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

Использование RTSP при multicast-рассылке дает участникам проверки возможность проверки характеристик мультимедийного сеанса. В частности, брандмауэры смогут установить используемый входящий порт, что позволяет открывать порты и выполнять любое необходимое перенаправление данных к портам. 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.

Методы RTSP	Направление передачи (примечание 1)	Указание по применению DVB (примечание 2)	Уточнение DVB по применению
ANNOUNCE	H \rightarrow S	О	Уточнения отсутствуют
ANNOUNCE	S \rightarrow H	Р	Multicast-сервер может использовать этот метод для асинхронного обновления служебной информации
DESCRIBE	H \rightarrow S	Р	Уточнения отсутствуют
GET_PARAMETER	H \rightarrow S	Р	Уточнения отсутствуют
GET_PARAMETER	S \rightarrow H	О	Уточнения отсутствуют
OPTIONS	H \rightarrow S	М	HNED может использовать этот метод для запроса сервера RTSP о тех методах, которые поддерживает сервер
PAUSE	H \rightarrow S	НП	Уточнения отсутствуют
PLAY	H \rightarrow S	М	Этот метод может быть использован для сигнализации посредникам о том, что вскоре начнется доставка multicast-рассылки. Заголовки запросов диапазона и частоты настройки не следует использовать (см. таблицы 9 и 10)
REDIRECT	S \rightarrow H	М	Multicast-сервер может использовать этот метод для балансировки нагрузки
SETUP	H \rightarrow S	М	Этот метод может быть использован посредниками для распределения ресурсов, открытия портов и т.д. Метод SETUP не повлияет на состояние режима multicast сервера RTSP. Сервер может использовать этот метод для подсчета количества «прослушивающих» HNED. Этот метод может быть применен посредниками для отмены результата выполнения метода SETUP, т.е. закрытия портов, удаления ресурсов и т.д.
TEARDOWN	H \rightarrow S	М	Этот метод может быть использован посредниками для отмены результата выполнения метода SETUP: закрытия портов, удаления ресурсов и т.д. Метод TEARDOWN не влияет на состояние режима multicast сервера RTSP. Сервер может использовать этот метод для подсчета количества «прослушивающих» HNED
Примечания 1 Перечень условных обозначений: М — обязательный, О — опциональный, Р — рекомендуемый, НП — не применять. 2 Методы RTSP RECORD и SET_PARAMETER не поддерживаются.

УДК 621.397.132.129: 006.354	ОКС 33.170
Ключевые слова: телевидение вещательное цифровое, DVB-IPTV, провайдер, транспортный поток MPEG-2, домашняя сеть, RTSP, HNED, вещание медиа, контент, SD&S, XML

---