4. Audio

Audio

4.1 Regole indipendenti dalla codifica

Poiché la capacità di sopprimere il silenzio è una delle motivazioni principali per l'uso dei pacchetti per trasmettere la voce, l'header RTP trasporta sia un numero di sequenza che un timestamp per consentire a un ricevitore di distinguere tra pacchetti persi e periodi di tempo in cui non sono stati trasmessi dati. La trasmissione discontinua (soppressione del silenzio) PUÒ essere utilizzata con qualsiasi formato di payload audio. I ricevitori DEVONO presumere che i mittenti possano sopprimere il silenzio, a meno che ciò non sia limitato da una segnalazione specificata altrove. (Anche se il trasmettitore non sopprime il silenzio, il ricevitore dovrebbe essere preparato a gestire periodi in cui non sono presenti dati poiché i pacchetti possono andare persi.)

Alcuni formati di payload (vedere le sezioni 4.5.3 e 4.5.6) definiscono un frame "descrittore di inserimento del silenzio" o "rumore di comfort" per specificare i parametri per il rumore artificiale che può essere generato durante un periodo di silenzio per approssimare il rumore di fondo alla sorgente. Per altri formati di payload, un formato di payload generico Comfort Noise (CN) è specificato in RFC 3389 [9]. Quando il formato di payload CN viene utilizzato con un altro formato di payload, valori diversi nel campo del tipo di payload RTP distinguono i pacchetti di rumore di comfort da quelli del formato di payload selezionato.

Per le applicazioni che non inviano pacchetti o inviano pacchetti occasionali di rumore di comfort durante il silenzio, il primo pacchetto di un talkspurt, cioè il primo pacchetto dopo un periodo di silenzio durante il quale i pacchetti non sono stati trasmessi in modo contiguo, DOVREBBE essere distinto impostando il bit marcatore nell'header dei dati RTP a uno. Il bit marcatore in tutti gli altri pacchetti è zero. L'inizio di un talkspurt PUÒ essere utilizzato per regolare il ritardo di riproduzione per riflettere i ritardi di rete variabili. Le applicazioni senza soppressione del silenzio DEVONO impostare il bit marcatore a zero.

La frequenza di clock RTP utilizzata per generare il timestamp RTP è indipendente dal numero di canali e dalla codifica; di solito è uguale al numero di periodi di campionamento al secondo. Per codifiche a N canali, ogni periodo di campionamento (diciamo, 1/8.000 di secondo) genera N campioni. (Questa terminologia è standard, ma un po' confusa, poiché il numero totale di campioni generati al secondo è quindi la frequenza di campionamento moltiplicata per il numero di canali.)

Se vengono utilizzati più canali audio, i canali sono numerati da sinistra a destra, iniziando da uno. Nei pacchetti audio RTP, le informazioni dai canali con numero inferiore precedono quelle dai canali con numero superiore.

Per più di due canali, DOVREBBE essere seguita la convenzione seguita dal formato di interscambio audio AIFF-C [3], utilizzando la seguente notazione, a meno che non sia specificata un'altra convenzione per una particolare codifica o formato di payload:

  l  sinistra (left)
  r  destra (right)
  c  centro (center)
  S  surround
  F  anteriore (front)
  R  posteriore (rear)

  canali    descrizione   canale
                            1     2   3   4   5   6
  _________________________________________________
  2         stereo          l     r
  3                         l     r   c
  4                         l     c   r   S
  5                        Fl     Fr  Fc  Sl  Sr
  6                         l     lc  c   r   rc  S

     Nota: RFC 1890 definiva due convenzioni per l'ordinamento di quattro
     canali audio. Poiché l'ordine è indicato implicitamente dal
     numero di canali, questo era ambiguo. In questa revisione,
     l'ordine descritto come "quadrifonico" è stato eliminato per
     rimuovere l'ambiguità. Questa scelta si è basata sull'osservazione
     che il formato audio consumer quadrifonico non è diventato popolare
     mentre il suono surround lo è diventato successivamente.

I campioni per tutti i canali appartenenti a un singolo istante di campionamento DEVONO essere all'interno dello stesso pacchetto. L'interlacciamento dei campioni da diversi canali dipende dalla codifica. Linee guida generali sono fornite nelle sezioni 4.3 e 4.4.

La frequenza di campionamento DOVREBBE essere tratta dall'insieme: 8.000, 11.025, 16.000, 22.050, 24.000, 32.000, 44.100 e 48.000 Hz. (I vecchi computer Apple Macintosh avevano una frequenza di campionamento nativa di 22.254,54 Hz, che può essere convertita a 22.050 con qualità accettabile scartando 4 campioni in un frame di 20 ms.) Tuttavia, la maggior parte delle codifiche audio sono definite per un insieme più ristretto di frequenze di campionamento. I ricevitori DOVREBBERO essere preparati ad accettare audio multicanale, ma POSSONO scegliere di riprodurre solo un singolo canale.

4.2 Raccomandazioni operative

Le seguenti raccomandazioni sono parametri operativi predefiniti. Le applicazioni DOVREBBERO essere preparate a gestire altri valori. Gli intervalli forniti sono intesi a fornire indicazioni agli autori di applicazioni, consentendo a un insieme di applicazioni conformi a queste linee guida di interoperare senza negoziazione aggiuntiva. Queste linee guida non intendono limitare i parametri operativi per le applicazioni che possono negoziare un insieme di parametri interoperabili, ad esempio, attraverso un protocollo di controllo della conferenza.

Per l'audio a pacchetti, l'intervallo di pacchettizzazione predefinito DOVREBBE avere una durata di 20 ms o un frame, a seconda di quale sia il più lungo, a meno che non sia indicato diversamente nella Tabella 1 (colonna "ms/packet"). L'intervallo di pacchettizzazione determina il ritardo minimo end-to-end; pacchetti più lunghi introducono meno overhead di intestazione ma un ritardo maggiore e rendono la perdita di pacchetti più evidente. Per applicazioni non interattive come lezioni o per collegamenti con gravi vincoli di larghezza di banda, un ritardo di pacchettizzazione maggiore PUÒ essere utilizzato. Un ricevitore DOVREBBE accettare pacchetti che rappresentano tra 0 e 200 ms di dati audio. (Per codifiche audio a frame, un ricevitore DOVREBBE accettare pacchetti con un numero di frame uguale a 200 ms diviso per la durata del frame, arrotondato per eccesso.) Questa restrizione consente un dimensionamento ragionevole del buffer per il ricevitore.

4.3 Linee guida per codifiche audio basate su campioni

Nelle codifiche basate su campioni, ogni campione audio è rappresentato da un numero fisso di bit. All'interno dei dati audio compressi, i codici per i singoli campioni possono estendersi oltre i confini del byte. Un pacchetto audio RTP può contenere un numero qualsiasi di campioni audio, soggetto al vincolo che il numero di bit per campione moltiplicato per il numero di campioni per pacchetto produca un conteggio intero di ottetti. Le codifiche frazionarie producono meno di un ottetto per campione.

La durata di un pacchetto audio è determinata dal numero di campioni nel pacchetto.

Per codifiche basate su campioni che producono uno o più ottetti per campione, i campioni di diversi canali campionati nello stesso istante di campionamento DOVREBBERO essere impacchettati in ottetti consecutivi. Ad esempio, per una codifica a due canali, la sequenza di ottetti è (canale sinistro, primo campione), (canale destro, primo campione), (canale sinistro, secondo campione), (canale destro, secondo campione), .... Per codifiche multi-ottetto, gli ottetti DOVREBBERO essere trasmessi in ordine di byte di rete (cioè, ottetto più significativo per primo).

L'impacchettamento di codifiche basate su campioni che producono meno di un ottetto per campione è specifico della codifica.

Il timestamp RTP riflette l'istante in cui il primo campione nel pacchetto è stato campionato, cioè, l'informazione più vecchia nel pacchetto.

4.4 Linee guida per codifiche audio basate su frame

Le codifiche basate su frame codificano un blocco di audio di lunghezza fissa in un altro blocco di dati compressi, tipicamente anch'esso di lunghezza fissa. Per le codifiche basate su frame, il mittente PUÒ scegliere di combinare diversi tali frame in un singolo pacchetto RTP. Il ricevitore può dire il numero di frame contenuti in un pacchetto RTP, se tutti i frame hanno la stessa lunghezza, dividendo la lunghezza del payload RTP per la dimensione del frame audio che è definita come parte della codifica. Questo non funziona quando si trasportano frame di diverse dimensioni a meno che le dimensioni dei frame siano relativamente prime. Se non lo sono, i frame DEVONO indicare la loro dimensione.

Per i codec basati su frame, l'ordine dei canali è definito per l'intero blocco. Cioè, per l'audio a due canali, i campioni destro e sinistro DOVREBBERO essere codificati indipendentemente, con il frame codificato per il canale sinistro che precede quello per il canale destro.

Tutti i codec audio orientati ai frame DOVREBBERO essere in grado di codificare e decodificare diversi frame consecutivi all'interno di un singolo pacchetto. Poiché la dimensione del frame per i codec orientati ai frame è data, non c'è bisogno di utilizzare una designazione separata per la stessa codifica, ma con un diverso numero di frame per pacchetto.

I pacchetti RTP DEVONO contenere un numero intero di frame, con i frame inseriti in base all'età all'interno di un pacchetto, in modo che il frame più vecchio (da riprodurre per primo) appaia immediatamente dopo l'header del pacchetto RTP. Il timestamp RTP riflette l'istante in cui il primo campione nel primo frame è stato campionato, cioè l'informazione più vecchia nel pacchetto.

4.5 Codifiche audio

nome della campionam. default codifica campione/frame bit/campione rate ms/frame ms/packet

DVI4 campione 4 var. 20 G722 campione 8 16.000 20 G723 frame N/A 8.000 30 30 G726-40 campione 5 8.000 20 G726-32 campione 4 8.000 20 G726-24 campione 3 8.000 20 G726-16 campione 2 8.000 20 G728 frame N/A 8.000 2,5 20 G729 frame N/A 8.000 10 20 G729D frame N/A 8.000 10 20 G729E frame N/A 8.000 10 20 GSM frame N/A 8.000 20 20 GSM-EFR frame N/A 8.000 20 20 L8 campione 8 var. 20 L16 campione 16 var. 20 LPC frame N/A 8.000 20 20 MPA frame N/A var. var. PCMA campione 8 var. 20 PCMU campione 8 var. 20 QCELP frame N/A 8.000 20 20 VDVI campione var. var. 20

Tabella 1: Proprietà delle codifiche audio (N/A: non applicabile; var.: variabile)

Le caratteristiche delle codifiche audio descritte in questo documento sono mostrate nella Tabella 1; sono elencate in ordine del loro tipo di payload nella Tabella 4. Mentre la maggior parte dei codec audio sono specificati solo per una frequenza di campionamento fissa, alcuni algoritmi basati su campioni (indicati da una voce di "var." nella colonna della frequenza di campionamento della Tabella 1) possono essere utilizzati con diverse frequenze di campionamento, risultando in diverse velocità in bit codificate. Quando utilizzati con una frequenza di campionamento diversa da quella per cui è definito un tipo di payload statico, DEVONO essere utilizzati mezzi non RTP al di fuori dello scopo di questo memo per definire un tipo di payload dinamico e DEVONO indicare la frequenza di clock del timestamp RTP selezionata, che di solito è la stessa della frequenza di campionamento per l'audio.

4.5.1 DVI4

DVI4 utilizza uno schema di codifica a modulazione di codice a impulsi delta adattiva (ADPCM) che è stato specificato dalla Interactive Multimedia Association (IMA) come "IMA ADPCM wave type". Tuttavia, la codifica definita qui come DVI4 differisce in tre aspetti dalla specifica IMA:

o L'header RTP DVI4 contiene il valore previsto piuttosto che il primo valore di campione contenuto nell'header del blocco IMA ADPCM.

o I blocchi IMA ADPCM contengono un numero dispari di campioni, poiché il primo campione di un blocco è contenuto solo nell'header (non compresso), seguito da un numero pari di campioni compressi. DVI4 ha solo un numero pari di campioni compressi, utilizzando la parola `predict' dall'header per decodificare il primo campione.

o Per DVI4, i campioni a 4 bit sono impacchettati con il primo campione nei quattro bit più significativi e il secondo campione nei quattro bit meno significativi. Nel codec IMA ADPCM, i campioni sono impacchettati nell'ordine opposto.

Ogni pacchetto contiene un singolo blocco DVI. Questo profilo definisce solo la versione a 4 bit per campione, mentre IMA specificava anche una codifica a 3 bit per campione.

La parola "header" per ogni canale ha la seguente struttura:

  int16  predict;  /* valore previsto del primo campione
                      dal blocco precedente (formato L16) */
  u_int8 index;    /* indice corrente nella tabella stepsize */
  u_int8 reserved; /* impostato a zero dal mittente, ignorato dal ricevitore */

Ogni ottetto che segue l'header contiene due campioni a 4 bit, quindi il numero di campioni per pacchetto DEVE essere pari perché non c'è modo di indicare un ultimo ottetto parzialmente riempito.

L'impacchettamento dei campioni per più canali è oggetto di ulteriori studi.

L'algoritmo IMA ADPCM è stato descritto nel documento IMA Recommended Practices for Enhancing Digital Audio Compatibility in Multimedia Systems (versione 3.0). Tuttavia, la Interactive Multimedia Association ha cessato le operazioni nel 1997. Risorse per una copia archiviata di quel documento e un'implementazione software della codifica RTP DVI4 sono elencate nella Sezione 13.

4.5.2 G722

G722 è specificato nella Raccomandazione ITU-T G.722, "7 kHz audio-coding within 64 kbit/s". L'encoder G.722 produce un flusso di ottetti, ciascuno dei quali DEVE essere allineato all'ottetto in un pacchetto RTP. Il primo bit trasmesso nell'ottetto G.722, che è il bit più significativo del campione della sottobanda superiore, DEVE corrispondere al bit più significativo dell'ottetto nel pacchetto RTP.

Anche se la frequenza di campionamento effettiva per l'audio G.722 è 16.000 Hz, la frequenza di clock RTP per il formato di payload G722 è 8.000 Hz perché quel valore è stato assegnato erroneamente in RFC 1890 e deve rimanere invariato per compatibilità all'indietro. La velocità degli ottetti o la velocità delle coppie di campioni è 8.000 Hz.

4.5.3 G723

G723 è specificato nella Raccomandazione ITU G.723.1, "Dual-rate speech coder for multimedia communications transmitting at 5.3 and 6.3 kbit/s". Il codec G.723.1 5.3/6.3 kbit/s è stato definito dall'ITU-T come codec obbligatorio per applicazioni terminali videofonici GSTN ITU-T H.324. L'algoritmo ha una specifica in virgola mobile nell'Allegato B a G.723.1, un algoritmo di compressione del silenzio nell'Allegato A a G.723.1 e uno schema di codifica dei canali scalabile per applicazioni wireless in G.723.1 Allegato C.

Questa Raccomandazione specifica una rappresentazione codificata che può essere utilizzata per comprimere la componente del segnale vocale dei servizi multimediali a un bit rate molto basso. L'audio è codificato in frame di 30 ms, con un ritardo aggiuntivo di 7,5 ms dovuto al look-ahead. Un frame G.723.1 può essere di tre dimensioni: 24 ottetti (frame 6.3 kb/s), 20 ottetti (frame 5.3 kb/s), o 4 ottetti. Questi frame di 4 ottetti sono chiamati frame SID (Silence Insertion Descriptor) e sono utilizzati per specificare i parametri del rumore di comfort. Non c'è restrizione su come i frame di 4, 20 e 24 ottetti siano mescolati. I due bit meno significativi del primo ottetto nel frame determinano la dimensione del frame e il tipo di codec:

     bit   contenuto                    ottetti/frame
  parola ad alto tasso (6.3 kb/s)        24
  parola a basso tasso (5.3 kb/s)        20
  frame SID                              4
  riservato

È possibile passare tra i due tassi a qualsiasi confine di frame di 30 ms. Entrambi (5.3 kb/s e 6.3 kb/s) i tassi sono una parte obbligatoria dell' encoder e del decoder. I ricevitori DEVONO accettare entrambi i tassi di dati e DEVONO accettare frame SID a meno che la restrizione di queste capacità non sia stata segnalata. La registrazione MIME per G723 in RFC 3555 [7] specifica i parametri che POSSONO essere utilizzati con MIME o SDP per limitare a un singolo tasso di dati o per limitare l'uso dei frame SID. Questo codificatore è stato ottimizzato per rappresentare la parola con qualità quasi telefonica ai tassi sopra indicati utilizzando una quantità limitata di complessità.

L'impacchettamento del flusso di bit codificato in ottetti e l'ordine di trasmissione degli ottetti è specificato nella Rec. G.723.1 ed è lo stesso di quello prodotto dall'implementazione di riferimento del codice C G.723. Per il tasso di dati di 6.3 kb/s, questo impacchettamento è illustrato come segue, dove i bit dell'header (HDR) sono sempre "0 0" come mostrato nella Fig. 1 per indicare il funzionamento a 6.3 kb/s, e il bit Z è sempre impostato a zero. I diagrammi mostrano l'impacchettamento dei bit in "ordine di byte di rete", noto anche come ordine big-endian. I bit di ogni parola a 32 bit sono numerati da 0 a 31, con il bit più significativo a sinistra e numerato 0. Gli ottetti (byte) di ogni parola sono trasmessi per primi l'ottetto più significativo. I bit di ogni campo dati sono numerati nell' ordine della rappresentazione del flusso di bit della codifica (bit meno significativo per primo). Le barre verticali indicano i confini tra frammenti di campo.

0                   1                   2                   3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LPC |HDR| LPC | LPC | ACL0 |LPC| | | | | | | | |0 0 0 0 0 0|0 0|1 1 1 1 0 0 0 0|2 2 1 1 1 1 1 1|0 0 0 0 0 0|2 2| |5 4 3 2 1 0| |3 2 1 0 9 8 7 6|1 0 9 8 7 6 5 4|5 4 3 2 1 0|3 2| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ACL2 |ACL|A| GAIN0 |ACL|ACL| GAIN0 | GAIN1 | | | 1 |C| | 3 | 2 | | | |0 0 0 0 0|0 0|0|0 0 0 0|0 0|0 0|1 1 0 0 0 0 0 0|0 0 0 0 0 0 0 0| |4 3 2 1 0|1 0|6|3 2 1 0|1 0|6 5|1 0 9 8 7 6 5 4|7 6 5 4 3 2 1 0| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | GAIN2 | GAIN1 | GAIN2 | GAIN3 | GRID | GAIN3 | | | | | | | | |0 0 0 0|1 1 0 0|1 1 0 0 0 0 0 0|0 0 0 0 0 0 0 0|0 0 0 0|1 1 0 0| |3 2 1 0|1 0 9 8|1 0 9 8 7 6 5 4|7 6 5 4 3 2 1 0|3 2 1 0|1 0 9 8| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MSBPOS |Z|POS| MSBPOS | POS0 |POS| POS0 | | | | 0 | | | 1 | | |0 0 0 0 0 0 0|0|0 0|1 1 1 0 0 0|0 0 0 0 0 0 0 0|0 0|1 1 1 1 1 1| |6 5 4 3 2 1 0| |1 0|2 1 0 9 8 7|9 8 7 6 5 4 3 2|1 0|5 4 3 2 1 0| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | POS1 | POS2 | POS1 | POS2 | POS3 | POS2 | | | | | | | | |0 0 0 0 0 0 0 0|0 0 0 0|1 1 1 1|1 1 0 0 0 0 0 0|0 0 0 0|1 1 1 1| |9 8 7 6 5 4 3 2|3 2 1 0|3 2 1 0|1 0 9 8 7 6 5 4|3 2 1 0|5 4 3 2| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | POS3 | PSIG0 |POS|PSIG2| PSIG1 | PSIG3 |PSIG2| | | | 3 | | | | | |1 1 0 0 0 0 0 0|0 0 0 0 0 0|1 1|0 0 0|0 0 0 0 0|0 0 0 0 0|0 0 0| |1 0 9 8 7 6 5 4|5 4 3 2 1 0|3 2|2 1 0|4 3 2 1 0|4 3 2 1 0|5 4 3| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

              Figura 1: Impacchettamento dei bit G.723 (6.3 kb/s)

Per il tasso di dati di 5.3 kb/s, i bit dell'header (HDR) sono sempre "0 1", come mostrato nella Fig. 2, per indicare il funzionamento a 5.3 kb/s.

0                   1                   2                   3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LPC |HDR| LPC | LPC | ACL0 |LPC| | | | | | | | |0 0 0 0 0 0|0 1|1 1 1 1 0 0 0 0|2 2 1 1 1 1 1 1|0 0 0 0 0 0|2 2| |5 4 3 2 1 0| |3 2 1 0 9 8 7 6|1 0 9 8 7 6 5 4|5 4 3 2 1 0|3 2| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ACL2 |ACL|A| GAIN0 |ACL|ACL| GAIN0 | GAIN1 | | | 1 |C| | 3 | 2 | | | |0 0 0 0 0|0 0|0|0 0 0 0|0 0|0 0|1 1 0 0 0 0 0 0|0 0 0 0 0 0 0 0| |4 3 2 1 0|1 0|6|3 2 1 0|1 0|6 5|1 0 9 8 7 6 5 4|7 6 5 4 3 2 1 0| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | GAIN2 | GAIN1 | GAIN2 | GAIN3 | GRID | GAIN3 | | | | | | | | |0 0 0 0|1 1 0 0|1 1 0 0 0 0 0 0|0 0 0 0 0 0 0 0|0 0 0 0|1 1 0 0| |3 2 1 0|1 0 9 8|1 0 9 8 7 6 5 4|7 6 5 4 3 2 1 0|4 3 2 1|1 0 9 8| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | POS0 | POS1 | POS0 | POS1 | POS2 | | | | | | | |0 0 0 0 0 0 0 0|0 0 0 0|1 1 0 0|1 1 0 0 0 0 0 0|0 0 0 0 0 0 0 0| |7 6 5 4 3 2 1 0|3 2 1 0|1 0 9 8|1 0 9 8 7 6 5 4|7 6 5 4 3 2 1 0| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | POS3 | POS2 | POS3 | PSIG1 | PSIG0 | PSIG3 | PSIG2 | | | | | | | | | |0 0 0 0|1 1 0 0|1 1 0 0 0 0 0 0|0 0 0 0|0 0 0 0|0 0 0 0|0 0 0 0| |3 2 1 0|1 0 9 8|1 0 9 8 7 6 5 4|3 2 1 0|3 2 1 0|3 2 1 0|3 2 1 0| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

              Figura 2: Impacchettamento dei bit G.723 (5.3 kb/s)

L'impacchettamento dei frame SID (silenzio) G.723.1, che sono indicati dai bit dell'header (HDR) aventi il pattern "1 0", è raffigurato nella Fig. 3.

0                   1                   2                   3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LPC |HDR| LPC | LPC | GAIN |LPC| | | | | | | | |0 0 0 0 0 0|1 0|1 1 1 1 0 0 0 0|2 2 1 1 1 1 1 1|0 0 0 0 0 0|2 2| |5 4 3 2 1 0| |3 2 1 0 9 8 7 6|1 0 9 8 7 6 5 4|5 4 3 2 1 0|3 2| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

               Figura 3: G.723 SID mode bit packing

4.5.4 G726-40, G726-32, G726-24, e G726-16

La Raccomandazione ITU-T G.726 descrive, tra gli altri, l'algoritmo raccomandato per la conversione di un singolo canale PCM a 64 kbit/s A-law o mu-law codificato a 8.000 campioni/sec da e verso un canale a 40, 32, 24 o 16 kbit/s. La conversione viene applicata al flusso PCM utilizzando una tecnica di transcodifica a Modulazione di codice a impulsi differenziale adattiva (ADPCM). La rappresentazione ADPCM consiste in una serie di parole in codice con una corrispondenza uno-a-uno con i campioni nel flusso PCM. I tassi di dati G726 di 40, 32, 24 e 16 kbit/s hanno parole in codice di 5, 4, 3 e 2 bit, rispettivamente.

Le codifiche a 16 e 24 kbit/s non forniscono una qualità della voce paragonabile a quella telefonica. Sono progettate per l'uso in Apparecchiature di Moltiplicazione del Circuito Digitale (DCME) sovraccariche. ITU-T G.726 raccomanda che le codifiche a 16 e 24 kbit/s siano alternate con codifiche a tasso di dati più elevato per fornire una dimensione media del campione tra 3,5 e 3,7 bit per campione.

Le codifiche di G.726 sono qui indicate come G726-40, G726-32, G726-24 e G726-16. Prima del 1990, G721 descriveva la codifica ADPCM a 32 kbit/s e G723 descriveva le codifiche a 40, 32 e 16 kbit/s. Pertanto, G726-32 designa lo stesso algoritmo di G721 in RFC 1890.

Un flusso di parole in codice G726 non contiene informazioni sulla codifica utilizzata, pertanto le transizioni tra i tipi di codifica G726 non sono permesse all'interno di una sequenza di parole in codice impacchettate. Le applicazioni DEVONO determinare il tipo di codifica delle parole in codice impacchettate dall'identificatore del payload RTP.

NESSUN'informazione di intestazione specifica del payload DEVE essere inclusa come parte dei dati audio. Un flusso di parole in codice G726 DEVE essere impacchettato in ottetti come segue: la prima parola in codice viene inserita nel primo ottetto in modo tale che il bit meno significativo della parola in codice si allinei con il bit meno significativo nell'ottetto, la seconda parola in codice viene poi impacchettata in modo che il suo bit meno significativo coincida con il bit meno significativo non occupato nell'ottetto. Quando una parola in codice completa non può essere inserita in un ottetto, i bit che si sovrappongono al confine dell' ottetto sono inseriti nei bit meno significativi del prossimo ottetto. L'impacchettamento DEVE terminare con un ottetto finale completamente impacchettato. Il numero di parole in codice impacchettate sarà quindi un multiplo di 8, 2, 8 e 4 per G726-40, G726-32, G726-24 e G726-16, rispettivamente. Un esempio dello schema di impacchettamento per le parole in codice G726-32 è come mostrato, dove il bit 7 è il bit meno significativo del primo ottetto, e il bit A3 è il bit meno significativo della prima parola in codice:

      0                   1
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
     |B B B B|A A A A|D D D D|C C C C| ...
     |0 1 2 3|0 1 2 3|0 1 2 3|0 1 2 3|
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-

Un esempio dello schema di impacchettamento per le parole in codice G726-24 segue, dove di nuovo il bit 7 è il bit meno significativo del primo ottetto, e il bit A2 è il bit meno significativo della prima parola in codice:

      0                   1                   2
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
     |C C|B B B|A A A|F|E E E|D D D|C|H H H|G G G|F F| ...
     |1 2|0 1 2|0 1 2|2|0 1 2|0 1 2|0|0 1 2|0 1 2|0 1|
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-

Si noti che la direzione "little-endian" in cui i campioni sono impacchettati in ottetti nei formati di payload G726-16, -24, -32 e -40 specificati qui è coerente con la Raccomandazione ITU-T X.420, ma è l'opposto di quanto specificato nella Raccomandazione ITU-T I.366.2 Allegato E per il trasporto ATM AAL2. Un secondo set di formati di payload RTP corrispondente alla pacchettizzazione dell'Allegato E di I.366.2 e identificato dai sottotipi MIME AAL2-G726-16, -24, -32 e -40 sarà specificato in un documento separato.

4.5.5 G728

G728 è specificato nella Raccomandazione ITU-T G.728, "Coding of speech at 16 kbit/s using low-delay code excited linear prediction".

Un encoder G.278 traduce 5 campioni audio consecutivi in un indice di codebook a 10 bit risultando in un bit rate di 16 kb/s per l'audio campionato a 8.000 campioni al secondo. Il gruppo di cinque campioni consecutivi è chiamato vettore. Quattro vettori consecutivi, etichettati da V1 a V4 (dove V1 deve essere riprodotto per primo dal ricevitore), formano un frame G.728. I quattro vettori di 40 bit sono impacchettati in 5 ottetti, etichettati da B1 a B5. B1 DEVE essere inserito per primo nel pacchetto RTP.

Facendo riferimento alla figura sottostante, il principio per l'ordine dei bit è il "mantenimento della significatività dei bit". I bit di un vettore più vecchio sono più significativi dei bit dei vettori più nuovi. Il MSB del frame va al MSB di B1 e il LSB del frame va al LSB di B5.

               1         2         3        3
     0         0         0         0        9
     ++++++++++++++++++++++++++++++++++++++++
     <---V1---><---V2---><---V3---><---V4---> vettori
     <--B1--><--B2--><--B3--><--B4--><--B5--> ottetti
     <------------- frame 1 ---------------->

In particolare, B1 contiene gli otto bit più significativi di V1, con il MSB di V1 che è il MSB di B1. B2 contiene i due bit più bassi di V1, il più significativo dei due nel suo MSB, e i sei bit più significativi di V2. B1 DEVE essere inserito per primo nel pacchetto RTP e B5 per ultimo.

4.5.6 G729

G729 è specificato nella Raccomandazione ITU-T G.729, "Coding of speech at 8 kbit/s using conjugate structure algebraic-code-excited linear- prediction (CS-ACELP)". Questo codec è stato ottimizzato per rappresentare la voce con alta qualità, dove G.728 è a basso ritardo e G.723.1 è a basso bitrate. L'encoder G.729 opera su frame vocali di 10 ms corrispondenti a 80 campioni a una frequenza di campionamento di 8000 campioni al secondo. Il flusso di bit generato ha un bit rate di 8 kbit/s. Pertanto, ogni frame contiene 80 bit.

L'impacchettamento del flusso di bit codificato in ottetti e l'ordine di trasmissione degli ottetti è specificato nella Rec. G.729 ed è lo stesso di quello prodotto dall'implementazione di riferimento del codice C G.729. I bit di ogni frame a 80 bit sono numerati da 1 a 80, con il bit più significativo a sinistra e numerato 1. Gli ottetti (byte) di ogni parola sono trasmessi per primi l'ottetto più significativo. I bit di ogni campo dati sono numerati nell'ordine della rappresentazione del flusso di bit della codifica (bit meno significativo per primo). Le barre verticali indicano i confini tra frammenti di campo.

0                   1                   2                   3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |L0 | L1 | L2 | L3 | P1 | | | | | | | |0|0 0 0 0 0 0 0|0 0 0 0 0|0 0 0 0 0|0 0 0 0 0 0 0 0| | |6 5 4 3 2 1 0|4 3 2 1 0|4 3 2 1 0|7 6 5 4 3 2 1 0| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |P1 | P2 | C1 | S1 | C2 | S2 | P1 | | | | | | | | | |0 0|0 0 0|0 0 0 0 0|0 0 0|0 0 0 0 0|0 0 0|0 0 0 0 0 0 0 0| |9 8|4 3 2 1 0|c c c c c|3 2 1 0|c c c c c|3 2 1 0|7 6 5 4 3 2 1 0| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | P2 | C3 | S3 | C4 | S4 | | | | | | | |0 0 0|0 0 0 0 0|0 0 0|0 0 0 0 0|0 0 0| |4 3 2 1 0|c c c c c|3 2 1 0|c c c c c|3 2 1 0| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

L'Allegato A a G.729 specifica una versione a complessità ridotta dell' algoritmo G.729. Il codificatore Allegato A produce un flusso di bit identico a quello del codificatore G.729.

L'Allegato B a G.729 definisce un algoritmo di compressione del silenzio, che è utilizzato con G.729 o G.729 Allegato A. Rilevando un periodo di silenzio, l' encoder trasmette un frame SID (Silence Insertion Descriptor) di 2 ottetti che specifica parametri di rumore di comfort. Non c'è restrizione su come i frame di 10 e 2 ottetti siano mescolati. Il frame SID è parzialmente indici di codebook somma e parzialmente parametri dell'algoritmo di compressione del silenzio. I campi del frame SID sono mostrati nel diagramma sottostante.

0                   1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |L0 | L1 | L2 | L3 | GAIN | | | | | | | |0|0 0 0 0 0 0 0|0 0 0 0 0|0 0 0 0 0|0 0 0 0 0| | |6 5 4 3 2 1 0|4 3 2 1 0|4 3 2 1 0|4 3 2 1 0| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Per G.729 Allegato B, la generazione VAD/DTX codificata a canale include la trasmissione di frame a 1/16 di tasso (800 bps) che sono lunghi solo 10 bit (1,25 ottetti). Poiché questi non si adattano in un numero intero di ottetti, l'impacchettamento di questi frame rimane per studi futuri. I ricevitori che operano sotto questo formato di payload DEVONO accettare i frame vocali a 80 bit e i frame SID a 16 bit. Il ricevitore PUÒ scartare i frame a 10 bit, se presenti.

4.5.7 G729D e G729E

L'Allegato D a G.729 definisce un'estensione a bit rate inferiore (6.4 kb/s) all' algoritmo. Il codificatore G.729 Allegato D produce un frame a 64 bit.

L'Allegato E a G.729 definisce un'estensione a bit rate superiore (11.8 kb/s) all' algoritmo. Il codificatore G.729 Allegato E produce un frame a 118 bit.

L'impacchettamento del flusso di bit codificato in ottetti e l'ordine di trasmissione degli ottetti è specificato nella Rec. G.729 ed è lo stesso di quello prodotto dall'implementazione di riferimento del codice C G.729. I bit di ogni frame a 64 bit o 118 bit sono numerati da 1 a n, con il bit più significativo a sinistra e numerato 1. Gli ottetti (byte) di ogni parola sono trasmessi per primi l'ottetto più significativo. I bit di ogni campo dati sono numerati nell' ordine della rappresentazione del flusso di bit della codifica (bit meno significativo per primo).

Gli Allegati D ed E della Raccomandazione ITU-T G.729 non specificano attualmente come dovrebbero essere gestiti il Rilevamento dell'Attività Vocale (VAD) e la Trasmissione Discontinua (DTX) . Pertanto, NON DOVREBBERO essere utilizzati con questo formato di payload.

4.5.8 GSM

GSM (Group Speciale Mobile) indica lo standard europeo GSM 06.10 per la transcodifica vocale a tasso pieno, ETS 300 961, che si basa sulla codifica RPE/LTP (eccitazione a impulsi residui/predizione a lungo termine) a un tasso di 13 kb/s [11,12,13]. Il testo dello standard può essere ottenuto dal sito web dell'ETSI (European Telecommunications Standards Institute) all'indirizzo http://www.etsi.org.

4.5.8.1 Problemi generali di impacchettamento

Lo standard GSM specifica il flusso di bit prodotto dal codec, ma non specifica come questi bit dovrebbero essere impacchettati per la trasmissione. A differenza dei formati di payload per le altre codifiche audio specificate in questo documento, il formato di payload GSM impacchetta i byte diversamente dalla rappresentazione standard utilizzata dall'implementazione di riferimento GSM 06.10 C.

L'implementazione standard GSM 06.10 impacchetta i 260 bit di un frame GSM in 33 ottetti (16 parole in sistemi a 16 bit), con i bit che occupano i bit meno significativi di ogni byte/parola. Per trasmettere questi in RTP, i 260 bit sono impacchettati in 33 ottetti come definito in ETSI TS 101 318 [4]. Quest'ultimo è effettivamente lo standard per VoIP/VoFR/VoATM ed è lo stesso del formato "Toast" utilizzato dall'implementazione GSM citata nella Sezione 13.

Nel formato di payload RTP, un frame è impacchettato in 33 ottetti (264 bit) riempiendo i 4 bit di riserva dell'ultimo ottetto con zeri. Due frame sono impacchettati in 66 ottetti. La mappatura dei campi è mostrata nella Tabella 2.

4.5.8.2 Nomi e numeri delle variabili GSM

I parametri del codec audio GSM sono nominati nel seguente modo, secondo lo standard GSM 06.10.

                         Tabella 2: Formato payload GSM

Campo Nome Campo Bit Ottetto Bit

1 LARc[0] 6 1 0--5 2 LARc[1] 6 1, 2 6--7, 0--3 3 LARc[2] 5 2, 3 4--7, 0 4 LARc[3] 5 3 1--5 5 LARc[4] 4 3, 4 6--7, 0--1 6 LARc[5] 4 4 2--5 7 LARc[6] 3 4, 5 6--7, 0 8 LARc[7] 3 5 1--3 9 Nc[0] 7 5, 6 4--7, 0--2 10 bc[0] 2 6 3--4 11 Mc[0] 2 6 5--6 12 xmaxc[0] 6 6, 7 7, 0--4 13 xmc[0] 3 7 5--7 14 Nc[1] 7 8 0--6 15 bc[1] 2 8, 9 7, 0 16 Mc[1] 2 9 1--2 17 xmaxc[1] 6 9, 10 3--7, 0 18 xmc[1] 3 10 1--3 19 Nc[2] 7 10, 11 4--7, 0--2 20 bc[2] 2 11 3--4 21 Mc[2] 2 11 5--6 22 xmaxc[2] 6 11, 12 7, 0--4 23 xmc[2] 3 12 5--7 24 Nc[3] 7 13 0--6 25 bc[3] 2 13, 14 7, 0 26 Mc[3] 2 14 1--2 27 xmaxc[3] 6 14, 15 3--7, 0 28 xmc[3] 3 15 1--3

4.5.9 GSM-EFR

GSM-EFR è specificato in ETS 300 726 (GSM 06.60). Questo è un codec vocale a tasso pieno migliorato, con la stessa frequenza di clock (8000 Hz) e bit rate (12.2 kb/s) del codec GSM.

4.5.10 L8

L8 indica campioni di dati audio lineari, utilizzando 8 bit di precisione con un offset di 128, cioè, il segnale più negativo è rappresentato dal valore 0, il segnale zero dal valore 128 e il segnale più positivo dal valore 255.

4.5.11 L16

L16 indica campioni di dati audio lineari con segno (16 bit). I campioni audio lineari L16 DOVREBBERO essere trasmessi in ordine di byte di rete (ottetto più significativo per primo).

4.5.12 LPC

LPC designa una codifica predittiva lineare sperimentale contribuita da Ron Frederick allo Xerox PARC, che si basa su un'implementazione originariamente scritta da Steve Casner all'ISI. Il codice sorgente per l' encoder e il decoder è disponibile come elencato nella Sezione 13.

4.5.13 MPA

MPA designa l'uso di flussi elementari audio MPEG-1 o MPEG-2. Il formato di payload RTP è come specificato in RFC 2250 [14], Sezione 3.

4.5.14 PCMA e PCMU

PCMA e PCMU sono specificati nella Raccomandazione ITU-T G.711. I dati audio sono codificati come otto bit per campione, dopo il ridimensionamento logaritmico. PCMU indica ridimensionamento mu-law, PCMA ridimensionamento A-law. Una descrizione dettagliata è data da Jayant e Noll [15]. Ogni ottetto G.711 DEVE essere allineato all'ottetto in un pacchetto RTP. Il bit di segno di ogni ottetto G.711 DEVE corrispondere al bit più significativo dell'ottetto nel pacchetto RTP (cioè, assumendo che i campioni G.711 siano gestiti come ottetti sulla macchina host, il bit di segno deve essere il bit più significativo dell' ottetto come definito dal formato della macchina host). Le modalità 56 kb/s e 48 kb/s di G.711 non sono applicabili a RTP, poiché PCMA e PCMU DEVONO sempre essere trasmessi come campioni a 8 bit.

4.5.15 QCELP

Il codec audio Qualcomm Code Excited Linear Prediction (QCELP) è specificato in TIA/EIA IS-733, "TR45: High Rate Speech Service Option 17 for Wideband Spread Spectrum Communication Systems".

Il codec QCELP è utilizzato per lo standard del sistema di telefonia cellulare CDMA TIA/EIA IS-95. Il codec QCELP scala a diversi tassi di dati, che possono essere selezionati su base frame per frame. Il tasso di dati massimo è 13 kbit/s. Questo formato di payload non definisce un tipo di frame silenzioso separato, ma il tasso di dati può essere ridotto a circa 1 kbit/s nei periodi di silenzio.

Il formato di payload RTP è specificato in [16].

4.5.16 RED

Il formato di payload audio ridondante "RED" è specificato in RFC 2198 [17]. Definisce un mezzo mediante il quale copie ridondanti multiple di un pacchetto audio possono essere trasmesse in un singolo flusso RTP.

4.5.17 VDVI

VDVI è una versione a tasso variabile di DVI4, disponibile per l'assegnazione dinamica. I campioni DVI4 sono impacchettati in ottetti, ma il numero di bit per campione può variare da pacchetto a pacchetto ed è specificato nell' header del pacchetto. Per VDVI, il campo tipo payload dell'header RTP è un tipo dinamico che mappa a "VDVI".

Ogni pacchetto contiene un singolo blocco DVI. La parola "header" per ogni canale ha la seguente struttura:

  int16  predict;  /* valore previsto del primo campione
                      dal blocco precedente (formato L16) */
  u_int8 index;    /* indice corrente nella tabella stepsize */
  u_int8 sample_size; /* numero di bit per campione */

Sample-size DEVE essere uno tra 3, 4, o 5. Se sample_size è 4, l' impacchettamento dei campioni è lo stesso di DVI4. Se sample_size è 3 o 5, i campioni sono impacchettati nei prossimi bit disponibili dell'ottetto corrente della finestra del pacchetto, iniziando con il MSB. Quando un campione si estende oltre il confine di un ottetto, i bit sono posizionati nei LSB del primo ottetto e nei MSB del secondo ottetto. Il prossimo campione è quindi impacchettato iniziando dal primo MSB disponibile del secondo ottetto. Il processo continua per l'intero pacchetto.