1. Einleitung

Das Real-time Transport Protocol, das zugehörige RTP Control Protocol (RTP/RTCP, RFC 3550) [1] und das Profil für audiovisuelle Kommunikation mit minimaler Kontrolle (RFC 3551) [2] definieren Mechanismen für die Übertragung zeitbasierter Medien über ein IP-Netzwerk. RTP bietet Mittel zur Erhaltung des Timings und zur Erkennung von Paketverlusten, und RTP-Payload-Formate sorgen für eine ordnungsgemäße Rahmung von (kontinuierlichen) Medien in einer paketbasierten Umgebung. RTCP ermöglicht es Empfängern, Feedback zur Empfangsqualität zu geben, und erlaubt es allen Mitgliedern einer RTP-Sitzung, etwas voneinander zu erfahren.

Die RTP-Spezifikation bietet nur rudimentäre Unterstützung für die Verschlüsselung von RTP- und RTCP-Paketen. Secure RTP (RFC 3711) [4] definiert ein RTP-Profil ("SAVP") für sichere RTP-Mediensitzungen und legt Methoden für die ordnungsgemäße Verschlüsselung von RTP- und RTCP-Paketen, Integrität und Replay-Schutz fest. Die anfängliche Aushandlung von SRTP und seiner Sicherheitsparameter muss außerhalb des Bandes (out-of-band) erfolgen, z. B. unter Verwendung des Session Description Protocol (SDP, RFC 4566) [6] zusammen mit Erweiterungen zur Übermittlung von Schlüsselmaterial (RFC 4567 [7], RFC 4568 [8]).

Die RTP-Spezifikation bietet auch eine begrenzte Unterstützung für zeitnahes Feedback von Empfängern an Sender, in der Regel durch Berichte über Empfangsstatistiken in regelmäßigen Abständen, die von der Gruppengröße, der durchschnittlichen RTCP-Paketgröße und der verfügbaren RTCP-Bandbreite abhängen. Das erweiterte RTP-Profil für RTCP-basiertes Feedback ("AVPF") (RFC 4585, [3]) ermöglicht es Sitzungsteilnehmern statistisch, sofortiges Feedback zu geben, während die durchschnittliche RTCP-Datenrate für alle Sender beibehalten wird. Wie bei SAVP muss die Verwendung von AVPF und seiner Parameter außerhalb des Bandes mittels SDP (RFC 4566, [6]) und der in RFC 4585 [3] definierten Erweiterungen ausgehandelt werden.

Sowohl SRTP als auch AVPF sind RTP-Profile und müssen ausgehandelt werden. Dies impliziert, dass entweder das eine oder das andere verwendet werden kann, aber nicht beide Profile für dieselbe RTP-Sitzung ausgehandelt werden können (unter Verwendung einer einzigen SDP-Sitzungsebenenbeschreibung). Die gemeinsame Verwendung von sicherer Kommunikation und zeitnahem Feedback ist jedoch wünschenswert. Daher spezifiziert dieses Dokument ein neues RTP-Profil ("SAVPF"), das die Merkmale von SAVP und AVPF kombiniert.

Da SAVP und AVPF weitgehend orthogonal sind, ist die Kombination beider meist unkompliziert. In diesem Dokument müssen keine anspruchsvollen Algorithmen spezifiziert werden. Stattdessen wird auf beide bestehenden Profile verwiesen, und es werden nur die Auswirkungen ihrer Kombination und mögliche Abweichungen von den Regeln der bestehenden Profile sowie der Aushandlungsprozess beschrieben.

1.1. Definitionen

Es gelten die Definitionen von RFC 3550 [1], RFC 3551 [2], RFC 4585 [3] und RFC 3711 [4].

Die folgenden Definitionen werden in diesem Dokument speziell verwendet:

• RTP-Sitzung: Eine Verbindung zwischen einer Gruppe von Teilnehmern, die mit RTP kommunizieren, wie in RFC 3550 [1] definiert.

• (SDP-) Medienbeschreibung: Dieser Begriff bezieht sich auf die Spezifikation in einer einzelnen m=-Zeile in einer SDP-Nachricht. Eine SDP-Medienbeschreibung darf nur eine RTP-Sitzung definieren.

• Mediensitzung: Eine Mediensitzung bezieht sich auf eine Sammlung von SDP-Medienbeschreibungen, die semantisch gruppiert sind, um Alternativen desselben Kommunikationsmittels darzustellen. Aus einer solchen Gruppe wird eine für eine Kommunikationsbeziehung ausgehandelt oder ausgewählt und die entsprechende RTP-Sitzung instanziiert. Wenn keine gemeinsamen Sitzungsparameter gefunden werden können, die für die beteiligten Endpunkte geeignet sind, wird die Mediensitzung abgelehnt. Im einfachsten Fall entspricht eine Mediensitzung einer SDP-Medienbeschreibung und einer RTP-Sitzung.

1.2. Terminologie

Die Schlüsselwörter "MUST" (muss), "MUST NOT" (darf nicht), "REQUIRED" (erforderlich), "SHALL" (soll), "SHALL NOT" (soll nicht), "SHOULD" (sollte), "SHOULD NOT" (sollte nicht), "RECOMMENDED" (empfohlen), "MAY" (kann) und "OPTIONAL" (optional) in diesem Dokument sind wie in RFC 2119 [5] beschrieben zu interpretieren.