Note:

1. Selezionare l'header esterno, o il piu basso a livello di protocollo da includere nei calcoli. Ad esempio, selezionando "RTP" include il payload e l'header RTP, ma non UDP, IP, o link headers.
   
2. La pacchettizzazione del payload (carico utile) puo essere specificata in termini di ritardo dei pacchetti (in millisecondi) o di numero di fotogrammi per pacchetto. Specificarne uno dei due e il calcolatore cerchera' di capire l'altro sulla base del ritardo del frame in base al codec selezionato.
   
3. Frame-based codec (ad esempio G.723.1): questo campo specifica il numero di fotogrammi per pacchetto, o FPP. Sample-based codec (ad esempio G.711): questo campo indica il numero di samples (campioni) per pacchetto. Si noti che
   questa calcolo non segue la convenzione H.323 di otto campioni in un "frame" di sample-based codecs. Se questo ti confonde o non ti e chiaro, ti basta specificare la pacchettizzazione in termini di ritardo dei pacchetti.
   
4. Questo riduce la larghezza di banda totale al 35% di quello che sarebbe stato senza soppressione del silenzio (questa riduzione varia tipicamente dal 35% al 50%). Ogni frame SID non e' incluso nel calcolo della larghezza di banda.
   
5. Questo aumenta la larghezza di banda nella direzione opposta tenendo conto del traffico RTCP. La larghezza di banda, che non include il link headers, e aumentato del 5%. Il traffico RTCP puo infatti essere inferiore, per cui questa dovrebbe essere considerata una libera stima.
   
6. Questo e il numero di canali unidirezionali, cioe' per la larghezza di banda complessiva utilizzata per una semplice chiamata a due vie, si dovrebbe impostare questo campo a 2.
   
7. Larghezza di banda media e la stessa di quella massima tranne quando la casella del silence-suppression e selezionata, in questo caso e minore.
   
8. Questa e la larghezza di banda istantanea massima. Quando la soppressione del silenzio viene utilizzata su un canale fisico che ha una capacita fissa, ad esempio 33,6 kbps, si deve considerare soprattutto questo valore perche quando e' presente un segmale vocale, uno ha bisogno di tutti la larghezza di banda possibile e la valore della larghezza di banda media non e realmente utile. Per esempio, a quanto pare, in base alla larghezza di banda media calcolata, si dovrebbe essere in grado di trasmettere G.711 64kbps a 160 campioni per pacchetto utilizzando l' RTP silence-Supression
   attraverso un collegamento a 33,6 kbps PPP, perche questo consuma solo 28,8 kbps in media. Tuttavia, quando vi e un segnale vocale si avra bisosno di 82.4kbps, quindi questo codec non e adatto per questa applicazione.
   
9. Ritardo di calcolo non e compreso in alcun di questi valori. Come il DSP MIPS, il ritardo di calcolo e dipende dall'implementazione e puo variare notevolmente anche se di solito non e' una parte significativa del ritardo end-to-end.
   
10. Questo e il MIPS richiesto per una coppia encoder/decoder e non solo uno o l'altro. E' un' implementazione che dipende e varia considerevolmente da un' implementazione all'altra.
    
11. Mean Opinion Score e molto soggettiva e varia da un episodio ad un altro a seconda di una serie di cose, per esempio, la dimensione del campione, ambiente acustico, e la metodologia. I valori qui presentati fanno riferimento all'audio senza perdita di pacchetti. Alcuni codec sono meglio di altri dal punto di vista di perdita di pacchetti.
    
12. Il rate del pacchetto e particolarmente importante per il dimensionamento di una rete verso un router perche i router non sono solo limitati dalla larghezza di banda, ma anche dal numero di pacchetti al secondo, o pps, che in grado di elaborare.