RFC 3550 - 3. Definitions

3. Definizioni (Definitions)

   RTP payload: I dati trasportati da RTP in un pacchetto, per esempio campioni audio o dati video compressi. Il formato e l'interpretazione del payload sono al di fuori dello scopo di questo documento.

   RTP packet: Un pacchetto dati costituito dall'header RTP fisso, da una lista possibilmente vuota di sorgenti contributrici (vedere sotto) e dai dati del payload. Alcuni protocolli sottostanti possono richiedere che sia definita un'incapsulazione del pacchetto RTP. Tipicamente un pacchetto del protocollo sottostante contiene un singolo pacchetto RTP, ma possono essere contenuti più pacchetti RTP se permesso dal metodo di incapsulazione (vedere la Sezione 11).

   RTCP packet: Un pacchetto di controllo costituito da una parte di header fisso simile a quella dei pacchetti dati RTP, seguita da elementi strutturati che variano a seconda del tipo di pacchetto RTCP. I formati sono definiti nella Sezione 6. Tipicamente, più pacchetti RTCP sono inviati insieme come pacchetto RTCP composto in un singolo pacchetto del protocollo sottostante; questo è abilitato dal campo di lunghezza nell'header fisso di ciascun pacchetto RTCP.

   Port: L'"astrazione che i protocolli di trasporto usano per distinguere tra multiple destinazioni all'interno di un dato computer host. I protocolli TCP/IP identificano le porte usando piccoli interi positivi." [12] I selettori di trasporto (TSEL) usati dal livello di trasporto OSI sono equivalenti alle porte. RTP dipende dal protocollo di livello inferiore per fornire qualche meccanismo come le porte per eseguire il multiplexing dei pacchetti RTP e RTCP di una sessione.

   Transport address: La combinazione di un indirizzo di rete e di una porta che identifica un endpoint a livello di trasporto, per esempio un indirizzo IP e una porta UDP. I pacchetti sono trasmessi da un indirizzo di trasporto sorgente a un indirizzo di trasporto destinazione.

   RTP media type: Un RTP media type è la collezione di tipi di payload che possono essere trasportati all'interno di una singola sessione RTP. Il Profilo RTP assegna i RTP media type ai tipi di payload RTP.

   Multimedia session: Un insieme di sessioni RTP concorrenti tra un gruppo comune di partecipanti. Per esempio, una videoconferenza (che è una sessione multimediale) può contenere una sessione RTP audio e una sessione RTP video.

   RTP session: Un'associazione tra un insieme di partecipanti che comunicano con RTP. Un partecipante può essere coinvolto in più sessioni RTP contemporaneamente. In una sessione multimediale, ciascun medium è tipicamente trasportato in una sessione RTP separata con i propri pacchetti RTCP a meno che la codifica stessa non effettui il multiplexing di più medium in un singolo flusso di dati. Un partecipante distingue multiple sessioni RTP ricevendo diverse sessioni usando diverse coppie di indirizzi di trasporto destinazione, dove una coppia di indirizzi di trasporto comprende un indirizzo di rete più una coppia di porte per RTP e RTCP. Tutti i partecipanti in una sessione RTP possono condividere una coppia comune di indirizzi di trasporto destinazione, come nel caso dell'IP multicast, o le coppie possono essere diverse per ciascun partecipante, come nel caso di indirizzi di rete unicast individuali e coppie di porte. Nel caso unicast, un partecipante può ricevere da tutti gli altri partecipanti nella sessione usando la stessa coppia di porte, o può usare una coppia di porte distinta per ciascuno.

   La caratteristica distintiva di una sessione RTP è che ciascuna mantiene uno spazio completo e separato di identificatori SSRC (definiti poi). L'insieme dei partecipanti inclusi in una sessione RTP consiste di quelli che possono ricevere un identificatore SSRC trasmesso da uno qualsiasi dei partecipanti sia in RTP come SSRC o CSRC (definito anche sotto) sia in RTCP. Per esempio, si consideri una conferenza a tre parti implementata usando UDP unicast con ciascun partecipante che riceve dagli altri due su coppie di porte separate. Se ciascun partecipante invia feedback RTCP sui dati ricevuti da uno solo degli altri partecipanti indietro a quel partecipante, allora la conferenza è composta da tre sessioni RTP punto-a-punto separate. Se ciascun partecipante fornisce feedback RTCP sulla sua ricezione di uno degli altri partecipanti a entrambi gli altri partecipanti, allora la conferenza è composta da una sessione RTP multi-parte. Quest'ultimo caso simula il comportamento che si verificherebbe con la comunicazione IP multicast tra i tre partecipanti.

   Il quadro RTP consente le variazioni qui definite, ma un particolare protocollo di controllo o progetto di applicazione imporrà di norma vincoli su queste variazioni.

   Synchronization source (SSRC): La sorgente di un flusso di pacchetti RTP, identificata da un identificatore SSRC numerico a 32 bit trasportato nell'header RTP in modo da non dipendere dall'indirizzo di rete. Tutti i pacchetti da una sorgente di sincronizzazione formano parte dello stesso spazio di temporizzazione e di numeri di sequenza, così un ricevitore raggruppa i pacchetti per sorgente di sincronizzazione per la riproduzione. Esempi di sorgenti di sincronizzazione includono il mittente di un flusso di pacchetti derivato da una sorgente di segnale come un microfono o una telecamera, o un mixer RTP (vedere sotto). Una sorgente di sincronizzazione può cambiare il suo formato dati, ad esempio la codifica audio, nel tempo. L'identificatore SSRC è un valore scelto casualmente inteso per essere globalmente unico all'interno di una particolare sessione RTP (vedere la Sezione 8). Un partecipante non deve usare lo stesso identificatore SSRC per tutte le sessioni RTP in una sessione multimediale; il legame degli identificatori SSRC è fornito tramite RTCP (vedere la Sezione 6.5.1). Se un partecipante genera più flussi in una sessione RTP, per esempio da telecamere separate, ciascuno DEVE essere identificato come un SSRC diverso.

   Contributing source (CSRC): Una sorgente di un flusso di pacchetti RTP che ha contribuito al flusso combinato prodotto da un mixer RTP (vedere sotto). Il mixer inserisce una lista degli identificatori SSRC delle sorgenti che hanno contribuito alla generazione di un particolare pacchetto nell'header RTP di quel pacchetto. Questa lista è chiamata lista CSRC. Un'applicazione di esempio è la conferenza audio dove un mixer indica tutti i parlanti la cui voce è stata combinata per produrre il pacchetto in uscita, consentendo al ricevitore di indicare l'attuale parlante, anche se tutti i pacchetti audio contengono lo stesso identificatore SSRC (quello del mixer).

   End system: Un'applicazione che genera il contenuto da inviare nei pacchetti RTP e/o consuma il contenuto dei pacchetti RTP ricevuti. Un end system può agire come una o più sorgenti di sincronizzazione in una particolare sessione RTP, ma tipicamente solo una.

   Mixer: Un sistema intermedio che riceve pacchetti RTP da una o più sorgenti, possibilmente cambia il formato dati, combina i pacchetti in qualche maniera e poi inoltra un nuovo pacchetto RTP. Poiché la temporizzazione tra multiple sorgenti in ingresso non sarà generalmente sincronizzata, il mixer farà aggiustamenti di temporizzazione tra i flussi e genererà la propria temporizzazione per il flusso combinato. Così, tutti i pacchetti dati originati da un mixer saranno identificati come aventi il mixer come loro sorgente di sincronizzazione.

   Translator: Un sistema intermedio che inoltra i pacchetti RTP con il loro identificatore di sorgente di sincronizzazione intatto. Esempi di traduttori includono dispositivi che convertono codifiche senza miscelazione, replicatori da multicast a unicast e filtri a livello di applicazione nei firewall.

   Monitor: Un'applicazione che riceve i pacchetti RTCP inviati dai partecipanti a una sessione RTP, in particolare i rapporti di ricezione, e stima l'attuale qualità del servizio per il monitoraggio della distribuzione, la diagnosi dei guasti e le statistiche a lungo termine. La funzione di monitor è probabile che sia integrata nelle applicazioni partecipanti alla sessione, ma può anche essere una applicazione separata che non partecipa altrimenti e non invia né riceve i pacchetti dati RTP (poiché sono su una porta separata). Questi sono chiamati monitor di terze parti. È anche accettabile per un monitor di terze parti ricevere i pacchetti dati RTP ma non inviare pacchetti RTCP né essere altrimenti contato nella sessione.

   Non-RTP means: Protocolli e meccanismi che possono essere necessari in aggiunta a RTP per fornire un servizio utilizzabile. In particolare, per le conferenze multimediali, un protocollo di controllo può distribuire indirizzi multicast e chiavi per la cifratura, negoziare l'algoritmo di cifratura da usare e definire mappature dinamiche tra i valori di tipo di payload RTP e i formati di payload che essi rappresentano per formati che non hanno un valore di tipo di payload predefinito. Esempi di tali protocolli includono il Session Initiation Protocol (SIP) (RFC 3261 [13]), l'ITU Recommendation H.323 [14] e applicazioni che usano SDP (RFC 2327 [15]), come RTSP (RFC 2326 [16]). Per applicazioni semplici, la posta elettronica o un database di conferenza possono anch'essi essere usati. La specifica di tali protocolli e meccanismi è al di fuori dello scopo di questo documento.