RFC 3550 - 1. Introduction

1. Introduzione (Introduction)

   Questo memorandum specifica il 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. Tali servizi includono l'identificazione del tipo di payload, la numerazione delle sequenze, la marcatura temporale e il monitoraggio della consegna. Le applicazioni eseguono tipicamente RTP sopra UDP per sfruttarne i servizi di multiplexing e di checksum; entrambi i protocolli contribuiscono a parti della funzionalità del protocollo di trasporto. Tuttavia, RTP può essere usato con altri opportuni protocolli di rete o di trasporto sottostanti (vedere la Sezione 11). RTP supporta il trasferimento di dati a più destinazioni usando la distribuzione multicast se fornita dalla rete sottostante.

   Si noti che RTP stesso non fornisce alcun meccanismo per garantire una consegna tempestiva né fornisce 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é assume 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 dei pacchetti del mittente, ma i numeri di sequenza possono anche essere usati 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 di conferenze multimediali multi-partecipante, non è limitato a quella particolare applicazione. L'archiviazione di dati continui, la simulazione distribuita interattiva, il badge attivo e le applicazioni di controllo e misurazione possono anch'esse trovare RTP applicabile.

   Questo documento definisce RTP, costituito da due parti strettamente collegate:

   o il real-time transport protocol (RTP), per trasportare dati che hanno proprietà in tempo reale.

   o il RTP control protocol (RTCP), per monitorare la qualità del servizio e per trasmettere informazioni sui partecipanti a una sessione in corso. Quest'ultimo aspetto di RTCP può essere sufficiente per sessioni "debolmente controllate" (loosely controlled), ovvero dove non c'è un controllo esplicito delle membership né una configurazione, ma non è necessariamente destinato a supportare tutti i requisiti di comunicazione di controllo di un'applicazione. Questa funzionalità può essere totalmente o parzialmente assorbita da un protocollo di controllo di sessione separato, che è al di fuori dello scopo di questo documento.

   RTP rappresenta un nuovo stile di protocollo che segue i principi dell'application level framing e dell'integrated layer processing proposti da Clark e Tennenhouse [10]. Cioè, RTP è inteso per 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 quadro di protocollo che è deliberatamente non completo. Questo documento specifica quelle funzioni attese come comuni a tutte le applicazioni per le quali RTP sarebbe appropriato. A differenza dei protocolli convenzionali in cui funzioni aggiuntive potrebbero essere accolte rendendo il protocollo più generale o aggiungendo un meccanismo a opzioni che richiederebbe l'analisi, RTP è inteso per essere adattato tramite modifiche e/o aggiunte agli header come necessario. Esempi sono dati 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 la Sezione 13):

   o un documento di specifica del profilo, che definisce un insieme di codici di tipo di payload e la loro mappatura su formati di payload (ad esempio, codifiche multimediali). Un profilo può anche definire estensioni o modifiche a RTP 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 compagno RFC 3551 [1].

   o documenti di specifica del formato del 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é un contesto sulle decisioni di progettazione di RTP, può essere trovata in [11].

1.1 Terminologia (Terminology)

Le parole chiave "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", and "OPTIONAL" in questo documento devono essere interpretate come descritto in BCP 14, RFC 2119 [2] e indicano i livelli di requisito per implementazioni RTP conformi.