ГОСТ Р 54994—2012
44
На рисунке В.3 показаны элементы и коммуникационные потоки, образующие архитектуру RET, для службы
вещания медиа (LMB) при восстановлении потерянных пакетов для служб LMB для случая многоадресной переда-чи
с использованием многоадресного метода восстановления служб LMB, когда потеря пакета происходит в потоке от
сервера LMB RET к совокупности HNED (этап 1 на рисунке В.3).
Сервер LMB RET не нуждается в сообщении FB RTCP от устройств HNED, так как потерю пакета он обнару-
живает сам (с помощью клиента LMB медиа в своем составе). Сервер LMB RET, обнаружив потерю пакета, пере-
дает на закрепленные за ним устройства HNED запрос с предложением не передавать сообщение FB через канал
RTCP. Передача этого запроса выполняется сообщением RTCP FF при многоадресной передаче (этап 2 на рисунке
В.3), что позволяет предотвращать «штормы NACK». По запросу RTCP FB, передаваемому от клиента RET, нахо-
дящемуся в составе сервера LMB RET, к серверу RET в составе головной станции (этап III), RET сервер в составе
головной станции передает на сервер LMB RET потерянный пакет протоколом RTP RET (этап III). Этот механизм
предполагает, что клиенты RET при обнаружении потери пакета формирование запроса RET выполняют посред-
ством рандомизации времени ожидания (IETF [47]) или применением более усовершенствованного механизма в
соответствии с приложением В, В.6.3. В связи с тем, что SSRC, используемые сервером LMB RET, могут отличать-ся
от SSRC исходного сеанса многоадресной передачи, допускаются отклонения правил при мультиплексировании
сеанса сервером LMB RET от рекомендаций, определенных в IETF [48]. Детализация правил формирования со-
общений LMB RET должна быть в соответствии с ETSI [12] (приложение F, F.3.2).
В.3 Сигнализация RTCP для HNED, поддерживающих повторную передачу RET
В.3.1 Общие положения
Отчеты RTCP устройств HNED для RET, включая службы LMB, всегда передаются к серверу LMB RET, ко-
торый является целью RTCP в одноадресном режиме. Сервер LMB RET никогда не должен возвращать отчеты
к устройствам HNED, кроме тех случаев, когда сервер LMB RET передает сообщение FF RTCP (приложение В,
В.4.2). Ниже описываются параметры отчетов RTCP, которые могут быть переданы устройствам HNED и должны
поддерживаться устройствами HNED.
В.3.2 Сообщение RTCP FB
Для запроса повторной передачи HNED использует протокол RTCP. Формат универсального сообщения FB
транспортного уровня NACK, как определено в IETF [47], используется для запросов повторной передачи пакетов,
как показано на рисунке В.4.
Рисунок В.4 — Формат пакета сообщения FB RTCP
Семантика основных полей пакета сообщения FB RTCP:
- поле «FMT» (Feedback Message Type), 5 битов. Идентифицирует тип сообщения FB и интерпретируется в
соответствии с типом (транспортный уровень, полезная нагрузка — определенная, или полезная нагрузка обрат-
ной связи прикладного уровня). Значения для каждого из трех типов обратной связи определены в соответствую-
щих разделах IETF [47]. В случае передачи сообщения типа RTCP FB в поле должна быть установлена «1»;
- поле «PT» (Payload Type): 8 битов. Идентифицирует тип полезной нагрузки. В случае «RTPFB» в поле уста-
навливается величина 205;
- поле «Feedback Control Information» (FCI): n*32 бита. Содержит информацию управления обратной связи.
Поле FCI в сообщении FB RTCPможет содержать одну и более универсальных квитанций NACK. Сообщения RTCP
от HNED всегда передаются в сети одноадресно, в том числе и для службы LMB. Транспортный адрес для обмена
сообщениями RTCP (IP-адрес назначения и порт назначения UDP) получен HNED методами конфигурации, пред-
ставленными в приложении В, В.5.
В поле «SSRC отправителя пакетов» в сообщении FB RTCP использовано значение SSRC HNED в исходном
сеансе RTP для служб LMB.
Поле «SSRC источника медиа» содержит SSRC головного узла, используемого для службы LMB, и для кото-
рого сообщение FB RTCP сообщает о потере пакетов.
Формат универсальной квитанции NACK в поле FCI в сообщении FB RTCP показан на рисунке В.5.