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".

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

Molte telecamere CCTV / Security, spesso chiamate IP Camera , supportano anche lo streaming RTSP, specialmente queste con profili ONVIF G, S, T.

Cliente

Riferimenti

link esterno