3. Registrazione di codifiche aggiuntive

3. Registrazione di codifiche aggiuntive

   Questo profilo elenca un insieme di codifiche, ciascuna delle quali è composta da una particolare compressione o rappresentazione dei dati multimediali più un formato di payload per l'incapsulamento all'interno di RTP. Alcuni di quei formati di payload sono specificati qui, mentre altri sono specificati in RFC separate. Si prevede che codifiche aggiuntive oltre all'insieme elencato qui saranno create in futuro e specificate in ulteriori RFC di formato di payload.

   Questo profilo assegna anche a ciascuna codifica un nome breve che PUÒ essere utilizzato da protocolli di controllo di livello superiore, come il Session Description Protocol (SDP), RFC 2327 [6], per identificare le codifiche selezionate per una particolare sessione RTP.

   In alcuni contesti può essere utile fare riferimento a queste codifiche sotto forma di un content-type MIME. Per facilitare ciò, l'RFC 3555 [7] fornisce registrazioni per tutti i nomi di codifiche elencati qui come nomi di sottotipo MIME sotto i tipi MIME "audio" e "video" attraverso la procedura di registrazione MIME specificata nell'RFC 2048 [8].

   Qualsiasi codifica aggiuntiva specificata per l'uso sotto questo profilo (o altri) può anche essere assegnata a nomi registrati come sottotipi MIME presso l'Internet Assigned Numbers Authority (IANA). Questo registro fornisce un mezzo per garantire che i nomi assegnati alle codifiche aggiuntive siano mantenuti unici. L'RFC 3555 specifica le informazioni richieste per la registrazione delle codifiche RTP.

   Oltre ad assegnare nomi alle codifiche, questo profilo assegna anche numeri di tipo di payload RTP statici ad alcune di esse. Tuttavia, lo spazio dei numeri di tipo di payload è relativamente piccolo e non può ospitare assegnazioni per tutte le codifiche esistenti e future. Durante le prime fasi dello sviluppo RTP, era necessario utilizzare tipi di payload assegnati staticamente perché nessun altro meccanismo era stato specificato per legare le codifiche ai tipi di payload. Si prevedeva che mezzi non RTP oltre lo scopo di questo memo (come servizi di directory o protocolli di invito) sarebbero stati specificati per stabilire una mappatura dinamica tra un tipo di payload e una codifica. Ora, i meccanismi per definire le associazioni di tipo di payload dinamico sono stati specificati nel Session Description Protocol (SDP) e in altri protocolli come la raccomandazione ITU-T H.323/H.245. Questi meccanismi associano il nome registrato del formato di codifica/payload, insieme a qualsiasi parametro aggiuntivo richiesto, come il tasso di clock del timestamp RTP e il numero di canali, a un numero di tipo di payload. Questa associazione è efficace solo per la durata della sessione RTP in cui viene effettuata l'associazione del tipo di payload dinamico. Questa associazione si applica solo alla sessione RTP per la quale è fatta, quindi i numeri possono essere riutilizzati per diverse codifiche in diverse sessioni in modo da evitare la limitazione dello spazio dei numeri.

   Questo profilo riserva i numeri di tipo di payload nell'intervallo 96-127 esclusivamente per l'assegnazione dinamica. Le applicazioni DOVREBBERO utilizzare prima i valori in questo intervallo per i tipi di payload dinamici. Quelle applicazioni che devono definire più di 32 tipi di payload dinamici POSSONO legare codici inferiori a 96, nel qual caso è RACCOMANDATO che vengano utilizzati prima i numeri di tipo di payload non assegnati. Tuttavia, i tipi di payload assegnati staticamente sono associazioni predefinite e POSSONO essere legati dinamicamente a nuove codifiche se necessario. Ridefinire i tipi di payload inferiori a 96 può causare un funzionamento errato se si tenta di unirsi a una sessione senza ottenere informazioni sulla descrizione della sessione che definiscono i tipi di payload dinamici.

   I tipi di payload dinamici NON DOVREBBERO essere utilizzati senza un meccanismo ben definito per indicare la mappatura. I sistemi che prevedono di interoperare con altri operanti sotto questo profilo NON DOVREBBERO effettuare le proprie assegnazioni di codifiche proprietarie a particolari tipi di payload fissi.

   Questa specifica stabilisce la politica che nessun tipo di payload statico aggiuntivo sarà assegnato oltre a quelli definiti in questo documento. Stabilire questa politica evita il problema di cercare di creare un insieme di criteri per accettare assegnazioni statiche e incoraggia l'implementazione e la distribuzione dei meccanismi di tipo di payload dinamico.

   L'insieme finale delle assegnazioni di tipo di payload statico è fornito nelle Tabelle 4 e 5.