Real-time Transport Protocol

Nel mondo di oggi, Real-time Transport Protocol è un argomento di grande rilevanza e interesse per molte persone. Nel corso della storia, Real-time Transport Protocol ha svolto un ruolo fondamentale nella società, nella cultura e nella vita quotidiana delle persone. Fin dalle sue origini, Real-time Transport Protocol ha generato dibattito, polemiche e fascino, diventando un punto di riferimento per comprendere meglio il mondo che ci circonda. In questo articolo esploreremo le diverse sfaccettature di Real-time Transport Protocol, analizzando il suo impatto su vari aspetti della società e dell'individuo. Attraverso un approccio multidisciplinare, scopriremo le molteplici dimensioni e prospettive che Real-time Transport Protocol offre, arricchendo così la nostra conoscenza e comprensione di questo importante argomento.

In telecomunicazioni l'RTP o Real-time Transport Protocol è un protocollo del livello applicazioni (e del livello trasporto) utilizzato per servizi di comunicazione in tempo reale su Internet.

Descrizione

È stato sviluppato da un gruppo di ricerca noto come Audio-Video Transport Working Group, facente capo alla IETF (Internet Engineering Task Force). Il corrispondente RFC è stato pubblicato nel 1996.

RTP doveva inizialmente essere un protocollo multicast, ma viene più spesso impiegato in applicazioni unicast. È basato sul protocollo UDP e viene usato in congiunzione con RTCP (RTP Control Protocol) che monitora la qualità del servizio e trasporta le informazioni riguardo ai partecipanti ad una sessione. RTCP è sufficiente per sessioni “loosely controlled”, in cui cioè non c'è un reale controllo dei partecipanti e set-up della sessione, e non è necessario che tutti i requisiti di controllo siano soddisfatti. Per questo RTP può essere coadiuvato da un protocollo apposito per la gestione delle sessioni (come SIP o H.323). Rappresenta una delle tecnologie fondamentali nell'industria della telefonia su IP.

Questo protocollo permette distribuzione di servizi che necessitano di trasferimento in tempo reale, come l'interattività audio e video. Fra questi servizi si trovano anche:

  • l'identificazione del payload type
  • la numerazione sequenziale
  • la marcazione temporale (timestamp)
  • il monitoraggio.

Solitamente le applicazioni pongono l'RTP sopra l'UDP per le operazioni di multiplexing e checksum, anche se può essere usato con altri protocolli di rete e trasporto sottostanti.

I numeri di sequenza (sequence numbers) che troviamo nel protocollo RTP permettono all'utente che riceve i dati di ricostruire la sequenza dei pacchetti del mittente. Le conferenze multicast multimediali non sono però la sua unica capacità, anche se è stato implementato inizialmente per tale scopo. Ad esempio, trovano posto in questo protocollo la memorizzazione di un flusso dati continuo, le simulazioni interattive distribuite, le misurazioni e i controlli.

Header

bit offset 0-1 2 3 4-7 8 9-15 16-31
0 Ver. P X CC M PT Sequence Number
32 Timestamp
64 SSRC identifier
96 CSRC identifiers (optional)
...

I pacchetti RTP sono formati da un header di minimo 12 byte seguiti da un payload che dipende dalla specifica applicazione. L'header RTP è formato da:

  • Ver. (Version): (2bit) indica la versione del protocollo. La versione corrente è la numero 2.
  • P (Padding): (1 bit) indica se è presente un byte di padding alla fine del pacchetto.
  • X (Extension): (1 bit) indica la presenza di un Extension header tra l'header standard e il payload.
  • CC (CSRC Count): (4 bit) contiene il numero di CSRC identifiers (definiti sotto) che seguono l'header minimo.
  • M (Marker): (1 bit) Usato dal livello applicativo e quindi definito dal profilo specifico. Se è settato, significa che il pacchetto ha una qualche speciale rilevanza per il livello applicativo.
  • PT (Payload Type): (7 bit) indica il formato del payload e determina la sua interpretazione dall'applicazione. Questo è specifico per ogni profilo RTP.
  • Sequence Number: (16 bit) il sequence number viene incrementato di uno per ogni pacchetto RTP inviato e permette al ricevente di identificare perdite di pacchetti e ripristinare l'ordine corretto. Il protocollo RTP non prende provvedimenti quanto un pacchetto viene perduto, ma lascia campo libero all'applicazione. In accordo con l'RFC 3550, il valore iniziale deve essere casuale per rendere attacchi di tipo known-plaintext più difficili.
  • Timestamp: (32 bit) utilizzato per permettere al ricevente di riprodurre il media ricevuto all'intervallo appropriato. La granularità dipende dall'applicazione ed è definita dallo specifico profilo RTP.
  • SSRC: (32 bit) il synchronization source identifier identifica in modo univoco la fonte dello stream all'interno della sessione RTP.
  • CSRC: (da 0 a 15, 32 bit ciascuno) gli identificatori contributing source enumerano le fonti di uno stream generato da più fonti. Il numero di identificatori CSRC è dato dal valore del campo CC.

Altri progetti

Collegamenti esterni