Das Real Time Streaming Protocol (RTSP), das von der IETF entwickelt und 1998 als RFC 2326 geschaffen wurde, ist ein Protokoll zur Verwendung in Streaming-Media-Systemen, das es einem Client ermöglicht, einen Streaming-Media-Server fernzusteuern, indem er VCR-ähnliche Befehle wie "Play" und "Pause" ausgibt und den zeitbasierten Zugriff auf Dateien auf einem Server ermöglicht.

Das Senden von Streaming-Daten selbst ist nicht Teil des RTSP-Protokolls. Die meisten RTSP-Server verwenden das standardbasierte RTP als Transportprotokoll für die eigentlichen Audio-/Videodaten. Der RTSP-Server von RealNetworks verfügt auch über das proprietäre RDT von RealNetworks als Transportprotokoll.

Funktionen und Merkmale

  • Steuerkanal, kein Medientransport: RTSP definiert Steuerbefehle (z. B. PLAY, PAUSE, TEARDOWN), nicht das Format der Mediendaten selbst.
  • Session-Management: Server können Sitzungen anlegen und verwalten; Clients erhalten Session-IDs, mit denen weitere Befehle zur gleichen Sitzung geschickt werden.
  • Zugriff auf Zeitbereiche: Über Header wie Range kann auf bestimmte Zeitabschnitte oder Positionen in einem Stream zugegriffen werden (z. B. Zeitbasiertes Springen/Seek).
  • Protokollbefehle: RTSP verwendet eine Befehlssyntax ähnlich zu HTTP (Request/Response) und kennt Methoden wie OPTIONS, DESCRIBE, SETUP, PLAY, PAUSE, TEARDOWN, GET_PARAMETER und SET_PARAMETER.
  • Transportflexibilität: Kontrolle läuft typischerweise über TCP (Default-Port 554), die Mediendaten werden aber oft über RTP/RTCP per UDP ausgeliefert; alternativ ist ein "interleaved" Modus möglich, bei dem RTP über denselben TCP-Kanal wie RTSP gesendet wird (praktisch bei Firewalls/NAT).

Typische RTSP-Ablaufsequenz

  • Client fragt mit DESCRIBE Informationen (SDP) über die verfügbaren Medienstreams an.
  • Mit SETUP wird für jeden Medienstrom der Transport (z. B. RTP-Port oder interleaved/TCP) ausgehandelt und eine Session-ID erzeugt.
  • PLAY startet die Wiedergabe, PAUSE unterbricht sie, TEARDOWN beendet die Session.
  • Während der Wiedergabe liefert RTP die Audiound Videopakete; RTCP kann zur Monitoring- und QoS-Information genutzt werden.

Einsatzgebiete

  • IP-Kameras und Überwachung: Viele Netzwerkkameras bieten RTSP-Streams, die von Videomanagement-Systemen oder Playern empfangen werden können.
  • Video-on-Demand (VoD): RTSP eignet sich für den zeitbasierten Zugriff und die Steuerung bei VoD-Servern.
  • Live-Streaming: In professionellen Umgebungen oder bei geringerer Latenzanforderung wird RTSP zusammen mit RTP genutzt.
  • Test- und Entwicklungswerkzeuge: Programme wie VLC, ffmpeg, GStreamer u. a. unterstützen RTSP als Client- und Serverkomponente.

Sicherheit und Einschränkungen

  • Transportverschlüsselung: RTSP selbst ist ursprünglich unverschlüsselt; Control-Kanäle können jedoch über TLS abgesichert werden (RTSP-over-TLS) und Mediendaten über SRTP geschützt werden.
  • Firewall/NAT-Probleme: UDP-basierte RTP-Streams können hinter Firewalls oder NAT-Geräten Probleme bereiten; der interleaved-Modus (RTP über TCP) oder Tunneling sind übliche Workarounds.
  • Kompatibilität: Da RTSP vor allem das Steuerprotokoll ist, hängt die Interoperabilität von Codecs, SDP-Darstellung und Transportoptionen ab.

Vor- und Nachteile

  • Vorteile: Feine Steuerbarkeit (Pause, Seek), Einsatz in Low-Latency-Szenarien, verbreitet in IP-Kameras und professionellen Setups.
  • Nachteile: Komplexität bei NAT/Firewall, keine einheitliche Sicherheitslösung in der Originalspezifikation, im Web-Streaming (Browser-basiert) weniger verbreitet als HTTP-basierte Ansätze (HLS, DASH).

Standards und Implementierungen

  • Ursprünglich RFC 2326 (1998). Eine überarbeitete Spezifikation ist als RTSP 2.0 in RFC 7826 (2016) veröffentlicht worden, die mehrere Verbesserungen und Klarstellungen enthält.
  • Beliebte Clients/Server: VLC, ffmpeg, GStreamer, Live555 und kommerzielle VMS/RTSP-Server in IP-Kamera-Systemen.

Praxis-Tipps

  • Wenn Probleme beim Zugriff auf RTSP-Streams hinter Firewalls auftreten, testweise den interleaved-Modus (RTP over TCP) verwenden.
  • Bei Bedarf an Sicherheit Mediendaten mit SRTP und Steuerkanal mit TLS absichern.
  • Für browserbasiertes Streaming empfiehlt sich heutzutage meist HLS oder DASH; RTSP bleibt jedoch in Anwendungen mit niedrigster Latenz oder direkter Kameraanbindung relevant.

RTSP bleibt ein wichtiges Steuerprotokoll für Streaming-Anwendungen, besonders dort, wo Feinsteuerung und geringe Verzögerung wichtig sind. Die Trennung von Steuer- und Mediendaten erlaubt flexible Architekturen, erfordert aber bei Integration und Sicherheit genaue Planung.