Zusammenfassung

  • Ein SSRC fasste einen Zeit- und Sequenzraum zusammen, war aber nur eine zufällig gewählte, innerhalb einer RTP-Sitzung eindeutige Kennung.
  • Erkannte eine Quelle ihr eigenes SSRC bei einer anderen Quelle, sendete sie RTCP BYE für den alten Wert, wählte einen neuen Kandidaten und prüfte ihn gegen bekannte Quellen.
  • Dieselbe Kennung von einer anderen Transportadresse konnte Kollision, Schleife, NAT-Neuzuordnung, Translator-Neustart oder Mobilität bedeuten; CNAME half bei der Kontinuität, nicht bei der Authentisierung.

Das SSRC ordnete Wiedergabestatus, nicht Menschen

Ein Empfänger führt unter dem SSRC Sequenznummern, Zeitstempel, Empfangsberichte und Wiedergabezustand. Zwei unabhängige Sender mit derselben Kennung lassen fremde Uhren und Verlustverläufe wie einen fehlerhaften Stream aussehen. Die Kollision beschädigt damit die Zuordnung der Beobachtungen.

RFC 1889 definierte 1996 einen zufällig gewählten 32-Bit-Wert, der nicht von der Netzadresse abhängt. Multicast, Mixer und Translator ließen eine Adresse als universellen Quellnamen ungeeignet erscheinen. Eine zentrale Vergabe vor jedem Konferenzbeitrag hätte zudem die lockere Mitgliedschaft verändert.

Die dezentrale Wahl setzte voraus, dass jede Implementierung auch das seltene Scheitern beherrschte.

Der Zufall brauchte eine Rückfallregel

RFC 3550 schätzt für tausend gleichzeitig startende Quellen eine Kollisionswahrscheinlichkeit von ungefähr 10^-4. Tritt eine neue Quelle zu tausend bereits eindeutigen Werten, liegt das Beispiel bei etwa 2×10^-7. Das sind Modellwerte, keine Messung aktueller Sitzungen.

Eine lokale IP-Adresse reicht nicht: private Adressräume treffen hinter Übersetzern aufeinander, und ein Host kann mehrere Quellen erzeugen. Ein schlecht initialisierter Zufallsgenerator wiederholt bei gleichzeitigem Start womöglich dieselbe Folge. Vor dem ersten Senden kann eine Quelle die Sitzung beobachten und einen bereits verwendeten Kandidaten verwerfen.

RTP versprach also keine unfehlbare Zahl. Es verband Sorgfalt bei der Wahl mit einer interoperablen Reparatur.

BYE beendete die Kennung, nicht zwingend die Übertragung

Entdeckt eine Quelle ihr eigenes SSRC bei einer anderen, muss sie für den alten Wert ein RTCP-BYE-Paket senden und einen neuen Zufallswert wählen. Der Kandidat wird in der Quelltabelle nachgeschlagen; ist er belegt, wird erneut gewählt.

Kamera, Mikrofon oder Anwendung dürfen weiterlaufen. RFC 7656 formuliert die zeitliche Grenze: Ein RTP-Stream besitzt zu einem Zeitpunkt genau ein SSRC, kann es aber ändern; eine Kollision ist ein gültiger Anlass.

Wer SSRC als dauerhafte Person speichert, erzeugt einen falschen Austritt und Eintritt. Wer Aufzeichnungen allein danach schneidet, teilt einen Stream in zwei vermeintliche Subjekte. Das Protokoll verleiht dem Wert diese Dauer nicht.

Der Empfänger durfte Pakete auswählen, nicht Eigentum vergeben

Bei einer Kollision zweier fremder Quellen kann ein Empfänger anhand verschiedener Transportadressen oder CNAMEs eine Quelle behalten und die andere verwerfen. Die betroffenen Sender sollen den Konflikt selbst auflösen.

Der bereits etablierte Pfad erhält damit vorläufige Kontinuität, kein Recht am Wert. BYE oder Ablauf der Tabelleninformation verändern die Entscheidungslage.

RTP und RTCP können unterschiedliche UDP-Quellports verwenden. Daher speichert die Tabelle die erste Daten- und Kontrolladresse getrennt. Hinter einem Mixer kann eine gemeinsame Adresse die Herkunft verdecken; zwei SDES-Blöcke mit gleichem SSRC und verschiedenen CNAMEs liefern dann weitere Kollisionsindizien.

Eine Schleife sah zunächst genauso aus

Ein Weiterleitungsloop bringt dasselbe SSRC von einer anderen Adresse zurück. Die erste Abweichung unterscheidet nicht zwischen zweiter Quelle und zurückgekehrter Kopie.

RFC 3550 verlangt deshalb eine zeitlich begrenzte Liste konkurrierender RTP- und RTCP-Adressen. Betrifft der Konflikt das eigene SSRC, benennt sich die Quelle einmal um und merkt sich den Pfad. Weitere Rückläufer werden ignoriert. Ohne diese Erinnerung könnte eine Schleife endlose BYE-Pakete und Umbenennungen auslösen.

Mixer und Translator müssen Schleifen unterbrechen. RFC 7667 zeigt aber die Sichtgrenze: Erkennung funktioniert nur, wenn SSRC- und CSRC-Identitäten durchgängig erhalten bleiben. Unabhängig verkettete Sitzungen und manche Umschalt- oder Weiterleitungstopologien zerstören diese gemeinsame Grundlage.

Eine neue Adresse hatte mehrere mögliche Ursachen

RFC 3550 lockerte die frühere Pflicht, bei jedem Wechsel der Transportadresse auch das SSRC zu ändern. Mobile Anwendungen dürfen denselben Stream auf einem neuen Pfad fortsetzen. Der Empfänger kann die neue Adresse übernehmen, sollte jedoch ein Hin- und Herspringen bei echter Kollision verhindern.

Ein neu gestarteter Translator mit anderem UDP-Port lässt alle weitergereichten Quellen vorübergehend wie Loops erscheinen. RFC 5135 beschreibt dasselbe Problem nach Ablauf einer NAT-Zuordnung: neues IP/Port-Paar plus altes SSRC löst Kollisionsbehandlung aus und kann Diagnose sowie Jitterpuffer beeinträchtigen.

Die Abweichung ist somit Beleg für einen Klassifizierungsbedarf, nicht Beweis für Angriff oder einen bestimmten Schuldigen.

CNAME bewahrte eine andere Form der Kontinuität

RFC 7022 trennt die Lebensdauern. Das SSRC kann sich bei Kollision oder Neustart ändern, während der RTCP-CNAME ein Endpoint und zusammengehörige Streams verbindet. Längere Beständigkeit hilft der Überwachung; ein CNAME je Sitzung verringert Verknüpfbarkeit.

Der CNAME ist dennoch kein Ausweis. Teilnehmer wählen ihn selbst und können einen fremden Wert nachahmen. Korrelation und Authentisierung bleiben getrennt.

Auch Signalisierung schafft keine lückenlose Reservierung. RFC 8834 verlangt für WebRTC weiterhin zufällige SSRC-Zuweisung und die Auflösung nach RFC 3550. Neue Werte können vor Bestätigung genutzt werden; Hilfsströme für Wiederholung bringen zusätzliche, zuvor nicht angekündigte SSRCs.

Quellen und Grenzen

Die ursprüngliche Regel steht in RFC 1889, der ausgereifte Algorithmus in RFC 3550. RFC 5135 behandelt NAT, RFC 7022 CNAME, RFC 7656 Stream-Semantik, RFC 7667 Topologien und RFC 8834 WebRTC. Daraus folgen keine heutigen Kollisionsraten, Produktkonformität, Personenidentität, Medienauthentizität oder Wiedergabegarantie.