1. Introduzione (Introduction)
Questo memorandum specifica il protocollo di trasporto in tempo reale (Real-time Transport Protocol, RTP), che fornisce servizi di consegna end-to-end per dati con caratteristiche in tempo reale, come audio e video interattivi. Questi servizi includono l'identificazione del tipo di payload, la numerazione di sequenza, la marcatura temporale e il monitoraggio della consegna. Le applicazioni eseguono tipicamente RTP su UDP per utilizzare i suoi servizi di multiplexing e checksum; entrambi i protocolli contribuiscono a parti della funzionalità del protocollo di trasporto. Tuttavia, RTP può essere utilizzato con altri protocolli di rete o di trasporto sottostanti appropriati (vedere Sezione 11). RTP supporta il trasferimento di dati verso più destinazioni utilizzando la distribuzione multicast se fornita dalla rete sottostante.
Si noti che RTP stesso non fornisce alcun meccanismo per garantire la consegna tempestiva o fornire altre garanzie di qualità del servizio, ma si affida ai servizi di livello inferiore per farlo. Non garantisce la consegna né impedisce la consegna fuori sequenza, né presume che la rete sottostante sia affidabile e consegni i pacchetti in sequenza. I numeri di sequenza inclusi in RTP consentono al ricevitore di ricostruire la sequenza di pacchetti del mittente, ma i numeri di sequenza possono anche essere utilizzati per determinare la posizione corretta di un pacchetto, ad esempio nella decodifica video, senza necessariamente decodificare i pacchetti in sequenza.
Sebbene RTP sia progettato principalmente per soddisfare le esigenze delle conferenze multimediali multi-partecipante, non è limitato a quella particolare applicazione. L'archiviazione di dati continui, la simulazione distribuita interattiva, i badge attivi e le applicazioni di controllo e misurazione possono anche trovare RTP applicabile.
Questo documento definisce RTP, composto da due parti strettamente collegate:
-
il protocollo di trasporto in tempo reale (Real-time Transport Protocol, RTP), per trasportare dati che hanno proprietà in tempo reale.
-
il protocollo di controllo RTP (RTP Control Protocol, RTCP), per monitorare la qualità del servizio e trasmettere informazioni sui partecipanti in una sessione in corso. Quest'ultimo aspetto di RTCP può essere sufficiente per sessioni "debolmente controllate", cioè dove non c'è un controllo esplicito dell'appartenenza e della configurazione, ma non è necessariamente destinato a supportare tutti i requisiti di comunicazione di controllo di un'applicazione. Questa funzionalità può essere completamente o parzialmente assunta da un protocollo di controllo di sessione separato, che è al di fuori dell'ambito di questo documento.
RTP rappresenta un nuovo stile di protocollo che segue i principi del framing a livello di applicazione e dell'elaborazione a livello integrato proposti da Clark e Tennenhouse [10]. Cioè, RTP è destinato ad essere malleabile per fornire le informazioni richieste da una particolare applicazione e sarà spesso integrato nell'elaborazione dell'applicazione piuttosto che essere implementato come un livello separato. RTP è un framework di protocollo che è deliberatamente incompleto. Questo documento specifica quelle funzioni che ci si aspetta siano comuni a tutte le applicazioni per le quali RTP sarebbe appropriato. A differenza dei protocolli convenzionali in cui funzioni aggiuntive potrebbero essere accomodate rendendo il protocollo più generale o aggiungendo un meccanismo di opzione che richiederebbe l'analisi, RTP è destinato ad essere personalizzato attraverso modifiche e/o aggiunte agli header secondo necessità. Gli esempi sono forniti nelle Sezioni 5.3 e 6.4.3.
Pertanto, oltre a questo documento, una specifica completa di RTP per una particolare applicazione richiederà uno o più documenti complementari (vedere Sezione 13):
-
un documento di specifica del profilo, che definisce un insieme di codici di tipo di payload e la loro mappatura ai formati di payload (ad esempio, codifiche multimediali). Un profilo può anche definire estensioni o modifiche a RTP che sono specifiche per una particolare classe di applicazioni. Tipicamente un'applicazione opererà sotto un solo profilo. Un profilo per dati audio e video può essere trovato nel RFC complementare 3551 [1].
-
documenti di specifica del formato di payload, che definiscono come un particolare payload, come una codifica audio o video, deve essere trasportato in RTP.
Una discussione sui servizi in tempo reale e sugli algoritmi per la loro implementazione, nonché una discussione di base su alcune delle decisioni di progettazione di RTP, può essere trovata in [11].
1.1 Terminologia
Le parole chiave "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY" e "OPTIONAL" in questo documento devono essere interpretate come descritto in BCP 14, RFC 2119 [2] e indicano i livelli di requisito per le implementazioni RTP conformi.