Кратко

  • XR-блок — это показание конкретного источника о конкретном потоке в определённом окне и точке измерения; подробность не делает его нейтральной истиной обо всём сервисе.
  • Сетевая потеря, отбрасывание в приёмнике, сбой декодирования и восприятие человека — разные результаты. Отсутствующий блок, unavailable и измеренный ноль тоже нельзя объединять.

Четыре свидетеля одного разговора

Маршрут сообщает, что пакеты дошли до края сети. Приёмник сообщает, что часть поздних пакетов выброшена. Приложение показывает остановку декодера. Пользователь говорит, что звук исчезал. Эти показания не конкурируют за право быть единственной правдой. Они описывают разные механизмы.

RFC 3611 был опубликован в ноябре 2003 года как Standards Track. Он определил RTCP XR с packet type 207 и семь исходных блоков: Loss RLE, Duplicate RLE, Packet Receipt Times, Receiver Reference Time, DLRR, Statistics Summary и VoIP Metrics. Тип и длина позволяют пропускать неизвестные расширения. Значит, старый сборщик может корректно принять пакет и не понять часть содержания.

Заголовок XR несёт SSRC создателя отчёта. Многие блоки отдельно указывают SSRC измеряемого источника. Свидетель и предмет наблюдения — не одно поле. Если хранилище оставляет число и удаляет пару идентичностей, оно больше не знает, кто о ком сделал утверждение.

Ноль или несколько блоков допустимы. Нет блока — не значит нулевое значение. Возможны отсутствие запроса, согласования, реализации, доставки или доступа. Реестр IANA подтверждает назначение типа, но не наличие поддержки в конкретном сеансе.

У RFC 3611 есть три verified errata: исправлены имя параметра RTT получателя, синтаксис SDP без параметров и число в примере burst density. Версия интерпретации входит в происхождение результата.

Свидетель транспорта

Loss RLE сообщает события приёма и потери в границах последовательности. Он может использовать thinning, систематически сокращая наблюдения ради размера. Такой блок не является полным журналом, даже если полностью соответствует спецификации.

Packet Receipt Times добавляет времена приёма, но значение зависит от формата времени, последовательности и точки измерения. Receiver Reference Time вместе с DLRR позволяет вычислять round-trip time. DLRR отдельно не является односторонней задержкой и не доказывает путь медиапакетов.

Окно меняет смысл числа. RFC 6776 добавил расширенные границы последовательности и длительности. RFC 6792 разделил interval, cumulative и sampled. RFC 8861 предупреждает: XR и SR/RR в разных compound packets менее полезны, если их интервалы не синхронизированы. Время записи в базу не синхронизирует измерения.

Свидетель конечной системы

Потерянный пакет не пришёл в точку наблюдения. Discard мог прийти, но стать бесполезным из-за раннего или позднего момента и политики jitter buffer. Поздние RFC выделили отдельные блоки для счётчика discard, burst/gap discard, de-jitter buffer и Discard RLE.

Стабильный loss при растущем discard указывает на вариацию задержки, буфер, нагрузку и политику конечной системы. Растущий loss требует транспортного расследования. Смешивание двух величин создаёт удобную, но неверную виновность.

Burst/gap зависит от Gmin. RFC 3611 рекомендует 16 и требует постоянное ненулевое значение в сеансе. Одинаковая последовательность при другом пороге может дать другую классификацию. Метод должен храниться вместе с итогом.

Свидетель приложения и человека

R factor и MOS — оценки. Они могут учитывать loss, discard, burstiness и delay, но не становятся прямым ответом слушателя. Некоторые conversational metrics не определены для multicast conference и должны быть unavailable. Несколько полей кодируют unavailable значением 127.

Если система превращает 127 в плохой балл, отличный балл или ноль, она создаёт измерение. Нужны отдельные состояния: измеренный ноль, unavailable, не запрошено, не поддерживается, неизвестный тип и отфильтровано.

Даже корректный MOS не доказывает конкретное восприятие. Кодек, concealment, резервирование, сборка кадров, громкоговоритель и состояние приложения образуют цепочку после транспорта. Человеческий результат требует собственного свидетельства.

Наблюдение имеет цену и аудиторию

XR расходует RTCP bandwidth. Более крупные блоки могут увеличить средний интервал. Приложение ограничивает размер, thinning, круг отчётчиков и частоту. Больше полей иногда означает меньшую временную детализацию.

RFC 3611 прямо говорит о повышенной конфиденциальности. Пакетные следы могут раскрывать multicast topology, VoIP-показатели — персональную информацию. Шифрование и фильтрация защищают, но уменьшают monitoring information. Пустое поле после политики приватности — изменение видимости, не улучшение качества.

Нужен ограниченный сбор: подробности для уполномоченной команды инцидента, агрегаты для широкого управления, сроки хранения и явный код filtered. Скрытое нельзя преобразовать в ноль.

Реестр показаний вместо единого приговора

Минимальная запись хранит reporter SSRC, measured SSRC, сеанс, точку, блок, версию errata, тип окна, последовательности, длительность, часы, payload, thinning, алгоритм, единицы и sentinel. Она отдельно отмечает отсутствующее, неизвестное и отфильтрованное.

Затем четыре уровня связываются без слияния: транспорт, конечная система, приложение, человек. Работающий код создаёт наблюдение; стандарт делает его переносимым; управленческая система обязана сохранить границы.

RFC 3611 не вынес окончательный приговор качеству. Он дал нескольким свидетелям точные формы показаний. Ошибка начинается, когда их имена и окна удаляют ради одного удобного счёта.

Источники