Il protocollo RTP [2] si occupa del trasporto "end-to-end" di dati che necessitano di essere consegnati in tempo reale, ad esempio l'audio e il video interattivi; le applicazioni solitamente usano RTP su UDP per sfruttare i suoi servizi di "multiplexing" e di "checksum"; RTP, basandosi punto su UDP, non prevede nessun meccanismo per assicurare il tempo di consegna massimo, l'ordine dei pacchetti o per garantire la qualità del servizio, altresì utilizza numeri di sequenza che permettano al destinatario di ricostruire l'esatto ordine con cui il mittente ha spedito i suoi pacchetti. RTP è in primo luogo studiato per le esigenze dei partecipanti a conferenze multimediali, ma non è necessariamente limitato a questa particolare applicazione. Questo protocollo di fatto consiste di due parti strettamente connesse:Il protocollo di trasporto dati in tempo reale (RTP);
l' eventuale protocollo di controllo (RTCP) che monitora la qualità del servizio e raccoglie informazioni sui partecipanti alla sessione.
Header del pacchetto RTP
Header del pacchetto RTCP
Report RTCP
Flusso dei pacchetti RTP ed RTCP in una sessione multicast
Nel seguito utilizzeremo le espressioni "RTP payload" per riferirci ai dati trasportati in un pacchetto RTP,ad esempio campioni audio o dati video compressi; "payload type" per identificare il formato dell' RTP payload [4] (PCM, PCMU,...).
Il protocollo sfrutta, tramite un meccanismo di allocazione dinamico, un insieme di indirizzi multicast ed una coppia di porte, una usata per i dati audio, l'altra per i pacchetti di controllo (RTCP); le informazioni sugli indirizzi e le porte vengono distribuite a coloro che intendono partecipare alla sessione per esempio via SAP/SDP o SIP/SDP.1.2 Audio e Video RTP
I dati audio vengono spediti a pezzi ad esempio della durata di 20 ms; ogni frazione è preceduta da una header RTP. L' header RTP ed i dati audio sono a loro volta contenuti in un pacchetto UDP; l'header RTP indica il tipo di codifica dei dati audio (ad esempio PCM,ADPCM o LPC); il mittente può cambiare la codifica durante la conferenza, ad esempio per permettere il collegamento di un nuovo partecipante ad inferiore banda di trasmissione o per reagire ad informazioni sulla congestione della rete veicolate da RTCP.
Audio e video nella stessa conferenza vengono trasmessi come due diverse sessioni RTP ciascuna gestita attraverso pacchetti RTCP; vengono sfruttate due differenti coppie di porte UDP e/o di indirizzi multicast; una delle ragioni di questa separazione è di permettere ai partecipanti di ricevere a richiesta un solo flusso di dati. I dati RTP vengono mandati sulle porte UDP pari, mentre i pachetti RTCP corrispondenti sulle successive porte dispari.
Nell'RTP Video/Audio Profile [3] viene stabilita una corrispondenza standard tra i numeri dei payload types e le più usate codifiche dati; non a tutte le codifiche usate da RTP deve essere assegnato un payload type statico, infatti i codici dal 96 al 127 possono essere definiti dinamicamente.
Payload
types
| PT | FORMATO | A/V | CLOCK RATE | CANALI (audio) |
| 0 | PCMU | A | 8000 | 1 |
| 1 | 1016 | A | 8000 | 1 |
| 2 | G721 | A | 8000 | 1 |
| 3 | GSM | A | 8000 | 1 |
| 4 | non assegnato | A | 8000 | 1 |
| 5 | DVI4 | A | 8000 | 1 |
| 6 | DVI4 | A | 16000 | 1 |
| 7 | LPC | A | 8000 | 1 |
| 8 | PCMA | A | 8000 | 1 |
| 9 | G722 | A | 8000 | 1 |
| 10 | L16 | A | 44100 | 2 |
| 11 | L16 | A | 44100 | 1 |
| 12 | non assegnato | A | -- | -- |
| 13 | non assegnato | A | -- | -- |
| 14 | MPA | A | 90000 | -- |
| 15 | G728 | A | 8000 | 1 |
| 16--23 | non assegnati | A | -- | -- |
| 24 | non assegnato | V | -- | -- |
| 25 | CelB | V | 90000 | -- |
| 26 | JPEG | V | 90000 | -- |
| 27 | non assegnato | V | -- | -- |
| 28 | nv | V | 90000 | -- |
| 29 | non assegnato | V | -- | -- |
| 30 | non assegnato | V | -- | -- |
| 31 | H261 | V | 90000 | -- |
| 32 | MPV | V | 90000 | -- |
| 33 | MP2T | AV | 90000 | -- |
| 34--71 | non assegnati | -- | -- | -- |
| 72--76 | riservati | N/A | N/A | N/A |
| 77--95 | non assegnati | -- | -- | -- |
| 96--127 | dinamici | -- | -- | -- |