Real Time Streaming Protocol (RTSP) ist ein Netzkontrollprotokoll, das für den Gebrauch in der Unterhaltung und den Kommunikationssystemen entworfen ist, um strömende Mediaserver zu kontrollieren. Das Protokoll wird verwendet, um Mediasitzungen zwischen Endpunkten zu gründen und zu kontrollieren. Kunden von Mediaservern geben EINEM Videogerät ähnliche Befehle, wie Spiel und Pause aus, um Echtzeitkontrolle des Play-Backs von Mediadateien vom Server zu erleichtern.

Die Übertragung von strömenden Daten selbst ist nicht eine Aufgabe des RTSP Protokolls. Die meisten RTSP Server verwenden Real-time Transport Protocol (RTP) in Verbindung mit dem Echtzeitkontrollprotokoll (RTCP) für die Mediastrom-Übergabe, jedoch führen einige Verkäufer Eigentumstransportprotokolle durch. Der RTSP Server von RealNetworks zeigt zum Beispiel auch Eigentumsreal Data Transport (RDT) von RealNetworks.

RTSP wurde von der Mehrparteimultimediasitzungskontrollarbeitsgruppe (MMUSIC WG) von Internet Engineering Task Force (IETF) entwickelt und als RFC 2326 1998 veröffentlicht.

RTSP, der RTP und RTCP verwendet, berücksichtigt die Durchführung der Rate-Anpassung.

Protokoll-Direktiven

Während ähnlich, in mancher Hinsicht zu HTTP definiert RTSP im Steuern des Multimediaplay-Backs nützliche Kontrollfolgen. Während HTTP staatenlos ist, hat RTSP Staat; ein Bezeichner, wird wenn erforderlich, verwendet gleichzeitige Sitzungen verfolgen. Wie HTTP verwendet RTSP TCP, um der Länge nach Verbindung aufrechtzuerhalten, und, während die meisten RTSP-Kontrollnachrichten vom Kunden an den Server, etwas Befehl-Reisen in der anderen Richtung (d. h. vom Server bis Kunden) gesandt werden.

Präsentiert hier sind die grundlegenden RTSP-Bitten. Einige typische HTTP-Bitten, wie die OPTIONS-Bitte, sind auch verfügbar. Die Verzug-Transportschicht-Hafen-Zahl ist 554.

OPTIONEN

: Eine OPTIONS-Bitte kehrt zurück die Bitte tippt der Server wird akzeptieren.

C-> S: OPTIONEN rtsp://example.com/media.mp4 RTSP/1.0

CSeq: 1

Verlangen Sie: implizites Spiel

Vertretung - Verlangt: Gzipped-Nachrichten

S-> C: RTSP/1.0 200, OK

, CSeq: 1

Publikum: BESCHREIBEN SIE EINSTELLUNG, TEARDOWN, SPIEL, PAUSE

</pre>

BESCHREIBEN SIE

: Eine BESCHREIBEN Bitte schließt eine RTSP URL-ADRESSE und den Typ von Antwort-Daten ein, die behandelt werden können. Der Verzug-Hafen für das RTSP Protokoll ist 554 sowohl für UDP (missbilligt als auch für sehr selten verwendet) und TCP-Transporte. Diese Antwort schließt die Präsentationsbeschreibung normalerweise im Format von Session Description Protocol (SDP) ein. Unter anderem verzeichnet die Präsentationsbeschreibung die mit der gesamten URL-ADRESSE kontrollierten Mediaströme. Im typischen Fall gibt es einen Mediastrom jeder für den Audio- und Video-.

C-> S: BESCHREIBEN SIE rtsp://example.com/media.mp4 RTSP/1.0

CSeq: 2

S-> C: RTSP/1.0 200, OK

, CSeq: 2

Zufriedene Basis: rtsp://example.com/media.mp4

Zufriedener Typ: application/sdp

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"

</pre>

EINSTELLUNG

: Eine EINSTELLUNGS-Bitte gibt an, wie ein einzelner Mediastrom transportiert werden muss. Das muss getan werden, bevor eine SPIEL-Bitte gesandt wird. Die Bitte enthält die Mediastrom-URL-ADRESSE und einen Transport specifier. Dieser specifier schließt normalerweise einen lokalen Hafen ein, um RTP Daten (Audio- oder Video-), und ein anderer für RTCP Daten (meta Information) zu erhalten. Die Server-Antwort bestätigt gewöhnlich die gewählten Rahmen, und füllt die fehlenden Teile wie die gewählten Häfen des Servers aus. Jeder Mediastrom muss mit der EINSTELLUNG konfiguriert werden, bevor eine gesamte Spiel-Bitte gesandt werden kann.

C-> S: EINSTELLUNG 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

Sitzung: 12345678

</pre>

SPIEL

: Eine SPIEL-Bitte wird ein oder alle Mediaströme veranlassen, gespielt zu werden. Spiel-Bitten können durch das Senden vielfacher SPIEL-Bitten aufgeschobert werden. Die URL-ADRESSE kann die gesamte URL-ADRESSE sein (um alle Mediaströme zu spielen), oder eine einzelne Mediastrom-URL-ADRESSE (um nur diesen Strom zu spielen). Eine Reihe kann angegeben werden. Wenn keine Reihe angegeben wird, wird der Strom vom Anfang und den Spielen zum Ende gespielt, oder, wenn der Strom Pause gemacht wird, wird es am Punkt fortgesetzt es wurde Pause gemacht.

C-> S: SPIELEN SIE rtsp://example.com/media.mp4 RTSP/1.0

CSeq: 4

Reihe: npt=5-20

Sitzung: 12345678S-> C: RTSP/1.0 200, OK, CSeq: 4 Sitzung: 12345678

RTP-Info:

url=rtsp://example.com/media.mp4/streamid=0;seq=9810092;rtptime=3450012 </pre>

PAUSE

: Eine PAUSE-Bitte hinkt provisorisch ein oder alle Mediaströme, so kann sie später mit einer SPIEL-Bitte fortgesetzt werden. Die Bitte enthält eine Anhäufung oder Mediastrom-URL-ADRESSE. Ein Reihe-Parameter auf einer PAUSE-Bitte gibt an, wenn man Pause macht. Wenn der Reihe-Parameter weggelassen wird, kommt die Pause sofort und unbestimmt vor.

C-> S: PAUSE rtsp://example.com/media.mp4 RTSP/1.0

CSeq: 5

Sitzung: 12345678S-> C: RTSP/1.0 200, OK, CSeq: 5 Sitzung: 12345678</pre>

AUFZEICHNUNG

: Diese Methode Eingeweihte, die eine Reihe von Mediadaten gemäß der Präsentationsbeschreibung registrieren. Der Zeitstempel widerspiegelt Anfang und Schließzeit (UTC). Wenn keine Zeitreihe gegeben wird, verwenden Sie den Anfang oder in der Präsentationsbeschreibung zur Verfügung gestellte Schließzeit. Wenn die Sitzung bereits angefangen hat, fangen Sie Aufnahme sofort an. Der Server entscheidet, ob man die registrierten Daten unter der Bitte URI oder ein anderer URI versorgt. Wenn der Server die Bitte URI nicht verwendet, sollte die Antwort 201 sein und eine Entität enthalten, die die Staaten der Bitte beschreibt und sich auf die neue Quelle und einen Positionskopfball bezieht.

C-> S: REGISTRIEREN SIE rtsp://example.com/media.mp4 RTSP/1.0

CSeq: 6

Sitzung: 12345678S-> C: RTSP/1.0 200, OK, CSeq: 6 Sitzung: 12345678</pre>

GEBEN SIE BEKANNT

: Die BEKANNT GEBEN Methode dient zwei Zwecken:

: Wenn gesandt, vom Kunden zum Server, geben Sie BEKANNT schlägt die Beschreibung einer Präsentation oder Mediagegenstands an, der durch die Bitte-URL-ADRESSE zu einem Server identifiziert ist. Wenn gesandt, vom Server bis Kunden, geben Sie BEKANNT aktualisiert die Sitzungsbeschreibung in Realtime. Wenn ein neuer Mediastrom zu einer Präsentation hinzugefügt wird (z.B, während einer lebenden Präsentation), sollte die ganze Präsentationsbeschreibung wieder, aber nicht gerade die zusätzlichen Bestandteile gesandt werden, so dass Bestandteile gelöscht werden können.

C-> S: GEBEN SIE rtsp:rtsp://example.com/media.mp4 RTSP/1.0 BEKANNT

CSeq: 7

Datum: 23 1997-15:35:06 Uhr GMT von Jan

Sitzung: 12345678 Zufriedener Typ: application/sdp

Zufriedene Länge: 332

v=0

o=mhandley 2890844526 2890845468 IN IP4 126.16.64.4

S=SDP-Seminar

I=A-Seminar über das 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</pre>

TEARDOWN

: Eine TEARDOWN-Bitte wird verwendet, um die Sitzung zu begrenzen. Es hört alle Mediaströme auf und befreit verwandten Daten ganzen Sitzung auf dem Server.

C-> S: TEARDOWN rtsp://example.com/media.mp4 RTSP/1.0

CSeq: 8

Sitzung: 12345678S-> C: RTSP/1.0 200, OK, CSeq: 8</pre>

Durchführungen

Server

• QuickTime, der Server Verströmt: Die geschlossene Quelle des Apfels, die Server verströmt, schifft sich das mit Mac OS X Server ein.
• Darwin, der Server Verströmt: Die offene-sourced Version von QuickTime, der Server Verströmt, durch den Apfel aufrechterhalten.
• pvServer: Früher genannter PacketVideo, der Server Verströmt, das ist das strömende Server-Produkt von Alcatel-Lucent.
• Spirale Universaler Server: RealNetworks kommerzieller strömender Server für RTSP, RTMP, EIN/AUSGABE-STEUERSYSTEM, Silverlight und strömende Mediakunden von HTTP
• Spirale-DNA-Server: Der strömende Server von RealNetworks. Kommt sowohl in der offenen Quelle als auch in den Eigentumsgeschmäcken.
• LIVE555: Offene Quelle C ++ Server und Kundenbibliotheken, die in weithin bekannten Kunden wie VLC und mplayer verwendet sind.
• Feng: Magerer und bösartiger strömender Server mit dem Fokus mit dem rfc Gehorsam.
• VideoLAN: Offener Quellmediaspieler und strömender Server.
• Windows Media Services: Der strömende Server des Microsofts mit dem Windows-Server eingeschlossen.
• VX30: Einteilung des Videoservers und eingebetteten javanischen Kunden vom Maui X-Strom.
• Xenon Strömender Server: Beweglicher strömender Server von der Vidiator Technologie (die Vereinigten Staaten) Inc.
• RtpRtspStack: Einteilung des Servers, der für den niedrigen Fußabdruck und die hohen Leistungsanwendungen entworfen wird.
• Gstreamer hat RTSP Server und Kunden gestützt.
• FFmpeg: Schließt ffserver ein GPL oder LGPL RTSP strömender Server ein.
• Erlyvideo hat RTSP Kunden und kann Video zu anderen Protokollen wiederverströmen.
• ViaMotion: integrierter RTSP Server für das Video Auf Verlangen durch Anevia

Kunde

• LOCKE (mit der Version 7.20.0 — am 9. Februar 2010 beginnend)

,

• FFmpeg (undokumentierter)
• # Lebendes Play-Back:
• #, lebende Sendung zu einer Datei Sparend:
• GStreamer
• Mediaspieler-Klassiker
• MPlayer
• MythTV über Freebox
• QuickTime
• RealPlayer
• Skype
• Spotify
• VLC Mediaspieler
• Winamp
• Windows-Mediaspieler
• xine
• JetAudio

Links

• ein Hauptinformationsbehältnis über RTSP.
• Tunnelbau RTSP und RTP durch HTTP, Eine Standardlösung, RTSP zu helfen, durch Brandmauern und Webvertretungen zu arbeiten