In den vorhergehenden Anwendungsfällen wurde bereits mehrfach zu RTP gehörige Kontrollprotokoll RTCP angesprochen, das wir nun näher betrachten wollen. RTCP hat vier Aufgaben:

1. Hauptzweck ist es, den Teilnehmern laufend aktuelle Informationen über die Qualität der Datenverteilung im Netzwerk zu liefern. Dieses Feedback ermöglicht den Teilnehmern, den von ihnen generierten Datenstrom an die Netzbedingungen anzupasssen (z.B. durch Reduktion der Datenrate bei geringer QoS) und Fehler einzugrenzen. RTCP überträgt dazu periodisch sog. Sender Reports (SR) und Receiver Reports (RR).
    
2. Die zweite wichtige Aufgabe ist es, für jeden Teilnehmer eine konstante, eindeutige Kennzeichnung (Canonical Name, CNAME) zu übertragen. Diese Kennzeichnung wird vom Empfänger dazu verwendet, mehrere Datenströme eines Teilnehmers (z.B. Audio und Video), die in getrennten Sessions übertragen werden, wieder zusammenzuführen.
    
3. Diese Kontrolldaten müssen zwar periodisch von allen Teilnehmer übertragen werden, dürfen bei großen Teilnehmerzahlen jedoch nicht die Bandbreite für den Nutzdatentransport einschränken. Da jeder Teilnehmer jedoch alle RTCP-Pakete erhält, kennt er die Gesamtzahl der Teilnehmer und kann daraus die Rate berechnen, mit der Kontrollpakete gesendet werden dürfen.
    
4. Optional kann jeder Teilnehmer via RTCP grundlegende Informationen über sich selbst versenden (Source Description, SDES), die z.B. in der Benutzungsoberfläche der Anwendung angezeigt werden können.

Sender/Receiver Report

Der Sender bzw. Receiver Report (SR bzw. RR) wird periodisch von jedem Teilnehmer gesendet, um den anderen Teilnehmern Informationen über die Qualität der Datenübertragung mitzuteilen.

Neben den technischen Informationen wie einigen Flags und Zählern enthält der Header die eindeutige Kennung der Datenquelle (Synchronization Source, SSRC), die diesen Report erzeugt hat.

Hat diese Quelle seit dem letzten Versand eines Sender bzw. Receiver Report auch Nutzdaten versandt, so folgt nach dem Header der Sender Info-Block (in diesem Fall heißt das Paket "Sender Report"; fehlt der Sender Info-Block dagegen, so heißt es "Receiver Report"). Er enthält zum einen Zeitstempel mit der realen Uhrzeit, an dem der Report versandt wurde, und zum anderen einen äquivalenten Zeitstempel in der von RTP für diesen Strom verwendeten Einheit. Außerdem wird die Anzahl der seit Übertragungsbeginn gesendeten Pakete bzw. Bytes angegeben.

Für jede externe Datenquelle, von der dieser Teilnehmer seit dem letzten Versand eines Sender bzw. Receiver Reports Nutzdaten erhalten hat, folgt anschließend ein Report Block. Er enthält zu jeder (durch ihre SSRC identifizierte) Datenquelle den Prozentsatz und die Anzahl der nicht empfangenen Nutzdatenpakete, die höchste bereits empfangene Sequenznummer, die Varianz des Zeitintervalls zwischen dem Eintreffen zweier Datenpakete, den Zeitstempel des letzten empfangenen Sender Reports sowie das seitdem verstrichene Zeitintervall.

Weitere anwendungsspezifische Felder können in Profile Specifications definiert werden.

Source Description

Jeder Teilnehmer sendet periodisch Source Description (SDES)-Pakete, die Zusatzinformationen über ihn enthalten können. Um Overhead einzusparen, können mehrere Datenquellen (Synchronization Sources, SSRCs) in einem Paket beschrieben werden.

Die eindeutige Teilnehmerkennung (Canonical Name, CNAME) muss für jede Quelle angegeben werden, da sie wichtig für die Verknüpfung verschiedener Datenströme eines Teilnehmers ist. Die übrigen Elemente sind jedoch optional und sollten, um Bandbreite zu sparen, lediglich in größeren zeitlichen Abständen übertragen werden. Ihre Bedeutung ist im wesentlichen selbsterklärend. Über das Kurznachricht-Element kann ein Teilnehmer kurze Mitteilungen an alle anderen verschicken, zudem steht ein Element für applikations-spezifische Erweiterungen bereit.

< Anwendungsfälle | Fazit: RTP/RTCP >