VoIP Howto: Informazioni tecniche sul VoIP

4. Informazioni tecniche sul VoIP

Ecco alcune importanti informazioni sulla tecnologia VoIP, necessarie per comprenderla bene.

4.1 Vista d'insieme di una connessione VoIP

Per configurare una comunicazione VoIP abbiamo bisogno:

Prima di tutto di un ADC per convertire la voce in segnali digitali (bits)
I bit vanno compressi in un buon formato per la trasmissione: c'é tutta una serie di protocolli atti a tale scopo che vedremo più avanti.
Adesso dobbiamo inserire i pacchetti voce in pacchetti di dati standard utilizzando un protocollo real-time (tipicamente RTP su UDP su IP)
Abbiamo bisogno di un protocollo di segnalazione per chiamare gli utenti: ITU-T H323 fa proprio al caso nostro.
In ricezione dobbiamo disassemblare i pacchetti, estrarre i dati, convertirli in segnali vocali analogici e mandarli alla scheda audio (o alla cornetta).
Tutto questo deve essere effettuato in tempo reale poiché non possiamo permetterci ritardi eccessivi durante il dialogo vocale! (vedi sezione QoS, Qualità del Servizio)

                         
                        Architettura base

Voce )) ADC - Algoritmo di compressione - Assembl. RTP in TCP/IP -----
                                                         ---->       |
                                                         <----       |
Voce (( DAC - Algoritmo di decompress.  - Disass. RTP da TCP/IP  -----

4.2 Conversione analogica digitale

Questo viene fatto dall'hardware, tipicamente da un ADC integrato.

Oggi pressoché ogni scheda audio permette di convertire in 16 bit una banda di 22050 Hz (per il campionamente della quale abbiamo bisogno di 44100 Hz per il teorema del campionamento) ottendendo una velocità di 2 bytes * 44100 (campioni al secondo) = 88200 Bytes/s, 176.4 kBytes/s per i flussi dati stereo.

Per il VoIP non abbiamo certamente una velocita' cosi' elevata (176.4 kBytes/s): vediamo allora quali codifiche utilizzare.

4.3 Algoritmi di compressione

Vediamo quali formati di digitalizzazione e compressione utilizziamo.

PCM, Pulse Code Modulation, Standard ITU-T G.711

La banda della voce é 4 kHz, quindi abbiamo campioni alla velocità di 8 kHz (dal teorema del campionamento).
Rappresentiamo ogni campione con 8 bit (quindi con 256 valori possibili).
La velocità compressiva é 8000 Hz *8 bit = 64 kbit/s, la tipica velocità di un canale telefonico digitale.
Nelle applicazioni reali si utilizzano le varianti mu-law (Nord America) e a-law (Europa) che codificano il segnale analogico su scala logaritmica sfruttando 12 o 13 bits invece di 8 bits (vedi Standard ITU-T G.711).

ADPCM, Adaptive differential PCM, Standard ITU-T G.726

Converte soltanto la differenza tra il pacchetto attuale e quello precedente richiedendo 32 kbps (vedi Standard ITU-T G.726).

LD-CELP, Standard ITU-T G.728
CS-ACELP, Standard ITU-T G.729 and G.729a
MP-MLQ, Standard ITU-T G.723.1, 6.3kbps, Truespeech
ACELP, Standard ITU-T G.723.1, 5.3kbps, Truespeech
LPC-10, fino a 2.5 kbps!!

Gli ultimi protocolli sono i più significativi perché garantiscono un basso utilizzo di banda utilizzando metodi di codifica alla sorgente: inoltre le codifiche G.723.1 hanno un MOS molto elevato (Mean Opinion Score, utilizzato per misurare la fedeltà vocale) ma attenzione alle prestazioni richieste, finoa 26 MIPS (milioni di istruzioni al secondo)!

4.4 RTP Protocollo di trasporto Real Time

Adesso che abbiamo i dati "grezzi", per incapsularli nello stack TCP/IP, seguiamo la seguente struttura:

VoIP data packets
       RTP
       UDP
       IP
    I,II layers

I Pacchetti di voce risiedono in pacchetti RTP (Protocollo di trasporto Real-Time) che a loro volta giacciono su pacchetti UDP-IP.

Prima di tutto notiamo che VoIP non utilizza il protocollo TCP perche' troppo persante per le applicazioni multimediali (che sono, di per se stesse "real time"), quindi abbiamo bisogno di usare l'UDP

Secondo, con l'UDP non possiamo implicitamente controllare l'ordine di arrivo dei pacchetti o quanto impiegano ad arrivare (concetto di datagramma): entrambi sono molto importanti per ottenere una buona qualita' audio della voce (per poter distinguere le parole) e una buona qualita' di conversazione (la facilita' con cui si segue un discorso).

Il protocollo RTP risolve il problema permettendo al ricevitore di ordinare i pacchetti in base all'ordine di arrivo e di non aspettare troppo a lungo per un pacchetto perso (in effetti non abbiamo bisogno di ogni singolo pacchetto di voce, possiamo anche perderne qualcuno, l'importante e' ricevere un flusso continuo della maggiorparte dei pacchetti trasmessi e, ovviamente, in ordine).

                    Real Time Transport Protocol
 
    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |V=2|P|X|  CC   |M|     PT      |       sequence number         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           timestamp                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           synchronization source (SSRC) identifier            |
   +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
   |            contributing source (CSRC) identifiers             |
   |                             ....                              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Dove:

V identifica la versione di RTP
P indica il padding, un byte di riempimento.
X indica la presenza delll'intestazione estesa.
Il campo CC rappresenta il numero di identificatori CSRC che seguono l'header a lunghezza fissa. Per esempio il campo CSRC viene utilizzato in caso di conferenza.
M é un bit per marcare.
PT indica il tipo di PayLoad (dati)

Per una descrizione approfondita del protocollo RTP e di tutte le applicazioni relative si veda i relativi RFCs 1889 e 1890.

4.5 RSVP

Nell'ambiente VoIP vengono utilizzati altri protocolli, come l'RSVP, che può gestire la Qualità del Servizio (QoS).

RSVP é un protocol di segnalazione che permette di riservare una certa quantità di banda e di latenza massima in ogni nodo (router) di rete attraversato che lo supporta.

Per informazioni dettagliate sull'RSVP si veda l' RFC 2205

4.6 Qualità del servizio (QoS)

Abbiamo detto molte volte che le applicazioni VoIP richiedono un flusso di dati in tempo reale.

Sfortunatamente, TCP/IP non può garantire tale flusso (può solo effettuare il massimo sforzo per cercare di conseguirlo). Abbiamo quindi bisogno di introdurre degli artifizi e delle politiche di schedulazione che possano gestire i pacchetti in OGNI router che attraversano.

Ecco allora:

Il campo TOS nel protocollo IP per descrivere il tipo di servizio:valori alti indicano bassa urgenza, mentre valori via via sempre più alti segnalano urgenza crescente.
Metodi di accodamento dei pacchetti:
1. FIFO (First in First Out), Il più stupido del metodi che fa passare i pacchetti in ordine di arrivo.
2. WFQ (Weighted Fair Queuing), consiste nel far passare in modo equo i pacchetti (per esempio, i pacchetti FTP non possono consumare tutta la banda disponibile), a seconda del tipo di dati che contengono, tipicamente vengono fatti passare un pacchetto UDP ed uno TCP in modo paritario.
3. CQ (Custom Queuing), gli utenti possono decidere la loro priorità.
4. PQ (Priority Queuing), c'é una numbero (tipicamente 4) di code con ciascuno un livello di priorità associato: prima di tutto, vengono fatti passare i pacchetti nella prima coda, poi (una volta terminati) si passa a quelli della seconda e così via.
5. CB-WFQ (Class Based Weighted Fair Queuing), simile al WFQ ma, in più, abbiamo il concetto di classi (fino a 64) e la di banda associata a ciascuna classe.
Proprietà di shaping e policing, che permetteno di limitare la sorgente ad una ben prefissata banda in:
1. download
2. upload
Prevenzione della congestione di rete, come il RED (Random Early Detection).

Una esaustiva descrizione sulla QoS può essere trovata sui Differentiated Services presso lo IETF.

4.7 H323: protocollo di segnalazione

Il protocollo H323 viene utilizzato, ad esempio, dall'applicativo Microsoft Netmeeting per creare chiamate VoIP.

Questo protocollo permette ad una serie di elementi di "parlare" tra loro:

Terminali, clients che inizializzano le connessioni VoIP. Sebbene i terminali possano dialogare insieme senza aver bisogno di nessun altra identità, é necessario introdurre elementi addizionali per una visione più scalabile.
Gatekeepers, che operano essenzialmente:
1. Una conversione nome-indirizzo, per utilizzare i nomi al posto degli indirizzi IP
2. Un controllo di accesso, per abilitare o disabilitare alcune macchine o alcuni utenti
3. Gestione della banda.
Gateways, punto di riferimento per la conversione TCP/IP - PSTN.
Multipoint Control Units (MCUs) to provide conference.
Vengono anche utilizzati Servers Proxy.

H323 permette anche la gestione del video.

Per quanto riguarda la voce, l'h323 é compatibile con le codifiche G.711, G.722, G.723, G.728 e G.729, mentre per il video supporta i protocolli h261 and h263.

Maggiori informazioni sul protocollo h323 sono disponibili sugli Standards presso Openh323, su at questo sito web h323, mentre la descrizione dello standard ufficiale é reperibile dalle ITU H-series Recommendations.

L'h323 viene implementato in molto prodotti software come Microsoft Netmeeting, Net2Phone, DialPad, ... e altri prodotti freeware che puoi trovare sul sito web Openh323.

Next Previous Contents