ГОСТ Р 59801—2021
О
к
ончание таблицы 2
Наименование
Определение
Service
Имя службы. Рекомендуется обеспечивать соответствие правилам для
имен DNS в Интернете
ServicelD
Servicejd, как определено в ГОСТ Р 55697. Это значение должно быть де
сятичным (см. примечание 2)
ServiceType
Шестнадцатеричное восьмибитовое значение (см. Hexadecimal&bit). кодиру
ющее type службы
Используется ли RTP со значением rtp или потоковое UDP со значением udp
StreamingType
TransportProtocolTyре
Строка, которая гложет быть использована для сигнализации типа транс
порта и типа FEC
Идентификатор Тransport stream
_
id согласно ГОСТ Р 55697
TSId
Usage
Указывает на используемую службу IPService. Этот элемент является стро
кой и может быть Main. SD. HD. PiP. FCC. 3D или DSMService. Это означает,
что другие службы IP поддерживают один и тот же контент и что они будут
отображаться как субслужбы IP этой службы. Значение DSMService являет
ся обязательным для тех служб, которые являются частью группы DSM и где
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
tvaionDemandProgram.
Для служб CoD и MBwTM при описании сеанса должен быть использован URL RTSP. Этот URL
RTSP может быть доступен:
7