Zusammenfassung

  • RFC 3605 führte das medienbezogene Attribut a=rtcp ein, weil ein NAT die frühere Nachbarschaft von RTP- und RTCP-Port aufheben und beide Flüsse sogar verschiedenen öffentlichen Adressen zuordnen kann.
  • Der explizite Wert beseitigt eine falsche Ableitung. Er beweist weder Socket-Bindung noch Mapping-Lebensdauer, Pakettransport, gültigen RTCP-Empfangsbericht oder Medienqualität. Jede Stufe braucht einen eigenen Beleg.

Eine interne Konfiguration zeigt Port 49170 für RTP und 49171 für RTCP. Außerhalb des NAT erscheint der erste Fluss auf 62004, der zweite auf 55319. Wer dort erneut eins addiert, sendet Steuerpakete an einen Port, den nie jemand zugewiesen hat. Die Formel ist nicht schlecht implementiert; ihr Geltungsbereich ist überschritten worden.

Genau diesen Bruch behandelte RFC 3605, veröffentlicht im Oktober 2003 auf dem Standards Track. SDP nannte gewöhnlich einen Medienport. Weitere Ports leitete die Anwendung algorithmisch ab. Port-Mapping konnte Reihenfolge und Parität zerstören. Bei einem Pool öffentlicher Adressen konnten RTP und RTCP sogar unter verschiedenen Adressen sichtbar werden.

Die Erweiterung definiert a=rtcp: mit Portnummer sowie optional Netztyp, Adresstyp und Verbindungsadresse. Das Attribut darf auf Medienebene verwendet werden und nicht auf Sitzungsebene. Statt aus einem übersetzten RTP-Port eine zweite Koordinate zu erraten, kann der Absender sie ausdrücklich dokumentieren.

Diese Präzision gilt für die Beschreibung, nicht automatisch für den Betrieb. Ein Generator kann die richtige Zeile erzeugen, während der Empfänger keinen Socket gebunden hat. Ein Parser kann sie akzeptieren, während ein nachgelagertes Modul sie verwirft. Eine Offer/Answer-Aushandlung kann erfolgreich sein, während ein Filter den ersten Datensatz blockiert.

Die Form als Attribut war eine bewusste Kompatibilitätsentscheidung. Eine veränderte Medienzeile hätte ältere Anwendungen veranlassen können, die gesamte Medienbeschreibung zurückzuweisen. Ein unbekanntes Attribut wird ignoriert. So kann ein älterer Peer RTP empfangen und trotzdem kein RTCP an den ausdrücklich genannten Port senden.

Damit entsteht eine dokumentierte Teilstörung: Der Nutzdatenpfad bleibt sichtbar, der Kontrollpfad verschwindet. Ein kurzer Hörtest kann bestanden werden, obwohl Empfangsberichte, Quellinformationen oder Synchronisationsdaten fehlen. Das Dashboard darf daher die RTP-Zählung nicht als Stellvertreter für die RTCP-Schleife benutzen.

Auch die Ermittlung des externen Werts bleibt begrenzt. RFC 3605 skizziert STUN: Zwei lokale UDP-Ports werden geöffnet, von beiden gehen Nachrichten an einen Server, und der Server meldet die beobachteten Quelladressen und Ports zurück. Diese Werte können anschließend im SDP stehen.

Der RFC nennt jedoch die Voraussetzung. Das NAT müsste gegenüber dem STUN-Server dieselbe Übersetzung verwenden wie gegenüber dem späteren SDP-Peer. Für alle eingesetzten NATs gibt es dafür keine Garantie. Eine Beobachtung durch einen Server zu einem Zeitpunkt ist kein dauerhaftes, zielunabhängiges Mapping.

Darum gehören Beobachter, Zeit und Ziel in den Datensatz. Interner Tuple, Schnittstelle, STUN-Server, externer Tuple, beabsichtigter Peer, SDP-Version und Zeit bis zum ersten Einsatz bilden gemeinsam den Nachweis. Wird nur Port 55319 gespeichert, ist nicht mehr prüfbar, wann und für wen diese Zahl wahr war.

Nach der Ankündigung folgen weitere Grenzen. Ein Sendecounter zeigt, dass die Anwendung Daten an den lokalen Socket übergeben wollte. Ein Mitschnitt an der Ausgangsschnittstelle zeigt den Datensatz dort. Ein Mitschnitt am entfernten Rand beweist seine Ankunft an diesem Punkt. Erst der RTCP-Parser kann Struktur und Sitzungszuordnung bestätigen.

Ein gültiger Bericht besitzt wiederum einen definierten Umfang. RFC 3550 nutzt RTCP für Rückmeldungen zur Empfangsqualität, Identifikation, Synchronisation und Steuerung. Werte beziehen sich auf meldende Quellen, Synchronisationsquellen und Intervalle. Sie sind kein Beweis für die Identität einer Person, lückenlose Beobachtung beider Richtungen oder ein gutes Geschäftsergebnis.

Fehlende Berichte sind besonders mehrdeutig. Der Peer kann a=rtcp ignorieren, den benachbarten Port verwenden, Multiplexing ausgehandelt haben, ein Mapping verlieren oder an einem Filter scheitern. Ein Berichtsintervall kann noch nicht fällig sein. Das Paket kann angekommen sein, während die Telemetrie-Pipeline ausfällt. Null Datensätze sind kein Bericht mit null Verlust.

Spätere Standards ersetzen diese Unterscheidung nicht. RFC 5761 ermöglicht die ausgehandelte Multiplexierung von RTP und RTCP auf einem Port. RFC 8859 ordnet rtcp in der Multiplexierungsanalyse der Kategorie TRANSPORT zu. Das IANA-Verzeichnis führt das medienbezogene Attribut weiterhin. Entscheidend ist der tatsächlich vereinbarte Modus, nicht eine nachträglich angenommene Voreinstellung.

RFC 5389 begrenzt auch die Rolle von STUN: Werkzeug statt vollständige NAT-Traversal-Lösung. Diese Begrenzung schützt vor institutioneller Überdehnung. Entdeckung liefert eine Beobachtung. SDP übermittelt eine Behauptung. Laufender Code bindet und sendet. Das Netz transportiert. Der Empfänger validiert. Die Analyse entscheidet.

Signalintegrität schließt eine andere Lücke. RFC 3605 weist darauf hin, dass ein Angreifer durch Umschreiben des SDP den RTCP-Anteil umleiten könnte. Eine Integritätsprüfung stärkt Herkunft und Unverändertheit der Ankündigung. Sie öffnet aber keinen Port, verlängert kein Mapping und autorisiert den Empfänger nicht automatisch für Telemetrie.

Das Betriebsmodell sollte deshalb die Zustände ausschreiben: ursprüngliches SDP und Hash; Parserergebnis; Offer/Answer; getrennter oder multiplexierter Modus; Socket und Prozess; NAT-Beobachtung; angekündigter Tuple; Integritätsprüfung; erster Versand; erste entfernte Ankunft; erstes gültiges RTCP; erster Bericht; Berichtsintervall; Aufnahme in die Analyse; ausgelöste Entscheidung.

Mit dieser Kette lässt sich Schweigen untersuchen, ohne es umzudeuten. Endet der Beleg bei der SDP-Annahme, bleibt die Erreichbarkeit offen. Gibt es einen entfernten Mitschnitt, aber keine Kennzahl, liegt der nächste Prüfpunkt in der Erfassung. Kommt ein Bericht an, ohne eine Reaktion auszulösen, ist die Entscheidungsprovenienz betroffen.

RFC 3605 machte eine nach der Übersetzung nicht mehr berechenbare Koordinate explizit. Das war eine präzise, minimale Lösung. Den wirklichen Pfad baut der implementierte Dienst; seine Funktion belegt der Betreiber. Die korrekte Portnummer beendet eine falsche Rechnung, aber noch keine Beweiskette.