Zusammenfassung

  • RTCP-Berichte besitzen keinen bedingungslosen Sendetermin. Beim Ablauf des Timers wird mit den aktuellen Schätzungen neu gerechnet; eine inzwischen größere Gruppe kann weiteres Warten erforderlich machen.
  • Mehrere Quellen eines Endpunkts behalten getrennte Zustände. Werden ihre Berichte zusammengefasst, müssen sowohl die Paketgröße als auch die vorgezogenen Sendezeiten richtig verrechnet werden.
  • Die Entwicklung von 1996 bis 2017 betrifft nicht nur Paketformate. Sie verändert, wann Teilnehmer senden dürfen und welche Schlüsse sie aus ausbleibenden Berichten ziehen können.

Bündeln spart Header, aber nicht automatisch Senderechte

RFC 8108 behandelt seit März 2017 ausdrücklich mehrere RTP-Quellen innerhalb einer Sitzung. Jeder SSRC führt einen eigenen RTCP-Zustand und einen eigenen Berichtszeitplan, auch wenn mehrere Quellen zum selben Endpunkt gehören. Ein Gerät ist deshalb nicht zwangsläufig ein einziger Teilnehmer in der Kontrollrechnung.

Die Berichte dieser Quellen lassen sich unter bestimmten Bedingungen in einem Paket zusammenfassen. Wird ein regulärer Bericht fällig, können weitere Berichte hinzukommen, deren Termine noch bevorstehen und die in das Paket passen. Das spart unter anderem gemeinsam genutzte Header. Es zieht aber auch Arbeit vor.

Würde man anschließend für alle Quellen einfach so weiterrechnen, als wäre der vorgezogene Versand ihr regulärer Termin gewesen, könnte das wiederholte Bündeln ihre Berichtsfrequenz erhöhen. Das Paket wäre effizienter verpackt, während die Quellen häufiger zu Wort kämen als ursprünglich vorgesehen.

Die Spezifikation berechnet deshalb effektive zukünftige Sendezeitpunkte und verwendet deren Mittelwert zur Aktualisierung des Planungszustands. Ein solcher Bezugswert kann nach der Gegenwart liegen. Er behauptet nicht, ein physischer Versand habe in der Zukunft stattgefunden. Er hält fest, wie die zeitliche Zuteilung trotz des vorgezogenen Versands fortgeführt werden soll.

Der Unterschied zwischen Ereignisprotokoll und Planungsrechnung ist hier entscheidend. Wer jeden Zeitwert als »letzter tatsächlicher Versand« interpretiert, kann einen vorgesehenen Ausgleich für einen Fehler halten. Wer ihn unbesehen durch die reale Uhrzeit ersetzt, kann dagegen genau den Ausgleich beseitigen.

Die zweite Rechnung betrifft die Bytes

Auch die Größe eines zusammengefassten Pakets darf nicht jeder enthaltenen Quelle vollständig zugeschlagen werden. Sonst sieht es für jede Quelle so aus, als koste ihr Bericht das gesamte Bündel. Der geschätzte Aufwand steigt, die berechneten Abstände können unnötig wachsen.

RFC 8108 verteilt die Paketgröße auf die unterschiedlichen SSRC, von denen die betreffenden Sender- oder Empfängerberichte stammen. Es geht nicht um die Anzahl der Menschen vor dem Bildschirm und auch nicht um jedes beiläufig erwähnte Quellkennzeichen. Die Einheit der Rechnung muss zur Einheit der Berichte passen.

Diese doppelte Korrektur zeigt, weshalb eine Transportoptimierung nicht bloß eine Verpackungsfrage ist. Das Protokoll benutzt durchschnittliche Größen und Zeitabstände, um eine gemeinsame Kontrollbandbreite zu verteilen. Verändert die Verpackung diese Eingangsgrößen, kann sie die Verteilung verändern, ohne dass ein Administrator ausdrücklich einen neuen Anteil festgelegt hat.

Warum die Berichte überhaupt warten

RTCP begleitet RTP mit Rückmeldungen zur Empfangsqualität, Informationen zur Quellenidentifikation und Beobachtungen, aus denen sich die Sitzungsgröße abschätzen lässt. Im klassischen Multicast-Beispiel senden wenige Quellen Audio an viele Empfänger. Mehr Zuhörer müssen nicht mehr ausgesendetes Audio bedeuten; regelmäßige Berichte aller Zuhörer würden bei unveränderter Einzelrate jedoch stetig mehr Kontrollverkehr erzeugen.

RFC 3550, veröffentlicht im Juli 2003, berücksichtigt dafür die jeweilige Teilnehmerzahl, die durchschnittliche RTCP-Paketgröße und die Kontrollbandbreite. Zur Größe gehören Netzwerk- und Transportheader. Auch ein kleiner Bericht verursacht mehr als nur die Bytes seiner Statistikfelder.

Die Sitzungsbandbreite ist ein gemeinsamer Konfigurationswert. Sie ist weder eine Messung der gerade freien Leitungskapazität noch eine Reservierungszusage des Netzes. RTP und RTCP garantieren für sich genommen keine rechtzeitige oder zuverlässige Medienzustellung. Die Rechnung begrenzt ein Verhalten der Teilnehmer, nicht alle möglichen Ursachen einer gestörten Verbindung.

Die oft zitierte Fünf-Prozent-Empfehlung ist ebenso wenig ein universeller Naturwert. Sie beschreibt zusätzliche Kontrollbandbreite im Verhältnis zur Datensitzung; Profile und ausdrückliche Parameter beeinflussen die Aufteilung. Auch die Mindestzeit in der deterministischen Grundrechnung ist nicht mit einer festen Untergrenze für jeden tatsächlich ausgelosten Sendeabstand gleichzusetzen.

Der Zufall war schon da

RFC 1889 enthielt im Januar 1996 bereits größenabhängige Berichtsintervalle, eine Schätzung der mittleren Paketgröße, zufällige Streuung und eine anfängliche Wartezeit. Die spätere Verbesserung lässt sich nicht korrekt als Einführung zufälliger statt starrer Termine erzählen.

Ein anderes Problem entsteht, wenn die Grundlage eines Termins während des Wartens veraltet. Ein neuer Teilnehmer beginnt in der Grundprozedur mit sich selbst und lernt aus gültigen Quellenbeobachtungen. Treten viele Quellen fast gleichzeitig bei, können viele erste Termine auf zu kleinen Gruppenschätzungen beruhen.

Die zufällige Verteilung verhindert dann vielleicht den identischen Sendezeitpunkt, aber nicht zu viel Verkehr in einem kurzen Zeitraum. Ein falsch bemessenes Gesamtbudget wird nicht dadurch richtig, dass seine Überschreitung unregelmäßig erfolgt.

RFC 3550 lässt beim Ablauf des Timers erneut rechnen. Mit den aktuellen Schätzungen wird ein neues Intervall bestimmt. Liegt der letzte Sendezeitpunkt zuzüglich dieses Intervalls bereits in der Vergangenheit oder Gegenwart, darf gesendet werden. Andernfalls wird der Termin auf den errechneten zukünftigen Zeitpunkt verschoben.

Der Timerablauf ist damit eine Aufforderung zur Prüfung, kein unveränderliches Senderecht. Das Verfahren verlangt nicht, bei jeder neu gehörten Quelle sofort alle Termine zu verschieben. Sein entscheidender Prüfpunkt liegt dort, wo aus dem alten Plan tatsächlicher Verkehr werden würde.

Nach einem erlaubten Versand wird für den nächsten Termin neu gezogen. Die Zufallszahl, die gerade den Versand ermöglicht hat, wurde bereits durch eine Bedingung ausgewählt. Sie als frische Stichprobe wiederzuverwenden, würde die Auswahl verzerren; der Algorithmusanhang erläutert diesen Effekt ausdrücklich.

Eine kleinere Gruppe braucht die alte Wartezeit nicht

Beim Ausscheiden vieler Teilnehmer entsteht der umgekehrte Fehler. Die verbleibenden Quellen können weiter auf Termine warten, die nur für die größere Gruppe sinnvoll waren. Berichte werden zu selten; andere Teilnehmer könnten das Schweigen schließlich als Abwesenheit deuten.

Die umgekehrte Timer-Neubewertung passt die noch verbleibende und die bereits verstrichene Zeit um den aktuellen Zeitpunkt herum an das Verhältnis zwischen neuer und alter Gruppenschätzung an. Sie hilft, schneller zum passenden Rhythmus zurückzufinden.

Sie schafft dennoch kein überall identisches Mitgliederverzeichnis. BYE-Nachrichten können eine Abreise anzeigen, bei großen gleichzeitigen Abgängen aber selbst einer Rückhalteprozedur unterliegen. Teilnehmer dürfen auch ohne BYE verschwinden und später aus den Tabellen auslaufen. Beobachtete Abwesenheit bleibt eine zeitabhängige Schlussfolgerung.

Das Zählen ersetzt zudem keine Authentisierung. Ein erfasster SSRC ist nicht automatisch eine verifizierte Person oder ein vertrauenswürdiges Gerät. Die Qualität der Eingaben begrenzt die Qualität der Zeitplanung, selbst wenn deren Mathematik korrekt implementiert ist.

Ein gemeinsamer Wert kann auch gemeinsam schaden

RFC 3556 macht mit RS und RR getrennte Bandbreitenparameter in Bit pro Sekunde ausdrückbar. Ihre Nullwerte haben unterschiedliche Wirkungen. RS gleich null unterbindet nicht sämtliche RTCP-Berichte der Sender; RR gleich null kann die Berichte der Nichtsender abschalten, was der Text nicht allgemein empfiehlt.

Weniger Berichte sparen Verkehr und entfernen zugleich Beobachtungen. Eine reine Bandbreitenkennzahl zeigt den ersten Effekt, nicht notwendigerweise den zweiten. Wer Empfangsberichte unterdrückt, verändert die Informationsgrundlage der Sitzung.

Umgekehrt kann eine unrealistisch hohe angekündigte Bandbreite exzessiven Kontrollverkehr auslösen. Die Spezifikation verlangt Plausibilitätsprüfungen für Sitzungsparameter, besonders bei nicht authentisierten Beschreibungen. Ein gemeinsamer Parameter ist nicht schon deshalb vernünftig, weil alle dieselbe Rechenvorschrift darauf anwenden.

Schnelle Rückmeldungen bleiben ein eigener Fall

Für manche Ereignisse kommt ein regulärer Bericht zu spät. RFC 4585 erlaubt seit Juli 2006 im AVPF-Profil frühe Rückmeldungen unter festgelegten Bedingungen. In Gruppen kann eine kurze zufällige Wartephase dazu dienen, gleichwertige Rückmeldungen anderer zu hören und den eigenen Doppelbericht zu unterdrücken.

Die Möglichkeit hebt weder das Kontrollbudget auf noch verpflichtet sie alle Empfänger zur sofortigen Antwort auf jeden Verlust. Sie behandelt zeitkritische Rückmeldung anders als regelmäßige Zustandsberichte. Eine Darstellung, die alle RTCP-Pakete demselben einfachen Warteablauf unterwirft, würde diese Unterscheidung verlieren.

RFC 5506 ermöglicht seit April 2009 für bestimmte frühe oder unmittelbare Rückmeldungen kleinere RTCP-Pakete. Zuvor muss mindestens ein zusammengesetztes Paket gesendet worden sein; die regulären Berichte bleiben während der Sitzung zusammengesetzt. Das kleinere Format ersetzt nicht den gesamten regelmäßigen Beobachtungsverkehr.

Es muss auch tatsächlich ankommen. Endpunkte oder Zwischenstationen können die reduzierte Form verwerfen. Anwendungen müssen dauerhafte Zustellungsfehler erkennen; bei gescheiterter Prüfung wird die Rückkehr zu zusammengesetzten Paketen dringend empfohlen. Eine ausgehandelte Fähigkeit ist noch kein Nachweis, dass der Pfad sie zulässt.

RFC 8108 ergänzt später die Bedingungen mehrerer SSRC und begrenzt die anfänglich verzögerungsfrei versendbaren zusammengesetzten RTCP-Pakete eines beitretenden Endpunkts auf vier. Das zählt Pakete, nicht Menschen oder Quellen. Weitere Berichte folgen der normalen Planung. Die Aktualisierung vereinheitlicht außerdem die Teilnehmer-Zeitüberschreitung zwischen den betroffenen Profilen, damit erlaubte Unterdrückung oder andere Sendeintervalle nicht zu falschen Austritten führen. Es handelt sich nicht um eine pauschale Fünf-Sekunden-Schweigefrist.

Gleiches Format, andere zeitliche Ordnung

RFC 3550 hält fest, dass sich die RTP- und RTCP-Formate auf der Leitung gegenüber RFC 1889 nicht verändert haben. Die wesentliche Verbesserung betrifft Timer. Alte und neue Teilnehmer können also dieselben Bytes verstehen und dennoch unterschiedliche zeitliche Entscheidungen treffen.

Der Anhang beschreibt Vorteile in gemischten Gruppen abhängig vom Anteil verbesserter Teilnehmer und verweist auf Analysen sowie Interoperabilitätstests. Das sind Aussagen der historischen Spezifikation, keine hier erhobenen Messwerte heutiger Konferenzdienste.

Die am 26. August 2026 geprüften Errata zu RFC 3550 enthalten keine bestätigte Korrektur, welche den dargestellten Timermechanismus ersetzt. Zurückgestellte oder abgelehnte Meldungen werden dadurch nicht zu beschlossenen Änderungen.

Von der erneuten Prüfung eines fälligen Termins bis zur zukünftigen Bezugszeit eines schon gesendeten Bündels bleibt die Aufgabe dieselbe: lokale Bequemlichkeit darf die gemeinsame Zeitrechnung nicht unbemerkt verändern. Ein Paket ist ein Ereignis. Der Anspruch auf das nächste ist eine andere Rechnung.