1 Introduction (Einführung)

1.1 Purpose (Zweck)

Das Real-Time Streaming Protocol (Echtzeit-Streaming-Protokoll, RTSP) etabliert und steuert entweder einen einzelnen oder mehrere zeitsynchronisierte Streams kontinuierlicher Medien wie Audio und Video. Es liefert typischerweise nicht selbst die kontinuierlichen Streams, obwohl das Verschachteln des kontinuierlichen Medienstroms mit dem Kontrollstrom möglich ist (siehe Abschnitt 10.12). Mit anderen Worten, RTSP fungiert als "Netzwerk-Fernbedienung" für Multimedia-Server.

Die Menge der zu steuernden Streams wird durch eine Präsentationsbeschreibung definiert. Dieses Memorandum definiert kein Format für eine Präsentationsbeschreibung.

Es gibt kein Konzept einer RTSP-Verbindung; stattdessen unterhält ein Server eine durch einen Identifikator gekennzeichnete Sitzung. Eine RTSP-Sitzung ist in keiner Weise an eine Transportschicht-Verbindung wie eine TCP-Verbindung gebunden. Während einer RTSP-Sitzung kann ein RTSP-Client viele zuverlässige Transportverbindungen zum Server öffnen und schließen, um RTSP-Anfragen auszugeben. Alternativ kann er ein verbindungsloses Transportprotokoll wie UDP verwenden.

Die von RTSP kontrollierten Streams können RTP [1] verwenden, aber der Betrieb von RTSP hängt nicht vom Transportmechanismus ab, der zum Übertragen kontinuierlicher Medien verwendet wird. Das Protokoll ist absichtlich in Syntax und Betrieb HTTP/1.1 [2] ähnlich, sodass Erweiterungsmechanismen für HTTP in den meisten Fällen auch zu RTSP hinzugefügt werden können. RTSP unterscheidet sich jedoch in mehreren wichtigen Aspekten von HTTP:

RTSP führt eine Reihe neuer Methoden ein und hat einen anderen Protokollidentifikator. * Ein RTSP-Server muss standardmäßig in fast allen Fällen einen Zustand aufrechterhalten, im Gegensatz zur zustandslosen Natur von HTTP. * Sowohl ein RTSP-Server als auch ein Client können Anfragen ausgeben. * Daten werden durch ein anderes Protokoll out-of-band übertragen. (Es gibt eine Ausnahme davon.) * RTSP ist definiert, um ISO 10646 (UTF-8) anstelle von ISO 8859-1 zu verwenden, konsistent mit aktuellen HTML-Internationalisierungsbemühungen [3]. * Der Request-URI enthält immer den absoluten URI. Aufgrund der Rückwärtskompatibilität mit einem historischen Fehler trägt HTTP/1.1 [2] nur den absoluten Pfad in der Anfrage und setzt den Hostnamen in ein separates Header-Feld.

Dies erleichtert "virtuelles Hosting", bei dem ein einzelner Host mit einer IP-Adresse mehrere Dokumentbäume hostet.

Das Protokoll unterstützt die folgenden Operationen:

Abrufen von Medien vom Medienserver: Der Client kann eine Präsentationsbeschreibung über HTTP oder eine andere Methode anfordern. Wenn die Präsentation multicast ist, enthält die Präsentationsbeschreibung die Multicast-Adressen und Ports, die für die kontinuierlichen Medien verwendet werden sollen. Wenn die Präsentation nur über Unicast an den Client gesendet werden soll, stellt der Client aus Sicherheitsgründen das Ziel bereit.

Einladung eines Medienservers zu einer Konferenz: Ein Medienserver kann "eingeladen" werden, einer bestehenden Konferenz beizutreten, entweder um Medien in die Präsentation abzuspielen oder um alle oder einen Teil der Medien in einer Präsentation aufzuzeichnen. Dieser Modus ist für verteilte Lehranwendungen nützlich. Mehrere Parteien in der Konferenz können sich abwechseln, die "Fernbedienungstasten zu drücken".

Hinzufügen von Medien zu einer bestehenden Präsentation: Besonders für Live-Präsentationen ist es nützlich, wenn der Server dem Client über zusätzlich verfügbare Medien informieren kann.

RTSP-Anfragen können von Proxies, Tunneln und Caches wie in HTTP/1.1 [2] behandelt werden.

1.2 Requirements (Anforderungen)

Die Schlüsselwörter "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY" und "OPTIONAL" in diesem Dokument sind wie in RFC 2119 [4] beschrieben zu interpretieren.

1.3 Terminology (Terminologie)

Ein Teil der Terminologie wurde von HTTP/1.1 [2] übernommen. Hier nicht aufgeführte Begriffe sind wie in HTTP/1.1 definiert.

Aggregate control (Aggregierte Steuerung): Die Steuerung mehrerer Streams unter Verwendung einer einzigen Timeline durch den Server. Für Audio-/Videofeeds bedeutet dies, dass der Client eine einzelne Wiedergabe- oder Pausennachricht ausgeben kann, um sowohl Audio- als auch Videofeeds zu steuern.

Conference (Konferenz): eine mehrparteiige, multimediale Präsentation, wobei "multi" größer oder gleich eins bedeutet.

Client (Client): Der Client fordert kontinuierliche Mediendaten vom Medienserver an.

Connection (Verbindung): Ein virtueller Transportschicht-Schaltkreis, der zwischen zwei Programmen zum Zweck der Kommunikation eingerichtet wurde.

Container file (Container-Datei): Eine Datei, die mehrere Medienströme enthalten kann, die zusammen oft eine Präsentation bilden, wenn sie gemeinsam abgespielt werden. RTSP-Server können aggregierte Steuerung über diese Dateien anbieten, obwohl das Konzept einer Container-Datei nicht im Protokoll eingebettet ist.

Continuous media (Kontinuierliche Medien): Daten, bei denen eine zeitliche Beziehung zwischen Quelle und Senke besteht; das heißt, die Senke muss die zeitliche Beziehung reproduzieren, die an der Quelle existierte. Die häufigsten Beispiele für kontinuierliche Medien sind Audio und Bewegtbild. Kontinuierliche Medien können Echtzeit (interaktiv) sein, wobei eine "enge" zeitliche Beziehung zwischen Quelle und Senke besteht, oder Streaming (Wiedergabe), wobei die Beziehung weniger streng ist.

Entity (Entität): Die Informationen, die als Nutzlast einer Anfrage oder Antwort übertragen werden. Eine Entität besteht aus Metainformationen in Form von Entity-Header-Feldern und Inhalt in Form eines Entity-Body, wie in Abschnitt 8 beschrieben.

Media initialization (Medieninitialisierung): Datentyp-/Codec-spezifische Initialisierung. Dies umfasst Dinge wie Taktraten, Farbtabellen usw. Alle transportunabhängigen Informationen, die ein Client für die Wiedergabe eines Medienstroms benötigt, treten in der Medieninitialisierungsphase des Stream-Setups auf.

Media parameter (Medienparameter): Parameter, der spezifisch für einen Medientyp ist und vor oder während der Stream-Wiedergabe geändert werden kann.

Media server (Medienserver): Der Server, der Wiedergabe- oder Aufnahmedienste für einen oder mehrere Medienströme bereitstellt. Verschiedene Medienströme innerhalb einer Präsentation können von verschiedenen Medienservern stammen. Ein Medienserver kann sich auf demselben oder einem anderen Host befinden als der Webserver, von dem die Präsentation aufgerufen wird.

Media server indirection (Medienserver-Umleitung): Umleitung eines Medienclients zu einem anderen Medienserver.

(Media) stream (Medienstrom): Eine einzelne Medieninstanz, z.B. ein Audiostrom oder ein Videostrom sowie ein einzelnes Whiteboard oder eine gemeinsam genutzte Anwendungsgruppe. Bei Verwendung von RTP besteht ein Stream aus allen RTP- und RTCP-Paketen, die von einer Quelle innerhalb einer RTP-Sitzung erstellt wurden. Dies entspricht der Definition eines DSM-CC-Streams ([5]).

Message (Nachricht): Die Grundeinheit der RTSP-Kommunikation, bestehend aus einer strukturierten Sequenz von Oktetten, die der in Abschnitt 15 definierten Syntax entspricht und über eine Verbindung oder ein verbindungsloses Protokoll übertragen wird.

Participant (Teilnehmer): Mitglied einer Konferenz. Ein Teilnehmer kann eine Maschine sein, z.B. ein Medienaufnahme- oder Wiedergabeserver.

Presentation (Präsentation): Eine Menge von einem oder mehreren Streams, die dem Client als vollständiger Medienfeed präsentiert werden, unter Verwendung einer wie unten definierten Präsentationsbeschreibung. In den meisten Fällen im RTSP-Kontext impliziert dies eine aggregierte Steuerung dieser Streams, muss aber nicht.

Presentation description (Präsentationsbeschreibung): Eine Präsentationsbeschreibung enthält Informationen über einen oder mehrere Medienströme innerhalb einer Präsentation, wie den Satz von Kodierungen, Netzwerkadressen und Informationen über den Inhalt. Andere IETF-Protokolle wie SDP (RFC 2327 [6]) verwenden den Begriff "session" für eine Live-Präsentation. Die Präsentationsbeschreibung kann mehrere verschiedene Formate annehmen, einschließlich, aber nicht beschränkt auf das Sitzungsbeschreibungsformat SDP.

Response (Antwort): Eine RTSP-Antwort. Wenn eine HTTP-Antwort gemeint ist, wird dies explizit angegeben.

Request (Anfrage): Eine RTSP-Anfrage. Wenn eine HTTP-Anfrage gemeint ist, wird dies explizit angegeben.

RTSP session (RTSP-Sitzung): Eine vollständige RTSP-"Transaktion", z.B. das Ansehen eines Films. Eine Sitzung besteht typischerweise aus einem Client, der einen Transportmechanismus für den kontinuierlichen Medienstrom einrichtet (SETUP), den Stream mit PLAY oder RECORD startet und den Stream mit TEARDOWN schließt.

Transport initialization (Transportinitialisierung): Die Aushandlung von Transportinformationen (z.B. Portnummern, Transportprotokolle) zwischen Client und Server.

1.4 Protocol Properties (Protokolleigenschaften)

RTSP hat folgende Eigenschaften:

Extendable (Erweiterbar): Neue Methoden und Parameter können einfach zu RTSP hinzugefügt werden.

Easy to parse (Einfach zu parsen): RTSP kann von Standard-HTTP- oder MIME-Parsern geparst werden.

Secure (Sicher): RTSP verwendet Web-Sicherheitsmechanismen wieder. Alle HTTP-Authentifizierungsmechanismen wie Basic (RFC 2068 [2, Abschnitt 11.1]) und Digest-Authentifizierung (RFC 2069 [8]) sind direkt anwendbar. Man kann auch Transport- oder Netzwerkschicht-Sicherheitsmechanismen wiederverwenden.

Transport-independent (Transportunabhängig): RTSP kann entweder ein unzuverlässiges Datagramm-Protokoll (UDP) (RFC 768 [9]), ein zuverlässiges Datagramm-Protokoll (RDP, RFC 1151, nicht weit verbreitet [10]) oder ein zuverlässiges Stream-Protokoll wie TCP (RFC 793 [11]) verwenden, da es Zuverlässigkeit auf Anwendungsebene implementiert.

Multi-server capable (Mehrserverfähig): Jeder Medienstrom innerhalb einer Präsentation kann sich auf einem anderen Server befinden. Der Client stellt automatisch mehrere gleichzeitige Steuersitzungen mit den verschiedenen Medienservern her. Die Mediensynchronisation wird auf Transportebene durchgeführt.

Control of recording devices (Steuerung von Aufnahmegeräten): Das Protokoll kann sowohl Aufnahme- als auch Wiedergabegeräte steuern, sowie Geräte, die zwischen den beiden Modi wechseln können ("VCR").

Separation of stream control and conference initiation (Trennung von Stream-Steuerung und Konferenzinitiierung): Die Stream-Steuerung ist von der Einladung eines Medienservers zu einer Konferenz getrennt. Die einzige Anforderung ist, dass das Konferenzinitiierungsprotokoll einen eindeutigen Konferenzidentifikator bereitstellt oder zur Erstellung verwendet werden kann. Insbesondere können SIP [12] oder H.323 [13] verwendet werden, um einen Server zu einer Konferenz einzuladen.

Suitable for professional applications (Geeignet für professionelle Anwendungen): RTSP unterstützt Frame-Level-Genauigkeit durch SMPTE-Zeitstempel, um Remote-Digitalbearbeitung zu ermöglichen.

Presentation description neutral (Präsentationsbeschreibungsneutral): Das Protokoll erzwingt kein bestimmtes Präsentationsbeschreibungs- oder Metadateiformat und kann den Typ des zu verwendenden Formats übermitteln. Die Präsentationsbeschreibung muss jedoch mindestens einen RTSP-URI enthalten.

Proxy and firewall friendly (Proxy- und Firewall-freundlich): Das Protokoll sollte leicht von Anwendungs- und Transportschicht- (SOCKS [14]) Firewalls behandelt werden können. Eine Firewall muss möglicherweise die SETUP-Methode verstehen, um ein "Loch" für den UDP-Medienstrom zu öffnen.

HTTP-friendly (HTTP-freundlich): Wo sinnvoll, verwendet RTSP HTTP-Konzepte wieder, sodass die bestehende Infrastruktur wiederverwendet werden kann. Diese Infrastruktur umfasst PICS (Platform for Internet Content Selection [15,16]) zum Zuordnen von Labels zu Inhalten. RTSP fügt jedoch nicht nur Methoden zu HTTP hinzu, da die Steuerung kontinuierlicher Medien in den meisten Fällen Serverzustand erfordert.

Appropriate server control (Angemessene Serversteuerung): Wenn ein Client einen Stream starten kann, muss er in der Lage sein, einen Stream zu stoppen. Server sollten nicht mit dem Streaming zu Clients beginnen auf eine Weise, dass Clients den Stream nicht stoppen können.

Transport negotiation (Transportaushandlung): Der Client kann die Transportmethode aushandeln, bevor er tatsächlich einen kontinuierlichen Medienstrom verarbeiten muss.

Capability negotiation (Fähigkeitsaushandlung): Wenn grundlegende Funktionen deaktiviert sind, muss ein sauberer Mechanismus vorhanden sein, mit dem der Client bestimmen kann, welche Methoden nicht implementiert werden. Dies ermöglicht Clients, die entsprechende Benutzeroberfläche zu präsentieren. Wenn beispielsweise das Suchen nicht erlaubt ist, muss die Benutzeroberfläche in der Lage sein, das Verschieben eines gleitenden Positionsindikators zu verbieten.

Eine frühere Anforderung in RTSP war die Multi-Client-Fähigkeit. Es wurde jedoch festgestellt, dass ein besserer Ansatz darin bestand, sicherzustellen, dass das Protokoll leicht auf das Multi-Client-Szenario erweiterbar ist. Stream-Identifikatoren können von mehreren Kontrollströmen verwendet werden, sodass das "Weitergeben der Fernbedienung" möglich wäre. Das Protokoll würde nicht darauf eingehen, wie mehrere Clients den Zugriff aushandeln; dies wird entweder einem "sozialen Protokoll" oder einem anderen Bodensteuerungsmechanismus überlassen.

1.5 Extending RTSP (RTSP erweitern)

Da nicht alle Medienserver dieselbe Funktionalität haben, werden Medienserver notwendigerweise verschiedene Sätze von Anfragen unterstützen. Zum Beispiel:

Ein Server kann nur zur Wiedergabe fähig sein und benötigt daher keine Unterstützung für die RECORD-Anfrage. * Ein Server kann nicht zur Suche (absolute Positionierung) fähig sein, wenn er nur Live-Events unterstützen soll. * Einige Server unterstützen möglicherweise keine Einstellung von Stream-Parametern und unterstützen daher GET_PARAMETER und SET_PARAMETER nicht.

Ein Server SOLLTE alle in Abschnitt 12 beschriebenen Header-Felder implementieren.

Es liegt an den Erstellern von Präsentationsbeschreibungen, vom Server nicht das Unmögliche zu verlangen. Diese Situation ist in HTTP/1.1 [2] ähnlich, wo die in [H19.6] beschriebenen Methoden wahrscheinlich nicht auf allen Servern unterstützt werden.

RTSP kann auf drei Arten erweitert werden, hier in der Reihenfolge des Ausmaßes der unterstützten Änderungen aufgeführt:

Bestehende Methoden können mit neuen Parametern erweitert werden, solange diese Parameter vom Empfänger sicher ignoriert werden können. (Dies entspricht dem Hinzufügen neuer Parameter zu einem HTML-Tag.) Wenn der Client eine negative Bestätigung benötigt, wenn eine Methodenerweiterung nicht unterstützt wird, kann ein Tag, das der Erweiterung entspricht, im Require:-Feld hinzugefügt werden (siehe Abschnitt 12.32). * Neue Methoden können hinzugefügt werden. Wenn der Empfänger der Nachricht die Anfrage nicht versteht, antwortet er mit Fehlercode 501 (Not implemented) und der Absender sollte nicht versuchen, diese Methode erneut zu verwenden. Ein Client kann auch die OPTIONS-Methode verwenden, um sich über vom Server unterstützte Methoden zu erkundigen. Der Server SOLLTE die von ihm unterstützten Methoden unter Verwendung des Public-Response-Headers auflisten. * Eine neue Version des Protokolls kann definiert werden, die es erlaubt, fast alle Aspekte (außer der Position der Protokollversionsnummer) zu ändern.

1.6 Overall Operation (Gesamtbetrieb)

Jede Präsentation und jeder Medienstrom kann durch eine RTSP-URL identifiziert werden. Die Gesamtpräsentation und die Eigenschaften der Medien, aus denen die Präsentation besteht, werden durch eine Präsentationsbeschreibungsdatei definiert, deren Format außerhalb des Geltungsbereichs dieser Spezifikation liegt. Die Präsentationsbeschreibungsdatei kann vom Client über HTTP oder andere Mittel wie E-Mail erhalten werden und muss nicht unbedingt auf dem Medienserver gespeichert sein.

Für die Zwecke dieser Spezifikation wird angenommen, dass eine Präsentationsbeschreibung eine oder mehrere Präsentationen beschreibt, von denen jede eine gemeinsame Zeitachse beibehält. Zur Vereinfachung der Darstellung und ohne Verlust der Allgemeinheit wird angenommen, dass die Präsentationsbeschreibung genau eine solche Präsentation enthält. Eine Präsentation kann mehrere Medienströme enthalten.

Die Präsentationsbeschreibungsdatei enthält eine Beschreibung der Medienströme, aus denen die Präsentation besteht, einschließlich ihrer Kodierungen, Sprache und anderer Parameter, die es dem Client ermöglichen, die am besten geeignete Kombination von Medien zu wählen. In dieser Präsentationsbeschreibung wird jeder Medienstrom, der individuell durch RTSP steuerbar ist, durch eine RTSP-URL identifiziert, die auf den Medienserver zeigt, der diesen bestimmten Medienstrom verarbeitet, und den auf diesem Server gespeicherten Stream benennt. Mehrere Medienströme können sich auf verschiedenen Servern befinden; beispielsweise können Audio- und Videoströme zur Lastverteilung über Server aufgeteilt werden. Die Beschreibung zählt auch die Transportmethoden auf, die der Server verwenden kann.

Neben den Medienparametern müssen die Netzwerk-Zieladresse und der Port bestimmt werden. Mehrere Betriebsmodi können unterschieden werden:

Unicast (Unicast): Die Medien werden an die Quelle der RTSP-Anfrage übertragen, wobei die Portnummer vom Client gewählt wird. Alternativ werden die Medien auf demselben zuverlässigen Stream wie RTSP übertragen.

Multicast, server chooses address (Multicast, Server wählt Adresse): Der Medienserver wählt die Multicast-Adresse und den Port. Dies ist der typische Fall für eine Live- oder Near-Media-on-Demand-Übertragung.

Multicast, client chooses address (Multicast, Client wählt Adresse): Wenn der Server an einer bestehenden Multicast-Konferenz teilnehmen soll, werden die Multicast-Adresse, der Port und der Verschlüsselungsschlüssel durch die Konferenzbeschreibung gegeben, die durch Mittel außerhalb des Geltungsbereichs dieser Spezifikation etabliert wurde.

1.7 RTSP States (RTSP-Zustände)

RTSP steuert einen Stream, der über ein separates Protokoll gesendet werden kann, unabhängig vom Kontrollkanal. Beispielsweise kann die RTSP-Steuerung über eine TCP-Verbindung erfolgen, während die Daten über UDP fließen. Somit setzt sich die Datenlieferung fort, auch wenn keine RTSP-Anfragen vom Medienserver empfangen werden. Auch kann während seiner Lebensdauer ein einzelner Medienstrom durch RTSP-Anfragen gesteuert werden, die sequentiell auf verschiedenen TCP-Verbindungen ausgegeben werden. Daher muss der Server einen "Sitzungszustand" aufrechterhalten, um RTSP-Anfragen mit einem Stream korrelieren zu können. Die Zustandsübergänge werden in Abschnitt A beschrieben.

Viele Methoden in RTSP tragen nicht zum Zustand bei. Die folgenden spielen jedoch eine zentrale Rolle bei der Definition der Zuweisung und Nutzung von Stream-Ressourcen auf dem Server: SETUP, PLAY, RECORD, PAUSE und TEARDOWN.

SETUP: Veranlasst den Server, Ressourcen für einen Stream zuzuweisen und eine RTSP-Sitzung zu starten.

PLAY und RECORD: Startet die Datenübertragung auf einem über SETUP zugewiesenen Stream.

PAUSE: Hält einen Stream vorübergehend an, ohne Serverressourcen freizugeben.

TEARDOWN: Gibt Ressourcen frei, die mit dem Stream verbunden sind. Die RTSP-Sitzung hört auf dem Server auf zu existieren.

RTSP-Methoden, die zum Zustand beitragen, verwenden das Session-Header-Feld (Abschnitt 12.37), um die RTSP-Sitzung zu identifizieren, deren Zustand manipuliert wird. Der Server generiert Sitzungsidentifikatoren als Antwort auf SETUP-Anfragen (Abschnitt 10.4).

1.8 Relationship with Other Protocols (Beziehung zu anderen Protokollen)

RTSP hat einige funktionale Überschneidungen mit HTTP. Es kann auch mit HTTP interagieren, da der erste Kontakt mit Streaming-Inhalten oft über eine Webseite hergestellt wird. Die aktuelle Protokollspezifikation zielt darauf ab, verschiedene Übergabepunkte zwischen einem Webserver und dem Medienserver, der RTSP implementiert, zu ermöglichen. Beispielsweise kann die Präsentationsbeschreibung über HTTP oder RTSP abgerufen werden, was die Rundreisen in webbrowserbasierten Szenarien reduziert, aber auch eigenständige RTSP-Server und -Clients ermöglicht, die überhaupt nicht auf HTTP angewiesen sind.

RTSP unterscheidet sich jedoch grundlegend von HTTP darin, dass die Datenlieferung out-of-band in einem anderen Protokoll stattfindet. HTTP ist ein asymmetrisches Protokoll, bei dem der Client Anfragen ausgibt und der Server antwortet. In RTSP können sowohl der Medienclient als auch der Medienserver Anfragen ausgeben. RTSP-Anfragen sind auch nicht zustandslos; sie können Parameter setzen und einen Medienstrom lange nach der Bestätigung der Anfrage weiter steuern.

Die Wiederverwendung von HTTP-Funktionalität hat Vorteile in mindestens zwei Bereichen, nämlich Sicherheit und Proxies. Die Anforderungen sind sehr ähnlich, sodass die Fähigkeit, HTTP-Arbeit an Caches, Proxies und Authentifizierung zu übernehmen, wertvoll ist.

Während die meisten Echtzeitmedien RTP als Transportprotokoll verwenden werden, ist RTSP nicht an RTP gebunden.

RTSP setzt die Existenz eines Präsentationsbeschreibungsformats voraus, das sowohl statische als auch zeitliche Eigenschaften einer Präsentation mit mehreren Medienströmen ausdrücken kann.