Protocollo di streaming in tempo reale - Real Time Streaming Protocol
Il Real Time Streaming Protocol ( RTSP ) è un protocollo di controllo di rete progettato per l'uso nei sistemi di intrattenimento e comunicazione per controllare i server multimediali in streaming . Il protocollo viene utilizzato per stabilire e controllare le sessioni multimediali tra gli endpoint. I client dei server multimediali emettono comandi come play , record e pause , per facilitare il controllo in tempo reale dello streaming multimediale dal server a un client (Video On Demand) o da un client al server (Voice Recording).
Storia
RTSP è stato sviluppato da RealNetworks , Netscape e Columbia University . La prima bozza è stata presentata a IETF nell'ottobre 1996 da Netscape e Progressive Networks , dopo di che Henning Schulzrinne della Columbia University ha presentato "RTSP'" ("RTSP prime") nel dicembre 1996. Le due bozze sono state unite per la standardizzazione dalla Multiparty Multimedia Session Control Working Group (MMUSIC WG) della Internet Engineering Task Force (IETF) e ulteriori bozze sono state pubblicate dal gruppo di lavoro. Lo standard proposto per RTSP è stato pubblicato come RFC 2326 nel 1998. RTSP 2.0 pubblicato come RFC 7826 nel 2016 in sostituzione di RTSP 1.0. RTSP 2.0 è basato su RTSP 1.0 ma non è retrocompatibile se non nel meccanismo di negoziazione della versione base e rimane uno "standard proposto".
Suite di protocolli Internet |
---|
Livello di applicazione |
Livello di trasporto |
Livello Internet |
Livello di collegamento |
RTP
La trasmissione di dati in streaming in sé non è un compito di RTSP. La maggior parte dei server RTSP utilizza il protocollo RTP ( Real-time Transport Protocol ) insieme al protocollo RTCP ( Real-time Control Protocol ) per la consegna del flusso multimediale. Tuttavia, alcuni fornitori implementano protocolli di trasporto proprietari. Il software server RTSP di RealNetworks , ad esempio, utilizzava anche Real Data Transport (RDT) proprietario di RealNetworks .
Direttive del protocollo
Sebbene in qualche modo simile a HTTP , RTSP definisce sequenze di controllo utili per controllare la riproduzione multimediale. Mentre HTTP è senza stato , RTSP ha lo stato; un identificatore viene utilizzato quando necessario per tenere traccia delle sessioni simultanee. Come HTTP, RTSP utilizza TCP per mantenere una connessione end-to-end e, mentre la maggior parte dei messaggi di controllo RTSP vengono inviati dal client al server, alcuni comandi viaggiano nella direzione opposta (cioè dal server al client).
Qui presentate sono le richieste RTSP di base. Sono disponibili anche alcune richieste HTTP tipiche , come la richiesta OPTIONS. Il numero di porta del livello di trasporto predefinito è 554 sia per TCP che per UDP , quest'ultimo utilizzato raramente per le richieste di controllo.
OPZIONI
- Una richiesta OPTIONS restituisce i tipi di richiesta che il server accetterà.
C->S: OPTIONS rtsp://example.com/media.mp4 RTSP/1.0 CSeq: 1 Require: implicit-play Proxy-Require: gzipped-messages S->C: RTSP/1.0 200 OK CSeq: 1 Public: DESCRIBE, SETUP, TEARDOWN, PLAY, PAUSE
DESCRIVERE
- Una richiesta DESCRIBE include un URL RTSP (rtsp://...) e il tipo di dati di risposta che possono essere gestiti. Questa risposta include la descrizione della presentazione, in genere in formato SDP ( Session Description Protocol ). Tra le altre cose, la descrizione della presentazione elenca i flussi multimediali controllati con l'URL aggregato. Nel caso tipico, è presente un flusso multimediale ciascuno per il flusso audio e video. Gli URL del flusso multimediale sono ottenuti direttamente dai campi di controllo SDP oppure sono ottenuti aggiungendo il campo di controllo SDP all'URL aggregato.
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 Content-Length: 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;"hinted video track" 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;"hinted audio track"
IMPOSTARE
- Una richiesta SETUP specifica come deve essere trasportato un singolo flusso multimediale. Questo deve essere fatto prima che venga inviata una richiesta PLAY. La richiesta contiene l'URL del flusso multimediale e un identificatore di trasporto. Questo identificatore include in genere una porta locale per la ricezione di dati RTP (audio o video) e un'altra per i dati RTCP (meta informazioni). La risposta del server di solito conferma i parametri scelti e completa le parti mancanti, come le porte scelte dal server. Ciascun flusso multimediale deve essere configurato utilizzando SETUP prima di poter inviare una richiesta di riproduzione aggregata.
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 Session: 12345678 C->S: SETUP rtsp://example.com/media.mp4/streamid=1 RTSP/1.0 CSeq: 3 Transport: RTP/AVP;unicast;client_port=8002-8003 Session: 12345678 S->C: RTSP/1.0 200 OK CSeq: 3 Transport: RTP/AVP;unicast;client_port=8002-8003;server_port=9002-9003;ssrc=1234ABCD Session: 12345678
GIOCARE A
- Una richiesta PLAY farà riprodurre uno o tutti i flussi multimediali. Le richieste di riproduzione possono essere impilate inviando più richieste di riproduzione. L'URL può essere l'URL aggregato (per riprodurre tutti i flussi multimediali) o un singolo URL del flusso multimediale (per riprodurre solo quel flusso). È possibile specificare un intervallo. Se non viene specificato alcun intervallo, lo stream viene riprodotto dall'inizio e fino alla fine oppure, se lo stream è in pausa, viene ripreso dal punto in cui era stato messo in pausa.
C->S: PLAY rtsp://example.com/media.mp4 RTSP/1.0 CSeq: 4 Range: npt=5-20 Session: 12345678 S->C: RTSP/1.0 200 OK CSeq: 4 Session: 12345678 RTP-Info: url=rtsp://example.com/media.mp4/streamid=0;seq=9810092;rtptime=3450012
PAUSA
- Una richiesta PAUSE interrompe temporaneamente uno o tutti i flussi multimediali, in modo che possa essere successivamente ripreso con una richiesta PLAY. La richiesta contiene un URL aggregato o del flusso multimediale. Un parametro di intervallo su una richiesta PAUSE specifica quando mettere in pausa. Quando il parametro range viene omesso, la pausa si verifica immediatamente ea tempo indeterminato.
C->S: PAUSE rtsp://example.com/media.mp4 RTSP/1.0 CSeq: 5 Session: 12345678 S->C: RTSP/1.0 200 OK CSeq: 5 Session: 12345678
DISCO
- Questo metodo avvia la registrazione di una serie di dati multimediali in base alla descrizione della presentazione. Il timestamp riflette l'ora di inizio e di fine (UTC). Se non viene fornito alcun intervallo di tempo, utilizzare l'ora di inizio o di fine fornita nella descrizione della presentazione. Se la sessione è già iniziata, inizia subito a registrare. Il server decide se memorizzare i dati registrati sotto l'URI di richiesta o un altro URI. Se il server non utilizza l'URI della richiesta, la risposta dovrebbe essere 201 e contenere un'entità che descrive gli stati della richiesta e fa riferimento alla nuova risorsa e un'intestazione Location.
C->S: RECORD rtsp://example.com/media.mp4 RTSP/1.0 CSeq: 6 Session: 12345678 S->C: RTSP/1.0 200 OK CSeq: 6 Session: 12345678
ANNUNCIARE
Il metodo ANNUNCIA ha due scopi:
- Quando viene inviato dal client al server, ANNOUNCE invia a un server la descrizione di una presentazione o di un oggetto multimediale identificato dall'URL di richiesta. Quando viene inviato dal server al client, ANNOUNCE aggiorna la descrizione della sessione in tempo reale. Se un nuovo flusso multimediale viene aggiunto a una presentazione (ad esempio, durante una presentazione dal vivo), l'intera descrizione della presentazione dovrebbe essere inviata di nuovo, anziché solo i componenti aggiuntivi, in modo che i componenti possano essere eliminati.
C->S: ANNUNCIA rtsp://example.com/media.mp4 RTSP/1.0
CSeq: 7
Data: 23 gennaio 1997 15:35:06 GMT
Sessione: 12345678
Tipo di contenuto: application/sdp
Lunghezza contenuto: 332
v=0
o=maniglia 2890844526 2890845468 IN IP4 126.16.64.4
s=Seminario SDP
i=A Seminario sul protocollo di descrizione della sessione
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=recvoly
m=audio 3456 RTP/AVP 0
m=video 2232 RTP/AVP 31
S->C: RTSP/1.0 200 OK
CSeq: 7
DEMOLIRE
- Una richiesta di TEARDOWN viene utilizzata per terminare la sessione. Arresta tutti i flussi multimediali e libera tutti i dati relativi alla sessione sul server.
C->S: TEARDOWN rtsp://example.com/media.mp4 RTSP/1.0 CSeq: 8 Session: 12345678 S->C: RTSP/1.0 200 OK CSeq: 8
GET_PARAMETER
- La richiesta GET_PARAMETER recupera il valore di un parametro di una presentazione o di un flusso specificato nell'URI. Il contenuto della risposta e della risposta è lasciato all'implementazione. GET_PARAMETER senza corpo dell'entità può essere utilizzato per testare la funzionalità del client o del server ("ping").
S->C: GET_PARAMETER rtsp://example.com/media.mp4 RTSP/1.0 CSeq: 9 Content-Type: text/parameters Session: 12345678 Content-Length: 15 packets_received jitter C->S: RTSP/1.0 200 OK CSeq: 9 Content-Length: 46 Content-Type: text/parameters packets_received: 10 jitter: 0.3838
SET_PARAMETER
- Questo metodo richiede di impostare il valore di un parametro per una presentazione o un flusso specificato dall'URI.
C->S: SET_PARAMETER rtsp://example.com/media.mp4 RTSP/1.0 CSeq: 10 Content-length: 20 Content-type: text/parameters barparam: barstuff S->C: RTSP/1.0 451 Invalid Parameter CSeq: 10 Content-length: 10 Content-type: text/parameters barparam
REINDIRIZZARE
- Una richiesta REDIRECT informa il client che deve connettersi a un'altra posizione del server. Contiene l'intestazione obbligatoria Posizione, che indica che il client deve inviare richieste per quell'URL. Può contenere il parametro Range, che indica quando il reindirizzamento ha effetto. Se il client vuole continuare a inviare o ricevere supporti per questo URI, il client DEVE emettere una richiesta di TEARDOWN per la sessione corrente e un SETUP per la nuova sessione presso l'host designato.
S->C: REDIRECT rtsp://example.com/media.mp4 RTSP/1.0 CSeq: 11 Location: rtsp://bigserver.com:8001 Range: clock=19960213T143205Z-
Dati binari incorporati (interlacciati)
- Alcuni progetti di firewall e altre circostanze possono costringere un server a interlacciare metodi RTSP e trasmettere dati. Questo interleaving dovrebbe essere generalmente evitato a meno che non sia necessario poiché complica il funzionamento di client e server e impone un sovraccarico aggiuntivo. I dati binari interlacciati DOVREBBE essere utilizzati solo se RTSP è trasportato su TCP. I dati di flusso come i pacchetti RTP sono incapsulati da un segno di dollaro ASCII (24 esadecimale), seguito da un identificatore di canale a un byte, seguito dalla lunghezza dei dati binari incapsulati come un numero intero binario a due byte nell'ordine dei byte di rete. I dati del flusso seguono immediatamente dopo, senza CRLF, ma includendo le intestazioni del protocollo di livello superiore. Ogni blocco $ contiene esattamente un'unità di dati del protocollo di livello superiore, ad esempio un pacchetto RTP.
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 Date: 05 Jun 1997 18:57:18 GMT Transport: RTP/AVP/TCP;interleaved=0-1 Session: 12345678 C->S: PLAY rtsp://example.com/media.mp4 RTSP/1.0 CSeq: 4 Session: 12345678 S->C: RTSP/1.0 200 OK CSeq: 4 Session: 12345678 Date: 05 Jun 1997 18:59:15 GMT RTP-Info: url=rtsp://example.com/media.mp4;seq=232433;rtptime=972948234 S->C: $\000{2 byte length}{"length" bytes data, w/RTP header} S->C: $\000{2 byte length}{"length" bytes data, w/RTP header} S->C: $\001{2 byte length}{"length" bytes RTCP packet}
Adattamento della tariffa
RTSP che utilizza RTP e RTCP consente l'implementazione dell'adattamento della velocità.
implementazioni
server
- Darwin Streaming Server : versione open source di QuickTime Streaming Server gestita da Apple.
- Feng : server di streaming snello e medio con particolare attenzione alla conformità rfc.
- Server e client RTSP basati su GStreamer .
- Helix DNA Server : server di streaming di RealNetworks . Disponibile sia in versioni open-source che proprietarie.
- Helix Universal Server : server di streaming commerciale RealNetworks per client multimediali in streaming RTSP, RTMP, iOS, Silverlight e HTTP
- LIVE555 liveMedia / openRTSP : server C++ open source e librerie client utilizzate in client noti come VLC e mplayer .
- Motion : un'applicazione software CCTV gratuita per Linux.
- Nimble Streamer supporta input pull e annuncio RTSP con output di riproduzione interlacciato TCP.
- pvServer : precedentemente chiamato PacketVideo Streaming Server, questo è il prodotto server di streaming di Alcatel-Lucent.
- QuickTime Streaming Server : server di streaming closed-source di Apple fornito con Mac OS X Server.
- VideoLAN : lettore multimediale open source e server di streaming.
- Servizi Windows Media : server di streaming Microsoft precedentemente incluso con Windows Server che utilizza RTSP modificato con estensioni Windows Media
- Wowza Streaming Engine : server di streaming multiformato per RTSP/RTP, RTMP , MPEG-TS , ICY, HTTP ( HTTP Live Streaming , HTTP Dynamic Streaming , Smooth Streaming , MPEG-DASH ), WebRTC
- YouTube ha implementato un front-end web mobile nel giugno 2007 che serve video attraverso questo protocollo.
Molte telecamere CCTV / Security, spesso chiamate IP Camera , supportano anche lo streaming RTSP, specialmente queste con profili ONVIF G, S, T.
Cliente
- Astra
- cURL (a partire dalla versione 7.20.0-9 febbraio 2010)
- FFmpeg
- GStreamer
- JetAudio
- LIVE555 liveMedia / openRTSP : server C++ open source e librerie client utilizzate in client noti come VLC e mplayer .
- Lettore multimediale classico
- MPlayer
- MythTV tramite Freebox
- Tempo veloce
- Vero giocatore
- Skype
- Spotify
- Lettore multimediale VLC
- Winamp
- Windows Media Player
- xine
- ZoneMinder
- Motion_(software_sorveglianza)
Riferimenti
link esterno
- "Informazioni e aggiornamenti sul protocollo di streaming in tempo reale" . Archiviato dall'originale il 06/03/2007., un archivio centrale di informazioni su RTSP.
- "Tunnel RTSP e RTP tramite HTTP" . Archiviato dall'originale il 01-05-2013., Una soluzione standard per aiutare RTSP a funzionare attraverso firewall e proxy web
- " Managed Media Aggregation utilizzando Rtsp e Rtp ", accompagna uno sviluppatore attraverso l'implementazione di RtspClient e RtspServer conformi agli standard.