RFC 3550 - 13. RTP Profiles and Payload Format Specifications

13. Specifiche dei profili RTP e dei formati di payload (RTP Profiles and Payload Format Specifications)

Una specifica completa di RTP per una particolare applicazione richiederà uno o più documenti compagni di due tipi qui descritti: profili e specifiche del formato di payload.

RTP può essere usato per una varietà di applicazioni con requisiti alquanto differenti. La flessibilità di adattarsi a quei requisiti è fornita consentendo molteplici scelte nella specifica principale del protocollo, poi selezionando le scelte appropriate o definendo estensioni per un particolare ambiente e classe di applicazioni in un documento di profilo separato. Tipicamente un'applicazione opererà sotto un solo profilo in una particolare sessione RTP, così non c'è alcuna indicazione esplicita all'interno del protocollo RTP stesso circa quale profilo è in uso. Un profilo per applicazioni audio e video può essere trovato nel compagno RFC 3551. I profili sono tipicamente intitolati "RTP Profile for ...".

Il secondo tipo di documento compagno è una specifica del formato di payload, che definisce come un particolare tipo di dati payload, come video codificato H.261, debba essere trasportato in RTP. Questi documenti sono tipicamente intitolati "RTP Payload Format for XYZ Audio/Video Encoding". I formati di payload possono essere utili sotto multipli profili e possono quindi essere definiti indipendentemente da qualsiasi profilo particolare. I documenti di profilo sono poi responsabili dell'assegnazione di una mappatura predefinita di quel formato a un valore di tipo di payload se necessario.

All'interno di questa specifica, i seguenti elementi sono stati identificati per una possibile definizione all'interno di un profilo, ma questo elenco non è inteso essere esaustivo:

Header dati RTP: L'ottetto nell'header dati RTP che contiene il bit di marker e il campo del tipo di payload PUÒ essere ridefinito da un profilo per soddisfare requisiti differenti, per esempio con più o meno bit di marker (Sezione 5.3, p. 18).

Tipi di payload: Assumendo che un campo di tipo di payload sia incluso, il profilo definirà usualmente un insieme di formati di payload (es. codifiche multimediali) e una mappatura statica predefinita di quei formati a valori di tipo di payload. Alcuni dei formati di payload possono essere definiti per riferimento a separate specifiche del formato di payload. Per ciascun tipo di payload definito, il profilo DEVE specificare la frequenza dell'orologio del timestamp RTP da usare (Sezione 5.1, p. 14).

Aggiunte all'header dati RTP: Campi addizionali POSSONO essere accodati all'header dati RTP fisso se qualche funzionalità addizionale è richiesta attraverso la classe di applicazioni del profilo indipendentemente dal tipo di payload (Sezione 5.3, p. 18).

Estensioni dell'header dati RTP: Il contenuto dei primi 16 bit della struttura di estensione dell'header dati RTP DEVE essere definito se l'uso di quel meccanismo è permesso sotto il profilo per estensioni specifiche dell'implementazione (Sezione 5.3.1, p. 18).

Tipi di pacchetto RTCP: Nuovi tipi di pacchetto RTCP specifici per classe di applicazione POSSONO essere definiti e registrati presso IANA.

Intervallo di rapporto RTCP: Un profilo DOVREBBE specificare che i valori suggeriti nella Sezione 6.2 per le costanti impiegate nel calcolo dell'intervallo di rapporto RTCP saranno usati. Questi sono la frazione RTCP della banda di sessione, l'intervallo minimo di rapporto e la divisione della banda tra mittenti e ricevitori. Un profilo PUÒ specificare valori alternativi se è stato dimostrato che funzionano in modo scalabile.

Estensione SR/RR: Una sezione di estensione PUÒ essere definita per i pacchetti RTCP SR e RR se c'è informazione addizionale che dovrebbe essere riportata regolarmente sul mittente o sui ricevitori (Sezione 6.4.3, p. 42 e 43).

Uso SDES: Il profilo PUÒ specificare le priorità relative per gli elementi RTCP SDES da trasmettere o escludere interamente (Sezione 6.3.9); una sintassi o semantica alternativa per l'elemento CNAME (Sezione 6.5.1); il formato dell'elemento LOC (Sezione 6.5.5); la semantica e l'uso dell'elemento NOTE (Sezione 6.5.7); o nuovi tipi di elemento SDES da registrare presso IANA.

Sicurezza: Un profilo PUÒ specificare quali servizi di sicurezza e algoritmi dovrebbero essere offerti dalle applicazioni, e PUÒ fornire guida circa il loro uso appropriato (Sezione 9, p. 65).

Mappatura stringa-chiave: Un profilo PUÒ specificare come una password o frase segreta fornita dall'utente è mappata in una chiave di cifratura.

Congestione: Un profilo DOVREBBE specificare il comportamento di controllo della congestione appropriato per quel profilo.

Protocollo sottostante: L'uso di un particolare protocollo di rete o di trasporto sottostante per trasportare pacchetti RTP PUÒ essere richiesto.

Mappatura di trasporto: Una mappatura di RTP e RTCP a indirizzi a livello di trasporto, es. porte UDP, diversa dalla mappatura standard definita nella Sezione 11, p. 68 può essere specificata.

Incapsulamento: Un incapsulamento di pacchetti RTP può essere definito per consentire che multipli pacchetti dati RTP siano trasportati in un singolo pacchetto di livello inferiore o per fornire il framing su protocolli sottostanti che non lo fanno già (Sezione 11, p. 69).

Non ci si aspetta che un nuovo profilo sia richiesto per ogni applicazione. All'interno di una classe di applicazioni, sarebbe meglio estendere un profilo esistente anziché crearne uno nuovo per facilitare l'interoperazione tra le applicazioni poiché ciascuna opererà tipicamente sotto un solo profilo. Estensioni semplici come la definizione di valori di tipo di payload addizionali o di tipi di pacchetto RTCP possono essere realizzate registrandoli tramite IANA e pubblicando le loro descrizioni in un addendum al profilo o in una specifica del formato di payload.