ГОСТ Р 54994—2012
тификатора представлен в стандарте IETF [25] (приложение 6). В том случае, если источник синхрони-
зации изменяет свой исходный транспортный адрес, он должен также выбрать новый идентификатор
SSRC;
- Contributing Source (CSRC): поле «Список идентификаторов CSRC» (длина поля переменная,
включает от 0 до 15 субполей (элементов), по 32 бита. Поле «Список идентификаторов CSRC» содер-
жит перечень источников потоков RTP. Идентификаторы CSRC вставлены миксером, используя иден-
тификаторы SSRC тех источников, которые участвовали в создании данного пакета RTP. Поля CSRC
являются опциональными. Они должны игнорироваться оконечным устройством.
7.2.2.2 Управляющий протокол RTCP используется совместно с протоколом RTP для периодиче-
ской передачи пакетов управления. Протокол RTCP выполняет четыре основные функции:
- обеспечивает обратную связь между источником данных и получателем данных для оценки ка-
чества распределения данных;
- поддерживает устойчивый идентификатор источника данных RTP на транспортном уровне, ис-
пользуя каноническое имя CNAME;
- позволяет масштабировать число участников обмена протоколом RTP регулированием частоты
передачи пакетов в зависимости от числа участников;
- позволяет формировать информацию для управления сеансом, например передачей идентифи-
каторов участников процесса распределения данных.
Для передачи информации управления предусмотрены следующие типы пакетов RTCP:
- SR — отчет отправителя, содержит статистическую информацию о передаче и приеме участни-
ков, которые являются активными отправителями;
- RR — отчет получателя, содержит статистическую информацию о приеме от участников, кото-
рые не являются активными отправителями;
- SDES — элементы описания источника, включая CNAME;
- BYE — указатель завершения соединения.
В контексте задач передачи транспортных потоков служб DVB по сетям с IP протоколами исполь-
зование пакетов SR и RR является обязательным.
В том случае, когда HNED должно декодировать разные транспортные потоки одновременно (на-
пример, «картинка в картинке»), должна обеспечиваться синхронизация этих транспортных потоков,
учитывая, что некоторые потоки синхронизированы от независимых часов с произвольными значения-
ми времени. С этой целью в отчете отправителя передаются метки времени RTP и метки времени NTP.
Метки времени RTPопределяются источником часов RTP. Метки времени NTPопределяются временем
по сетевому протоколу времени (NTP) согласно IETF [29]. Эти метки в отчете отправителя позволяют
HNED вычислять необходимое смещение времени транспортных потоков, что бы обеспечить их син-
хронизацию.
7.2.3 Инкапсуляция ТП непосредственно (прямая инкапсуляция) в пакеты прямого пользо-
вательского протокола дейтаграммы (UDP)
В том случае, если сети IP могут обеспечить малые значения потерь пакетов, малые значения
дрожания пакетов и отсутствие изменений порядка следования пакетов, транспортный поток может
инкапсулироваться непосредственно в пакеты протокола UDP в соответствии с Рекомендацией ITU-T
[27]. Формат пакета IP (IPv4) UDP показан на рисунке 12.
Рисунок 12 — Формат пакета IP (IPv4) UDP
27
Каждый пакет IP включает в себя заголовок IP, заголовок UDP и целое число пакетов n по 188 бай-
тов транспортного потока MPEG 2. Количество пакетов транспортного потока, содержащихся в каждом
пакете UDP, определяется полем длины в заголовке UDP.
Пакеты нескольких транспортных потоков, которые могут инкапсулироваться в каждом пакете IP,
ограничены максимальным размером дейтаграммы MTU (65 535 байтов для IPv4). Не должно допу-
скаться превышение MTU сети. Превышение MTU сети приведет к фрагментации IP, которая значи-
тельно увеличивает эффективную частоту потерь сети. Это обусловлено тем, что при потере одного
фрагмента остающиеся фрагменты должны быть отброшены приемником. Это создает дополнитель-