Кратко

  • RFC 3605 ввёл медиa-атрибут a=rtcp, чтобы явно указывать порт и при необходимости адрес RTCP, когда NAT разрушает прежнее правило соседних портов RTP и RTCP.
  • Объявленный endpoint, доставленный пакет и валидный отчёт — разные свидетельства. Даже отчёт относится к определённым источникам и интервалу и сам по себе не доказывает качество для пользователя или правильность решения автоматики.

Инцидент мог бы закончиться слишком рано. В системе нашёлся валидный receiver report, значит команда отметила канал управления как исправный. Но отчёт покрывал один источник и короткий интервал до переключения сети. Жалоба пользователя относилась к обратному направлению после переключения. Правильный пакет оказался настоящим и одновременно недостаточным для сделанного вывода.

RFC 3605, опубликованный в октябре 2003 года как Standards Track, решал более раннюю задачу. RTP обычно передавал медиа через один UDP-порт, а RTCP использовал следующий нечётный. SDP сообщал медиапорт, после чего приложение вычисляло порт управления.

Port-mapping NAT мог уничтожить порядок и чётность. Два соседних внутренних порта превращались во внешние номера без видимой связи. При пуле публичных адресов RTP и RTCP могли выйти даже через разные адреса. Формула «плюс один» переставала описывать фактическую топологию.

RFC определил a=rtcp: с номером порта и необязательными типом сети, типом адреса и адресом соединения. Атрибут предназначен для уровня медиа и не должен применяться ко всей сессии. Неизвестную после трансляции координату стало возможно сообщить явно.

Явность устраняет ошибочный вывод, но не создаёт работающий путь. Генератор может записать строку до открытия сокета. Парсер может принять её, а модуль отправки — не использовать. Offer/Answer может завершиться, хотя фильтр блокирует пакеты. Запись в SDP — это утверждение конфигурации с определённым автором и временем.

Форма атрибута сохраняет особый режим совместимости. Изменённую медиастроку старое приложение могло бы полностью отвергнуть. Неизвестный атрибут оно просто игнорирует. Поэтому старый peer способен принимать RTP и одновременно не посылать RTCP на указанный endpoint. Медиа и управление расходятся без полного отказа сессии.

Отсюда следует первая дисциплина: слышимый звук не является доказательством feedback path. Краткая проверка может показать приемлемое медиа, пока система не получает данные, необходимые для оценки потерь, синхронизации и источников. Один зелёный статус скрывает разные направления и разные плоскости.

RFC 3605 описывает возможное обнаружение внешних координат через STUN. Хост выделяет два UDP-порта, отправляет с каждого серверу, а сервер возвращает увиденные адреса и порты источника. Так появляются значения, которые можно поместить в SDP.

Ограничение указано рядом: алгоритм предполагает одинаковую трансляцию к STUN-серверу и будущему SDP-peer. Нет гарантии, что все NAT обладают этим свойством. Наблюдение одного сервера в момент T не резервирует тот же tuple для другого адресата в момент T+1.

Поэтому доказательство маппинга должно включать наблюдателя, время, внутренний socket, интерфейс, внешний tuple, предполагаемого peer и возраст значения при первом использовании. Если оставить только порт, невозможно понять, для какого направления и эпохи он был верен.

Далее нужны отдельные квитанции передачи. Счётчик приложения говорит о передаче байтов локальному socket. Захват на выходном интерфейсе показывает пакет там. Захват на удалённой границе подтверждает прибытие к этой точке. RTCP-парсер подтверждает структуру и связь с сессией. Система хранения подтверждает, что данные доступны анализу.

RFC 3550 задаёт RTCP функции обратной связи о приёме, идентификации участников, синхронизации и управления. Полученный отчёт связан с reporting source, SSRC и интервалом. Его числа нельзя распространять на направление, источник или время, которых в нём нет.

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

Отсутствие отчёта ещё менее определённо. Peer мог игнорировать a=rtcp, использовать соседний порт, договориться о multiplexing, потерять NAT-состояние или столкнуться с фильтром. Возможно, интервал отчётности ещё не наступил. Пакет мог прийти, а pipeline — не сохранить его. Пустая таблица не содержит измерение нулевой потери.

RFC 5761 позднее определил согласованное объединение RTP и RTCP на одном порту. RFC 8859 классифицирует rtcp как транспортный атрибут при анализе SDP multiplexing. Реестр IANA продолжает содержать этот медиа-атрибут. Значит, операционная запись должна хранить реально согласованный режим, а не восстанавливать его из текущего default.

RFC 5389 ограничил роль STUN ролью инструмента, а не полного решения обхода NAT. Это правильная модель для всей цепочки. Discovery наблюдает. SDP объявляет. Runtime открывает и отправляет. Сеть доставляет. RTCP сообщает. Аналитика интерпретирует. Каждая стадия должна оставаться в границах собственного доказательства.

Целостность сигнализации тоже отвечает лишь на один вопрос. RFC 3605 отмечает, что переписывание SDP позволяет перенаправить RTCP-часть обмена. Защита от изменения подтверждает происхождение и неизменность строки. Она не продлевает mapping, не открывает порт и не доказывает полномочия получателя.

Полная модель сохраняет исходный SDP и hash, результат парсинга, offer/answer, режим раздельных или общих портов, bind сокета, наблюдение NAT, объявленный tuple и проверку целостности. Затем отдельно фиксирует первую отправку, удалённое прибытие, валидный RTCP, первый отчёт, его источники и интервал, ingestion, правило анализа, решение и проверку эффекта.

Особенно важно связывать решение с конкретным набором отчётов. Изменение bitrate, сигнал о нарушении SLA или закрытие инцидента должны иметь список входных свидетельств и время. Иначе настоящий отчёт легко превращается в ложное обобщение, а более поздняя коррекция не может найти решения, которые он затронул.

RFC 3605 не утверждал, что строка a=rtcp является самим контролем. Он дал минимальный способ выразить координату, которую NAT сделал непредсказуемой. Реализация должна построить путь, мониторинг — подтвердить его, а руководитель решения — не приписывать отчёту больше, чем он измерил.