Кратко

  • SSRC объединял один временной и порядковый контекст, но выбирался случайно и должен был быть уникален лишь внутри конкретного RTP-сеанса.
  • Обнаружив свой SSRC у другого источника, отправитель посылал RTCP BYE для старого значения, выбирал новый кандидат и проверял, что тот не занят.
  • Совпадение SSRC при другом транспортном адресе могло означать коллизию, петлю, смену NAT, перезапуск транслятора или мобильность; CNAME давал связь, но не удостоверял владельца.

Два источника не могли делить одно состояние воспроизведения

По SSRC получатель собирает последовательность пакетов, временные метки, RTCP-отчёты и состояние буфера. Если независимые отправители выбрали одно значение, чужие часы и потери попадают в одну историю. Коллизия способна выглядеть как необъяснимый скачок одного потока.

RFC 1889 в 1996 году определил 32-битный SSRC, не зависящий от сетевого адреса. Это было важно для multicast, микшеров и трансляторов. Централизованная выдача перед каждым участием противоречила бы свободному присоединению, поэтому источники выбирали случайные значения, предназначенные быть уникальными в RTP-сеансе.

Вероятность оставалась ненулевой. Готовность разрешить коллизию была обязательной частью реализации.

Случайность требовала правильного начала и запасного выхода

RFC 3550 оценивает вероятность хотя бы одной коллизии среди тысячи одновременно стартующих источников примерно как 10^-4. Для одного нового источника при тысяче уже уникальных значений пример даёт около 2×10^-7. Это расчёт, а не статистика эксплуатации.

Локальный IP-адрес не уникален между частными сетями и несколькими источниками одного хоста. Псевдослучайная функция без тщательной инициализации может выдать одинаковые ряды одновременно запущенным процессам. Новый участник также способен сначала послушать сеанс и отказаться от уже встреченного кандидата.

RTP не обещал невозможность события. Он уменьшал шанс и определял восстановление.

BYE относился к старому пространству синхронизации

Когда источник видит, что другой использует его SSRC, он должен отправить RTCP BYE со старым значением и выбрать другое случайное. Кандидат проверяется по таблице источников; занятое число отбрасывается.

Микрофон, камера или приложение могут продолжить работу. RFC 7656 позднее сформулировал границу: в каждый момент у RTP-потока один SSRC, однако со временем он может меняться, в том числе из-за коллизии.

Если интерфейс приравнял SSRC к человеку, он покажет ложный уход и приход. Если запись навсегда ключуется числом, один поток превратится в две сущности. BYE завершает метку, а не доказывает исчезновение участника.

Получатель выбирал рабочие пакеты, а не хозяина числа

Если сталкиваются два сторонних источника, получатель может сохранить пакеты одного и отбросить другого, различая транспортные адреса или CNAME. Самим источникам предстоит сменить значения.

Сохранение ранее установленной записи предотвращает смешивание, но не присваивает SSRC. Приход BYE или тайм-аут меняют имеющиеся свидетельства.

Для RTP и RTCP возможны разные исходные UDP-порты, поэтому алгоритм отдельно хранит первый адрес данных и первый адрес управления. За микшером адреса могут совпасть; два SDES-фрагмента с одним SSRC и разными CNAME тогда помогают обнаружить конфликт.

Возвращённый пакет выглядел как новая сторона

Петля пересылки приносит тот же SSRC с другого адреса. Первое несовпадение не объясняет, возник ли второй источник или вернулась копия собственного пакета.

RFC 3550 хранит временный список конфликтующих RTP- и RTCP-адресов. При первом конфликте собственного SSRC источник меняет число и запоминает путь. Повторные возвраты с того же адреса игнорируются. Иначе одна петля вызвала бы бесконечную цепь BYE и переименований.

Микшеры и трансляторы обязаны разрывать создаваемые ими петли. Но RFC 7667 показывает предел: детектор работает, только если SSRC и CSRC правильно сохранены в общей области. Независимые сеансы и некоторые переключающие топологии уничтожают эту видимость.

Новый адрес не сообщал единственную причину

RFC 3550 смягчил старое требование менять SSRC при любом изменении транспортного адреса. Мобильное приложение может законно продолжить поток с нового пути. Получатель может принять адрес, одновременно защищаясь от переключений при настоящей коллизии.

Перезапущенный транслятор с новым UDP-портом заставляет пересылаемые SSRC выглядеть петлёй до истечения состояния. RFC 5135 описывает NAT: новая привязка IP или порта к прежнему SSRC запускает обработку коллизии и может мешать диагностике и буферу джиттера.

Такой сигнал требует классификации. Он не доказывает атаку, намеренное дублирование или вину определённого устройства.

CNAME сохранял другую непрерывность

RFC 7022 разделяет сроки жизни. После коллизии или перезапуска SSRC может смениться, а RTCP CNAME способен связать endpoint и родственные потоки. Длительное значение помогает мониторингу; новое значение для каждого сеанса уменьшает межсеансовую корреляцию.

CNAME не является удостоверением. Участник выбирает его сам и может повторить чужое значение. Это средство сопоставления, не доказательство человека, организации или права передачи.

Современная сигнализация тоже не устраняет runtime-значения. RFC 8834 требует от WebRTC случайного назначения и разрешения по RFC 3550. Оба endpoint могут начать использовать новый номер до подтверждения сигнализации, а вспомогательные потоки повторной передачи добавляют не объявленные заранее SSRC.

Источники и пределы

Начальная модель задана RFC 1889, зрелый алгоритм — RFC 3550. NAT ограничен RFC 5135, CNAME — RFC 7022, семантика потока — RFC 7656, топологии — RFC 7667, WebRTC — RFC 8834. Документы не доказывают текущую частоту, соответствие продукта, личность, подлинность контента или успешное воспроизведение.