2. RTP- und RTCP-Paketformate und Protokollverhalten
2.1. RTP
Die in [2] definierten Regeln gelten auch für dieses Profil, außer den im Folgenden genannten Regeln:
RTCP-Pakettypen (RTCP packet types):
Zwei zusätzliche RTCP-Pakettypen sind registriert, und die zugehörigen FB-Nachrichten zur Übertragung von Feedback-Information werden in Abschnitt 6 dieses Memos definiert.
RTCP-Berichtsintervalle (RTCP report intervals):
Dieses Dokument beschreibt drei Betriebsmodi, die die RTCP-Berichtsintervalle beeinflussen (siehe Abschnitt 3.2 dieses Memos). Im Regular-RTCP-Modus gelten alle Regeln aus [1] mit Ausnahme des empfohlenen Mindestabstands von fünf Sekunden zwischen zwei RTCP-Berichten derselben RTP-Entität. In den Modi Immediate Feedback und Early RTCP entfällt der Mindestabstand von fünf Sekunden zwischen zwei RTCP-Berichten, und zusätzlich gelten die in Abschnitt 3 dieses Memos angegebenen Regeln, wenn RTCP-Pakete mit FB-Nachrichten (definiert in Abschnitt 4 dieses Memos) übertragen werden sollen.
Die in [1] festgelegten Regeln können durch Sitzungsbeschreibungen mit anderen Parametern überschrieben werden (z.B. für den RTCP zugewiesenen Bandbreitenanteil für Sender bzw. Empfänger). Für mit dem Session Description Protocol (SDP) [3] definierte Sitzungen gelten die Regeln von [4].
Überlastkontrolle (Congestion control):
Es gelten dieselben Grundregeln wie in [2] ausführlich dargestellt. Darüber hinaus wird in Abschnitt 7 weiter auf die Auswirkungen von Feedback und die Reaktion eines Senders auf FB-Nachrichten eingegangen.
2.2. Zugrunde liegende Transportprotokolle (Underlying Transport Protocols)
RTP soll über unzuverlässigen Transportprotokollen eingesetzt werden, einschließlich UDP und dem Datagram Congestion Control Protocol (DCCP). Dieser Abschnitt beschreibt kurz die über einfachen RTP-Betrieb hinausgehenden Besonderheiten, die durch RTCP-Feedback gemäß diesem Memo eingeführt werden.
UDP: UDP bietet Best-Effort-Zustellung von Datagrammen für Punkt-zu-Punkt- sowie Multicast-Kommunikation. UDP unterstützt weder Überlastkontrolle noch Fehlerreparatur. Das in diesem Memo definierte RTCP-basierte Feedback kann minimale Unterstützung für begrenzte Fehlerreparatur bieten. Da RTCP-Feedback nicht garantiert in hinreichend kleinen Zeitskalen (in der Größenordnung der RTT) arbeitet, eignet sich RTCP-Feedback nicht zur Unterstützung der Überlastkontrolle. Dieses Memo behandelt sowohl Unicast- als auch Multicast-Betrieb.
DCCP: DCCP [19] ermöglicht überlastkontrollierte, aber unzuverlässige Datagrammströme für Unicast-Kommunikation. Mit auf TCP Friendly Rate Control (TFRC) [20] basierender Überlastkontrolle (CCID 3) eignet sich DCCP besonders für Audio- und Video-Kommunikation. DCCPs Bestätigungsnachrichten können detailliertes Feedback über empfangene und verpasste Datagramme (und damit über Überlast) liefern.
Bei RTP über DCCP wird die Überlastkontrolle auf der DCCP-Schicht durchgeführt, und auf der RTP-Schicht sind keine zusätzlichen Mechanismen erforderlich. Darüber hinaus kann ein RTCP-Feedback-fähiger Sender das häufigere DCCP-basierte Feedback nutzen, sodass ein Empfänger unter Umständen auf (zusätzliche) Generic-Feedback-Nachrichten verzichten kann.