6. RTP Control Protocol -- RTCP (RTP-Steuerprotokoll -- RTCP)

Das RTP-Steuerprotokoll (RTCP, RTP Control Protocol) basiert auf der periodischen Übertragung von Steuerpaketen an alle Teilnehmer der Sitzung unter Verwendung desselben Verteilungsmechanismus wie die Datenpakete. Das zugrunde liegende Protokoll MUSS das Multiplexen von Daten- und Steuerpaketen bereitstellen, beispielsweise durch Verwendung unterschiedlicher Portnummern mit UDP. RTCP erfüllt vier Funktionen:

Die Hauptfunktion ist es, ein Feedback über die Qualität der Datenverteilung zu geben. Dies ist ein integraler Bestandteil der Rolle von RTP als Transportprotokoll und steht in Zusammenhang mit den Fluss- und Überlaststeuerungsfunktionen anderer Transportprotokolle (siehe Abschnitt 10 über die Anforderung der Überlaststeuerung). Das Feedback kann direkt für die Steuerung adaptiver Kodierungen nützlich sein [18,19], aber Experimente mit IP-Multicast haben gezeigt, dass es auch entscheidend ist, Feedback von Empfängern zu erhalten, um Verteilungsfehler zu diagnostizieren. Das Senden von Empfangsberichten an alle Teilnehmer ermöglicht demjenigen, der Probleme beobachtet, zu bewerten, ob diese lokal oder global sind. Mit einem Verteilungsmechanismus wie IP-Multicast ist es auch möglich, dass eine Entität wie ein Netzwerkanbieter, die anderweitig nicht an der Sitzung beteiligt ist, die Rückinformation empfängt und als Drittanbieter-Überwacher zur Diagnose von Netzwerkproblemen agiert. Diese Feedbackfunktion wird durch die RTCP-Sender- und Empfangsberichte, weiter unten in Abschnitt 6.4 beschrieben, erfüllt.
RTCP transportiert einen persistenten Transport-Ebene-Identifikator für eine RTP-Quelle namens kanonischer Name oder CNAME, Abschnitt 6.5.1. Da sich der SSRC-Identifikator ändern kann, falls ein Konflikt entdeckt wird oder ein Programm neu gestartet wird, benötigen die Empfänger den CNAME, um jeden Teilnehmer zu verfolgen. Die Empfänger können den CNAME auch benötigen, um mehrere Datenströme eines bestimmten Teilnehmers in einem Satz verknüpfter RTP-Sitzungen zuzuordnen, beispielsweise zur Lip-Sync-Synchronisation von Audio und Video. Die inter-mediale Synchronisation erfordert zudem die in den RTCP-Paketen der Daten sender enthaltenen NTP- und RTP-Zeitstempel.
Die ersten beiden Funktionen erfordern, dass alle Teilnehmer RTCP-Pakete senden; folglich muss die Rate kontrolliert werden, damit RTP auf eine große Anzahl von Teilnehmern skalierbar bleibt. Indem jeder Teilnehmer seine Steuerpakete an alle anderen sendet, kann jeder unabhängig die Anzahl der Teilnehmer beobachten. Diese Zahl wird zur Berechnung der Senderate verwendet, wie in Abschnitt 6.2 erklärt.
Eine vierte, OPTIONALE Funktion ist die Übertragung minimaler Sitzungssteuerungsinformationen, beispielsweise der Identifikation von Teilnehmern zur Anzeige in der Benutzeroberfläche. Dies dürfte in „schwach gesteuerten" (loosely controlled) Sitzungen am nützlichsten sein, wo Teilnehmer ohne Mitgliedschaftskontrolle oder Parameteraushandlung beitreten und gehen. RTCP dient als bequemer Kanal, um alle Teilnehmer zu erreichen, ist jedoch nicht notwendigerweise dafür vorgesehen, alle Steuerungskommunikationsanforderungen einer Anwendung abzudecken. Ein höherwertiges Sitzungssteuerungsprotokoll, das den Rahmen dieses Dokuments überschreitet, kann erforderlich sein.

Die Funktionen 1 bis 3 SOLLTEN in allen Umgebungen verwendet werden, besonders jedoch in der IP-Multicast-Umgebung. RTP-Anwendungsentwickler SOLLTEN Mechanismen vermeiden, die nur im Unicast-Modus funktionieren und nicht auf größere Zahlen skalieren. Die RTCP-Übertragung kann für Sender und Empfänger separat gesteuert werden, wie in Abschnitt 6.2 für Fälle wie unidirektionale Links beschrieben, wo ein Empfängerfeedback nicht möglich ist.

Nicht-normative Anmerkung: Im Multicast-Routing-Ansatz namens Source-Specific Multicast (SSM) gibt es pro „Kanal" (ein Quelladress-, Gruppenadress-Paar) nur einen Sender, und die Empfänger (außer der Quelle des Kanals) können Multicast nicht direkt zur Kommunikation mit den anderen Kanalmitgliedern nutzen. Die hier gegebenen Empfehlungen berücksichtigen SSM nur über die Option in Abschnitt 6.2, RTCP der Empfänger vollständig zu deaktivieren. Zukünftige Arbeiten werden die Anpassung von RTCP an SSM spezifizieren, sodass das Empfängerfeedback aufrechterhalten werden kann.

6.1 RTCP Packet Format (RTCP-Paketformat)

Diese Spezifikation definiert mehrere RTCP-Pakettypen zur Übertragung einer Vielzahl von Steuerinformationen:

SR : Senderbericht (Sender Report), für Statistiken der Sendung und des Empfangs von Teilnehmern, die aktive Sender sind.
RR : Empfangsbericht (Receiver Report), für Empfangsstatistiken von Teilnehmern, die keine aktiven Sender sind, und in Kombination mit SR für aktive Sender, die über mehr als 31 Quellen berichten.
SDES : Quellenbeschreibungselemente (Source Description), einschließlich CNAME.
BYE : Zeigt das Ende der Teilnahme an.
APP : Anwendungsspezifische Funktionen.

Jedes RTCP-Paket beginnt mit einem festen Bereich ähnlich dem der Datenpakete, gefolgt von strukturierten Elementen, die je nach Pakettyp variabel lang sein können, aber an einer 32-Bit-Grenze enden MÜSSEN. Die Ausrichtungsanforderung und ein Längenfeld im festen Bereich jedes Pakets ermöglichen es, RTCP-Pakete „stapelbar" zu machen. Mehrere RTCP-Pakete können ohne Trennzeichen zu einem zusammengesetzten RTCP-Paket (Compound RTCP Packet) konkateniert werden, das in einem einzigen Paket des zugrunde liegenden Protokolls, beispielsweise UDP, gesendet wird. Es gibt keinen expliziten Zähler für einzelne RTCP-Pakete im zusammengesetzten Paket, da die unteren Protokollebenen eine globale Länge zur Bestimmung des Endes des zusammengesetzten Pakets bereitstellen sollen.

Jedes einzelne RTCP-Paket im zusammengesetzten Paket kann unabhängig ohne Anforderung an die Reihenfolge oder Kombination der Pakete verarbeitet werden. Um jedoch die Protokollfunktionen zu erfüllen, werden folgende Einschränkungen auferlegt:

Empfangsstatistiken (in SR oder RR) sollten so oft wie möglich innerhalb der Bandbreitenbeschränkungen gesendet werden, um die Auflösung der Statistiken zu maximieren; daher MUSS jedes periodisch gesendete zusammengesetzte RTCP-Paket ein Berichtspaket enthalten.
Neue Empfänger müssen den CNAME einer Quelle so schnell wie möglich erhalten, um die Quelle zu identifizieren und die Medienzuordnung für Zwecke wie Lip-Sync zu beginnen; daher MUSS jedes zusammengesetzte RTCP-Paket auch das SDES-CNAME enthalten, außer wenn das zusammengesetzte RTCP-Paket wie in Abschnitt 9.1 beschrieben für Teilverschlüsselung geteilt wird.
Die Anzahl der Pakettypen, die zuerst im zusammengesetzten Paket erscheinen dürfen, muss begrenzt werden, um die Anzahl der konstanten Bits im ersten Wort und die Wahrscheinlichkeit zu erhöhen, RTCP-Pakete erfolgreich gegen falsch adressierte RTP-Datenpakete oder andere unzusammenhängende Pakete zu validieren.

Daher MÜSSEN alle RTCP-Pakete in einem zusammengesetzten Paket aus mindestens zwei Einzelpaketen gesendet werden, mit folgendem Format:

Verschlüsselungspräfix (Encryption Prefix) : Falls und nur falls das zusammengesetzte Paket gemäß der Methode in Abschnitt 9.1 verschlüsselt werden soll, MUSS ihm eine zufällige 32-Bit-Menge vorangestellt werden, die für jedes gesendete zusammengesetzte Paket neu gezogen wird. Falls Füllung für die Verschlüsselung benötigt wird, muss sie an das letzte Paket des zusammengesetzten Pakets angehängt werden.
SR oder RR : Das erste RTCP-Paket im zusammengesetzten Paket MUSS immer ein Berichtspaket sein, um die Header-Validierung wie in Anhang A.2 beschrieben zu erleichtern. Dies gilt auch, falls keine Daten gesendet oder empfangen wurden, in welchem Fall ein leeres RR gesendet werden MUSS, und sogar falls das einzige andere RTCP-Paket im zusammengesetzten Paket ein BYE ist.
Zusätzliche RR : Falls die Anzahl der Quellen, für die Empfangsstatistiken berichtet werden, 31 übersteigt, die Anzahl, die in ein SR- oder RR-Paket passt, sollten zusätzliche RR-Pakete dem ersten Berichtspaket folgen.
SDES : Ein SDES-Paket, das ein CNAME-Element enthält, MUSS in jedem zusammengesetzten RTCP-Paket enthalten sein, außer wie in Abschnitt 9.1 vermerkt. Weitere Quellenbeschreibungselemente können optional eingeschlossen werden, falls eine bestimmte Anwendung dies erfordert, unter Berücksichtigung der Bandbreitenbeschränkungen (siehe Abschnitt 6.3.9).
BYE oder APP : Andere RTCP-Pakettypen, einschließlich solcher, die noch zu definieren sind, können in beliebiger Reihenfolge folgen, außer dass BYE das letzte Paket sein SOLLTE, das mit einem bestimmten SSRC/CSRC gesendet wird. Die Pakettypen dürfen öfter als einmal erscheinen.

Ein einzelner RTP-Teilnehmer SOLLTE ein einziges zusammengesetztes RTCP-Paket pro Berichtsintervall senden, damit die RTCP-Bandbreite pro Teilnehmer korrekt geschätzt wird (siehe Abschnitt 6.2), außer wenn das zusammengesetzte RTCP-Paket wie in Abschnitt 9.1 beschrieben für Teilverschlüsselung geteilt wird. Falls es zu viele Quellen gibt, um alle benötigten RR-Pakete in einem einzigen zusammengesetzten RTCP-Paket ohne Überschreitung der MTU (Maximum Transmission Unit) des Netzwerkpfads unterzubringen, sollte nur die Untermenge, die in eine MTU passt, in jedem Intervall enthalten sein. Die Untermengen SOLLTEN im Round-Robin-Verfahren über mehrere Intervalle ausgewählt werden, damit alle Quellen berichtet werden.

Es wird EMPFOHLEN, dass Übersetzer und Mischer die einzelnen RTCP-Pakete der mehreren Quellen, die sie weiterleiten, nach Möglichkeit zu einem einzigen zusammengesetzten Paket kombinieren, um den Paket-Overhead zu amortisieren (siehe Abschnitt 7). Ein Beispiel für ein zusammengesetztes RTCP-Paket, wie es von einem Mischer erzeugt werden könnte, zeigt Abbildung 1. Falls die globale Länge eines zusammengesetzten Pakets die MTU des Netzwerkpfads überschreiten würde, sollte es in mehrere kürzere zusammengesetzte Pakete segmentiert werden, die in separaten Paketen des zugrunde liegenden Protokolls übertragen werden. Dies beeinträchtigt die RTCP-Bandbreitenschätzung nicht, da jedes zusammengesetzte Paket mindestens einen eigenen Teilnehmer repräsentiert. Beachten Sie, dass jedes der zusammengesetzten Pakete mit einem SR- oder RR-Paket beginnen muss.

Eine Implementierung SOLLTE eingehende RTCP-Pakete mit ihr unbekannten Typen ignorieren. Zusätzliche RTCP-Pakettypen können wie in Abschnitt 15 beschrieben bei der Internet Assigned Numbers Authority (IANA) registriert werden.

si chiffriert: zufällige 32-Bit-Zahl
|
|[--------- paket --------][---------- paket ----------][-paket-]
|
|                empfangs           stück        stück
V                berichte          element element   element element
--------------------------------------------------------------------
R[SR #sendinfo #site1#site2][SDES #CNAME PHONE #CNAME LOC][BYE##why]
--------------------------------------------------------------------
|                                                                  |
|<-----------------------  zusammengesetztes paket ----------------------->|
|<--------------------------  UDP-Paket ------------------------->|

#: SSRC/CSRC-Identifikator

              Abbildung 1 : Beispiel eines zusammengesetzten RTCP-Pakets

6.2 RTCP Transmission Interval (RTCP-Übertragungsintervall)

RTP ist so konzipiert, dass eine Anwendung automatisch von einer Größe von wenigen Teilnehmern auf Tausende skaliert. Beispielsweise ist in einer Audio-Konferenz der Datentraffic intrinsisch selbstbegrenzt, da jeweils nur eine oder zwei Personen sprechen; daher bleibt die Datenbandbreite auf einem gegebenen Link unabhängig von der Teilnehmerzahl relativ konstant. Der Steuertraffic ist jedoch nicht selbstbegrenzt. Würden die Empfangsberichte jedes Teilnehmers mit konstanter Rate gesendet, würde der Steuertraffic linear mit der Teilnehmerzahl wachsen. Daher muss die Rate durch dynamische Berechnung des Intervalls zwischen den RTCP-Paketübertragungen reduziert werden.

Für jede Sitzung wird angenommen, dass der Datentraffic einer aggregierten Obergrenze namens „Sitzungsbandbreite" (Session Bandwidth) unterliegt, die zwischen den Teilnehmern aufgeteilt werden soll. Diese Bandbreite könnte reserviert sein und die Obergrenze durch das Netz durchgesetzt werden. Falls keine Reservierung vorliegt, können andere, umgebungsabhängige Einschränkungen den maximal „vernünftigen" Wert für die Sitzung festlegen, und dies wäre die Sitzungsbandbreite. Die Sitzungsbandbreite kann auf Basis von Kosten oder Vorabkenntnis der für die Sitzung verfügbaren Netzwerkbandbreite gewählt werden. Sie ist etwas unabhängig von der Medienkodierung, aber die Wahl der Kodierung kann durch die Sitzungsbandbreite begrenzt sein. Oft ist die Sitzungsbandbreite die Summe der Nominalbandbreiten der erwarteten gleichzeitig aktiven Sender. Für Audio in Telekonferenzen wäre dies typischerweise die Bandbreite eines Senders. Für geschichtete Kodierungen ist jede Schicht eine separate RTP-Sitzung mit eigenem Sitzungszuweisungsparameter für die Sitzungsbandbreite.

Der Sitzungsbandbreitenparameter soll von einer Sitzungsverwaltungsanwendung bereitgestellt werden, wenn sie eine Medienanwendung aufruft, aber Medienanwendungen KÖNNEN einen Standardwert basierend auf der Datenbandbreite eines einzelnen Senders für die gewählte Sitzungskodierung setzen. Die Anwendung kann auch Bandbreitengrenzen basierend auf Multicast-Gültigkeitsbereichsregeln oder anderen Kriterien anwenden. Alle Teilnehmer MÜSSEN denselben Wert für die Sitzungsbandbreite verwenden, damit dasselbe RTCP-Intervall berechnet wird.

Die Bandbreitenberechnungen für Steuer- und Datentraffic umfassen die unteren Transport- und Netzwerkprotokollebenen (beispielsweise UDP und IP), da dies das ist, was ein Ressourcenreservierungssystem benötigen würde. Die Anwendung kann ebenfalls erwartet werden, zu wissen, welche dieser Protokolle verwendet werden. Link-Ebene-Header werden in der Berechnung nicht berücksichtigt, da das Paket auf seinem Weg mit verschiedenen Link-Ebene-Headern gekapselt wird.

Der Steuertraffic sollte auf einen kleinen bekannten Bruchteil der Sitzungsbandbreite begrenzt werden: klein, damit die Hauptfunktion des Transportprotokolls, Daten zu transportieren, nicht beeinträchtigt wird; bekannt, damit der Steuertraffic in die Bandbreitenspezifikation für ein Ressourcenreservierungsprotokoll aufgenommen werden kann und damit jeder Teilnehmer unabhängig seinen Anteil berechnen kann. Die RTCP-Bandbreite addiert sich zur Sitzungsbandbreite für den Datentraffic. Es wird EMPFOHLEN, den Bruchteil der Sitzungsbandbreite, der für RTCP hinzugefügt wird, auf 5 % festzusetzen. Es wird ebenfalls EMPFOHLEN, ein Viertel der RTCP-Bandbreite den aktiv Daten sendenden Teilnehmern zu widmen, sodass in Sitzungen mit vielen Empfängern, aber wenigen Sendern neu beitretende Teilnehmer den CNAME für die sendenden Standorte schneller erhalten. Wenn der Anteil der Sender über einem Viertel der Teilnehmer liegt, erhalten die Sender ihren Anteil an der vollen RTCP-Bandbreite. Obwohl die Werte dieser und anderer Konstanten in der Intervallberechnung nicht kritisch sind, MÜSSEN alle Teilnehmer der Sitzung dieselben Werte verwenden, damit dasselbe Intervall berechnet wird. Daher SOLLTEN diese Konstanten für ein bestimmtes Profil festgelegt werden.

Ein Profil KANN angeben, dass die RTCP-Steuerbandbreite ein separater Sitzungsparameter statt eines starren Prozentsatzes der Sitzungsbandbreite sein kann. Die Verwendung eines separaten Parameters ermöglicht adaptiven Anwendungen, eine konsistente RTCP-Bandbreite mit einer „typischen" Datenbandbreite festzulegen, die unter der durch den Sitzungsbandbreitenparameter angegebenen Maximalbandbreite liegt.

Das Profil KANN ferner angeben, dass die RTCP-Steuerbandbreite in zwei separate Sitzungsparameter für Teilnehmer, die aktive Daten sender sind, und solche, die es nicht sind, aufgeteilt werden kann; nennen wir die Parameter S und R. Gemäß der Empfehlung, ein Viertel der RTCP-Bandbreite den Daten sendenden Teilnehmern zu widmen, wären die empfohlenen Standardwerte für diese beiden Parameter 1,25 % bzw. 3,75 %. Wenn der Anteil der Sender über S/(S+R) der Teilnehmer liegt, erhalten die Sender ihren Anteil an der Summe dieser Parameter. Die Verwendung zweier Parameter ermöglicht es, die RTCP-Empfangsberichte für eine bestimmte Sitzung vollständig zu deaktivieren, indem die RTCP-Bandbreite für Nicht-Datensender auf Null gesetzt wird, während die RTCP-Bandbreite für Daten sender ungleich Null bleibt, sodass Senderberichte weiterhin für die inter-mediale Synchronisation gesendet werden können. Die Deaktivierung von RTCP-Empfangsberichten wird NICHT EMPFOHLEN, da sie für die am Anfang von Abschnitt 6 aufgeführten Funktionen, insbesondere das Feedback der Empfangsqualität und die Überlaststeuerung, benötigt werden. Es kann jedoch für Systeme auf unidirektionalen Links oder für Sitzungen angemessen sein, die kein Feedback über Empfangsqualität oder das Vorhandensein von Empfängern benötigen und andere Mittel zur Vermeidung von Überlastung haben.

Das berechnete Intervall zwischen den Übertragungen zusammengesetzter RTCP-Pakete SOLLTE auch eine Untergrenze haben, um zu verhindern, dass Paketbüschel die zulässige Bandbreite überschreiten, wenn die Teilnehmerzahl klein ist und der Traffc nicht durch das Gesetz der großen Zahlen geglättet wird. Dies verhindert auch, dass das Berichtsintervall während vorübergehender Störungen wie einer Netzwerkpartition zu kurz wird, wenn die Anpassung verzögert wird, sobald die Partition aufgelöst ist. Beim Anwendungsstart sollte eine Verzögerung auferlegt werden, bevor das erste zusammengesetzte RTCP-Paket gesendet wird, um Zeit zu lassen, RTCP-Pakete anderer Teilnehmer zu empfangen, damit das Berichtsintervall schneller zum korrekten Wert konvergiert. Diese Verzögerung kann auf die Hälfte des minimalen Intervalls gesetzt werden, um eine schnellere Benachrichtigung zu ermöglichen, dass der neue Teilnehmer anwesend ist. Der empfohlene Wert für ein festes Mindestintervall beträgt 5 Sekunden.

Eine Implementierung KANN das minimale RTCP-Intervall auf einen kleineren Wert reduzieren, der indirekt proportional zum Sitzungsbandbreitenparameter steht, mit folgenden Einschränkungen:

Für Multicast-Sitzungen dürfen nur aktive Daten sender den reduzierten Mindestwert zur Berechnung des Intervalls für zusammengesetzte RTCP-Pakete verwenden.
Für Unicast-Sitzungen kann der reduzierte Wert auch von Teilnehmern verwendet werden, die keine aktiven Daten sender sind, und die Verzögerung vor dem Senden des ersten zusammengesetzten RTCP-Pakets kann Null sein.
Für alle Sitzungen sollte der feste Mindestwert bei der Berechnung des Ablaufintervalls der Teilnehmer (siehe Abschnitt 6.3.5) verwendet werden, damit Implementierungen, die den reduzierten Wert nicht zum Senden von RTCP-Paketen verwenden, nicht von anderen Teilnehmern vorzeitig abgelaufen werden.
Der empfohlene Wert für das reduzierte Minimum in Sekunden ist 360 geteilt durch die Sitzungsbandbreite in Kilobit pro Sekunde. Dieses Minimum ist für Bandbreiten über 72 kb/s kleiner als 5 Sekunden.

Der in den Abschnitten 6.3 und Anhang A.7 beschriebene Algorithmus wurde entworfen, um die in diesem Abschnitt skizzierten Ziele zu erreichen. Er berechnet das Intervall zwischen dem Senden zusammengesetzter RTCP-Pakete, um die zulässige Steuerbandbreite auf die Teilnehmer aufzuteilen. Dies ermöglicht einer Anwendung, ein schnelles Feedback für kleine Sitzungen zu bieten, wo beispielsweise die Identifikation aller Teilnehmer wichtig ist, während sie sich automatisch an große Sitzungen anpasst. Der Algorithmus weist folgende Eigenschaften auf:

Das berechnete Intervall zwischen RTCP-Paketen wächst linear mit der Anzahl der Gruppenmitglieder. Dies ist der lineare Faktor, der eine konstante Menge an Steuertraffic ergibt, wenn man über alle Mitglieder summiert.
Das Intervall zwischen RTCP-Paketen wird zufällig im Bereich [0,5; 1,5] des berechneten Intervalls variiert, um eine unbeabsichtigte Synchronisation aller Teilnehmer zu vermeiden [20]. Das erste nach dem Beitritt zu einer Sitzung gesendete RTCP-Paket wird ebenfalls um eine zufällige Variation der Hälfte des minimalen RTCP-Intervalls verzögert.
Eine dynamische Schätzung der durchschnittlichen Größe des zusammengesetzten RTCP-Pakets wird berechnet, einschließlich aller empfangenen und gesendeten Pakete, um sich automatisch an Änderungen der transportierten Steuerinformationsmenge anzupassen.
Da das berechnete Intervall von der beobachteten Gruppenmitgliederzahl abhängt, können beim Beitritt eines neuen Benutzers zu einer bestehenden Sitzung oder wenn viele Benutzer gleichzeitig einer neuen Sitzung beitreten unerwünschte Starteffekte auftreten. Diese neuen Benutzer haben anfangs schlechte Schätzungen der Gruppenzugehörigkeit, und ihr RTCP-Sendeintervall ist daher zu kurz. Dieses Problem kann signifikant sein, wenn viele Benutzer gleichzeitig beitreten. Um dies zu behandeln, wird ein Algorithmus namens „Timer-Reconsideration" (Timer-Neuüberlegung) eingesetzt. Dieser Algorithmus implementiert einen einfachen Back-off-Mechanismus, der die Benutzer davon abhält, RTCP-Pakete zu senden, wenn die Gruppengrößen zunehmen.
Wenn Benutzer eine Sitzung verlassen, entweder mit einem BYE oder durch Ablauf, verringert sich die Gruppenzugehörigkeit, und das berechnete Intervall sollte abnehmen. Ein Algorithmus der „Reverse Reconsideration" (Umgekehrten Neuüberlegung) wird verwendet, um den Mitgliedern zu erlauben, ihre Intervalle schneller als Reaktion auf Verringerungen der Gruppenzugehörigkeit zu reduzieren.
BYE-Pakete erhalten eine andere Behandlung als andere RTCP-Pakete. Wenn ein Benutzer eine Gruppe verlässt und ein BYE-Paket senden möchte, kann er dies vor seinem nächsten geplanten RTCP-Paket tun. Die BYE-Übertragung folgt jedoch einem Back-off-Algorithmus, der eine Flut von BYE-Paketen verhindert, falls eine große Anzahl von Mitgliedern die Sitzung gleichzeitig verlässt.

Dieser Algorithmus kann für Sitzungen verwendet werden, in denen alle Teilnehmer senden dürfen. In diesem Fall ist der Sitzungsbandbreitenparameter das Produkt aus der Bandbreite des einzelnen Senders multipliziert mit der Anzahl der Teilnehmer, und die RTCP-Bandbreite ist 5 % davon.

Einzelheiten zur Arbeitsweise des Algorithmus sind in den folgenden Abschnitten gegeben. Anhang A.7 zeigt ein Implementierungsbeispiel.

6.2.1 Maintaining the Number of Session Members (Aufrechterhaltung der Anzahl der Sitzungsmitglieder)

Die Berechnung des RTCP-Paketintervalls hängt von einer Schätzung der Anzahl der an der Sitzung teilnehmenden Standorte ab. Neue Standorte werden der Zählung hinzugefügt, wenn sie gehört werden, und ein Eintrag für jeden sollte in einer nach SSRC- oder CSRC-Identifikator (siehe Abschnitt 8.2) indizierten Tabelle zur Verfolgung erstellt werden. Neue Einträge KÖNNEN als ungültig betrachtet werden, bis mehrere Pakete mit dem neuen SSRC empfangen wurden (siehe Anhang A.1) oder bis ein RTCP-SDES-Paket mit einem CNAME für diesen SSRC empfangen wurde. Einträge KÖNNEN aus der Tabelle entfernt werden, wenn ein RTCP-BYE-Paket mit dem entsprechenden SSRC-Identifikator empfangen wird, außer dass einige nachziehende Datenpakete noch nach dem BYE ankommen und die Neuerstellung des Eintrags verursachen könnten. Stattdessen sollte der Eintrag als mit BYE versehen markiert und nach angemessener Zeit entfernt werden.

Ein Teilnehmer KANN einen anderen Standort inaktiv markieren oder ihn entfernen, falls er noch nicht gültig ist, wenn kein RTP- oder RTCP-Paket über eine kleine Anzahl von RTCP-Berichtsintervallen (5 wird EMPFOHLEN) empfangen wurde. Dies bietet eine gewisse Robustheit gegen Paketverluste. Alle Standorte müssen denselben Wert für diesen Multiplikator haben und etwa denselben Wert für das RTCP-Berichtsintervall berechnen, damit dieser Ablauf korrekt funktioniert. Daher sollte dieser Multiplikator für ein bestimmtes Profil festgelegt werden.

Für Sitzungen mit einer sehr großen Anzahl von Teilnehmern kann es unmöglich sein, eine Tabelle zur Speicherung des SSRC-Identifikators und des Status für alle zu unterhalten. Eine Implementierung KANN SSRC-Sampling wie in [21] beschrieben verwenden, um die Speicheranforderungen zu reduzieren. Eine Implementierung KANN jeden anderen Algorithmus ähnlicher Leistung verwenden. Eine Schlüsselanforderung ist, dass jeder betrachtete Algorithmus die Gruppengröße nicht wesentlich unterschätzen sollte, obwohl er sie überschätzen darf.

6.3 RTCP Packet Send and Receive Rules (RTCP-Paket Sende- und Empfangsregeln)

Die Regeln, wie RTCP-Pakete gesendet werden und was bei Empfang eines solchen zu tun ist, sind hier skizziert. Eine Implementierung, die in einer Multicast- oder Multipoint-Unicast-Umgebung operiert, MUSS die Anforderungen von Abschnitt 6.2 erfüllen. Eine solche Implementierung KANN den in diesem Abschnitt definierten Algorithmus zur Erfüllung dieser Anforderungen verwenden oder einen anderen Algorithmus, solange er gleichwertige oder bessere Leistung bietet. Eine auf Zwei-Parteien-Unicast beschränkte Implementierung SOLLTE dennoch die Randomisierung des RTCP-Sendeintervalls verwenden, um eine unbeabsichtigte Synchronisation mehrerer Instanzen in derselben Umgebung zu vermeiden, kann aber die Algorithmen der „Timer-Reconsideration" und „Reverse Reconsideration" der Abschnitte 6.3.3, 6.3.6 und 6.3.7 weglassen.

Um diese Regeln auszuführen, muss ein Sitzungsteilnehmer mehrere Zustandselemente verwalten:

tp : der letzte Zeitpunkt, zu dem ein RTCP-Paket übertragen wurde;
tc : die aktuelle Zeit;
tn : der nächste geplante Übertragungszeitpunkt eines RTCP-Pakets;
pmembers : die geschätzte Anzahl der Sitzungsmitglieder zum Zeitpunkt, als tn zuletzt neu berechnet wurde;
members : die neueste Schätzung der Anzahl der Sitzungsmitglieder;
senders : die neueste Schätzung der Anzahl der Sender in der Sitzung;
rtcp_bw : Die Ziel-RTCP-Bandbreite, also die gesamte Bandbreite, die von allen Mitgliedern dieser Sitzung für RTCP-Pakete verwendet wird, in Oktetten pro Sekunde. Dies ist ein angegebener Bruchteil des „Sitzungsbandbreite"-Parameters, der der Anwendung beim Start übergeben wurde.
we_sent : Flagge, die wahr ist, falls die Anwendung seit der Übertragung des vorherigen zweiten RTCP-Berichts Daten gesendet hat.
avg_rtcp_size : Die durchschnittliche Größe des zusammengesetzten RTCP-Pakets in Oktetten über alle von diesem Teilnehmer gesendeten und empfangenen RTCP-Pakete. Die Größe umfasst die Header der unteren Transport- und Netzwerkprotokollebenen (beispielsweise UDP und IP) wie in Abschnitt 6.2 erklärt.
initial : Flagge, die wahr ist, falls die Anwendung noch kein RTCP-Paket gesendet hat.

Viele dieser Regeln verwenden das „siebte Intervall" zwischen Paketübertragungen. Dieses Intervall ist im folgenden Abschnitt beschrieben.

6.3.1 Computing the RTCP Transmission Interval (Berechnung des RTCP-Übertragungsintervalls)

Um die Skalierbarkeit aufrechtzuerhalten, sollte das durchschnittliche Intervall zwischen den Paketen eines Sitzungsteilnehmers mit der Gruppengröße wachsen. Dieses Intervall wird berechnetes Intervall genannt. Es ergibt sich aus der Kombination einer Reihe der oben beschriebenen Zustandselemente. Das berechnete Intervall T wird dann wie folgt bestimmt:

Falls die Anzahl der Sender kleiner oder gleich 25 % der Mitgliedschaft (members) ist, hängt das Intervall davon ab, ob der Teilnehmer ein Sender ist (gemäß dem Wert von we_sent). Falls der Teilnehmer ein Sender ist (we_sent wahr), wird die Konstante C auf die durchschnittliche RTCP-Paketgröße (avg_rtcp_size) geteilt durch 25 % der RTCP-Bandbreite (rtcp_bw) gesetzt, und die Konstante n auf die Anzahl der Sender. Falls we_sent nicht wahr ist, wird C auf die durchschnittliche RTCP-Paketgröße geteilt durch 75 % der RTCP-Bandbreite gesetzt. Die Konstante n wird auf die Anzahl der Empfänger (members - senders) gesetzt. Wenn die Anzahl der Sender größer als 25 % ist, werden Sender und Empfänger zusammen behandelt. C wird auf die durchschnittliche RTCP-Paketgröße geteilt durch die gesamte RTCP-Bandbreite gesetzt und n auf die Gesamtzahl der Mitglieder. Wie in Abschnitt 6.2 dargelegt, KANN ein RTP-Profil angeben, dass die RTCP-Bandbreite explizit durch zwei separate Parameter (nennen wir sie S und R) für sendende und nicht sendende Teilnehmer definiert werden kann. In diesem Fall wird der 25 %-Anteil zu S/(S+R) und der 75 %-Anteil zu R/(S+R). Beachten Sie, dass, falls R null ist, der Prozentsatz der Sender nie größer als S/(S+R) ist, und die Implementierung eine Division durch Null vermeiden muss.
Falls der Teilnehmer noch kein RTCP-Paket gesendet hat (die Variable initial ist wahr), wird die Konstante Tmin auf 2,5 Sekunden gesetzt, andernfalls auf 5 Sekunden.
Das deterministische berechnete Intervall Td wird auf max(Tmin, n*C) gesetzt.
Das berechnete Intervall T wird auf eine gleichmäßig zwischen 0,5 und 1,5 mal dem deterministischen berechneten Intervall verteilte Zahl gesetzt.
Der resultierende Wert von T wird durch e-3/2 = 1,21828 geteilt, um den Umstand zu kompensieren, dass der Timer-Reconsideration-Algorithmus gegen einen Wert der RTCP-Bandbreite konvergiert, der unter dem erwarteten Durchschnitt liegt.

Dieses Verfahren liefert ein zufälliges Intervall, das aber im Durchschnitt mindestens 25 % der RTCP-Bandbreite den Sendern und den Rest den Empfängern gibt. Falls die Sender mehr als ein Viertel der Mitgliedschaft ausmachen, teilt dieses Verfahren die Bandbreite im Durchschnitt gleichmäßig zwischen allen Teilnehmern auf.

6.3.2 Initialization (Initialisierung)

Beim Beitritt zur Sitzung initialisiert der Teilnehmer tp auf 0, tc auf 0, senders auf 0, pmembers auf 1, members auf 1, we_sent auf falsch, rtcp_bw auf den angegebenen Bruchteil der Sitzungsbandbreite, initial auf wahr und avg_rtcp_size auf die wahrscheinliche Größe des ersten RTCP-Pakets, das die Anwendung später konstruieren wird. Das berechnete Intervall T wird dann berechnet, und das erste Paket ist für den Zeitpunkt tn = T geplant. Das bedeutet, ein Sendezeitgeber wird gesetzt, der zum Zeitpunkt T abläuft. Beachten Sie, dass eine Anwendung jeden gewünschten Ansatz zur Implementierung dieses Zeitgebers verwenden kann.

Der Teilnehmer fügt seinen eigenen SSRC der Mitgliedertabelle hinzu.

6.3.3 Receiving an RTP or Non-BYE RTCP Packet (Empfang eines RTP- oder Nicht-BYE-RTCP-Pakets)

Wenn ein RTP- oder RTCP-Paket von einem Teilnehmer empfangen wird, dessen SSRC nicht in der Mitgliedertabelle ist, wird der SSRC der Tabelle hinzugefügt, und der Wert von members wird aktualisiert, nachdem der Teilnehmer wie in Abschnitt 6.2.1 beschrieben validiert wurde. Dieselbe Behandlung erfolgt für jeden CSRC in einem validierten RTP-Paket.

Wenn ein RTP-Paket von einem Teilnehmer empfangen wird, dessen SSRC nicht in der Sendertabelle ist, wird der SSRC der Tabelle hinzugefügt, und der Wert von senders wird aktualisiert.

Für jedes empfangene zusammengesetzte RTCP-Paket wird der Wert von avg_rtcp_size aktualisiert:

avg_rtcp_size = (1/16) * packet_size + (15/16) * avg_rtcp_size

wobei packet_size die Größe des gerade empfangenen RTCP-Pakets ist.

6.3.4 Receiving an RTCP BYE Packet (Empfang eines RTCP-BYE-Pakets)

Außer wie in Abschnitt 6.3.7 für den Fall beschrieben, dass ein RTCP-BYE gesendet werden muss, wird bei Empfang eines RTCP-BYE-Pakets der SSRC gegen die Mitgliedertabelle geprüft. Falls vorhanden, wird der Eintrag aus der Tabelle entfernt und der Wert von members aktualisiert. Der SSRC wird dann gegen die Sendertabelle geprüft. Falls vorhanden, wird der Eintrag entfernt und senders aktualisiert.

Zusätzlich, um die RTCP-Senderate an Änderungen der Gruppenzugehörigkeit anzupassen, SOLLTE der folgende Algorithmus der „Reverse Reconsideration" ausgeführt werden, wenn ein empfangenes BYE-Paket members auf einen Wert unter pmembers reduziert:

Der Wert von tn wird gemäß folgender Formel aktualisiert:

tn = tc + (members/pmembers) * (tn - tc)

Der Wert von tp wird gemäß folgender Formel aktualisiert:

tp = tc - (members/pmembers) * (tc - tp)

Das nächste RTCP-Paket wird für die Übertragung zum Zeitpunkt tn neu geplant, der nun früher liegt.
Der Wert von pmembers wird gleich members gesetzt.

Dieser Algorithmus verhindert nicht, dass die Schätzung der Gruppengröße für eine kurze Zeit fälschlich auf Null fällt, wenn die meisten Teilnehmer einer großen Sitzung gleichzeitig gehen, aber einige bleiben. Der Algorithmus bringt die Schätzung schneller zum korrekten Wert zurück. Diese Situation ist eher ungewöhnlich, und die Folgen sind harmlos genug, um als nachrangiges Problem betrachtet zu werden.

6.3.5 Timing Out an SSRC (Ablauf eines SSRC)

Gelegentlich muss der Teilnehmer prüfen, ob einer der anderen Teilnehmer abläuft. Dazu berechnet der Teilnehmer das deterministische (ohne den Randomisierungsfaktor) berechnete Intervall Td für einen Empfänger, also mit we_sent falsch. Jedes andere Sitzungsmitglied, das seit dem Zeitpunkt tc - MTd (M ist der Ablauf-Multiplikator, Standardwert 5) kein RTP- oder RTCP-Paket gesendet hat, läuft ab. Das bedeutet, sein SSRC wird aus der Mitgliederliste entfernt und members aktualisiert. Eine ähnliche Prüfung wird für die Senderliste durchgeführt. Jedes Mitglied der Senderliste, das seit dem Zeitpunkt tc - 2T (in den beiden letzten RTCP-Berichtsintervallen) kein RTP-Paket gesendet hat, wird aus der Senderliste entfernt und senders aktualisiert.

Falls Mitglieder ablaufen, SOLLTE der in Abschnitt 6.3.4 beschriebene Reverse-Reconsideration-Algorithmus ausgeführt werden.

Der Teilnehmer MUSS diese Prüfung mindestens einmal pro RTCP-Sendeintervall durchführen.

6.3.6 Expiration of Transmission Timer (Ablauf des Sendezeitgebers)

Wenn der Paketsendezeitgeber abläuft, führt der Teilnehmer folgende Operationen aus:

Das Sendeintervall T wird wie in Abschnitt 6.3.1 beschrieben berechnet, einschließlich des Randomisierungsfaktors.
Falls tp + T kleiner oder gleich tc ist, wird ein RTCP-Paket übertragen. tp wird auf tc gesetzt, dann ein weiterer Wert für T wie im vorigen Schritt berechnet und tn auf tc + T gesetzt. Der Sendezeitgeber wird für den erneuten Ablauf zum Zeitpunkt tn gesetzt. Falls tp + T größer als tc ist, wird tn auf tp + T gesetzt. Es wird kein RTCP-Paket übertragen. Der Sendezeitgeber wird für den Ablauf zum Zeitpunkt tn gesetzt.
pmembers wird auf members gesetzt.

Falls ein RTCP-Paket übertragen wird, wird der Wert von initial auf FALSCH gesetzt. Zusätzlich wird der Wert von avg_rtcp_size aktualisiert:

avg_rtcp_size = (1/16) * packet_size + (15/16) * avg_rtcp_size

wobei packet_size die Größe des gerade übertragenen RTCP-Pakets ist.

6.3.7 Transmitting a BYE Packet (Übertragung eines BYE-Pakets)

Wenn ein Teilnehmer eine Sitzung verlassen möchte, wird ein BYE-Paket übertragen, um die anderen Teilnehmer über das Ereignis zu informieren. Um eine Flut von BYE-Paketen zu vermeiden, wenn viele Teilnehmer das System verlassen, MUSS ein Teilnehmer den folgenden Algorithmus ausführen, falls die Mitgliederzahl bei der Entscheidung zum Verlassen größer als 50 ist. Dieser Algorithmus übernimmt die Rolle der Variablen members, um BYE-Pakete stattdessen zu zählen:

Wenn der Teilnehmer beschließt, das System zu verlassen, wird tp auf tc (die aktuelle Zeit) zurückgesetzt, members und pmembers werden auf 1 initialisiert, initial auf 1 gesetzt, we_sent auf falsch, senders auf 0 und avg_rtcp_size auf die Größe des zusammengesetzten BYE-Pakets. Das berechnete Intervall T wird berechnet. Das BYE-Paket wird dann für den Zeitpunkt tn = tc + T geplant.
Jedes Mal, wenn ein BYE-Paket eines anderen Teilnehmers empfangen wird, wird members unabhängig davon um 1 erhöht, ob dieser Teilnehmer in der Mitgliedertabelle existiert, und wenn SSRC-Sampling verwendet wird, unabhängig davon, ob der BYE-SSRC in die Stichprobe aufgenommen worden wäre. members wird NICHT erhöht, wenn andere RTCP- oder RTP-Pakete empfangen werden, sondern nur für BYE-Pakete. Ebenso wird avg_rtcp_size nur für empfangene BYE-Pakete aktualisiert. senders wird bei Eintreffen von RTP-Paketen NICHT aktualisiert; er bleibt 0.
Die Übertragung des BYE-Pakets folgt dann den Regeln für die Übertragung eines regulären RTCP-Pakets wie oben.

Dies ermöglicht das sofortige Senden von BYE-Paketen, während deren gesamte Bandbreitennutzung kontrolliert wird. Im schlimmsten Fall könnte dies bewirken, dass der RTCP-Steuertraffic das Doppelte der üblichen Bandbreite (10 %) verwendet -- 5 % für Nicht-BYE-RTCP-Pakete und 5 % für BYE.

Ein Teilnehmer, der nicht warten möchte, bis der obige Mechanismus das Senden eines BYE-Pakets erlaubt, KANN die Gruppe verlassen, ohne überhaupt ein BYE zu senden. Dieser Teilnehmer wird schließlich von den anderen Gruppenmitgliedern abgelaufen.

Falls die Schätzung der Gruppengröße members beim Entschluss des Teilnehmers zum Verlassen kleiner als 50 ist, KANN der Teilnehmer sofort ein BYE-Paket senden. Alternativ kann der Teilnehmer den obigen BYE-Back-off-Algorithmus ausführen.

In beiden Fällen darf ein Teilnehmer, der noch nie ein RTP- oder RTCP-Paket gesendet hat, KEIN BYE-Paket senden, wenn er die Gruppe verlässt.

6.3.8 Updating we_sent (Aktualisierung von we_sent)

Die Variable we_sent enthält wahr, falls der Teilnehmer kürzlich ein RTP-Paket gesendet hat, sonst falsch. Diese Bestimmung erfolgt mit denselben Mechanismen wie für die Verwaltung der anderen in der Sendertabelle aufgelisteten Teilnehmer. Wenn der Teilnehmer ein RTP-Paket sendet, während we_sent falsch ist, fügt er sich der Sendertabelle hinzu und setzt we_sent auf wahr. Der in Abschnitt 6.3.4 beschriebene Reverse-Reconsideration-Algorithmus SOLLTE ausgeführt werden, um die Verzögerung vor dem Senden eines SR-Pakets möglicherweise zu verringern. Jedes Mal, wenn ein weiteres RTP-Paket gesendet wird, wird der Sendezeitpunkt dieses Pakets in der Tabelle gepflegt. Der normale Ablaufalgorithmus für Sender wird dann auf den Teilnehmer angewendet -- falls seit dem Zeitpunkt tc - 2T kein RTP-Paket übertragen wurde, entfernt sich der Teilnehmer aus der Sendertabelle, verringert den Senderzähler und setzt we_sent auf falsch.

6.3.9 Allocation of Source Description Bandwidth (Zuweisung der Quellenbeschreibungsbandbreite)

Diese Spezifikation definiert neben dem obligatorischen CNAME-Element weitere Quellenbeschreibungselemente (SDES) wie NAME (persönlicher Name) und EMAIL (E-Mail-Adresse). Sie bietet auch eine Möglichkeit, neue anwendungsspezifische RTCP-Pakettypen zu definieren. Anwendungen sollten bei der Zuweisung von Steuerbandbreite an diese Zusatzinformationen Vorsicht walten lassen, da dies die Rate verlangsamt, mit der Empfangsberichte und CNAME gesendet werden, und damit die Protokollleistung beeinträchtigt. Es wird EMPFOHLEN, dass höchstens 20 % der einem einzelnen Teilnehmer zugewiesenen RTCP-Bandbreite für den Transport der Zusatzinformation verwendet werden. Zudem ist nicht vorgesehen, dass alle SDES-Elemente in jeder Anwendung enthalten sind. Die eingeschlossenen SOLLTEN einen Bruchteil der Bandbreite gemäß ihrem Nutzen erhalten. Anstatt diese Bruchteile dynamisch zu schätzen, wird empfohlen, die Prozentsätze statisch in Berichtsintervallzählungen basierend auf der typischen Länge eines Elements zu übersetzen.

Beispielsweise könnte eine Anwendung so entworfen sein, dass sie nur CNAME, NAME und EMAIL sendet und keine anderen. NAME könnte eine viel höhere Priorität als EMAIL erhalten, weil NAME ständig in der Benutzeroberfläche der Anwendung angezeigt würde, während EMAIL nur auf Anfrage angezeigt würde. Bei jedem RTCP-Intervall würden ein RR-Paket und ein SDES-Paket mit dem CNAME-Element gesendet. Für eine kleine Sitzung, die mit dem minimalen Intervall läuft, wäre das im Durchschnitt alle 5 Sekunden. Alle drei Intervalle (15 Sekunden) würde ein zusätzliches Element in das SDES-Paket aufgenommen. Siebenmal von acht wäre es das NAME-Element, und beim achten Mal (2 Minuten) das EMAIL-Element.

Wenn mehrere Anwendungen im Zusammenspiel über eine Inter-Anwendungsverbindung über einen gemeinsamen CNAME für jeden Teilnehmer operieren, beispielsweise in einer Multimediakonferenz, die aus einer RTP-Sitzung pro Medium besteht, KANN die zusätzliche SDES-Information in einer einzigen RTP-Sitzung gesendet werden. Die anderen Sitzungen würden nur das CNAME-Element transportieren. Insbesondere sollte dieser Ansatz auf die mehreren Sitzungen eines geschichteten Kodierungsschemas angewendet werden (siehe Abschnitt 2.4).

6.4 Sender and Receiver Reports (Sender- und Empfangsberichte)

Die RTCP-Senderberichte (SR, Sender Report) und Empfangsberichte (RR, Receiver Report) liefern Statistiken zur Empfangsqualität für die Medien. Reguläre (aktive) Datensender senden SR, und Empfänger, die keine aktiven Sender sind, senden RR. SR enthalten sowohl Sende- als auch Empfangsstatistiken; das zusätzliche Feld ist am nützlichsten, wenn ein Sender auch Empfänger ist.

Das Format der SR- und RR-Pakete, mit der Darstellung ihrer Unterfelder, ist wie folgt:

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
header |V=2|P|    RC   |   PT=SR=200   |             length            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                         SSRC of sender                        |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
sender |              NTP timestamp, most significant word             |
info   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |             NTP timestamp, least significant word             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                         RTP timestamp                         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                     sender's packet count                     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                      sender's octet count                     |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
report |                 SSRC_1 (SSRC of first source)                 |
block  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1    | fraction lost |       cumulative number of packets lost       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |           extended highest sequence number received           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                      interarrival jitter                      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                         last SR (LSR)                         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                   delay since last SR (DLSR)                   |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
report |                 SSRC_2 (SSRC of second source)                |
block  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2    :                               ...                             :
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
 |                  profile-specific extensions                      |
 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

6.4.1 SR: Sender Report RTCP Packet (SR : RTCP-Senderbericht-Paket)

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
header |V=2|P|    RC   |   PT=SR=200   |             length            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                         SSRC of sender                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
sender |              NTP timestamp, most significant word             |
info   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |             NTP timestamp, least significant word             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                         RTP timestamp                         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                     sender's packet count                     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                      sender's octet count                     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Das Format des SR-Pakets ist wie folgt:

Version (V) : 2 Bits. Wie in Abschnitt 5.1 definiert.
Füllung (P) : 1 Bit. Wie in Abschnitt 5.1 definiert. Falls das Füllbit gesetzt ist, enthält dieses Paket am Ende weitere Fülloktette, die nicht zum Steuerinformationsteil gehören. Das letzte Fülloktett enthält eine Zählung, wie viele Oktette ignoriert werden sollen, einschließlich seiner selbst. Siehe Abschnitt 6.6.1 für die Bedeutung von Füllung für das zusammengesetzte Paket. Die Erhöhung ist nicht notwendig, falls die Länge des zusammengesetzten Pakets ein Vielfaches von 4 Oktetten ist.
Berichtszähler (RC, Report Count) : 5 Bits. Die Anzahl der im Paket enthaltenen Empfangsberichtsblöcke (Reception Report Block). Ein Wert von Null ist gültig.
Pakettyp (PT, Packet Type) : 8 Bits. Enthält die Konstante 200, um anzuzeigen, dass dieses Paket ein RTCP-SR-Paket ist.
Länge (Length) : 16 Bits. Die Länge dieses RTCP-Pakets in Einheiten von 32 Bits minus eins; dies umfasst den Header und etwaige Füllung. (Die Rechtfertigung für die Verringerung um eins ist, dass der Wert Null eine gültige Wahl im 16-Bit-Längenfeld ist, während für Header höherer Protokollebenen der Wert Null fast immer für eine andere Verwendung reserviert ist.) Dies ist konform zum 16-Bit-Längenfeld im festen RTP-Header, beschrieben in Abschnitt 5.1.
SSRC des Senders (SSRC of Sender) : 32 Bits. Der Identifikator der Synchronisationsquelle für den Erzeuger dieses Pakets.
NTP-Abtastzeitpunkt (NTP Timestamp) : 64 Bits. Entspricht dem Abtastzeitpunkt (siehe Abschnitt 5.1), zu dem die RTP-Zeitstempel- und Senderinformationen in diesem Bericht gemessen werden. Hinsichtlich der RTP-Zeitstempelinformationen ist es nicht notwendig, dass die Wanduhren des Teilnehmers für die Nützlichkeit der NTP-Zeitstempelmessungen synchronisiert sind. Im Gegensatz zu den meisten Zustandsautomaten muss ein Teilnehmer nicht denselben NTP-Zeitstempel für jedes SR-Paket verwenden, solange das NTP-RTP-Zeitstempelpaar zum Abtastzeitpunkt berechnet wird. Dieser Teilnehmer KANN die Wanduhr eines beliebigen Zeitpunkts als Uhrenbasis zur Messung der Abtastzeitpunkte verwenden, unabhängig von der Wanduhr eines anderen Teilnehmers. Die Bedeutung dieses Feldes liegt darin, die Schätzung und inter-mediale Synchronisation der RTP-Zeitstempelpaare aus verschiedenen Quellen dieses Teilnehmers zu ermöglichen.
RTP-Zeitstempel (RTP Timestamp) : 32 Bits. Entspricht dem NTP-Abtastzeitpunkt (oben) mit derselben Einheit und demselben zufälligen Versatz wie die RTP-Zeitstempel der Datensitzung. Diese Korrespondenz kann verwendet werden, um die RTP-Zeitstempel unabhängiger Medien in einer Multimediasitzung zu verknüpfen und die Ende-zu-Ende-Verzögerung des Medienstroms zu messen.
Paketzähler des Senders (Sender's Packet Count) : 32 Bits. Die Gesamtzahl der vom Sender seit Beginn der Übertragung einschließlich des in diesem Bericht erfassten Abtastzeitpunkts gesendeten RTP-Pakete. Dieser Zähler SOLLTE zurückgesetzt werden, falls der Sender seinen SSRC-Identifikator ändert.
Oktettzähler des Senders (Sender's Octet Count) : 32 Bits. Die Gesamtzahl der Nutzlastoktette (das heißt ohne Header oder Füllung) der Mediendaten, die vom Sender in RTP-Datenpaketen seit Beginn der Übertragung gesendet wurden. Dieser Zähler SOLLTE zurückgesetzt werden, falls der Sender seinen SSRC-Identifikator ändert. Dieses Feld kann zur Schätzung der durchschnittlichen Nutzlastrate verwendet werden.

6.4.2 RR: Receiver Report RTCP Packet (RR : RTCP-Empfangsbericht-Paket)

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
header |V=2|P|    RC   |   PT=RR=201   |             length            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                     SSRC of packet sender                   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
report |                 SSRC_1 (SSRC of first source)                 |
block  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1    | fraction lost |       cumulative number of packets lost       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |           extended highest sequence number received           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                      interarrival jitter                      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                         last SR (LSR)                         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                   delay since last SR (DLSR)                   |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
report |                 SSRC_2 (SSRC of second source)                |
block  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2    :                               ...                             :
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
 |                  profile-specific extensions                      |
 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

Das Format des RR-Pakets ist wie folgt:

Version (V), Füllung (P), Berichtszähler (RC), Pakettyp (PT), Länge (Length) : wie für das SR-Paket definiert (Abschnitt 6.4.1).
SSRC des Paketsenders (SSRC of Packet Sender) : 32 Bits. Der Identifikator der Synchronisationsquelle für den Erzeuger dieses Pakets. Falls ein Teilnehmer Empfangsberichte von einem einzelnen Medium, mehreren Medien einer Sitzung oder mehreren Medien mehrerer Sitzungen sendet, ist der Paket-SSRC der des Teilnehmers.

Ein RR-Paket enthält keine Senderinformationen, folgt aber demselben Format wie das SR-Paket ab dem Berichtszählerfeld. Das folgende Format wird für jeden Empfangsberichtsblock verwendet, falls der Berichtszähler größer als Null ist.

6.4.3 Extending the Sender and Receiver Reports (Erweiterung der Sender- und Empfangsberichte)

Falls ein RTP-Profil Erweiterungen der Sender- oder Empfangsinformationen über die Basisinformationen hinaus definiert, könnte ein anwendungsspezifisches Profil definiert werden, um sie mittels eines Erweiterungsberichtsmechanismus zu transportieren. Eine solche Lösung ist anwendungsspezifisch und liegt außerhalb des Rahmens dieses Dokuments. Der Header eines RTCP-Pakets könnte von strukturierten Erweiterungs- und Erweiterungsabschnitten gefolgt sein, aber diese SOLLTEN unabhängig von den von RTCP für die Empfangsberichtsblöcke bereitgestellten Längen- und Zählmechanismen definiert werden.

6.4.4 Analyzing Sender and Receiver Reports (Analyse der Sender- und Empfangsberichte)

Es wird erwartet, dass das Feedback über die Empfangsqualität nicht nur für den Sender nützlich ist, sondern auch für andere Empfänger und Drittanbieter-Überwacher. Der Sender kann seine Übertragungen basierend auf dem Feedback anpassen; die Empfänger können bestimmen, ob Probleme lokal, regional oder global sind; Netzwerkmanager können unabhängige profilunabhängige Überwacher verwenden, die nur die RTCP-Pakete und nicht die entsprechenden RTP-Datenpakete empfangen, um die Leistung ihrer Netze für die Multicast-Verteilung zu bewerten.

Kumulative Zähler werden sowohl in den Senderinformationen als auch in den Empfangsberichtsblöcken verwendet, damit Differenzen zwischen beliebigen zwei Berichten zur Messung über kurze und lange Zeiträume berechnet werden können und um Resilienz gegen den Verlust eines Berichts zu bieten. Die Differenz zwischen den beiden zuletzt empfangenen Berichten kann zur Schätzung der aktuellen Verteilungsqualität verwendet werden. Der NTP-Zeitstempel ist eingeschlossen, damit Raten über das Intervall zwischen zwei Berichten berechnet werden können. Da dieser Zeitstempel unabhängig von der Taktfrequenz für die Datenkodierung ist, ist es möglich, qualitätsunabhängige Überwacher unabhängig von Kodierung und Profil zu implementieren.

Ein Beispiel für eine Berechnung ist die Paketverlustrate über das Intervall zwischen zwei Empfangsberichten. Die Differenz in der kumulativen Anzahl verlorener Pakete gibt die im Intervall verlorene Anzahl an. Die Differenz in den empfangenen erweiterten Sequenznummern gibt die im Intervall erwartete Paketanzahl an. Das Verhältnis dieser beiden Werte ist der Paketverlustanteil im Intervall. Dieses Verhältnis sollte gleich dem Feld „Fraction Lost" sein, falls die beiden Berichte aufeinanderfolgend sind, stimmt sonst aber möglicherweise nicht überein. Die Verlustrate pro Sekunde kann erhalten werden, indem der Verlustanteil durch die Differenz der NTP-Zeitstempel (in Sekunden) geteilt wird. Die Anzahl empfangener Pakete ist die Anzahl erwarteter Pakete minus die Anzahl verlorener. Die Anzahl erwarteter Pakete kann auch zur Beurteilung der statistischen Gültigkeit einer beliebigen Verlustschätzung verwendet werden. Beispielsweise ist der Verlust von 1 von 5 Paketen weniger aussagekräftig als der Verlust von 200 von 1000 Paketen.

Aus den Senderinformationen kann ein Drittanbieter-Überwacher die durchschnittliche Nutzlastrate und die durchschnittliche Paketrate über ein Intervall berechnen, ohne die Daten zu empfangen. Das Verhältnis der beiden ergibt die durchschnittliche Nutzlastgröße. Falls angenommen werden kann, dass der Paketverlust unabhängig von der Paketgröße ist, dann multipliziert mit der durchschnittlichen Nutzlastgröße (oder der entsprechenden Paketgröße) die Anzahl der von einem bestimmten Empfänger empfangenen Pakete die scheinbar verfügbare Rate für diesen Empfänger.

Zusätzlich zu den kumulativen Zählern, die Langzeitverlustmessungen mittels Differenzen zwischen Berichten ermöglichen, liefert das Feld „Fraction Lost" eine Kurzzeitmessung aus einem einzigen Bericht. Dies wird wichtiger, je größer eine Sitzung wird, bis zu dem Punkt, dass der Empfangsstatus für alle Empfänger möglicherweise nicht mehr vorgehalten wird oder das Intervall zwischen Berichten lang genug wird, dass von einem bestimmten Empfänger nur ein Bericht empfangen worden sein könnte.

Das Feld „Inter-Arrival Jitter" liefert ein zweites Kurzzeitmaß für die Netzwerküberlastung. Paketverlust folgt anhaltender Überlastung, während die Jitter-Messung vorübergehender Überlastung folgt. Die Jitter-Messung kann eine Überlastung anzeigen, bevor sie zu Paketverlusten führt. Das Inter-Arrival-Jitter-Feld ist nur eine Momentaufnahme des Jitter zum Zeitpunkt eines Berichts und nicht quantitativ zu verstehen. Vielmehr dient es dem Vergleich über eine Reihe von Berichten eines Empfängers im Laufe der Zeit oder über mehrere Empfänger, beispielsweise innerhalb desselben Netzwerks zur selben Zeit. Um den Vergleich zwischen Empfängern zu ermöglichen, ist es wichtig, dass der Jitter nach derselben Formel von allen Empfängern berechnet wird.

Da die Jitter-Berechnung auf dem RTP-Zeitstempel basiert, der den Zeitpunkt darstellt, zu dem das erste Datenabtastwert im Paket abgetastet wurde, beeinflusst jede Variation der Verzögerung zwischen diesem Abtastzeitpunkt und dem Zeitpunkt der Paketübertragung den berechneten Jitter. Eine solche Verzögerungsvariation tritt für Pakete mit variabler Audiodauer auf. Sie tritt auch für Video-Kodierungen auf, da der Zeitstempel für alle Pakete eines Frames derselbe ist, diese Pakete aber nicht alle gleichzeitig übertragen werden. Die Verzögerungsvariation bis zur Übertragung verringert effektiv die Genauigkeit der Jitter-Berechnung als Maß für das Netzwerkverhalten selbst, ist aber in Anbetracht dessen, dass der Empfangspuffer sie aufnehmen muss, angemessen einzubeziehen. Wenn die Jitter-Berechnung als Vergleichsmaß verwendet wird, hebt sich die (konstante) Komponente aus der Verzögerungsvariation bis zur Übertragung auf, sodass eine Änderung der Netzwerk-Jitter-Komponente beobachtet werden kann, sofern sie nicht relativ klein ist. Wenn die Änderung klein ist, ist sie wahrscheinlich unbedeutend.

6.5 SDES: Source Description RTCP Packet (SDES : RTCP-Quellenbeschreibungspaket)

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
header |V=2|P|    SC   |  PT=SDES=202  |             length            |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
chunk  |                          SSRC/CSRC_1                          |
  1    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                           SDES items                          |
       |                              ...                              |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
chunk  |                          SSRC/CSRC_2                          |
  2    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                           SDES items                          |
       |                              ...                              |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

Das SDES-Paket ist eine dreistufige Struktur, bestehend aus einem Header und null oder mehr Blöcken (Chunks), von denen jeder aus Elementen besteht, die die im Block identifizierte Quelle beschreiben. Die Elemente werden in den folgenden Abschnitten einzeln beschrieben.

Version (V), Füllung (P), Länge (Length) : Wie für das SR-Paket beschrieben (siehe Abschnitt 6.4.1).
Pakettyp (PT) : 8 Bits. Enthält die Konstante 202, um dieses Paket als RTCP-SDES-Paket zu identifizieren.
Quellenzähler (SC, Source Count) : 5 Bits. Die Anzahl der im SDES-Paket enthaltenen SSRC/CSRC-Blöcke. Ein Wert von Null ist gültig, aber nutzlos.

Jeder Block besteht aus einem SSRC/CSRC-Identifikator gefolgt von einer Liste von null oder mehr Elementen, die Informationen über den SSRC/CSRC tragen. Jeder Block beginnt an einer 32-Bit-Grenze. Jedes Element besteht aus einem 8-Bit-Typfeld, einem 8-Bit-Längenzähler, der die Textlänge beschreibt (also ohne diesen 2-Oktett-Header), und dem Text selbst. Beachten Sie, dass der Text 255 Oktette nicht überschreiten darf, was jedoch mit dem Bedürfnis, die RTCP-Bandbreite zu begrenzen, im Einklang ist.

Der Text ist gemäß dem in RFC 2279 [5] spezifizierten UTF-8-Encoding kodiert. US-ASCII ist eine Untermenge dieses Encodings und erfordert keine zusätzliche Kodierung. Das Vorhandensein von Multi-Oktett-Kodierungen wird angezeigt, indem das höchstwertige Bit eines Zeichens auf eins gesetzt wird.

Die Elemente sind zusammenhängend, das heißt, die Elemente werden nicht einzeln auf eine 32-Bit-Grenze aufgefüllt. Der Text wird nicht durch ein Nullzeichen abgeschlossen, da einige Multi-Oktett-Kodierungen Null-Oktette einschließen. Die Liste der Elemente in jedem Block MUSS durch ein oder mehr Null-Oktette abgeschlossen werden, wobei das erste als Elementtyp Null interpretiert wird, das das Listenende kennzeichnet. Auf das Null-Element-Typ-Oktett folgt kein Längen-Oktett, aber weitere Null-Oktette MÜSSEN eingefügt werden, falls nötig, um auf die nächste 32-Bit-Grenze aufzufüllen. Beachten Sie, dass diese Füllung von der durch das P-Bit im RTCP-Header angezeigten Füllung verschieden ist. Ein Block mit null Elementen (vier Null-Oktette) ist gültig, aber nutzlos.

Endsysteme senden ein SDES-Paket mit ihrem eigenen Quellenidentifikator (derselbe wie der SSRC im festen RTP-Header). Ein Mischer sendet ein SDES-Paket mit einem Block für jede Beitragende Quelle, von der er SDES-Informationen erhält, oder mehrere vollständige SDES-Pakete im obigen Format, falls es mehr als 31 solcher Quellen gibt (siehe Abschnitt 7).

Die derzeit definierten SDES-Elemente werden in den folgenden Abschnitten beschrieben. Nur das CNAME-Element ist obligatorisch. Einige hier gezeigte Elemente können nur für bestimmte Profile nützlich sein, aber die Elementtypen sind alle aus einem gemeinsamen Raum zugewiesen, um eine gemeinsame Nutzung und einfache profilunabhängige Anwendungen zu fördern. Zusätzliche Elemente können in einem Profil definiert werden, indem die Typnummern wie in Abschnitt 15 beschrieben bei der IANA registriert werden.

6.5.1 CNAME: Canonical End-Point Identifier SDES Item (CNAME : Kanonisches Endpunkt-Identifikator-SDES-Element)

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|    CNAME=1    |     length    | user and domain name        ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Der CNAME-Identifikator hat folgende Eigenschaften:

Da der zufällig zugewiesene SSRC-Identifikator sich ändern kann, falls ein Konflikt entdeckt wird oder ein Programm neu gestartet wird, MUSS das CNAME-Element enthalten sein, um die Verbindung zwischen dem SSRC-Identifikator und einem Identifikator für die Quelle (Sender oder Empfänger) bereitzustellen, der konstant bleibt.
Wie der SSRC-Identifikator SOLLTE auch der CNAME-Identifikator unter allen Teilnehmern innerhalb einer RTP-Sitzung eindeutig sein.
Um eine Verbindung über mehrere zusammenarbeitende Multimedia-Werkzeuge eines Teilnehmers in einem Satz verknüpfter RTP-Sitzungen zu ermöglichen, SOLLTE der CNAME für diesen Teilnehmer fest sein.
Um den Drittanbieter-Überwacher zu erleichtern, SOLLTE der CNAME so beschaffen sein, dass ein Programm oder eine Person die Quelle lokalisieren kann.

Daher SOLLTE der CNAME algorithmisch abgeleitet werden und nicht manuell eingegeben werden, falls möglich. Um diese Anforderungen zu erfüllen, SOLLTE das folgende Format verwendet werden, sofern ein Profil keine alternative Syntax oder Semantik spezifiziert. Das CNAME-Element SOLLTE das Format „user@host" haben oder „host", falls kein Benutzername verfügbar ist, wie auf Einzelbenutzersystemen. Für beide Formate ist „host" entweder der vollqualifizierte Domänenname (FQDN) des Hosts, von dem die Echtzeitdaten stammen, formatiert gemäß den Regeln in RFC 1034 [6], RFC 1035 [7] und Abschnitt 2.1 von RFC 1123 [8]; oder die Standard-ASCII-Darstellung der numerischen Host-Adresse auf der für die RTP-Kommunikation verwendeten Schnittstelle. Beispielsweise ist die Standard-ASCII-Darstellung einer IPv4-Adresse die „punktierte Dezimaldarstellung" (dotted decimal), auch dotted quad genannt, und für IPv6 werden Adressen textuell als durch Doppelpunkte getrennte Gruppen hexadezimaler Ziffern dargestellt (mit Details in RFC 3513 [23]). Es wird erwartet, dass andere Adresstypen ebenfalls eindeutige ASCII-Darstellungen haben. Der vollqualifizierte Domänenname ist für einen menschlichen Beobachter bequemer und kann den Bedarf ersparen, zusätzlich ein NAME-Element zu senden, kann aber in einigen Betriebsumgebungen schwer oder unmöglich zuverlässig zu erhalten sein. Anwendungen, die in solchen Umgebungen ausgeführt werden könnten, SOLLTEN stattdessen die ASCII-Darstellung der Adresse verwenden.

Beispiele sind „[email protected]", „[email protected]" oder „doe@2201:056D::112E:144A:1E24" für ein Mehrbenutzersystem. Auf einem System ohne Benutzernamen wären Beispiele „sleepy.example.com", „192.0.2.89" oder „2201:056D::112E:144A:1E24".

Der Benutzername SOLLTE in einer Form vorliegen, die ein Programm wie „finger" oder „talk" nutzen könnte, das heißt typischerweise der Anmeldename eher als der persönliche Name. Der Hostname muss nicht mit der E-Mail-Adresse des Teilnehmers identisch sein.

Diese Syntax liefert keine eindeutigen Identifikatoren für jede Quelle, falls eine Anwendung einem Benutzer erlaubt, mehrere Quellen von einem Host zu erzeugen. Eine solche Anwendung sollte sich auf den SSRC stützen, um die Quelle weiter zu identifizieren, oder das Profil für diese Anwendung sollte eine zusätzliche Syntax für den CNAME-Identifikator spezifizieren.

Falls jede Anwendung ihren CNAME unabhängig erzeugt, werden die resultierenden CNAMEs möglicherweise nicht identisch sein, wie es eine Verbindung über mehrere Multimedia-Werkzeuge eines Teilnehmers in einem Satz verknüpfter RTP-Sitzungen erfordern würde. Falls eine inter-mediale Verbindung benötigt wird, kann es notwendig sein, den CNAME jedes Werkzeugs extern mit demselben Wert über ein Koordinationswerkzeug zu konfigurieren.

Anwendungsautoren sollten sich bewusst sein, dass private Netzwerkadresszuweisungen wie die in RFC 1918 [24] vorgeschlagene Net-10-Zuweisung Adressen erzeugen können, die nicht global eindeutig sind. Dies führt zu nicht eindeutigen CNAMEs, falls Hosts mit privaten Adressen und ohne direkte IP-Verbindung zum öffentlichen Internet ihre RTP-Pakete über einen RTP-Ebene-Übersetzer in das öffentliche Internet weitergeleitet bekommen. (Siehe auch RFC 1627 [25].) Um diesen Fall zu behandeln, KÖNNEN Anwendungen einen Mechanismus zur Konfiguration eines eindeutigen CNAME bereitstellen, aber die Last liegt beim Übersetzer, die CNAMEs privater Adressen bei Bedarf in öffentliche Adressen zu übersetzen, um zu verhindern, dass private Adressen preisgegeben werden.

6.5.2 NAME: User Name SDES Item (NAME : Benutzernamen-SDES-Element)

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     NAME=2    |     length    | common name of source       ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Dies ist der tatsächliche Name, der zur Beschreibung der Quelle verwendet wird, beispielsweise „John Doe, Bit Recycler". Er kann in jeder vom Benutzer gewünschten Form vorliegen. Für Anwendungen wie Konferenzen dürfte diese Namensform in Teilnehmerlisten am wünschenswertesten anzuzeigen sein und daher häufiger als diese anderen Elemente außer CNAME gesendet werden. Profile KÖNNEN solche Prioritäten festlegen. Der NAME-Wert soll für die Dauer einer Sitzung konstant bleiben. Er SOLLTE NICHT als eindeutig unter allen Teilnehmern der Sitzung betrachtet werden.

6.5.3 EMAIL: Electronic Mail Address SDES Item (EMAIL : E-Mail-Adress-SDES-Element)

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|    EMAIL=3    |     length    | email address of source     ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Die E-Mail-Adresse ist gemäß RFC 2822 [9] formatiert, beispielsweise „[email protected]". Der EMAIL-Wert soll für die Dauer einer Sitzung konstant bleiben.

6.5.4 PHONE: Phone Number SDES Item (PHONE : Telefonnummer-SDES-Element)

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|    PHONE=4    |     length    | phone number of source      ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Die Telefonnummer SOLLTE mit dem Pluszeichen formatiert sein, der den internationalen Wählcode ersetzt. Beispielsweise „+1 908 555 1212" für eine Nummer in den Vereinigten Staaten.

6.5.5 LOC: Geographic User Location SDES Item (LOC : Geografischer Standort-SDES-Element)

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     LOC=5     |     length    | geographic location of site ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Je nach Anwendung sind unterschiedliche Detaillierungsgrade für dieses Element angemessen. Für Konferenzanwendungen kann eine Zeichenkette wie „Murray Hill, New Jersey" ausreichen, während für ein Aktiv-Marker-System Zeichenketten wie „Room 2A244, AT&T BL MH" passend sein könnten. Der Detaillierungsgrad liegt bei der Implementierung und/oder dem Benutzer, aber das Format und der Inhalt KÖNNEN durch ein Profil vorgeschrieben werden. Der LOC-Wert soll für die Dauer einer Sitzung konstant bleiben, außer für mobile Hosts.

6.5.6 TOOL: Application or Tool Name SDES Item (TOOL : Anwendungs- oder Werkzeugnamen-SDES-Element)

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     TOOL=6    |     length    |name/version of source appl. ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Eine Zeichenkette, die den Namen und eventuell die Version der den Strom erzeugenden Anwendung angibt, beispielsweise „videotool 1.2". Diese Information kann für Debugging-Zwecke nützlich sein und ist ähnlich den SMTP-Mailer- oder Mail-System-Version-Headern. Der TOOL-Wert soll für die Dauer einer Sitzung konstant bleiben.

6.5.7 NOTE: Notice/Status SDES Item (NOTE : Hinweis/Status-SDES-Element)

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     NOTE=7    |     length    | note about the source       ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Für dieses Element werden folgende Semantiken vorgeschlagen, aber diese oder andere Semantiken KÖNNEN durch ein Profil explizit definiert werden. Das NOTE-Element ist für vorübergehende Meldungen gedacht, die den aktuellen Status der Quelle beschreiben, beispielsweise „am Telefon, kann nicht sprechen". Oder, während eines Seminars, könnte dieses Element den Titel des Vortrags übertragen. Es sollte nur zur Übertragung außergewöhnlicher Informationen verwendet werden und NICHT systematisch von allen Teilnehmern enthalten sein, da dies die Rate verlangsamen würde, mit der Empfangsberichte und CNAME gesendet werden, und damit die Protokollleistung beeinträchtigen. Insbesondere sollte es nicht als Element in der Benutzerkonfigurationsdatei enthalten sein noch automatisch als Zitat-des-Tages generiert werden.

Da das NOTE-Element wichtig für die Anzeige sein kann, solange es aktiv ist, kann die Rate, mit der andere Nicht-CNAME-Elemente wie NAME gesendet werden, reduziert werden, damit das NOTE-Element diesen Anteil der RTCP-Bandbreite übernehmen kann. Wenn die vorübergehende Meldung inaktiv wird, SOLLTE das NOTE-Element weiterhin einige Male mit derselben Wiederholungsrate, aber mit einer Zeichenkette der Länge Null gesendet werden, um den Empfängern dies anzuzeigen. Die Empfänger SOLLTEN das NOTE-Element jedoch auch als inaktiv betrachten, falls es nicht über ein kleines Vielfaches der Wiederholungsrate empfangen wurde, vielleicht 20 bis 30 RTCP-Intervalle.

6.5.8 PRIV: Private Extensions SDES Item (PRIV : Private Erweiterungs-SDES-Element)

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     PRIV=8    |     length    | prefix length |prefix string...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
...             |                  value string               ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Dieses Element wird verwendet, um experimentelle oder anwendungsspezifische SDES-Erweiterungen zu definieren. Das Element enthält ein Präfix, bestehend aus einem Längen-Zeichenkette-Paar, gefolgt von der den Rest des Elements füllenden Wertzeichenkette, die die gewünschte Information trägt. Das Präfixlängenfeld hat eine Länge von 8 Bits. Die Präfixzeichenkette ist ein vom Definierer des PRIV-Elements gewählter Name, der eindeutig gegenüber anderen PRIV-Elementen sein soll, die diese Anwendung empfangen könnte. Der Ersteller der Anwendung könnte wählen, den Anwendungsnamen plus eine zusätzliche Untertypkennung zu verwenden, falls nötig. Alternativ wird EMPFOHLEN, dass andere einen auf der sie repräsentierenden Entität basierenden Namen wählen und die Nutzung des Namens innerhalb dieser Entität koordinieren.

Beachten Sie, dass das Präfix von der Gesamtlänge von 255 Oktetten des Elements verbraucht wird, daher sollte das Präfix so kurz wie möglich sein. Diese Einrichtung und die begrenzte RTCP-Bandbreite SOLLTEN NICHT überlastet werden; sie ist nicht dafür gedacht, alle Steuerungskommunikationsanforderungen aller Anwendungen zu erfüllen.

SDES-PRIV-Präfixe werden nicht bei der IANA registriert. Falls sich eine Form des PRIV-Elements als allgemein nützlich erweist, sollte ihm stattdessen ein bei der IANA registrierter regulärer SDES-Elementtyp zugewiesen werden, sodass kein Präfix benötigt wird. Dies vereinfacht die Nutzung und erhöht die Übertragungseffizienz.

6.6 BYE: Goodbye RTCP Packet (BYE : Abschieds-RTCP-Paket)

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P|    SC   |   PT=BYE=203  |             length            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                           SSRC/CSRC                           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
:                              ...                              :
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
(opt) |     length    |               reason for leaving            ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Das BYE-Paket zeigt an, dass eine oder mehrere Quellen nicht mehr aktiv sind.

Version (V), Füllung (P), Länge (Length) : Wie für das SR-Paket beschrieben (siehe Abschnitt 6.4.1).
Pakettyp (PT) : 8 Bits. Enthält die Konstante 203, um dieses Paket als RTCP-BYE-Paket zu identifizieren.
Quellenzähler (SC, Source Count) : 5 Bits. Die Anzahl der in diesem BYE-Paket enthaltenen SSRC/CSRC-Identifikatoren. Ein Zählerwert von Null ist gültig, aber nutzlos.

Die Regeln, wann ein BYE-Paket gesendet werden soll, sind in den Abschnitten 6.3.7 und 8.2 spezifiziert.

Falls ein BYE-Paket von einem Mischer empfangen wird, SOLLTE der Mischer das BYE-Paket mit unveränderten SSRC/CSRC-Identifikatoren weiterleiten. Falls ein Mischer stoppt, SOLLTE er ein BYE-Paket senden, das alle von ihm verwalteten Beitragendenquellen sowie seinen eigenen SSRC-Identifikator auflistet. Optional kann das BYE-Paket einen 8-Bit-Längenzähler gefolgt von dieser Anzahl von Oktetten Text enthalten, die den Grund des Verlassens angeben, beispielsweise „camera malfunction" oder „RTP loop detected". Die Zeichenkette hat dieselbe Kodierung wie für SDES beschrieben. Falls die Zeichenkette das Paket bis zur nächsten 32-Bit-Grenze füllt, wird die Zeichenkette nicht durch ein Nullzeichen abgeschlossen. Andernfalls MUSS das BYE-Paket mit Null-Oktetten bis zur nächsten 32-Bit-Grenze aufgefüllt werden. Diese Füllung ist von der durch das P-Bit im RTCP-Header angezeigten Füllung verschieden.

6.7 APP: Application-Defined RTCP Packet (APP : Anwendungsdefiniertes RTCP-Paket)

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P| subtype |   PT=APP=204  |             length            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                           SSRC/CSRC                           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                          name (ASCII)                         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                   application-dependent data                ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Das APP-Paket ist für experimentelle Nutzung gedacht, während neue Anwendungen und neue Funktionen entwickelt werden, ohne dass eine Registrierung eines Pakettypwerts erforderlich ist. APP-Pakete mit unbekannten Namen SOLLTEN ignoriert werden. Nach dem Testen und falls eine breitere Nutzung gerechtfertigt ist, wird EMPFOHLEN, dass jedes APP-Paket ohne die Subtyp- und Namensfelder neu definiert und bei der IANA unter Verwendung eines RTCP-Pakettyps registriert wird.

Version (V), Füllung (P), Länge (Length) : Wie für das SR-Paket beschrieben (siehe Abschnitt 6.4.1).
Subtyp (Subtype) : 5 Bits. Kann als Subtyp verwendet werden, um einen Satz von APP-Paketen unter einem einzigen Namen zu definieren, oder für anwendungsabhängige Daten.
Pakettyp (PT) : 8 Bits. Enthält die Konstante 204, um dieses Paket als RTCP-APP-Paket zu identifizieren.
Name : 4 Oktette. Ein vom Definierer des APP-Paketsatzes gewählter Name, der eindeutig gegenüber anderen APP-Paketen sein soll, die diese Anwendung empfangen könnte. Der Ersteller der Anwendung könnte den Anwendungsnamen wählen und dann die Zuweisung von Subtypwerten an andere koordinieren, die neue Pakettypen für die Anwendung definieren wollen. Alternativ wird EMPFOHLEN, dass andere einen auf der sie repräsentierenden Entität basierenden Namen wählen und die Nutzung des Namens innerhalb dieser Entität koordinieren. Der Name wird als eine Folge von vier ASCII-Zeichen interpretiert, wobei Groß- und Kleinschreibung als unterschiedlich behandelt werden.
Anwendungsabhängige Daten (Application-Dependent Data) : Variable Länge. Die anwendungsabhängigen Daten können in einem APP-Paket erscheinen oder auch nicht. Sie werden von der Anwendung und nicht von RTP selbst interpretiert. Sie MÜSSEN eine Länge haben, die ein Vielfaches von 32 Bits ist.

6.1 RTCP Packet Format (RTCP-Paketformat)​

6.2 RTCP Transmission Interval (RTCP-Übertragungsintervall)​

6.2.1 Maintaining the Number of Session Members (Aufrechterhaltung der Anzahl der Sitzungsmitglieder)​

6.3 RTCP Packet Send and Receive Rules (RTCP-Paket Sende- und Empfangsregeln)​

6.3.1 Computing the RTCP Transmission Interval (Berechnung des RTCP-Übertragungsintervalls)​

6.3.2 Initialization (Initialisierung)​

6.3.3 Receiving an RTP or Non-BYE RTCP Packet (Empfang eines RTP- oder Nicht-BYE-RTCP-Pakets)​

6.3.4 Receiving an RTCP BYE Packet (Empfang eines RTCP-BYE-Pakets)​

6.3.5 Timing Out an SSRC (Ablauf eines SSRC)​

6.3.6 Expiration of Transmission Timer (Ablauf des Sendezeitgebers)​

6.3.7 Transmitting a BYE Packet (Übertragung eines BYE-Pakets)​

6.3.8 Updating we_sent (Aktualisierung von we_sent)​

6.3.9 Allocation of Source Description Bandwidth (Zuweisung der Quellenbeschreibungsbandbreite)​

6.4 Sender and Receiver Reports (Sender- und Empfangsberichte)​

6.4.1 SR: Sender Report RTCP Packet (SR : RTCP-Senderbericht-Paket)​

6.4.2 RR: Receiver Report RTCP Packet (RR : RTCP-Empfangsbericht-Paket)​

6.4.3 Extending the Sender and Receiver Reports (Erweiterung der Sender- und Empfangsberichte)​

6.4.4 Analyzing Sender and Receiver Reports (Analyse der Sender- und Empfangsberichte)​

6.5 SDES: Source Description RTCP Packet (SDES : RTCP-Quellenbeschreibungspaket)​

6.5.1 CNAME: Canonical End-Point Identifier SDES Item (CNAME : Kanonisches Endpunkt-Identifikator-SDES-Element)​

6.5.2 NAME: User Name SDES Item (NAME : Benutzernamen-SDES-Element)​

6.5.3 EMAIL: Electronic Mail Address SDES Item (EMAIL : E-Mail-Adress-SDES-Element)​

6.5.4 PHONE: Phone Number SDES Item (PHONE : Telefonnummer-SDES-Element)​

6.5.5 LOC: Geographic User Location SDES Item (LOC : Geografischer Standort-SDES-Element)​

6.5.6 TOOL: Application or Tool Name SDES Item (TOOL : Anwendungs- oder Werkzeugnamen-SDES-Element)​

6.5.7 NOTE: Notice/Status SDES Item (NOTE : Hinweis/Status-SDES-Element)​

6.5.8 PRIV: Private Extensions SDES Item (PRIV : Private Erweiterungs-SDES-Element)​

6.6 BYE: Goodbye RTCP Packet (BYE : Abschieds-RTCP-Paket)​

6.7 APP: Application-Defined RTCP Packet (APP : Anwendungsdefiniertes RTCP-Paket)​