Cos'è RTSP e perché è necessario? Spiegazione del protocollo RTSP

Corrieri robotici, droni, automobili senza conducente e altri risultati della scienza e della tecnologia moderne non sembrano più qualcosa di un mondo fantastico. Sono diventati un fenomeno comune (o quasi) per noi. Le telecamere IP integrate consentono loro di “vedere” ciò che sta accadendo e noi possiamo vedere il mondo attraverso i loro “occhi”. Ma cosa succederebbe se vi dicessimo che la visione (telecamere IP) di queste creature ad alta tecnologia si basa su una tecnologia che ha più di 20 anni?

Ci credete? Rilassatevi e preparatevi a stupirvi.

In questo articolo, vi spiegheremo come la tecnologia degli anni ‘90 è ancora utilizzata con successo oggi, perché non c’è nulla di meglio e perché dovreste saperne di più.

Spoiler alert: il nome di questo veterano è RTSP.

In questo testo parleremo di RTSP, RTP, RTCP, di come esistano nelle telecamere IP odierne che supportano HEVC (H.265), con tecnologia di visione artificiale e analitica, e di come siano sopravvissuti fino ad oggi. Quindi cos’è di così buono e di così efficace in RTSP e perché non viene utilizzato in TV?

Indice:

1. Cos’è RTSP e perché è necessario?
2. La relazione tra RTSP e HTTP RTP (RTCP)
3. Relazione tra RTSP, RTP, RTCP e SDP
4. I metodi di base del protocollo RTSP. SIP e RTSP
5. Cos’era/cos’è RTSP
6. RTSP e RTMP
7. Flussonic e RTSP

Cos’è RTSP e perché è necessario?

RTSP (Real-Time Streaming Protocol) è un protocollo di livello applicativo progettato per i sistemi di telecomunicazioni e intrattenimento per controllare la distribuzione dei dati multimediali. RTSP è un protocollo di segnalazione, controlla la sessione di trasmissione dei dati.

In origine, RTSP era destinato a essere utilizzato per la distribuzione di programmi televisivi. Ed è stato così per un certo periodo. Poi un destino maligno ha deciso diversamente: RTSP è stato cancellato dalla televisione e ora può essere trovato solo nelle telecamere IP.

I principi stabiliti in RTSP possono essere osservati nello standard moderno WebRTC.

RTSP può essere paragonato a un telecomando televisivo. Può essere utilizzato per avviare, mettere in pausa, interrompere, ecc. il video sulla TV, il server multimediale. Il controllo non avviene tramite infrarossi, ma tramite Internet. L’umanità non ha ancora imparato a trasmettere il contenuto stesso tramite il telecomando televisivo (anche se si tratta dei nostri anni), ma è più che sufficiente per controllarlo.

Aspetta, quindi RTSP gestisce solo il contenuto, ma come avviene lo streaming del contenuto stesso?

Nel livello di trasporto, viene utilizzato RTP (Real-Time Protocol) per trasmettere lo streaming in tempo reale. La funzione RTSP è equivalente al telecomando di un server multimediale in streaming. Le telecamere IP possono utilizzare sia TCP che UDP per trasmettere contenuti in streaming. Tuttavia, va notato che UDP non ha senso pratico per questo compito.

Perché non UDP?

A causa della mancanza di moderni meccanismi di compensazione della perdita. Quindi i dati vengono semplicemente persi lungo il percorso. Nella nostra pratica, utilizziamo TCP, dove i dati e la gestione dei dati coesistono in un flusso simbiotico. Va notato che tutto funziona bene.

Abbiamo il concetto, abbiamo anche uno scopo in senso generale. Ma cosa succede nella pratica?

Prendiamo un esempio: supponiamo che tu abbia installato una telecamera di sorveglianza nella tua proprietà e hai paura che la tua videocamera e tutti i dati su di essa vengano rubati e non sarà mai possibile vedere i volti dei ladri. Cosa fare in questo caso? Metterlo in una cassaforte? Puoi impostare una registrazione video direttamente nel cloud. Utilizzando il protocollo RTSP, puoi inviare le informazioni a un servizio cloud remoto. Inoltre, se desideri visualizzare il file da un registratore video digitale (DVR) in remoto, la comunicazione con esso sarà anche tramite RTSP, ma solo se il dispositivo supporta il protocollo RTSP.

Oggi RTSP non viene più utilizzato per lo streaming web come tale, è stato oscurato e sostituito da rappresentanti più giovani della tecnologia di streaming: HLS e DASH, lasciandoci neanche una possibilità di resistere e combattere il cambiamento.

La relazione tra RTSP e HTTP RTP (RTCP)

Similitudini:

• Entrambi utilizzano testo semplice per inviare messaggi e la sintassi del protocollo RTSP è simile a HTTP.
• Inizialmente, RTSP è stato progettato per essere compatibile con il codice di parsing del protocollo HTTP precedentemente scritto.

Differenze:

• RTSP salva lo stato. I comandi RTSP devono sapere in quale stato si trovano attualmente. In altre parole, i comandi RTSP vengono sempre inviati in ordine, con ogni comando successivo che arriva dopo quello precedente. RTSP non interromperà la connessione, indipendentemente dallo stato in cui si trova. HTTP, d’altra parte, non salva lo stato. Dopo che il protocollo invia un comando, la connessione viene interrotta e non c’è alcuna dipendenza tra i comandi.

• RTSP utilizza la porta 554, mentre HTTP utilizza la porta 80.

• Rispetto a RTSP, le richieste HTTP vengono inviate dal client e il server risponde. Con RTSP, sia il client che il server possono inviare richieste, il che significa che RTSP può essere bidirezionale.

Relazione tra RTSP, RTP, RTCP e SDP

Uniamo insieme come sono correlati RTSP, RTP, RTCP e SDP:

• RTP (Real Time Protocol).

Un protocollo di streaming in tempo reale. RTP fornisce timestamp, numeri di serie e altri metodi per garantire il tempo di elaborazione durante le trasmissioni di dati in tempo reale.

• RTCP (Real-Time Transport Control Protocol)

Un protocollo per garantire la qualità del servizio e il controllo dei partecipanti. RTP e RTCP vengono utilizzati insieme.

• RTSP (Real-Time Streaming Protocol).

Un protocollo per controllare la consegna dei dati.

• SDP (Session Description Protocol).

Un protocollo per descrivere una sessione di dati in streaming.

I metodi di base del protocollo RTSP. SIP e RTSP

Vorremmo anche menzionare SIP (Session Initiation Protocol) per evidenziare le caratteristiche di RTSP e contrastarle con SIP.

SIP (Session Initiation Protocol) è simile a RTSP dal punto di vista visivo, ma la sua logica è molto diversa. Ad esempio, RTSP è spesso caratterizzato da una singola sessione TCP, mentre SIP è un anti-pattern.

Facciamo un confronto basato su SDP. RTSP (oggi SDP) viene utilizzato esclusivamente per descrivere il contenuto. In SIP, così come in WebRTC (che è un’estensione di SIP), SDP viene utilizzato per configurare porte e comunicazioni di rete.

Di seguito sono elencati i principali metodi RTSP:

RTSP Cos’era/è?

Cominciamo con un po’ di storia.

RTP insieme a RTCP è stato sviluppato nel 1996 e impostato nello standard RFC 1889. SDP è stato rilasciato nell’aprile 1998 nello standard RFC 2327. Anche RTSP è stato sviluppato nell’aprile 1998 dall’Internet Engineering Task Force (IETF) ed è riflessa nello standard RFC 2326. È diventato molto popolare subito perché permetteva di riprodurre video e audio direttamente su Internet senza dover scaricare il contenuto su un dispositivo client. Le persone erano entusiaste della quantità di tempo e risorse che poteva risparmiare!

RTSP proviene da reti in cui i ritardi e le perdite di consegna sono piccoli e stabili, cioè reti locali. È anche da dove provengono molte altre soluzioni.

RTSP è stato concepito e sviluppato quando il compito di controllare la consegna al client doveva essere affidato al server. Quindi, il server si occupava di tutta la logica: cosa, quando e a chi inviare. Possiamo dire che il server doveva essere il più complesso possibile e il client il più semplice e semplice possibile. Quando siamo passati ai protocolli HLS e DASH, la situazione era esattamente il contrario. Il cliente era ora più elaborato e il server più primitivo. Ma si è scoperto che le funzioni di controllo intelligente sulla consegna del server RTSP non sono sopravvissute fino ad oggi e sono cadute nell’oblio.

I server RTSP di oggi sono per lo più telecamere IP che non sono consapevoli di tutte le capacità di RTSP che sono state concepite decenni fa. Questo significa che non importa davvero se ci sono commenti dei clienti. Se il cliente riceve i dati, ottimo, se no, beh, succede, ci sono problemi.

Nota che RTSP è stato creato insieme alla telefonia. Si basava su soluzioni molto riuscite che già esistevano sul mercato, ma le abbiamo modificate un po’: RTP per la consegna dei dati, RTCP per la segnalazione della qualità della consegna dei dati (QoS) e SDP per il trasferimento delle informazioni sul contenuto. Per darti un’idea del successo di queste soluzioni, lo stesso RTP e RTCP

In un primo momento, RTSP è stato il leader tra le tecnologie di streaming video e audio. Ma nel corso del tempo, le tecnologie basate su HTTP che utilizzano un algoritmo di bitrate adattivo hanno eclissato RTSP e RTMP. Nonostante ciò, RTSP è ancora attivamente utilizzato oggi nella videosorveglianza per catturare il feed dalle telecamere IP.

È importante notare che RTSP per le telecamere IP e per la televisione sono due protocolli completamente diversi. Lo stesso RTSP per la televisione si trova solo nei sistemi legacy che sono ancora in funzione.

Dato che abbiamo iniziato a parlare di RTSP, dobbiamo menzionare anche RTMP.

RTSP contro RTMP

RTMP (Real-Time Messaging Protocol) è stato creato come protocollo per il trasferimento di funzioni, la gestione del codice remoto, una sorta di protocollo RPC, come lo era CORBA in passato o come lo è ora gRPC. RTMP era piuttosto complesso di per sé. In effetti, per quanto possa sembrare brusco, RTMP è ancora vivo solo perché le CDN hanno iniziato a supportarlo in tempo. Oggi, quasi tutte le CDN ti offrono la possibilità di trasmettere video tramite RTMP, ma non di riprodurlo. Oggi RTMP è solo un protocollo di pubblicazione, ma non di riproduzione perché non ha vantaggi rispetto agli attuali HLS, CMAF, ecc.

Nell’antichità, le telecamere IP vivevano principalmente sul codec MPEG-4 Part 2 e la TV aveva tutti i vantaggi di MPEG-2. E poi tutti sono passati al MPEG-4 Part 10, conosciuto anche come H.264 o AVC. Esatto, non c’è bisogno di rimanere fermi, è tempo di evolversi.

Ok, i codec sono stati cambiati, ma cosa succede a RTSP e RTMP? Cosa li caratterizza? Beh, non c’è via d’uscita.

Ti ricordi che RTSP è stato creato da soluzioni già di successo: RTP, RTCP, SDP? Ebbene, le telecamere IP, grazie alla flessibilità di SDP, sono passate senza problemi a H.264. Allo stesso modo, le telecamere IP sono passate a H.265 o HEVC.

RTMP, d’altra parte, non è stato in grado di fare transizioni simili con facilità. Perché? Perché RTMP non ha quella superpotenza di poter aggiungere nuovi codec, cioè di espandersi.

Come dice il detto, sopravvive il più adatto.

Flussonic e RTSP

I prodotti IT, scritti in fretta e non nel migliore dei modi, hanno avuto difficoltà a passare da UDP a TCP. Non sono riusciti a padroneggiare in modo qualitativo il modello di programmazione asincrona. Nella pratica, ciò si traduce nella trasformazione del socket TCP in modalità ’non bloccante’, in cui i dati possono andare persi, ovvero i tentativi del software di scrivere dati nel socket sembrano vani perché il socket è bloccato. Di conseguenza, il sistema operativo stesso non accetta i dati. Risulta che il software della telecamera semplicemente “scarta” i dati e, di conseguenza, ne risulta un disordine.

C’è un modo per risolvere questo problema?

Certamente, come collegare direttamente la telecamera IP al server con un cavo. Nonostante questo sia un modo ufficiale per installare le telecamere (che in realtà non sono state progettate per trasmettere dati su Internet), nell’attualità sembra una soluzione ridicola e frivola.

In Flussonic ci sono modalità per ripristinare la sincronizzazione. Ad esempio, se la telecamera cinese perde sincronizzazione e dati, in Flussonic ci sono meccanismi speciali per recuperare byte di informazioni perse, il che permette di resuscitare il flusso di dati. Quanto è interessante?

Cosa serve per iniziare a ricevere video dalla telecamera IP su Flussonic?

Innanzitutto, l’indirizzo IP della telecamera. Secondo, l’indirizzo IP della telecamera da solo non basta per ricevere video da essa. È sempre necessario specificare un altro percorso. Questo non è sempre fornito nella documentazione, quindi potrebbe essere necessario contattare il fornitore o il produttore della telecamera.

Come sono fatti i collegamenti RTSP:

• rtsp://nomehost/percorso - sintassi;
• rtsp://utente:password@ip/percorso - URL di autorizzazione;
• rtsp2://nomehost/percorso - abilita la trascodifica audio in AAC.
• rtsp://192.168.0.100/h264 - esempio di collegamento reale.

In Flussonic, tra le altre cose, puoi utilizzare l’opzione tracks=1 per catturare solo la traccia video. Ecco un esempio di configurazione:

stream fake { 
    input fake://fake; 
} 
stream input_rtsp { 
    input rtsp://localhost/fake tracks=1; 
} 

Flussonic Media Server consente di ricevere flussi tramite RTSP e molti altri protocolli.

Puoi scoprire come aggiungere una telecamera IP a Flussonic e inviare video al sito web nella sezione [documentazione] del nostro sito.

Puoi anche leggere su queste e molte altre funzionalità di Flussonic nella sezione documentazione del nostro sito web.

Autore:

Maksim Klyushkov

Flussonic Media Server Team Lead

At the forefront of Flussonic innovations: responsible for development of Flussonic Media Server, video analytics & UI services