agosty.ru33. ТЕЛЕКОММУНИКАЦИИ.АУДИО-И ВИДЕОТЕХНИКА33.170. Теле- и радиовещание

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

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

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

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

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

ГОСТР

59801-


2021



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

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

ФЕДЕРАЦИИ

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

Расширенные технические требования к передаче транспортных потоков служб 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);

ASM BMFF СА CDS Cl CoD CP CRC

DLNA

DNS DSM DTD DVB-HN DVB-IPTV DVB-S2

DVBSTP FCC FLUTE

FUS

GET

GZIP

HN HTTP INT IPv4 IPv6 IPI IPTV LMB MAC MBwTM middleware MIME MLD MPD POST


любой источник 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

Наименование полей

Определение полей

Указание применения

RTSPURLType (контент расширенного типа)

Поле содержит URL. пользуясь которым, можно получить доступ к описанию службы. Когда служба состоит из одного потока, для управления этим потоком URL используется во всех сообщениях RTSP (SETUP. PLAY. TEARDOWN и т. д.). Формат соответствует определениям, приведенным в таблице 2

Обязательное, если SP решил использовать RTSP

RTSPControlURL

URL используют в сообщениях RTSP (SETUP. PLAY. PAUSE и т. д.) для управления основным аудио-, ви-деопотоком. когда для этого основного аудио-, виде-опотока применяют AL-FEC или RET

Опциональное, но обязательное, если RTSP используют с RET или FEC

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

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

Наименование

Определение

BroadcastSystemType

Идентификатор системы вещания. Этот тип может принимать любое из значений (ANALOG. ID.DVB.C. ID_DVB_S ID.DVB Т. ID.DVB С2. ID.DVB S2. ID.DVB.T2. ID.ISDB.C, ID.ISDB.S. ID.ISDB.T, ID.ATSC.T»)

CPSystemIDType

Идентификатор системы защиты контента от копирования (ID System СР)

CPSystemSRMID

Идентификатор SRM System СР системы защиты контента

DomainType

Описывает тип «domain пате» (доменное имя)

Enhance menlServiceType

Содержит список серверов расширения служб LMB. Нормированы только RET и FCC

Genre

Описывает жанр контента, который кодируется числом в диапазоне значений от Одо 15. указанном в поле conlent.nibble.level.l дескриптора content, descriptor/

Hexadecimal3bit

3-битовое число, представленное одной шестнадцатеричной цифрой

HexadeamaMbit

4-битоеое. представленное шестнадцатеричной цифрой

HexadedmalSbil

8-битовое число, представленное как одна или две шестнадцатеричные цифры

Hexadecimall 6bit

16-битовое число, представленное от одной до четырех шестнадцатеричных цифр

Hexadecimal32bit

32-битовое число, представленное в виде восьми шестнадцатеричных цифр

lnlege<6bit

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

Трехбуквенный код языка. Может быть использован для переноса специальных значений

OrigNetld

Десятичный идентификатор original.network.id

PrimarySISource

Указывает, содержится ли основная информация SI в XML. где этот тип принимает значение XML. или в потоке, где этот тип принимает значение Stream

PulURL

Используется для указания полного URL. из которого можно извлечь информацию о механизме SD&S. включая схему протокола, полномочия и путь. HNED должно добавить к этому запрос URL

RTSP

Используется, если необходим URL RTSP

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

Наименование

Определение

Service

Имя службы. Рекомендуется обеспечивать соответствие правилам для имен DNS в Интернете

ServicelD

Servicejd. как определено в ГОСТ Р 55697. Эго значение должно быть десятичным (см. примечание 2)

ServiceType

Шестнадцатеричное еосьмибитоеое значение (см. HexadecimalSbil). кодирующее type службы

StreamingType

Используется ли RTP со значением rtp или потоковое UDP со значением udp

TransportPratocolType

Строка, которая может быть использована для сигнализации типа транспорта и типа FEC

TSW

Идентификатор Transport_stream_id согласно ГОСТ Р 55697

Usage

Указывает на используемую службу IPService. Этот элемент является строкой и может быть Main. SO. HD. PiP. FCC. 30 или DSMService. Это означает, что другие службы IP поддерживают один и тот же контент и что они будут отображаться как субслужбы IP этой службы. Значение DSMSerwce является обязательным для тех служб, которые являются частью группы OSM и где DSM активирован в HNED

Version

Число, передающее версию таблицы или записи. Это значение будет увеличиваться при изменении таблицы или записи по модулю 256. Это значение должно быть в шестнадцатеричном формате

Примечания

  • 1 Регулярное выражение RegEx, применяемое в качестве соответствия шаблону для сопоставления адреса IPv6 е определении IPType в настоящей таблице, способно проверять параметры для 128-битоэой структуры.

  • 2 ServicelD не следует путать с текстовым идентификатором службы по определению в ГОСТ Р 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

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

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

Метсо RTSP

Направление передачи

Применение нормы IETF

Применение нормы DVB

ANNOUNCE

H-S

Допускается

Допускается

ANNOUNCE

S—H

Допускается

Обязательно

DESCRIBE

H-S

Обязательно

Обязательно

GET.PARAMETER

H—S

Допускается

Обязательно

GET_PARAMETER

S—H

Допускается

Допускается

OPTIONS

H—S

Будет применяться

Будет применяться

OPTIONS

S—H

Допускается

Допускается

PAUSE

H—s

Обязательно

Будет применяться

PLAY

H-S

Будет применяться

Будет применяться

REDIRECT

S-H

Допускается

Будет применяться

SETUP

H—s

Будет применяться

Будет применяться

TEARDOWN

H—S

Будет применяться

Будет применяться

Примечание— H—HNED. S — сервер.

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

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

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

Метод RTSP

Направление передачи

Применение нормы IETF

Применение нормы DVB

ANNOUNCE

H—S

Опциональное

Опциональное

ANNOUNCE

S-H

Опциональное

Рекомендуемое

DESCRIBE

H—S

Рекомендуемое

Рекомендуемое

GET.PARAMETER

H—S

Опциональное

Рекомендуемое

GET.PARAMETER

S—H

Опциональное

Опциональное

OPTIONS

H—S

Обязательное

Обязательное

OPTIONS

S—H

Опциональное

Опциональное

PAUSE

H—S

Рекомендуемое

Обязательное

PLAY

H-S

Обязательное

Обязательное

REDIRECT

S—H

Опциональное

Обязательное

SETUP

H-S

Обязательное

Обязательное

TEARDOWN

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

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

Наименование

Описание

Указание применения

ContentDe sen ption

Описание элемента с испогъзова-нием формата TVAnylime

Обязательное

FECInfo

Подробная информация о FEC доступна для этого элемента контента (при его наличии)

Обязательное, если FEC доступен для этого элемента

RETInfo

Сведения о RET доступны для этого элемента контента

Обязательное, если для этого элемента доступен RET, a ServerError-EnhancementServicelnfo отсутствует

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

Наименование

Описание

Указание применения

ServerSasedEnhancementServicelnfo

Сведения о службе расширения на базовом сервере, доступные для этого элемента контента

Обязательное, если для этого элемента доступен сервер FCC

RTSPControlURL

URL RTSP. используемый для управления этим элементом контента

Обязательное, если для RTSP используется отдельный controlURL

Streaming

Атрибут должен указывать формат потоковой передачи (при его наличии)

Опционально

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

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

Наименование

Определение семантики

Укамнмв применения

ContentDescripbon

Использует тип Iva — 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-clienk

  • - атрибут RTCPReporbng @ Destination Address в контексте RET CoD переопределяется таким образом, что, если указан IF-едрес. на который HNED отправляет свои отчеты RTCP. это значение должно соответствовать адресу IP сервера CoD (=адрес IP источника в исходных пакетах потока RTP):

  • - когда предложением службы является расширенный элемент CoD с RET при использовании в определениях атрибутов для RET LMB. выражение «RET LMB» должно быть заменено на «RET», а выражение «original МС» — на выражение «original»

Обязательное, если доступна RET и не представлен ServerBased-Enhancement-ServiceInfo

ServerBasedEnhanoedServtcelnfo

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

Обязательное, если доступен сервер FCC

©RTSPControlURL

Элемент должен быть идентичен описанному в таблице 5 с уточнением, что сеансы unicast-рассылки с использованием агрегатного URL RET разрешены при мультиплексировании сеанса

Опциональное

©Streaming

Атрибут должен указывать формат потоковой передачи, основанный на DVB. — StreamingType в соответствии с атрибутом с таким же именем, приведенным в таблице 5

Опциональное

Клиент 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

Наименование параметров метода GET.PARAMETER

Результат

Описание

Stream-state

«current stream state»

Параметр извлекает текущее состояние потока. Возможные возвращаемые значения: проигрывание, пауза. остановка

Position

NPT

Параметр извлекает значение текущего времени в мультимедийном сеансе CoD. Position (позиция) указывает количество секунд от начала мультимедийного сеанса в формате NPT

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

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

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

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

Заголовок запроса RTSP

Указание no применению норм IETF (примечание 2}

Указание по применению норм OVB (примечание 2}

Уточнение по применению коры OVB (примечание 1)

Accept

О

М

Должен поддерживаться тип медиа: text/ xml. Другие типы являются олциональньши

Accept-Language

О

М

Уточнения отсутствуют

Bandwidth

О

М

Уточнения отсутствуют

Content-Encoding

Р

Р

Уточнения отсутствуют

Content-Length

Р

Р

Уточнения отсутствуют

Content-Type

Р

Р

Поддерживается тип контента: text/xml и texl/parameters

Cseq

Р

Р

Порядковый номер должен отображаться 32-разрядным числом без знака

Timestamp

О

НП для LMB. Р для СоО

Уточнения отсутствуют

If-Modified-Since

о

М

Уточнения отсутствуют

Proxy-Required

р

Р

Уточнения отсутствуют

Range

о

М

Уточнения отсутствуют

Require

р

Р

Уточнения отсутствуют

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

Заголовок запроса RTSP

Указание по применению норм t£TF (примечание 2)

Указание по применению норм DVB (примечание 2)

Уточнение по применению норм DVB (примечание 1)

Scale

О

НП для LMB. М для СоО

Необходимо поддерживать следующие масштабные коэффициенты: - 4 — быстрая перемотка назад:

  • - 2 — перемотка назад;

  • - 0 — пауза:

  • - 1 — нормальное проигрывание:

  • - 2 — перемотка вперед:

  • • 4 — быстрая перемотка вперед

Session

Р

Р

Уточнения отсутствуют

Transport

Р

Р

HNED может предоставлять несколько вариантов транспорта, которые может выбирать сервер RTSP. HNED должен поддерживать транспорт RTP/AVPAJDP для потоковой передачи RTP. Он должен поддерживать MP2T/H2221/UDP и RAW/RAW/ UDP для прямой потоковой передачи UDP. Параметры конфигурации транспорта должны быть предоставлены HNED для помощи в настройке посредников: unicast, multicast и dient_port

User-Agent

О

М

Рекомендуется формат заголовка User-Agent: User-Agent = 4Jser-Agent* Т devrcelD ’ HNED V1.0*

Примечания

  • 1 Значения условных обозначений: М — обязательный. О — опциональный. Р — рекомендуемый, НП — непримвняемый.

  • 2 В графе «Указания по применению IETF» представлены заголовки запросов, необходимые для поддержки в соответствии со спецификацией RTSP. В столбце «Указания по применению DVB» представлены заголовки запросов. которые должны поддерживаться в соответствии с требованиями DVB.

  • 3 Допускается формирование HNED заголовков запросов RTSP, не приведенных в таблице 9.

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

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

Заголовок запроса RTSP

Указания no применению поры IETF

Указания по применению норм DV8

Уточнения по применению норы OVB

Allow

О

М

Уточнения отсутствуют

Connection

P

Р

Уточнения отсутствуют

Content-Encoding

P

Р

Уточнения отсутствуют

Content-Language

P

Р

Уточнения отсутствуют

Content-Length

P

Р

Уточнения отсутствуют

Content-Type

P

Р

Уточнения отсутствуют

Cseq

P

Р

Порядковый номер должен отображаться 32-разрядным числом без знака

Expires

О

М

Уточнения отсутствуют

Last-Modified

0

м

Уточнения отсутствуют

Location

0

о

Уточнения отсутствуют

Public

о

м

Уточнения отсутствуют

Range

о

о

Уточнения отсутствуют

RTP-Info

О

М для потока RTP. НП для потока UDP

Уточнения отсутствуют

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

Заголовок запроса RTSP

Указания по применению норм IETF

Указания по применению норм DVB

Уточнения по применению норм DV8

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. 8 графах указания по DVB представлены заголовки запросов, которые должны поддерживаться для DVB.

  • 3 HNED может генерировать заголовки запросов RTSP. не приведенные в таблице 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 а ответах на запросы

Код состояния

Описание

200

Запрос одобрен (Ок)

275

Запрос отправлен (Request forwarded)

300

Множественный выбор (Multiple Choices)

301

Изменился навсегда (Moved Permanently)

302

Изменился временно (Moved Temporarily)

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

Код состояния

Описание

304

Не изменился (Not Modified)

400

Неверный запрос (Bad Reques)

401

Неавториэованный (Unauthorized)

403

Запрещено (Forbidden)

404

Не обнаружена (Not Found)

405

Метод не разрешен (Method Not Attowed)

406

Недопустимо (Not Acceptable)

408

Окончание времени запроса (Time-out)

410

Завершен (Gone)

411

Требуется указать длину пакета (Length Required)

412

Условие не выполнено (Precondition Faded)

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

Недопустимый диапазон (InvaM 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 при 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

Методы RTSP

Направление передачи {примечание t>

Указание по применению DVB (примечание 2)

Уточнение DV8 по применению

ANNOUNCE

Н—S

О

Уточнения отсутствуют

ANNOUNCE

S—Н

Р

Multicast-сервер может использовать этот метод для асинхронного обновления служебной информации

DESCRIBE

Н—S

Р

Уточнения отсутствуют

GET.PARAMETER

H—S

Р

Уточнения отсутствуют

GET.PARAMETER

S—Н

О

Уточнения отсутствуют

OPTIONS

H—S

м

HNEO может использовать этот метод для запроса сервера RTSP о тех методах. которые поддерживает сервер

PAUSE

Н—S

НП

Уточнения отсутствуют

PLAY

Н—S

м

Этот метод может быть использован для сигнализации посредникам о том. что вскоре начнется доставка multicast-рассылки. Заголовки запросов диапазона и частоты настройки не следует использовать (см. таблицы 9 и 10)

REDIRECT

S—Н

м

Multicast-сервер может использовать этот метод для балансировки нагрузки

SETUP

Н—•S

м

Этот метод может быть использован посредниками для распределения ресурсов. открытия портов и т. д.

Метод SETUP не повлияет на состояние режима multicast сервера RTSP. Сервер может использовать этот метод для подсчета количества «прослушивающих» HNED.

Этот метод может быть применен посредниками для отмены результата выполнения метода SETUP, т. е. закрытия портов, удаления ресурсов и т. д.

TEARDOWN

H—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

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

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

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

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

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