2. RTP- und RTCP-Paketformen und Protokollverhalten

2. RTP- und RTCP-Paketformen und Protokollverhalten

   Der Abschnitt "RTP-Profile und Nutzlastformatspezifikationen" von RFC 3550 zählt eine Reihe von Punkten auf, die in einem Profil spezifiziert oder modifiziert werden können. Dieser Abschnitt befasst sich mit diesen Punkten. Im Allgemeinen folgt dieses Profil den Standard- und/oder empfohlenen Aspekten der RTP-Spezifikation.

   RTP-Datenheader: Das Standardformat des festen RTP-Datenheaders wird verwendet (ein Marker-Bit).

   Nutzlasttypen: Statische Nutzlasttypen sind in Abschnitt 6 definiert.

   Ergänzungen zum RTP-Datenheader: Es werden keine zusätzlichen festen Felder an den RTP-Datenheader angehängt.

   Erweiterungen des RTP-Datenheaders: Es sind keine RTP-Header-Erweiterungen definiert, aber Anwendungen, die unter diesem Profil arbeiten, KÖNNEN solche Erweiterungen verwenden. Daher SOLLTEN Anwendungen NICHT annehmen, dass das RTP-Header-X-Bit immer Null ist, und SOLLTEN darauf vorbereitet sein, die Header-Erweiterung zu ignorieren. Wenn in Zukunft eine Header-Erweiterung definiert wird, MUSS diese Definition den Inhalt der ersten 16 Bits so spezifizieren, dass mehrere verschiedene Erweiterungen identifiziert werden können.

   RTCP-Pakettypen: Durch diese Profilspezifikation werden keine zusätzlichen RTCP-Pakettypen definiert.

   RTCP-Berichtsintervall: Die vorgeschlagenen Konstanten sind für die Berechnung des RTCP-Berichtsintervalls zu verwenden. Sitzungen, die unter diesem Profil arbeiten, KÖNNEN einen separaten Parameter für die RTCP-Verkehrsbandbreite angeben, anstatt den Standardanteil der Sitzungsbandbreite zu verwenden. Die RTCP-Verkehrsbandbreite KANN in zwei separate Sitzungsparameter für diejenigen Teilnehmer aufgeteilt werden, die aktive Datensender sind, und diejenigen, die es nicht sind. Gemäß der Empfehlung in der RTP-Spezifikation [1], dass 1/4 der RTCP-Bandbreite für Datensender bestimmt sein soll, wären die EMPFOHLENEN Standardwerte für diese beiden Parameter 1,25 % bzw. 3,75 %. Für eine bestimmte Sitzung KANN die RTCP-Bandbreite für Nicht-Datensender auf Null gesetzt werden, wenn über unidirektionale Verbindungen gearbeitet wird oder für Sitzungen, die kein Feedback zur Empfangsqualität erfordern. Die RTCP-Bandbreite für Datensender SOLLTE ungleich Null gehalten werden, damit Senderberichte weiterhin für die mediensynchrone Synchronisation und zur Identifizierung der Quelle durch CNAME gesendet werden können. Die Mittel, mit denen die ein oder zwei Sitzungsparameter für die RTCP-Bandbreite angegeben werden, liegen außerhalb des Geltungsbereichs dieses Memos.

   SR/RR-Erweiterung: Es ist kein Erweiterungsabschnitt für das RTCP-SR- oder RR-Paket definiert.

   SDES-Verwendung: Anwendungen KÖNNEN beliebige der in der RTP-Spezifikation beschriebenen SDES-Elemente verwenden. Während CNAME-Informationen in jedem Berichtsintervall gesendet werden MÜSSEN, SOLLTEN andere Elemente nur in jedem dritten Berichtsintervall gesendet werden, wobei NAME sieben von acht Mal innerhalb dieses Zeitfensters gesendet wird und die übrigen SDES-Elemente zyklisch das achte Zeitfenster einnehmen, wie in Abschnitt 6.2.2 der RTP-Spezifikation definiert. Mit anderen Worten, NAME wird in den RTCP-Paketen 1, 4, 7, 10, 13, 16, 19 gesendet, während beispielsweise EMAIL im RTCP-Paket 22 verwendet wird.

   Sicherheit: Die Standard-Sicherheitsdienste von RTP sind auch unter diesem Profil die Standarddienste.

   String-zu-Schlüssel-Zuordnung: Von diesem Profil wird keine Zuordnung spezifiziert.

   Überlastung: RTP und dieses Profil können im Kontext von erweiterten Netzwerkdiensten verwendet werden, zum Beispiel durch Integrated Services (RFC 1633) [4] oder Differentiated Services (RFC 2475) [5], oder sie können mit Best-Effort-Diensten verwendet werden.

   Wenn ein erweiterter Dienst verwendet wird, SOLLTEN RTP-Empfänger den Paketverlust überwachen, um sicherzustellen, dass der angeforderte Dienst tatsächlich bereitgestellt wird. Wenn dies nicht der Fall ist, dann SOLLTEN sie annehmen, dass sie einen Best-Effort-Dienst erhalten, und sich entsprechend verhalten.

   Wenn ein Best-Effort-Dienst verwendet wird, SOLLTEN RTP-Empfänger den Paketverlust überwachen, um sicherzustellen, dass die Paketverlustrate innerhalb akzeptabler Parameter liegt. Paketverlust gilt als akzeptabel, wenn ein TCP-Fluss über denselben Netzwerkpfad und unter denselben Netzwerkbedingungen einen durchschnittlichen Durchsatz erreichen würde, der über einen angemessenen Zeitraum gemessen nicht geringer ist als der des RTP-Flusses. Diese Bedingung kann erfüllt werden, indem Überlastungskontrollmechanismen implementiert werden, um die Übertragungsrate (oder die Anzahl der abonnierten Schichten für eine geschichtete Multicast-Sitzung) anzupassen, oder indem veranlasst wird, dass ein Empfänger die Sitzung verlässt, wenn die Verlustrate inakzeptabel hoch ist.

   Der Vergleich mit TCP kann nicht exakt spezifiziert werden, ist aber als "Größenordnungs"-Vergleich in Bezug auf Zeitskala und Durchsatz gedacht. Die Zeitskala, auf der der TCP-Durchsatz gemessen wird, ist die Round-Trip-Zeit der Verbindung. Im Wesentlichen besagt diese Anforderung, dass es nicht akzeptabel ist, eine Anwendung (die RTP oder ein anderes Transportprotokoll verwendet) im Best-Effort-Internet bereitzustellen, die willkürlich Bandbreite verbraucht und nicht fair mit TCP innerhalb einer Größenordnung konkurriert.

   Zugrundeliegendes Protokoll: Das Profil spezifiziert die Verwendung von RTP über Unicast- und Multicast-UDP sowie TCP. (Dies schließt die Verwendung dieser Definitionen nicht aus, wenn RTP durch andere Protokolle der unteren Schicht übertragen wird.)

   Transportzuordnung: Die Standardzuordnung von RTP und RTCP zu Adressen auf Transportebene wird verwendet.

   Kapselung: Dieses Profil überlässt den Anwendungen die Spezifikation der RTP-Kapselung in anderen Protokollen als UDP.