Echtzeit-Streaming-Protokoll

Das Real-Time Streaming Protocol ( RTSP ) ist ein Anwendungsprotokoll, das für das Multiplexen und Paketieren von Multimedia- Transportströmen (wie interaktiven Medien , Video und Audio ) über ein geeignetes Transportprotokoll entwickelt wurde . RTSP wird in Unterhaltungs- und Kommunikationssystemen zur Steuerung von Streaming- Medienservern eingesetzt . Das Protokoll dient dem Aufbau und der Steuerung von Mediensitzungen zwischen Endpunkten. Clients von Medienservern senden Befehle wie „ Wiedergabe“ , „Aufnahme“ und „Pause“ , um die Medienübertragung vom Server zum Client ( Video-on-Demand ) oder vom Client zum Server ( Sprachaufzeichnung ) in Echtzeit zu steuern .

RTSP wurde von RealNetworks , Netscape und der Columbia University entwickelt . ^{[ 1 ] [ 2 ]} Der erste Entwurf des Protokolls wurde im Oktober 1996 von Netscape und Progressive Networks bei der IETF eingereicht . Im Dezember desselben Jahres reichte Henning Schulzrinne von der Columbia University „RTSP՚“ („RTSP prime“) ein. ^{[ 3 ] [ 4 ]} Die beiden Entwürfe wurden von der Multiparty Multimedia Session Control Working Group (MMUSIC WG) der Internet Engineering Task Force (IETF) zur Standardisierung zusammengeführt, und weitere Entwürfe wurden von der Arbeitsgruppe veröffentlicht. ^{[ 5 ] [ 6 ]} RTSP wurde 1998 als RFC 2326 veröffentlicht. ^{[ 7 ]}

RTSP 2.0 wurde 2016 als RFC 7826 als Nachfolger von RTSP 1.0 veröffentlicht. Version 2.0 basiert auf Version 1.0, ist aber (mit Ausnahme des grundlegenden Versionsverhandlungsmechanismus) nicht abwärtskompatibel. ^{[ 8 ]}

Die Übertragung von Streaming-Daten selbst ist keine Aufgabe von RTSP. Die meisten RTSP-Server nutzen das Real-time Transport Protocol (RTP) in Verbindung mit dem Real-time Control Protocol (RTCP) zur Bereitstellung von Mediendatenströmen. Einige Anbieter implementieren jedoch proprietäre Transportprotokolle. Die RTSP-Serversoftware von RealNetworks beispielsweise nutzte auch RealNetworks' proprietäres Real Data Transport (RDT).

RTSP ähnelt HTTP in mancher Hinsicht , definiert jedoch Steuersequenzen, die für die Steuerung der Multimedia-Wiedergabe nützlich sind. Während HTTP zustandslos ist , verfügt RTSP über einen Zustand; bei Bedarf wird eine Kennung verwendet, um gleichzeitige Sitzungen zu verfolgen. Wie HTTP nutzt auch RTSP TCP, um eine Ende-zu-Ende-Verbindung aufrechtzuerhalten. Die meisten RTSP-Steuernachrichten werden zwar vom Client an den Server gesendet, einige Befehle werden jedoch in umgekehrter Richtung (d. h. vom Server zum Client) übertragen.

Nachfolgend werden die grundlegenden RTSP-Anfragen dargestellt. Einige typische HTTP-Anfragen , wie die OPTIONS-Anfrage, sind ebenfalls verfügbar. Die Standardportnummer der Transportschicht ist 554 ^{[ 7 ]} , sowohl für TCP als auch für UDP , wobei UDP jedoch selten für Steuerungsanfragen verwendet wird.

Eine OPTIONS-Anfrage gibt die Anfragetypen zurück, die der Server akzeptiert.

C->S: OPTIONS rtsp://example.com/media.mp4 RTSP/1.0 CSeq: 1 Erforderlich: implizites Spiel Proxy-Require: gzipped-messages S->C: RTSP/1.0 200 OK CSeq: 1 Öffentlich: BESCHREIBEN, AUFBAUEN, ABBAUEN, ABSPIELEN, PAUSE 

Eine DESCRIBE-Anfrage enthält eine RTSP- rtsp://URL und den Typ der verarbeitbaren Antwortdaten. Diese Antwort umfasst die Präsentationsbeschreibung, typischerweise im SDP-Format ( Session Description Protocol ). Die Präsentationsbeschreibung listet unter anderem die Medienströme auf, die über die aggregierte URL gesteuert werden. In der Regel gibt es jeweils einen Medienstrom für Audio- und Videostreams. Die URLs der Medienströme werden entweder direkt aus den SDP-Steuerfeldern oder durch Anhängen des SDP-Steuerfelds an die aggregierte URL ermittelt.

C->S: DESCRIBE rtsp://example.com/media.mp4 RTSP/1.0 CSeq: 2 S->C: RTSP/1.0 200 OK CSeq: 2 Content-Base: rtsp://example.com/media.mp4 Content-Type: application/sdp Inhaltslänge: 460 m=Video 0 RTP/AVP 96 a=control:streamid=0 a=range:npt=0-7.741000 a=length:npt=7.741000 a=rtpmap:96 MP4V-ES/5544 a=mimetype:string;"video/MP4V-ES" a=AvgBitRate:integer;304018 a=StreamName:string;"angedeutete Videospur" m=Audio 0 RTP/AVP 97 a=control:streamid=1 a=range:npt=0-7.712000 a=length:npt=7.712000 a=rtpmap:97 mpeg4-generic/32000/2 a=mimetype:string;"audio/mpeg4-generic" a=AvgBitRate:integer;65790 a=StreamName:string;"angedeutete Audiospur" 

Eine SETUP-Anfrage legt fest, wie ein einzelner Medienstream übertragen wird. Dies muss vor dem Senden einer PLAY-Anfrage erfolgen. Die Anfrage enthält die URL des Medienstreams und einen Transportbezeichner. Dieser Bezeichner umfasst typischerweise einen lokalen Port für den Empfang von RTP- Daten (Audio oder Video) und einen weiteren für RTCP -Daten (Metadaten). Die Serverantwort bestätigt üblicherweise die gewählten Parameter und ergänzt fehlende Angaben, wie z. B. die vom Server verwendeten Ports. Jeder Medienstream muss mit SETUP konfiguriert werden, bevor eine aggregierte Wiedergabeanfrage gesendet werden kann.

C->S: SETUP rtsp://example.com/media.mp4/streamid=0 RTSP/1.0 CSeq: 3 Transport: RTP/AVP;unicast;client_port=8000-8001 S->C: RTSP/1.0 200 OK CSeq: 3 Transport: RTP/AVP;unicast;client_port=8000-8001;server_port=9000-9001;ssrc=1234ABCD Sitzung: 12345678 C->S: SETUP rtsp://example.com/media.mp4/streamid=1 RTSP/1.0 CSeq: 3 Transport: RTP/AVP;Unicast;Client-Port=8002-8003 Sitzung: 12345678 S->C: RTSP/1.0 200 OK CSeq: 3 Transport: RTP/AVP;unicast;client_port=8002-8003;server_port=9002-9003;ssrc=1234ABCD Sitzung: 12345678 

Eine PLAY-Anfrage startet die Wiedergabe eines oder aller Medienstreams. Mehrere PLAY-Anfragen können gestapelt werden. Die URL kann die Gesamt-URL (zum Abspielen aller Medienstreams) oder die URL eines einzelnen Medienstreams (zum Abspielen nur dieses Streams) sein. Es kann ein Bereich angegeben werden. Wird kein Bereich angegeben, wird der Stream von Anfang bis Ende abgespielt oder, falls er pausiert ist, an der Stelle fortgesetzt, an der er pausiert wurde.

C->S: PLAY rtsp://example.com/media.mp4 RTSP/1.0 CSeq: 4 Bereich: npt=5-20 Sitzung: 12345678 S->C: RTSP/1.0 200 OK CSeq: 4 Sitzung: 12345678 RTP-Info: url=rtsp://example.com/media.mp4/streamid=0;seq=9810092;rtptime=3450012 

Eine PAUSE-Anfrage unterbricht vorübergehend einen oder alle Medienstreams, die später mit einer PLAY-Anfrage fortgesetzt werden können. Die Anfrage enthält eine aggregierte URL oder eine URL für einen Medienstream. Ein Bereichsparameter in einer PAUSE-Anfrage gibt an, wann pausiert werden soll. Wird der Bereichsparameter weggelassen, erfolgt die Pause sofort und unbegrenzt.

C->S: PAUSE rtsp://example.com/media.mp4 RTSP/1.0 CSeq: 5 Sitzung: 12345678 S->C: RTSP/1.0 200 OK CSeq: 5 Sitzung: 12345678 

Diese Methode initiiert die Aufzeichnung verschiedener Mediendaten gemäß der Präsentationsbeschreibung. Der Zeitstempel gibt Start- und Endzeit (in UTC) an. Ist kein Zeitraum angegeben, wird die in der Präsentationsbeschreibung angegebene Start- oder Endzeit verwendet. Beginnt die Sitzung bereits, startet die Aufzeichnung sofort. Der Server entscheidet, ob die aufgezeichneten Daten unter der angeforderten URI oder einer anderen URI gespeichert werden. Verwendet der Server nicht die angeforderte URI, sollte die Antwort den Statuscode 201 haben und eine Entität enthalten, die den Status der Anfrage beschreibt und auf die neue Ressource verweist, sowie einen Location-Header.

C->S: RECORD rtsp://example.com/media.mp4 RTSP/1.0 CSeq: 6 Sitzung: 12345678 S->C: RTSP/1.0 200 OK CSeq: 6 Sitzung: 12345678 

Die ANNOUNCE-Methode dient zwei Zwecken:

Wenn ANNOUNCE vom Client an den Server gesendet wird, übermittelt es die Beschreibung einer Präsentation oder eines Medienobjekts, das durch die Anfrage-URL identifiziert wird, an den Server. Wenn ANNOUNCE vom Server an den Client gesendet wird, aktualisiert es die Sitzungsbeschreibung in Echtzeit. Wird einer Präsentation ein neuer Medienstream hinzugefügt (z. B. während einer Live-Präsentation), muss die gesamte Präsentationsbeschreibung erneut gesendet werden, nicht nur die zusätzlichen Komponenten, damit diese gelöscht werden können.

 C->S: ANNOUNCE rtsp://example.com/media.mp4 RTSP/1.0 CSeq: 7 Datum: 23. Januar 1997 15:35:06 GMT Sitzung: 12345678 Content-Type: application/sdp Inhaltslänge: 332 v=0 o=mhandley 2890844526 2890845468 IN IP4 126.16.64.4 s=SDP Seminar i=Ein Seminar zum Sitzungsbeschreibungsprotokoll u= http://www.cs.ucl.ac.uk/staff/M.Handley/sdp.03.ps e=mjh@isi.edu (Mark Handley) c=IN IP4 224.2.17.12/127 t=2873397496 2873404696 a=recvonly m=audio 3456 RTP/AVP 0 m=Video 2232 RTP/AVP 31 S->C: RTSP/1.0 200 OK CSeq: 7 

Eine TEARDOWN-Anforderung dient zum Beenden der Sitzung. Sie stoppt alle Medienstreams und gibt alle sitzungsbezogenen Daten auf dem Server frei.

C->S: TEARDOWN rtsp://example.com/media.mp4 RTSP/1.0 CSeq: 8 Sitzung: 12345678 S->C: RTSP/1.0 200 OK CSeq: 8 

Die GET_PARAMETER-Anfrage ruft den Wert eines Parameters einer in der URI angegebenen Präsentation oder eines Streams ab. Der Inhalt der Antwort ist implementierungsabhängig. GET_PARAMETER-Anfragen ohne Antworttext können verwendet werden, um die Erreichbarkeit von Client oder Server zu testen („Ping“).

S->C: GET_PARAMETER rtsp://example.com/media.mp4 RTSP/1.0 CSeq: 9 Content-Type: text/parameters Sitzung: 12345678 Inhaltslänge: 15 empfangene Pakete Zittern C->S: RTSP/1.0 200 OK CSeq: 9 Inhaltslänge: 46 Content-Type: text/parameters Empfangene Pakete: 10 Jitter: 0,3838 

Diese Methode fordert dazu auf, den Wert eines Parameters für eine durch den URI angegebene Präsentation oder einen Stream festzulegen.

C->S: SET_PARAMETER rtsp://example.com/media.mp4 RTSP/1.0 CSeq: 10 Inhaltslänge: 20 Inhaltstyp: text/parameters barparam: barstuff S->C: RTSP/1.0 451 Ungültiger Parameter CSeq: 10 Inhaltslänge: 10 Inhaltstyp: text/parameters barparam 

Eine REDIRECT-Anfrage teilt dem Client mit, dass er eine Verbindung zu einem anderen Server herstellen muss. Sie enthält den obligatorischen Header „Location“, der angibt, dass der Client Anfragen an diese URL senden soll. Optional kann der Parameter „Range“ enthalten sein, der den Zeitpunkt der Umleitung festlegt. Möchte der Client weiterhin Medien für diese URI senden oder empfangen, muss er eine TEARDOWN-Anfrage für die aktuelle Sitzung und eine SETUP-Anfrage für die neue Sitzung am angegebenen Host senden.

S->C: REDIRECT rtsp://example.com/media.mp4 RTSP/1.0 CSeq: 11 Standort: rtsp://bigserver.com:8001 Bereich: Uhr=19960213T143205Z- 

Bestimmte Firewall-Architekturen oder andere Umstände können einen Server dazu zwingen, RTSP-Methoden und Streaming-Daten zu verschachteln. Diese Verschachtelung sollte im Allgemeinen vermieden werden, sofern sie nicht unbedingt erforderlich ist, da sie den Betrieb von Client und Server erschwert und zusätzlichen Aufwand verursacht. Verschachtelte Binärdaten sollten nur verwendet werden, wenn RTSP über TCP übertragen wird.

Streamdaten, wie z. B. RTP-Pakete, werden durch ein ASCII-Dollarzeichen (24 hexadezimal) gekapselt, gefolgt von einer ein Byte langen Kanalkennung und der Länge der gekapselten Binärdaten als zwei Byte lange Ganzzahl in Netzwerk-Byte-Reihenfolge. Unmittelbar im Anschluss folgen die Streamdaten ohne CRLF, jedoch einschließlich der Protokollheader der höheren Schicht. Jeder $-Block enthält genau eine Dateneinheit des Protokolls der höheren Schicht, z. B. ein RTP-Paket.

C->S: SETUP rtsp://example.com/media.mp4 RTSP/1.0 CSeq: 3 Transport: RTP/AVP/TCP;interleaved=0-1 S->C: RTSP/1.0 200 OK CSeq: 3 Datum: 05. Juni 1997 18:57:18 GMT Transport: RTP/AVP/TCP;interleaved=0-1 Sitzung: 12345678 C->S: PLAY rtsp://example.com/media.mp4 RTSP/1.0 CSeq: 4 Sitzung: 12345678 S->C: RTSP/1.0 200 OK CSeq: 4 Sitzung: 12345678 Datum: 05. Juni 1997 18:59:15 GMT RTP-Info: url=rtsp://example.com/media.mp4;seq=232433;rtptime=972948234 S->C: $\000{2 Byte Länge}{"Länge" Bytes Daten, mit RTP-Header} S->C: $\000{2 Byte Länge}{"Länge" Bytes Daten, mit RTP-Header} S->C: $\001{2 Byte Länge}{"Länge" Bytes RTCP-Paket} 

RTSP über HTTP wurde 1999 von Apple definiert. ^{[ 9 ]} Es bettet die RTP-Video- und Audiodaten in die RTSP-Befehlsverbindung (gemäß RFC 2326) ein und sendet diese anschließend über zwei HTTP-Verbindungen. Eine davon ist eine dauerhafte GET-Verbindung, die andere eine dauerhafte POST-Verbindung.

Diese Methode wird auch im ONVIF IP-Kamerastandard verwendet und kann mit HTTPS für sichere und verschlüsselte Video- und Audioübertragung kombiniert werden.

Es gibt verschiedene Methoden zur Verschlüsselung von RTSP-Befehlsnachrichten und RTP-Video- und Audiodaten.

RTSP 2.0 (RFC7826) definiert verschiedene Verschlüsselungsmethoden und führt eine neue rtsps://URL ein. Viele davon wurden in RFC2326 RTSP 1.0 Clients und Server integriert.

• RTSP-URL (über die rtsps://URL) – Diese Methode verwendet einen TLS- Socket (standardmäßig Port 322), um eine verschlüsselte Verbindung zwischen dem RTSP-Client und dem RTSP-Server herzustellen. Video und Audio können dann auf zwei Arten übertragen werden:
  • TCP Video/Audio - Das RTP-Video und -Audio wird zusammen mit den RTSP-Befehlen über die bereits verschlüsselte TLS -Verbindung gesendet .
  • UDP und Multicast-UDP Video/Audio - das RTP-Video und -Audio wird mit dem Secure RTP (SRTP) -Protokoll verschlüsselt und parallel zur RTSPS -TLS -Verbindung gesendet.
• RTSP über HTTPS – diese Methode bettet die RTP-Video- und Audiodaten in die RTSP-Befehlsverbindung (gemäß RFC 2326) ein und sendet diese anschließend über zwei verschlüsselte HTTPS-Verbindungen. Standardmäßig wird Port 443 verwendet.

rtsps://Die IANA hat das URL-Präfix und Port 322 für RTSP reserviert . ^{[ 10 ]} Stand September 2024 ist RTSP über HTTPS in mehreren ONVIF-IP-Kameras implementiert, und RTSP (über die rtsps://URL) wird von Axis- und Bosch-Überwachungskameras ^{[ 11 ]} , FFmpeg , GStreamer , MediaMTX ^{[ 12 ]} , Ant Media Server ^{[ 13 ]} und SharpRTSP ^{[ 14 ] unterstützt.}

RTSP unter Verwendung von RTP und RTCP ermöglicht die Implementierung der Ratenanpassung. ^{[ 15 ]}

• Ant Media Server: The Community version^[16] supports pulling from RTSP/S sources and can livestream using HLS or record in MP4. The Enterprise version can convert RTSP to WebRTC with approximately 200-500ms end-to-end latency.
• Darwin Streaming Server is an open source version of QuickTime Streaming Server maintained by Apple.
• GStreamer based RTSP Server and client.
• Helix DNA Server is RealNetworks' streaming server, which comes in both open-source and proprietary versions.
• Helix Universal Server is RealNetworks' commercial streaming server for RTSP, RTMP, iOS, Silverlight and HTTP streaming media clients.
• LIVE555 liveMedia / openRTSP are open source C++ server and client libraries used in well-known clients like VLC and mplayer.
• Motion is a free CCTV software application for Linux.
• Nimble Streamer supports RTSP pull and announce input, with TCP interleaved playback output.
• OvenMediaEngine is an open source low-latency streaming server that supports RTSP push input.
• pvServer: Formerly called PacketVideo Streaming Server, this is Alcatel-Lucent's streaming server product.
• QuickTime Streaming Server is Apple's closed-source streaming server that ships with Mac OS X Server.
• VideoLAN is an open source media player and streaming server.
• Windows Media Services is a Microsoft streaming server previously included with Windows Server that uses RTSP modified with Windows Media extensions.
• Wowza Streaming Engine is a multi-format streaming server for RTSP/RTP, RTMP, MPEG-TS, ICY, HTTP (HTTP Live Streaming, HTTP Dynamic Streaming, Smooth Streaming, MPEG-DASH), and WebRTC.
• YouTube implemented a mobile web front end in June 2007, which serves video through this protocol.^[17]

Many CCTV / Security cameras, often called IP cameras, support RTSP streaming too, especially those with ONVIF profiles G, S, T.

• Astra
• cURL (beginning with version 7.20.0—9 February 2010^[18])
• FFmpeg^[19]
• GStreamer
• JetAudio
• LIVE555 liveMedia / openRTSP : Open-Source- C++- Server- und Clientbibliotheken, die in bekannten Clients wie VLC und mplayer verwendet werden .
• Media Player Classic
• MPlayer
• MythTV via Freebox
• QuickTime
• RealPlayer
• Skype
• Spotify
• VLC Media Player
• Winamp
• Windows Media Player
• Xine
• ZoneMinder
• Bewegung (Überwachungssoftware)

• „Informationen und Aktualisierungen zum Echtzeit-Streaming-Protokoll“ . Archiviert vom Original am 06.03.2007., ein zentrales Informationsrepository über RTSP.
• „Tunnelung von RTSP und RTP über HTTP“ . Archiviert vom Original am 1. Mai 2013.Eine Standardlösung, um RTSP das Funktionieren durch Firewalls und Webproxys zu ermöglichen.
• „ Managed Media Aggregation using Rtsp and Rtp “, führt einen Entwickler durch die Implementierung eines standardkonformen RtspClient und RtspServer.