RTSP regelt nur die Session, der Stream selbst hat eine eigene Übertragung
Über das Real Time Streaming Protocol (RTSP) wird lediglich die Steuerung abgewickelt. Hierzu wird zwischen dem Player (Client) und dem Server eine Sitzung aufgebaut, das funktioniert ganz ähnlich wie ein Sitzungsaufbau mit HTTP. RTSP und HTTP benutzen TCP als Layer. Ein wesentlicher Unterschied zu HTTP ist jedoch der, daß der Stream nicht via RTSP/TCP übertragen wird sondern über ein eigenes Socket und UDP (User Datagram Protocol) wobei dieses Socket erst aufgebaut werden kann, wenn per RTSP die Sitzung steht.
Aufgrund dieser Funktionsweise eignet sich RTSP insbesondere für Mediatheken. So bekommen Benutzer bspw. einen Film auf Anforderung und können disen bedarfsweise auch anhalten und fortsetzen oder neu starten. Betrachte untenstehenden Screenshot (Wireshark) welcher die zu Sitzung gehörigen Request-Methoden zeigt, vom Aufbau bis zum Beenden der Sitzung:
Erforderlich sind 3 Requests mit den Methoden OPTIONS, DESCRIBE und SETUP. Erst wenn diese 3 Requests erfolgreich sind, ist die Session aufgebaut und die Methode PLAY kann requested werden.
Dieser Request dient zum Einen der Prüfung ob der Server RTSP-conform arbeitet. Zum Anderen dient ein OPTIONS-Request auch dazu, das Timeout einer Session zu verlängern, sozusagen als Keep-Alive. Der Request sieht so aus:
OPTIONS rtsp://192.168.178.33:554 RTSP/1.0 Cseq: 2 User-Agent: LibVLC/3.0.12 (LIVE555 Streaming Media v2016.11.28)
Woraufhin der Server antwortet wie folgt:
RTSP/1.0 200 OK CSEQ: 2 PUBLIC: DESCRIBE, SET_PARAMETER, SETUP, TEARDOWN, PAUSE, PLAY SERVER: TAS-Tech Streaming Server V100R001
RTSP-conform also heißt daß die im Response-Header aufgeführten Methoden verfügbar sind.
Dieser Request dient dazu den fürs SETUP erforderlichen URL zu präzisieren. Dieser URL ist im Response-Body finden was den zusätzlichen Header Accept erfordert:
DESCRIBE rtsp://192.168.178.33:554 RTSP/1.0 Cseq: 3 User-Agent: LibVLC/3.0.12 (LIVE555 Streaming Media v2016.11.28 Accept: application/sdp
Die Response liefert also einen Message-Body gemäß application/sdp, zum Parsen dessen empfiehlt sich das Perl-Modul Net::SDP (Session Description Protocol)
RTSP/1.0 200 OK CSEQ: 3 CONTENT_LENGTH: 318 CONTENT_TYPE: application/sdp SERVER: TAS-Tech Streaming Server V100R001 v=0 o=StreamingServer 3331435948 1116907222000 IN IP4 192.168.178.33 s=h264.mp4 i=TAS-Tech Live Cast c=IN IP4 192.168.178.33 t=0 0 a=recvonly a=range:npt=now- m=video 0 RTP/AVP 96 a=control:rtsp://192.168.178.33:554/0/video0 a=rtpmap:96 H264/90000 a=fmtp:96 packetization-mode=1 a=framesize:96 1280-720
In der Response, siehe obenstehend hervorgehoben ist der URL welcher beim SETUP-Request zu verwenden ist. Des Weiteren enthält dieser Response-Body sämtliche Meta-Informationen die zum Wiederherstellen des Media-Streams erforderlich sind.
Mit diesem Request schließlich wird die Sitzung aufgebaut. Gleichermaßen wird dem Request der Client-Port übergeben an welchen dann der Stream zu empfangen ist.
SETUP rtsp://192.168.178.33:554/0/video0 RTSP/1.0 Cseq: 4 User-Agent: LibVLC/3.0.12 (LIVE555 Streaming Media v2016.11.28 Transport: RTP/AVP;unicast;client_port=99091
Die Response liefert die Session-ID, deren Dauer (Timeout) und die Bestätigung für das Unicast-Socket, Client- und Server-Ports.
RTSP/1.0 200 OK CSEQ; 4 SERVER; TAS-Tech Streaming Server V100R001 SESSION: 2ZG3JnMl002b; timeout=60 TRANSPORT: RTP/AVP;unicast;client_port=99091-99092;server_port=8001-8002
Der Transport-Header in der Response weist den Weg für die Datenübertragung. Now we can play!
Diese Requests benötigen den Header Session mit der beim Setup erhaltenen Session-ID. Der Play-Request startet die Datenübertragung, Teaerdown beendet diese. Mit einem PAUSE-Request hingegegen wird die Übertragung nicht beendet sondern nur angehalten.
Nachdem der PLAY-Request erfolgreich gefeuert wurde, erfolgt der Transport der Daten über 2 UDP-Sockets welche den Client mit dem Server verbinden. Konkret heißt das, daß der Client RTCP-Daten an den Serverport 8002 (Controlport) sendet und RTP-Packets am Clientport 99091 empfängt, siehe Transport-Header in der Setup-Response welcher diese Ports präzisiert. Wireshark zeigt, wie die Übertragung über das UDP-Socket im Detail abläuft. Diese kleinen RTP-Datenpakete werden auch als Network-Abstraction-Layer (NAL) Units bezeichnet.
Datenschutzerklärung: Diese Seite dient rein privaten Zwecken. Auf den für diese Domäne installierten Seiten werden grundsätzlich keine personenbezogenen Daten erhoben. Das Loggen der Zugriffe mit Ihrer Remote Adresse erfolgt beim Provider soweit das technisch erforderlich ist. sos@rolfrost.de.