9. Modifiche rispetto alla RFC 1890
- Modifiche rispetto alla RFC 1890
Questa RFC rivede la RFC 1890. È per lo più retrocompatibile con la RFC 1890, tranne per le funzioni rimosse perché non sono state trovate due implementazioni interoperabili. Le aggiunte alla RFC 1890 codificano la pratica esistente nell'uso dei formati di payload sotto questo profilo. Poiché questo profilo può essere utilizzato senza utilizzare nessuno dei formati di payload elencati qui, l'aggiunta di nuovi formati di payload in questa revisione non influisce sulla retrocompatibilità. Le modifiche sono elencate di seguito, classificate in modifiche funzionali e non funzionali.
Modifiche funzionali:
o La sezione 11, "Considerazioni IANA", è stata aggiunta per specificare la registrazione del nome per questo profilo. Quell'appendice fa anche riferimento a una nuova Sezione 3 "Registrazione di codifiche aggiuntive" che stabilisce una politica secondo cui nessuna registrazione aggiuntiva di tipi di payload statici per questo profilo sarà effettuata oltre a quelle aggiunte in questa revisione e incluse nelle Tabelle 4 e 5. Invece, nomi di codifica aggiuntivi possono essere registrati come sottotipi MIME per il collegamento a tipi di payload dinamici. Riferimenti non normativi sono stati aggiunti alla RFC 3555 [7] dove i sottotipi MIME per tutti i formati di payload elencati sono registrati, alcuni con parametri opzionali per l' uso dei formati di payload.
o I tipi di payload statici 4, 16, 17 e 34 sono stati aggiunti per incorporare le registrazioni IANA effettuate dalla pubblicazione della RFC 1890, insieme alle descrizioni del formato di payload corrispondenti per G723 e H263.
o A seguito della discussione del gruppo di lavoro, i tipi di payload statici 12 e 18 sono stati aggiunti insieme alle descrizioni del formato di payload corrispondenti per QCELP e G729. Il tipo di payload statico 13 è stato assegnato al formato di payload Comfort Noise (CN) definito nella RFC 3389. Il tipo di payload 19 è stato contrassegnato come riservato perché era stato temporaneamente assegnato a una versione precedente di Comfort Noise presente in alcune revisioni bozza di questo documento.
o Il formato di payload per G721 è stato rinominato in G726-32 a seguito della rinumerazione ITU-T, e la descrizione del formato di payload per G726 è stata ampliata per includere le velocità dati -16, -24 e -40. A causa della confusione riguardante le revisioni bozza di questo documento, alcune implementazioni di questi formati di payload G726 impacchettavano i campioni in ottetti iniziando con il bit più significativo piuttosto che con il bit meno significativo come specificato qui. Per risolvere parzialmente questa incompatibilità, nuovi formati di payload denominati AAL2-G726-16, -24, -32 e -40 saranno specificati in un documento separato (vedere la nota nella Sezione 4.5.4), e l'uso del tipo di payload statico 2 è deprecato come spiegato nella Sezione 6.
o I formati di payload G729D e G729E sono stati aggiunti a seguito dell'aggiunta da parte dell'ITU-T degli allegati D ed E alla Raccomandazione G.729. Elenchi sono stati aggiunti per i formati di payload GSM-EFR, RED e H263-1998, pubblicati in altri documenti successivi alla RFC 1890. Questi formati di payload aggiuntivi sono referenziati solo da numeri di tipo di payload dinamici.
o Le descrizioni dei formati di payload per G722, G728, GSM, VDVI sono state ampliate.
o Il formato di payload per l'audio 1016 è stato rimosso e la sua assegnazione di tipo di payload statico 1 è stata contrassegnata come "riservata" perché non sono state trovate due implementazioni interoperabili.
o Requisiti per il controllo della congestione sono stati aggiunti nella Sezione 2.
o Questo profilo segue il suggerimento nella specifica RTP rivista secondo cui la larghezza di banda RTCP può essere specificata separatamente dalla larghezza di banda della sessione e separatamente per mittenti attivi e ricevitori passivi.
o La mappatura di una stringa pass-phrase utente in una chiave di crittografia è stata eliminata dalla Sezione 2 perché non sono state trovate due implementazioni interoperabili.
o La convenzione di ordinamento dei campioni "quadrifonica" per l'audio a quattro canali è stata rimossa per eliminare un'ambiguità come notato nella Sezione 4.1.
Modifiche non funzionali:
o Nella Sezione 4.1, è ora esplicitamente dichiarato che la soppressione del silenzio è consentita per tutti i formati di payload audio. (Questo è sempre stato il caso e deriva da un aspetto fondamentale del design di RTP e dalle motivazioni per l'audio a pacchetto, ma non era stato dichiarato esplicitamente prima.) Viene spiegato anche l'uso del rumore di comfort.
o Nella Sezione 4.1, il livello di requisito per l'impostazione del bit marcatore sul primo pacchetto dopo il silenzio per l'audio è stato modificato da "è" a "DOVREBBE essere", ed è stato chiarito che il bit marcatore viene impostato solo quando i pacchetti intenzionalmente non vengono inviati.
o Allo stesso modo, è stato aggiunto testo per specificare che il bit marcatore DOVREBBE essere impostato a uno nell'ultimo pacchetto di un fotogramma video, e che i fotogrammi video sono distinti dai loro timestamp.
o Riferimenti RFC sono aggiunti per i formati di payload pubblicati dopo la RFC 1890.
o Le considerazioni sulla sicurezza e le sezioni complete sul copyright sono state aggiunte.
o Secondo Peter Hoddie di Apple, solo i Macintosh pre-1994 utilizzavano la velocità 22254.54 e nessuno la velocità 11127.27, quindi quest'ultima è stata rimossa dalla discussione sulle frequenze di campionamento suggerite.
o La Tabella 1 è stata corretta per spostare alcuni valori dalla colonna "ms/packet" alla colonna "default ms/packet" dove appartenevano.
o Poiché l'Interactive Multimedia Association ha cessato le operazioni, è stata fornita una risorsa alternativa per un documento IMA referenziato.
o Una nota è stata aggiunta per G722 per chiarire una discrepanza tra la frequenza di campionamento effettiva e la frequenza di clock del timestamp RTP.
o Piccoli chiarimenti del testo sono stati apportati in diversi punti, alcuni in risposta a domande dei lettori. In particolare:
- Una definizione per "tipo di media" viene data nella Sezione 1.1 per consentire
alla spiegazione del multiplexing delle sessioni RTP nella Sezione 6 di essere
più chiara per quanto riguarda il multiplexing di più media.
- La spiegazione di come determinare il numero di fotogrammi audio
in un pacchetto dalla lunghezza è stata ampliata.
- Viene fornita una maggiore descrizione dell'allocazione della larghezza di banda agli elementi SDES.
- Una nota è stata aggiunta che la convenzione per l'ordine dei canali
specificata nella Sezione 4.1 può essere sovrascritta da una particolare
specifica di codifica o formato di payload.
- I termini DEVE, DOVREBBE, PUÒ, ecc. sono usati come definiti nella RFC
2119.
o È stato aggiunto un secondo autore per questo documento.