Voce Su IP2

Voce su IP Page 1
Capitolo 1. Voce su IP: i concetti fondamentali
1.1. Introduzione
L'argomento Voce su IP è, sicuramente, uno dei più gettonati dell'intero
mondo del networking. Tecnicamente, con questa tecnologia si intende il
trasporto di traffico di tipo telefonico fonia)
( su una rete in tecnologia IP.
Considerando che la tecnologia telefonica è un'invenzione tutt'altro che recente e
che la possibilità di effettuare telefonate è ormai di dominio pubblico da oltre un
secolo, quali sono i motivi di tutta questa enfasi?
1.1.1. La tecnologia di base
Prima di iniziare la trattazione dell'argomento VoIP, è opportuno fare un

breve richiamo alle tecnologie (commutazione di circuito e di pacchetto) che
sono alla base rispettivamente della rete telefonica e della rete dati.
1.1.1.1. Rete telefonica e commutazione di circuito
La rete PSTN (Public Switched Telephony

Network) è stata pensata e progettata per il
trasporto della voce ed adotta la tecnologia a
commutazione di circuito, vale a dire ogni volta
che una comunicazione è iniziata, gli switch
interni della rete commutano per creare un
circuito "fisico" diretto fra la parte chiamante e
quella chiamata.
Ciò significa che per tutta la durata della

comunicazione, gli interlocutori dispongono di un
canale dedicato non accessibile agli altri utenti,
indipendentemente dal fatto che le parti siano in
conversazione attiva o in silenzio. Si ha, così,
un'allocazione statica delle risorse ed ogni
circuito garantisce una banda di 64 kbps
bidirezionale (full duplex).
La banda costante e il collegamento diretto

tra le due parti permettono al segnale vocale di avere qualità garantita per tutta
la durata della comunicazione. Tuttavia, questo corrisponde ad avere una bassa
percentuale di utilizzazione della rete e quindi non si trae vantaggio dal
fenomeno del multiplexing statistico. Infatti, durante una comunicazione vocale,
un interlocutore passa più della metà del tempo in silenzio, in quanto i due
file://localhost/C:/Inetpub/wwwroot/netlibrary/books/voip.htm 8.24.27 22/10/2005

Voce su IP Page 2
interlocutori non parlano contemporaneamente: quando uno parla l'altro

(normalmente) resta in silenzio; inoltre anche tra una parola e l'altra ci sono
degli istanti di silenzio. I 64 kbps (full-duplex) allocati sono, perciò, usati per
meno della metà del periodo della conversazione e la banda libera rimane
inutilizzata. Il costo di una chiamata tramite PSTN è basato sulle risorse
riservate, dunque in base al tempo d'utilizzo e alla lunghezza del collegamento e
non in base alle risorse effettivamente impiegate.
Un altro limite della rete telefonica è l'utilizzo di un codec standard e

predeterminato a priori, il PCM64. Questo fattore è limitante sia nel momento in
cui si volesse utilizzare la rete telefonica per il trasporto di audio compresso con
una maggiore efficienza, sia nel momento in cui si volesse trasportare audio ad
alta qualità (ad esempio aumentando il bitrate oppure utilizzando un codec con
caratteristiche migliori). Tralasciando momentaneamente il problema che il
codec può essere cambiato solamente a prezzo di cambiare tutti gli apparati
d'accesso alla rete telefonica (oppure, per la rete ISDN, tutti i telefoni),
operazione evidentemente onerosa, l'allocazione statica dei 64kbps vanifica ogni
sforzo di compressione migliore in quanto, in ogni caso, per ogni telefonata deve
essere allocata tale banda (le tecnologie di trasporto, ad esempio SONET/SDH,
prevedono questo valore come unità minima di canale trasportabile).
Per realizzare il circuito virtuale tra le parti è necessaria inoltre una fase di
segnalazione e di set-up che possono richiedere un tempo anche dell'ordine del
secondo, con un considerevole lavoro di gestione della chiamata da parte della
rete.
Questi motivi portano a concludere che, tecnicamente, la tecnologia su cui si

basa la telefonica classica può essere migliorata, ed è proprio su questi punto
che andrà a puntare la tecnologia VoIP.
1.1.1.2. La rete dati e la commutazione di pacchetto
La totalità delle reti dati oggi esistenti si basa

sul concetto di commutazione di pacchetto, ossia
la creazione di un'unità elementare di trasporto
che sia in grado di viaggiare in maniera più o
meno autonoma sulla rete, recapitando a
destinazione il suo contenuto informativo.
La architettura di rete dati allo stato attuale è

la rete IP, caratterizzata da un servizio di tipo
best effort, senza meccanismi di prenotazione di
risorse. Gli apparati intermedi (nodi) non creano
un circuito fisico tra le parti, ma instradano il
pacchetto nella giusta direzione in base
all'informazione contenuta nell'intestazione dello
stesso. In questo modo non si ha allocazione di
risorse riservate, perciò su una linea di
collegamento (link) possono transitare
contemporaneamente anche pacchetti
appartenenti a flussi diversi, aumentando
notevolmente la percentuale d'utilizzazione della rete rispetto a quella telefonica.
Alcuni pacchetti di uno stesso flusso, però, possono percorrere cammini

diversi, possono arrivare a destinazione fuori sequenza, oppure possono
perdersi. In tal caso, l'apparato terminale (ad esempio il PC) ha il compito di
ordinare i pacchetti nella sequenza corretta e richiedere eventualmente la
ritrasmissione di quelli persi, rendendo il trasporto affidabile. Quest'operazione
può però non essere opportuna nel caso di trasmissione della voce in quanto
introduce notevoli ritardi ai quali i flussi voce sono particolarmente sensibili.
La tecnologia a commutazione di pacchetto permette di ovviare facilmente ai

problemi descritti nella sezione precedente dal momento che la mancanza di una
preallocazione fissata favorisce la multiplazione statistica tra le chiamate (quindi
sono adottabili tecniche di compressione dei silenzi e codec più aggressivi come
fattore di compressione, fatta salva la compatibilità con gli apparati terminali),

Voce su IP Page 3
quindi la gestione più efficiente della banda. Inoltre, non avendo il limite dei
64kbps permette anche il trasporto di traffico con bitrate più elevati, ad esempio
per il trasporto di voce con qualità superiore.
Il costo di una "chiamata" in tecnologia dati è quindi normalmente

determinato dalla quantità di dati che passano, indipendentemente dalla durata
della comunicazione.
Infine, la rete IP non ha il call setup, rendendo la gestione della chiamata

decisamente meno onerosa. Tuttavia questa scelta impone dei vincoli non
indifferenti per la gestione della qualità del servizio spettante alla singola
chiamata: questo è il motivo per cui altre tecnologie di reti dati (prime fra tutte
quelle che sono state definite nell'ambito degli operatori telefonici quali X.25,
Frame Relay e ATM) mantengono il concetto di call-setup.
Come si vedrà in seguito, uno dei problemi principali della rete IP è proprio la
fornitura di determinate garanzie di qualità alla telefonata.
1.1.2. Le differenti visioni della Voce su IP
Della tecnologia Voce su IP si fa un gran

parlare, ma non tutti sottintendono la stessa
visione del servizio che può essere offerto
all'utente finale. Mentre la tecnologia di base è la
stessa, gruppi di utenti diversi ne immaginano
scenari di utilizzo differenti. In particolare, è
possibile evidenziare come esistano tre possibili
bacini di utenza della tecnologia VoIP:
l'utente domestico (visione "consumer")

l'operatore telefonico (visione "telecom")
l'utente aziendale (visione "enterprise")
1.1.2.1. La visione "consumer" della Voce su IP
Probabilmente, la prima volta in cui il termine

VoIP è arrivato al grande pubblico è stato
quando, nel 1995, la Vocaltec ha rilasciato la
prima versione dell'applicazione "Internet
Phone". Questo software, installato sul proprio
personal computer, abilitava gli utenti a
comunicare tramite audio e testo e permetteva di
trasmettere e condividere immagini e grafici
tramite una whiteboard mediante l'impiego di
normalissimi dispositivi quali un microfono, le
casse e, per il video, una videocamera. In
mancanza di questi oggetti hardware il prodotto
instaurava una comunicazione al meglio delle sue
possibilità. Ad esempio, in mancanza di una
telecamera il software consentiva di ricevere
immagini ma (ovviamente) non di inviarle.
La VoIP era quindi intesa come uno

strumento che permettesse di poter effettuare
chiamate vocali da un altro personal computer all'altro, rendendo possibile una
comunicazione in tempo reale con l'aggiunta di funzionalità avanzate quali video,
lavagna condivisa, e altro. Non ultimo, la possibilità di poter condividere il
proprio desktop sul PC offriva la possibilità di operare direttamente su una

Voce su IP Page 4
macchina remota (ad esempio per risolvere problemi di configurazione),

funzionalità molto comoda in determinate occasioni.
I benefici della tecnologia VoIP "adattata" ad

una visione consumer sono principalmente il
costo ridotto della chiamata e la possibilità di
utilizzo di nuove applicazioni non disponibili con
la tecnologia telefonica classica.
D'altro canto, questa visione può essere

decisamente limitante. Infatti, una visione della
VoIP che richiede necessariamente la presenza di
un personal computer per poter operare presenta
notevoli criticità, tra le quali:
non tutti gli utenti dispongono di un PC,

mentre quasi tutti dispongono di un
telefono: è accettabile che solo i primi
possano disporre di VoIP?
il PC deve essere permanentemente

collegato alla rete, pena l'impossibilità di
poter ricevere chiamate
sono possibili solo chiamate PC-to-PC; manca la possibilità di chiamare un

utente abbonato ad un servizio telefonico tradizionale
il PC difficilmente gestisce la mobilità, caratteristica a cui sono ormai

abituati gli utenti (il successo dei telefoni mobili è sotto gli occhi di tutti).
Pertanto, è difficile rimpiazzare il servizio fornito dai telefoni cellulari in
quanto richiederebbe che i PC si possano spostare con l'utente e siano
sempre collegati alla rete IP
Il problema fondamentale di questa visione è pertanto il fatto che vi sia un

nesso obbligatorio tra la disponibilità di un PC e la possibilità di attivare la
tecnologia VoIP.
1.1.2.2. La visione "telecom" della Voce su IP: Telephony over IP
Nella visione degli operatori telefonici, la

visione "consumer" della VoIP è riduttiva dal
momento che la quantità di Personal Computer
presenti nel mondo (e il numero di utilizzatori
capaci ad adoperarli) è decisamente inferiore al
numero di telefoni. Nella visione degli operatori
telefonici si tende pertanto a non considerare il
PC come uno strumento abilitante alla tecnologia
VoIP, sostituendolo con il classico terminale
telefonico. Non si parla più di VoIP, ma si
preferisce il termine Telephony over IP (ToIP)
per indicare il trasporto di telefonate attraverso
una infrastruttura di rete in tecnologia IP. La
tecnologia ToIP è un sovrinsieme della tecnologia
VoIP.
Con il termine VoIP si indica infatti un

insieme di tecnologie per il trasporto di campioni
vocali su una rete IP e le necessarie tecnologie di
segnalazione necessarie ad effettuare la chiamata tra due entità con tecnologia
VoIP. Con il termine ToIP si intende invece quell'insieme di tecnologie che
permettono il trasporto di telefonate su una rete IP. Questo comprende quindi
non solo le tecnologie precedenti (VoIP) per quanto riguarda il mondo IP, ma
anche una serie di tecnologie "legacy" per permettere al mondo telefonico di
interfacciarsi con il mondo IP. Ad esempio, è necessario prevedere un modo per
trasportare la segnalazione SS#7 (ad esempio generate da due centrali
telefoniche tradizionali, ora interconnesse da una rete IP) sulla rete IP,

Voce su IP Page 5
prevedere un meccanismo di conversione della segnalazione SS#7 nella

corrispondente segnalazione prevista dalle tecnologie VoIP (ad esempio per
interfacciare una centrale telefonica "legacy" con una in tecnologia
completamente IP), prevedere l'implementazione dei servizi di rete intelligente
sia a livello di segnalazione, sia a livello di apparati (server) dedicati a tali servizi,
e così via.
Questo implica una serie di conseguenze:
anche un telefono tradizionale può

usufruire di una infrastruttura VoIP, fatto
salvo che esista un gateway (traduttore)
che trasforni i segnali vocali tradozionali in
pacchetto VoIP
la tecnologia VoIP può affermarsi senza la
necessità di dover cambiare i terminali alla
periferia della rete (operazione
notoriamente onerosa in termini economici
e di tempo impiegato)
il luogo più adatto per l'adozione della
VoIP è sicuramente il backbone della rete
telefonica, dal momento che è necessario
cambiare solamente l'interfaccia delle
centrali telefoniche verso il backbone e
abilitandole alla trasmissione di pacchetti
IP.
Una visione di questo tipo ha, ovviamente, anche alcuni aspetti negativi. Il
primo fra tutti è che il servizio telefonico fornito all'utente finale non si
avvantaggia di nessun miglioramento con il passaggio del backbone telefonico in
tecnologia VoIP. In altre parole, il passaggio da una telefonata in tecnologia
classica ad una in tecnologia VoIP non inserisce nessuna novità nel modo con cui
l'utente finale percepisce il servizio. Questo implica che la visione "telecom" della
VoIP non è orientata ad un miglioramento del servizio, ossia non è in grado di
fornire quelle nuove possibilità (interazione audio, video, dati) permesse invece
dalla visione "consumer". I motivi dell'adozione di tecnologie VoIP da parte del
gestore telefonico vanno quindi ricercati altrove e principalmente nella
prospettiva di una maggior economicità di gestione dell'infrastruttura.
1.1.2.2.1. ToIP: le ragioni della scelta
Un dato di fatto è che, ormai, il traffico di

tipo dati ha decisamente superato, in volume, il
traffico di tipo telefonico. Dal momento che il
mantenimento di due infrastrutture di rete
distinte (una per il traffico telefonico, una per il
traffico dati) è inutilmente costoso, gli operatori
hanno sempre cercato una razionalizzazione che
è consistita nell'unificare, almeno nelle funzioni di
base, le due reti.
In passato (e spesso ancora oggi), il traffico

dati veniva quindi trasportato su un'infrastruttura
di tipo telefonico ritagliando, all'interno dei canali
telefonici tradizionali (SONET/SDH e altro),
alcuni canali destinati al traffico dati. In molti
casi, poi, con l'aumentare del traffico dati sono
stati riservati interi link a questo tipo di traffico,
sempre però gestito con la tecnologia
precedente. In altre parole, si è forzato il traffico
dati al passaggio su un'infrastruttura di tipo telefonico.
Con l'attuale prevalere del traffico dati, potrebber diventare più conveniente
fare il contrario: costruire dei canali in tecnologia dati (una fra tutte, Ethernet e i
suoi derivati a lunga distanza), quindi forzare la voce a passare su questi canali.

Voce su IP Page 6
Anche in questo caso l'infrastruttura di rete, sotto certi aspetti, sarebbe comune
tra i due servizi con gli ovvi vantaggi economici e di gestione.
Il secondo motivo che spinge verso integrazione della telefonia su una rete
dati è l'esigenza, da parte di quest'ultima, di poter differenziare diversi tipi di
traffico su di essa. Storicamente, la tecnologia IP (e Internet che è la sua
incarnazione più famosa) non ha mai posto in grande risalto la necessià di poter
differenziare, all'interno della rete, il servizio fornito ai pacchetti IP.
Banalizzando, un normale tasferimento file può sopportare senza problemi un
rallentamento nel flusso dati, mentre una sessione interattiva (si pensi al telnet,
alla chat, oppure ad un sistema di prenotazioni quali le prenotazioni aeree)
richiede che la rete porti a destinazione i pacchetti in tempi estremamente
rapidi, senza rallentamenti.
L'incremento del numero di utilizzatori di reti IP ha fatto sì che nascessero

nuove applicazioni (si pensi ad esempio al video streaming), cambiando
profondamente latipologia di traffico di una rete IP classica e mettendo
chiaramente in risalto come determinate applicazioni abbiano necessità diverse
di altre e come la rete debba essere in grado di trattarle in maniera differente.
Questa esigenza si è fatta pressante con l'adozione delle reti IP anche per scopi
commerciali, dove un'azienda può voler un trattamento preferenziale per il
traffico da essa generato ed è ovviamente disposta a pagare un prezzo maggiore
rispetto ad un tipico utente domestico che utilizza la rete per svago.
Nel momento in cui la rete IP è in grado di differenziare il servizio fornito a

diverse tipologie di traffico, il passaggio ad unarete multiservizio è breve. Per
rete multiservizio si intente una infrastruttura di rete che è in grado di veicolare
su di essa servizi diversi. Il più comune esempio di rete multiservizio è la rete
telefonica classica, che è in grado di veicolare le telefonate, il traffico Internet,
ma anche il traffico di servizi diversi quali i POS (Point of Sale, punti di vendita
con pagamento in forma elettronica, ad esempio PagoBancomat), e altri. Il
termine multiservizio esprime il concetto che, su una stessa infrastruttura di
rete, vengano veicolati servizi diversi (o, almeno, coì sono percepiti dagli utenti
finali). Infatti, pur presentando le stesse caratteristiche tecniche viste in
precedenza per la rete multiservizio, un applicativo di navigazione web e uno di
video streaming non vengono visti come servizi diversi in quanto il loro traffico
viene generato da uno stesso apparato (il PC) e quindi il servizio percepito
dall'utente è un omnicomprensivo "accesso Internet".
La rete IP può quindi trasformarsi in una rete multiservizio dove il cuore

della rete è unico (tutto il traffico è IP), mentre la periferia è ancora distinta a
seconda del servizio: troveremo quindi PC con le varie applicazioni, telefoni,
POS, e altro ancora.
Vi sono alcuni motivi che stanno frenando la

migrazione da una tecnologia di trasporto di tipo
telefonico ad una di tipo dati:
largo numero di persone (soprattutto negli

operatori telefonici) che conoscono bene la
tecnologia telefonica ma non quella dati;
un passaggio di tecnologia impica uno
sforzo non indifferente di riconversione del
personale
larga base installata (valido soprattutto
negli operatori telefonici che forniscono il
servizio da molto tempo); il passaggio alla
VoIP richiede la sostituzione di una
tecnologia già in campo e, soprattutto,
decisamente collaudata, a fronte di una
tecnologia nuova ma che potrebbe anche
riservare sorprese; d'altro canto, perchè
sostenere una nuova spesa (la rete in
tecnologia dati) quando la precedente tecnologia è in piedi e funziona
benissimo?

Voce su IP Page 7
il conto della "convenienza" di una tecnologia rispetto all'altra non si fa sui

"volumi di traffico" (aspetto sicuramente a favore dei dati), ma sul profitto
che questi generano; questo parametro è ancora tutt'ora a favore del
traffico telefonico.
il passaggio ad una tecnologia di trasporto di tipo dati implica un salto nel
buio: mentre la tecnologia telefonica è sufficientemente assestata, quella
dati (per reti multiservizio) è solo agli inizi, e possono verificarsi problemi
con la sua adozione su larga scala
Queste problematiche fanno sì che gli operatori telefonici tradizionali siano

più lenti al passaggio verso una tecnologia totalmente dati, mentre nuovi
operatori, che non hanno nulla da perdere e devono affermarsi sul mercato,
siano più propensi ad una tecnologia di tipo dati prevalentemente per ragioni
economiche.
1.1.2.2.2. Esempio di rete ToIP
Nella visione degli operatori telefonici, quindi,

la tecnologia VoIP è delegata al trasporto di fonia
sul proprio backbone, in sostituzione (o spesso
affiancamento) delle tecnologie esistenti. Al
momento vi sono ben pochi tentativi seri di
conversione integrale di preesistenti reti
telefoniche verso la tecnologia IP.
Il modello di adozione di VoIP da parte dei

carrier prevede quindi (come si vede in figura) la
definizione di reti di accesso in tecnologia
telefonica per il collegamento di terminali di tipo
tradizionale e in tecnologia IP per il collegamento
di elaboratori. Mentre la seconda tipologia di rete
di accesso è già nativamente IP e non necessita
di alcuna conversione, il traffico raccolto dalla
rete telefonica viene pacchettizzato da un
opportuno gateway ed immesso nella rete IP. Il
posizionamento del gateway può essere più o
meno vicino alla sorgente del traffico a seconda delle preferenze dell'operatore.
Un gateway molto vicino alla sorgente implica un trasporto di traffico IP più
esteso, ma implica anche un numero di gateway più elevato; per questo motivo
la tendenza è quella di inserire i gateway (almeno inizialmente) in una posizione
tale da utilizzare la tecnologia VoIP solo tra le grosse centrali telefoniche
(normalmente poche decine su un territorio nazionale).
Uno dei primi prodotti commerciali per realizzare questa infrastruttura è

datato agosto 1996, quando la Vocaltec ha rilasciato la prima versione
dell'Internet Telephony Gateway, finalizzato ad interfacciare la rete PSTN alla
rete IP.
1.1.2.3. La visione "enterprise" della Voce su IP

Voce su IP Page 8
La visione che una azienda ha della tecnologia

VoIP è normalmente più avanzata rispetto alle
visioni precedenti, che vengono fuse ed
armonizzate insieme. Si mantiene pertanto la
centralità del telefono tradizionale, ma si
riconosce che l'adozione di questa tecnologia non
porta gli sperati vantaggi se non viene unita ad
altre tecnologie proprie del mondo dei Personal
Computer.
La visione enterprise della VoIP si focalizza

pertanto sul fornire all'utente un servizio
migliore, che viene tradotto in due linee portanti:
la personalizzazione del servizio telefonico e la
possibilità di integrare servizi innovativi tipici di
un PC.
Per quanto riguarda la personalizzazione del

servizio telefonico, i sistemi VoIP offrono
normalmente all'utente un'interfaccia web tramile la quale è possibile variare
dinamicamente parametri quali l'inotro delle chiamate (ad esempio, al mattino le
chiamate telefoniche vengono terminate sul telefono VoIP dell'ufficio, al
pomeriggio sul telefono cellulare, alla sera sul numero di casa) anche in base a
differenti parametri (giorno/ora di ricevimento della chiamata, identità del
chiamante, etc), la visualizzazione del traffico effettuato, le chiamate perse, etc.
Per quanto riguarda l'ntegrazione di servizi

innovativi, sono sicuramente importanti le
videochiamate, la condivisione di applicazioni, il
trasferimento di files, ma probabilmente
l'applicativo più importante è l'integrazione con
sistemi di e-presence. Questi sistemi (spesso
conosciuti come "instant messaging", dalla loro
funzione principale) permettono di mantenere
una lista di contatti e visualizzare, in ogni
momento, lo stato del contatto stesso (online,
online ma occupato, impegnato in una riunione,
etc). Questo permette di conoscere
immediatamente la disponibilità o meno di una
persona. Alla bisogna, l'utente può decidere di
inviare un breve messaggio di testo (l'instant
message, appunto) oppure attivare una chiamata
telefonica, o altro ancora.
Questi motivi fanno sì che nell'ambito

enterprise vi sia una visione più ampia della tecnologia VoIP e che la motivazione
relativa al risparmio economico, tipico della visione degli operatori telefonici, non
sia particolarmente importante. Infatti, anche se spesso l'adozione della
tecnologia VoIP porta ad un leggero risparmio economico (soprattutto su edifici
nuovi grazie all'unificazione del cablaggio e degli apparati attivi), sono i nuovi
servizi a fare la differenza. Questo non esclude l'utilizzo di tecnologie VoIP per
abbattere i costi telefonici (magari tra più sedi della stessa azienda), ma non è il
punto fondamentale.
1.2. Il processo di creazione di un flusso VoIP

In precedenza si è visto i principi della commutazione di circuito e di
pacchetto e la percezione della tecnologia VoIP sia presso un normale utente
consumer sia presso un operatore telefonico. In questa sezione si entrerà più
propriamente ad illustrare le varie fasi necessarie alla generazione e al recapito
di un flusso VoIP e si vedranno i principali parametri da tenere in conto per
garantire la qualità della comunicazione.
1.2.1. La trasmissione di un segnale vocale su rete IP

Voce su IP Page 9
In questa Sezione si esamineranno le varie fasi intermedie necessarie per la

trasmissione di un flusso vocale attraverso una rete IP.
1.2.1.1. Campionamento
Il processo di campionamento è quello che,

data una forma d'onda analogica (quella della
nostra voce) ne procede alla traduzione in
formato digitale. Il campionamento può essere
considerato istantaneo, ossia non introduce
ritardo percettibile nel processo.
Questa operazione ha sostanzialmente due

parametri di funzionamento:
la sensibilità dello strumento, ossia in

quanti bit viene trasformata
l'informazione; maggiore è il numero di bit
utilizzati, più alta è la precisione del
campionamento
il numero di campionamenti al secondo,
che esprime la massima frequenza di un
segnale analogico che potrà essere
ricostruito dall'apparato ricevente a partire
dai segnali generati; questo parametro è importante per aumentare la
risposta in frequenza, ma va tenuto conto che l'orecchio umano non è
particolarmente sensibile a determinati range di frequenza.
La banda utilizzata da un segnale campionato è dato dal prodotto tra le due

grandezze precedenti.
Il campionamento viene fatto direttamente dal telefono nel caso di

apparecchi digitali (ad esempio i telefonici ISDN) oppure da un apparato nella più
vicina centrale dell'operatore telefonico nel caso di tradizionali apparecchi
analogici.
1.2.1.2. Codifica
Spesso la codifica è confusa all'interno del processo di campionamento.
La procedura di codifica parte dai risultati

digitali "grezzi", prodotti dal processo di
campionamento, e li elabora per ottenere un
risultato "migliore", che normalmente equivale
ad abbassare il bitrate (la banda) del dato
campionato (compressione). Ci possono essere
più tecniche di codifica; tra le più note possiamo
citare:
codifica per differenze: se il campione

successivo differisce di poco rispetto al
campione precedente, se ne trasmette la
differenze (che richiede un numero di bit
inferiore) rispetto al campione originario
(tecnica utilizzata ad esempio dai codec
della famiglia ADPCM)
codifica pesata: se determinati campioni
sono spesso presente all'interno del flusso
vocale, si adotta una convenzione che li
codifichi con un numero di bit inferiore, in modo da risparmiare banda
(tecnica utilizzata ad esempio dalla compressione di files di tipo ZIP)
codifica a perdita: si basa sul principio che, per l'orecchio umano,
determinati segnali audio vengono praticamente ignorati. Questo tipo di

Voce su IP Page 10
codifica fa sì che questi tipi di segnali vengano cancellati, e la codifica

risultante diventi più snella grazie al fatto che ci sono meno dati da inviare
(tecnica utilizzata nella compressione di audio MP3)
Ovviamente queste tecniche possono anche essere combinate insieme nel

medesimo codificatore.
Con queste tecniche si possono ottenere

compressioni del segnale notevoli (si pensi al
formato MP3 a 96kbps, che ha una qualità audio
molto parente dei quella di un CD audio che ha
un bitrate di circa 600kbps), ma richiedono
normalmente una potenza elaborativa non
indifferente; inoltre, in particolare la codifica per
differenze, può richiedere la presenza di un
campione successivo per poter inviare il dato
attuale. Un tipico esempio è la codifica video
utilizzata in MPEG che adotta una codifica
differenziali sia rispetto alla trama precedente
che rispetto a quella successiva.
Non è sempre vero quindi che una codifica a

più basso bit rate sia intrinsecamente peggiore di
una a più alto bit rate: la differenza viene fatta
spesso dall'algoritmo. Non è quindi infrequente
trovare degli ottimi codificatori ad un bit rate
molto basso che lavorano in maniera molto simile al codificatore PCM64,
standard della rete telefonica. E' vero invece che un'algoritmo particolarmente
ottimizzato per la voce può trovarsi in grande difficoltà verso altri segnali vocali
(ad esempio la musica classica): algoritmi aggressivi si basano su determinati
principi (ad esempio che la voce umana non genera determinati tipi di
frequenze) che possono essere disattesi in caso di sorgenti di tipo diverso.
In generale, la fase di codifica introduce il problema della potenza

elaborativa necessaria a portarla a termine, che può diventare un ostacolo per la
VoIP in quanto potrebbe significare l'adozione di una CPU adeguatamente
potente (o di un chip DSP) a bordo di ogni singolo terminale (telefono). Inoltre,
determinati tipi di codifica (in particolar modo quella a perdita) suppongono che il
ricevitore ultimo dei dati sia l'orecchio umano: se così non è (ad esempio il
ricevitore è un modem analogico) la codifica a perdita può non essere applicabile
in quanto eliminerebbe informazioni che sono invece vitali per la comunicazione.
A causa delle limitazioni precedenti (potenza

elaborativa e inferiore contenuto informativo),
spesso le reti VoIP non implementano
l'operazione di codifica così come descritta in
questa sezione, limitandosi a generare i campioni
in maniera opportuna con il classico codec PCM64
e ad inviarli alla destinazione senza elaborazione
intermedia. Spesso, l'unica elaborazione fatta è
un'eventuale soppressione dei silenzi, che non
genera problemi anche se la sorgente non è di
tipo vocale. La mancata adozione di un algoritmo
di codifica evoluto fa sì che si vanifichi uno degli
aspetti interessanti della VoIP, ossia la possibilità
di abbassare il bit rate.
La scelta del codec non dipende dunque

esclusivamente dai quattro fattori "tecnici" (la
complessità di elaborazione, il ritardo introdotto,
la banda richiesta e la qualità del segnale
prodotto), ma anche da considerazioni di tipo logistico (l'aggornamento dei
terminali piuttosto che la potenza elaborativa richiesta nei gateway VoIP) e di
tipo commerciale (garantire il servizio "dati" sulla rete telefonica).
1.2.1.2.1. Codificatori per VoIP

Voce su IP Page 11
Esistono diversi tipi di codec, caratterizzati da

complessità differenti. Nel decidere quale
utilizzare all'interno di una rete VoIP, è
importante tenere conto di tutte le caratteristiche
e, in particolare, dell'occupazione di banda, del
ritardo introdotto dalla codifica (e decodifica del
segnale) e la qualità della voce riprodotta sul
sistema ricevente.
La principale codifica utilizzata per il

trasporto della telefonia su linee digitali (come
ISDN) è il PCM, descritto nella Raccomandazione
ITU-T G.711, che produce un flusso di 64 kbps.
Questa codifica è molto semplice e diffusa, per i
motivi detti in precedenza, soprattutto tra i
carrier.
Per cercare di utilizzare al meglio la banda a

disposizione, sono state esaminate a fondo le
caratteristiche della voce; il primo passo è quello di sfruttare la forte correlazione
presente in una serie di campioni in sequenza: su questo principio si basano i
codec ADPCM (Adaptivte Differential PCM). Grazie a questa caratteristica della
voce, l'ADPCM invia, dopo un campione completo, una serie di valori differenziali
che descrivono i successivi cambiamenti. Normalmente, la tecnica ADPCM è
utilizzata alla velocità di 32 kbps, ma può servire per produrre flussi voce anche
a 24 e 16 kbps, con un' accettabile perdita di fedeltà; questa categoria di codec,
in genere, è descritta dalla Raccomandazione ITU-T G.726.
Un impiego ancora migliore della banda passante è reso possibile dallo

sviluppo della codifica Codebook Excited Linear Predictive (CELP), che si basa su
un modello matematico della voce umana. Il trasmettitore analizza il flusso del
parlato confrontandolo con una serie di modelli e quindi, per ciascun componente
della voce, invia un codice corrispondente al modello appropriato, insieme ad
alcune informazioni per identificare le variazioni della voce reale rispetto a tale
modello. Il ricevitore combina il modello vocale con queste informazioni e
sintetizza il flusso del parlato.
Un buon codec CELP può produrre una qualità del tutto analoga a quella di
un flusso PCM a 64 kbps, però impiegando 16 kbps. In aggiunta, può utilizzare
una banda ancora inferiore, producendo un suono artificiale. I codec CELP di tipo
base usati nelle applicazioni VoIP, detti anche Low Delay CELP o LD CELP, sono
identificati dalla sigla ITU G.728.
Esistono anche sistemi più complessi come il G.729 (Conjugate Structure

Algebraic CELP abbreviato con CS ACELP), che eseguono un'analisi più
approfondita del flusso del parlato prima di codificarlo: la qualità che si ottiene è
equivalente a LD-CELP impiegando una banda circa dimezzata, ma il ritardo
introdotto è doppio.
Lo standard che offre la più elevata compressione, mantenendo una buona

qualità della voce, è il DR SCS (Dual Rate Speech Coding Standard) o G.723.
Può scendere fino alla velocità di 5,3 kbps e si trova comunemente su sistemi
per videoconferenza su linee analogiche.
Stante i limiti sulla scelta dei codec visti in precedenza, questi codificatori
molto aggressivi sono utilizzati prevalentemente nel caso di interazione PC-to-
PC, dove non sono presenti le limitazioni di cui sopra.
1.2.1.2.2. Soppressione dei silenzi
Una tecnica che è spesso abilitata nei codec VoIP è la soppressione dei
silenzi. Questa si basa su due semplici osservazioni:

Voce su IP Page 12
la maggior parte delle conversazioni telefoniche avviene in una modalità

half duplex: solo uno dei due interlocutori parla, mentre l'altro ascolta; di
conseguenza uno dei due canali (andata e ritorno) è normalmente inattivo
la velocità con cui una persona emette dei suoni (cioè "parla") è
decisamente limitata rispetto alle velocità degli elaboratori e ai tempi
scelti per la pacchettizzazione. Il tempo tra due parole può quindi essere
visto come un istante di silenzio la cui durata, per un calcolatore, può
essere significativa.
Nel caso in cui un codec sia in grado di gestire la soppressione dei silenzi, i
pacchetti vocali (inutili, a questo punto) non verranno trasmessi.
Questa tecnica, per quanto sia utile per ridurre la banda impiegata in una
comunicazione, introduce due problemi non indifferenti.
Il primo problema è dovuto al fatto che gli utenti telefonici sono abituati ad
ascoltare in sottofondo alla comunicazione una sorta di rumore bianco, il
cosiddetto "fruscio di fondo". Si è però verificato come l'assoluto silenzio della
cornetta disturbi la persona umana, che è portata a pensare che la
comunicazione sia stata abbattuta.. Per ovviare a questo primo problema, spesso
il ricevitore genera autonomamente un fruscio che rende più confortevole la
conversazione: il fruscio viene percepito dagli interlocutori come segnale che la
connessione tra i due è ancora attiva.
Il secondo problema deriva dal fatto che non è immediato, per un

codificatore, riconoscere che un utente ha iniziato a parlare. Tendenzialmente,
questa operazione richiede un intervallo temporale che può essere più o meno
elevato a seconda della bontà dell'apparato e della potenza elaborativa a
disposizione. In alcuni casi il tempo di riconoscimento del parlato è così elevato
che, a riconoscimento avvenuto, il campione è ormai vecchio e la sua
trasmissione risulterebbe inutile in quanto arriverebbe a destinazione fuori tempo
massimo. In questo caso si verifica che la prima parte (ad esempio la prima
sillaba) di una frase viene sistematicamente persa.
1.2.1.2.3. Cancellazione dell'eco
Dal momento che in una telefonata è

necessario sia ascoltare la voce che arriva dalla
controparte, sia parlare a nostra volta, è spesso
difficile evitare che la voce in arrivo non venga a
sua volta captata dal microfono e ritornata
(attenuata) al mittente. Il problema può essere
ridotto utilizzando gli auricolari accoppiati ad un
microfono vicino alla bocca: questo è possibile (e
consigliato) nell'interazione PC-to-PC, ma è
chiaramente improponibile nel caso di cornetta
telefonica.
Se il percorso complessivo richiede meno di

una manciata di millisecondi (10 è un valore
ragionevole), non ci sono particolari problemi in
quanto poiché la riflessione è percepita come
parte normale del discorso del parlante. Con un
ritardo maggiore, invece, si generano problemi;
di solito la persona che parla sente le proprie
parole riflesse e si ferma per cercare di capirle. Dal momento che il ritardo
complessivo nei sistemi VoIP può facilmente superare i 200 ms, diventa
necessario sopprimere l'eco.
Questo può essere fatto nel sistema d'elaborazione digitale dell'audio, come
parte del processo di elaborazione eseguito dal codec: il sistema campiona il
segnale di ritorno e sottrae qualsiasi replica dei segnali già inviati: l'efficienza
raggiunta è alta, ma la potenza elaborativa aumenta ed è possibile che si
introducano ulteriori ritardi.

Voce su IP Page 13
1.2.1.3. Pacchettizzazione
Mentre le precedenti operazioni

(campionamento e codifica) possono trovare
parzialmente impiego anche su una rete
telefonico di tipo digitale, l'operazione di
pacchettizzazione è peculiare delle reti a
pacchetto. Un pacchetto, per sua natura, è
composto da una serie di headers necessari
affinchè il pacchetto possa correttamente
giungere alla destinazione. Questi headers non
sono eliminabili, il che comporta che debbano
essere presenti sia nel caso in cui ci sia un solo
byte di dato da trasportare, sia nel caso in cui ce
ne siano molti.
Nel caso della voce su IP, il tipico header ha

una dimensione di 58 bytes (18 bytes Ethernet,
20 bytes IP, 8 bytes UDP, 12 bytes RTP): se, per
ogni pacchetto, si trasportasse un solo byte di
dato, l'efficienza diventerebbe pari al circa
all'1.7%, che equivale a dire che un flusso voce a 64kbps genererebbe un traffico
di 3.7Mbps. Questo è chiaramente una cosa improponibile,
Essendo questa una cosa improponibile, l'unica soluzione per abbattere il

costo (fisso) dell'header è quella di inserire più campioni nello stesso pacchetto.
Ad esempio, inserendo 58 campioni da 1 bytes l'uno si ottiene un'efficienza del
50%, con un'occupazione di banda di 128kbps. Purtroppo, però, non è possibile
fare il pacchetto grande a piacere, in quanto si aumenterebbe a dismisura il
ritardo con cui il pacchetto viene recapitato.
Per capire questo problema si supponga, ad esempio, di generare un

campione (grosso 1 byte) al secondo e che il tempo necessario a recapitare il
dato a destinazione (ossia il ritardo di trasmissione del campione sul filo) sia di 5
secondi. E' evidente come il destinatario della comunicazione, nel caso in ogni
pacchetto contenga un solo campione, riceverà i dati con un ritardo di 5 secondi.
Si supponga ora di trasportare la voce inserendo 10 campioni nello stesso
pacchetto prima di farlo partire. Il ritardo con cui l'ascoltatore riceverà i dati sarà
ora di 15 secondi: 10 necessari a riempire il pacchetto con 10 campioni, quindi
altri 5 per recapitare il pacchetto a destinazione. L'esempio precedente porta a
concludere come il numero di campioni per ogni pacchetto non sia una
grandezza che può essere decisa liberamente, in quanto all'aumentare del
numero di campioni aumenterà linearmente anche il ritardo con cui questi dati
verranno recapitati a destinazione, rendendo problematica l'interazione in tempo
reale di due persone.
Valori di ritardo di pacchettizzazione ragionevoli sono dell'ordine dei 20-

40ms.
1.2.1.4. Trasmissione del pacchetto sulla rete dati
La trasmissione dei pacchetti su una rete a commutazione di pacchetto va

incontro a delle incertezze maggiori rispetto alla trasmissione in modalità di
commutazione di circuito. Fatto salvo il tempo di propagazione (ossia il tempo
necessario affinchè il segnale si propaghi in un mezzo fisico, che è la massima
velocità a cui possono viaggiare i dati in un mezzo fisico e pari solitamente ai due
terzi della velocità della luce), che è un fattore da tenere in conto anche nella
tecnologia a circuito, esistono altri due fattori che possono rallentare il
proseguimento del pacchetto verso la destinazione.
1.2.1.4.1. Problematiche di accodamento

Voce su IP Page 14
Il fenomeno dell'accodamento avviene nei nodi

interni della rete dati qualora la somma del
traffico in ingresso, e diretta verso uno stesso
link in uscita, è maggiore della capacità del link.
In questo caso una parte del traffico verrà
memorizzato internamente al router e verrà
smaltito con gradualità, non appena il link in
esame è in grado di inviare un nuovo pacchetto.
Questo fenomeno, chiamato anchebuffering,

provoca un ulteriore ritardo di consegna del
pacchetto in quanto il pacchetto può fermarsi per
un periodo di tempo arbitrariamente lungo
all'interno del nodo di rete. Questo fenomeno
non è presente nelle reti telefoniche in quanto,
grazie alla fase di instaurazione del circuito (call
setup), i nodi intermedi sulla rete accettano la
chiamata solamente nel momento in cui possono
garantire che non esisteranno mai situazioni
come quella in esame (ossia il traffico in ingresso è maggiore della capacità di
smaltimento del link.
Il problema dell'accodamento può essere risolto in due modi:
adottando anche sulle reti IP un meccanismo di call setup, tale per cui la
situazione precedente è evitata grazie ad un meccanismo di prenotazione
delle risorse
adottando un sistema che ovvi parzialmente il problema dell'accodamento,
almeno per il traffico vocale; è ad esempio il caso di accodamento a
priorità (o priority scheduling).
Il priority scheduling non è altro che l'idea di creare all'interno di un router,

due percorsi di smaltimento dei dati; uno ad alta priorità, l'altro a priorità
standard. Nel momento in cui un pacchetto entra nel router, questo controlla la
tipologia del pacchetto e lo inserisce in uno dei due percorsi (o code). In altre
parole, tutti i pacchetti vocali finiranno insieme nella stessa coda, mentre tutti i
pacchetti dati finiranno nell'altra. L'accortezza sta nel trasmettere sempre, per
primi, i pacchetti che stanno nella coda ad alta priorità, indipendentemente dal
numero di pacchetti nell'altra coda. Questo significa che se i pacchetti vocali (ad
alta priorità) sono pochi rispetto alla totalità del traffico, questi troveranno
sempre la coda ad alta priorità libera e quindi saranno trasmessi
immediatamente.
Questo sistema non è deterministico, ossia non si garantisce che la coda ad

alta priorità sia sempre libera. Tuttavia, se la rete è ben progettata, con
ragionevole certezza i pacchetti voce verranno inoltrati molto velocemente
indipendentemente dal traffico effettivamente scorrente sulla rete.
La soluzione del priority scheduling non è certamente l'unica in questo filone;

tuttavia è molto utilizzata grazie alla sua semplicità.
1.2.1.4.2. Problematiche di trasmissione

Voce su IP Page 15
Il sistema di priority sceduling illustrato nel punto

precedente non permette ancora di risolvere tutti
i problemi. Si supponga infatti, che in router, in
mancanza di pacchetti ad alta priorità, inizi la
trasmissione di un pacchetto normale. Se, un
istante immediatamente successivo, arrivasse nel
router un pacchetto ad alta priorità, questo è
obbligato ad attendere la trasmissione del
pacchetto precedente prima di poter essere
immesso sul canale.
In altre parole, il priority queuing permette di

passare davanti a tutti i pacchetti in coda tranne,
normalmente, uno: quello attualmente in
trasmissione. Questo fenomeno introduce un
nuovo ritardo, anche questo non presente nella
commutazione di circuito, inversamente
proporzionale alla velocità del link in uscita: più il
collegamento è lento, più il tempo di attesa
diventa potenzialmente alto.
Inoltre, anche il pacchetto ad alta priorità necessita di un tempo finito per

essere immesso sul canale, con le stesse modalità del caso precedente. In altre
parole, il ritardo a cui va incontro ogni pacchetto è dato dalla somma del proprio
ritardo di trasmissione e da quello del pacchetto immediatamente precedente ad
esso. Questo è dovuto al meccanismostore and forward proprio dei router;
questo fenomeno non esiste se si implementa una tecnica di commutazione di
tipo cut through, normalmente non impiegata a causa della notevole
complessità, che è tuttavia la tecnica adottata dalla commutazione di circuito.
1.2.1.5. De-jitter
Non essendo predicibile a priori il ritardo

subito da ogni pacchetto nella rete, i pacchetti
arriveranno a destinazione con degli intervalli di
tempo variabili tra di essi. In altre parole, i
pacchetti non arriveranno equispaziati, ma la
differenza tra i tempi di arrivo di due qualunque
pacchetti consecutivi sarà un numero variabile. Il
jitter è una grandezza che rappresenta
esattamente questo fenomeno: il jitter è nullo
esclusivamente nel caso in cui i pacchetti arrivino
equispaziati.
Il jitter è un problema sui pacchetti vocali, in

quanto non permette la riproduzione fedele del
flusso audio. In altre parole, se i pacchetti sono
stati generati dalla sorgente con un intervallo di
tempo di 40ms tra uno e il successivo, la loro
riproduzione dovrà rispettare il medesimo
intervallo di tempo.
La soluzione al problema del jitter si trova inserendo i pacchetti all'interno di

una coda (ad esempio nel dispositivo di ricezione) ed estraendoli a ritmo
costante. La dimensione della coda dipende dal massimo jitter che può essere
inserito dalla rete o, in alternativa, al massimo intervallo di tempo che si è
disposti ad aspettare sul ricevitore, passato il quale il pacchetto viene
considerato perso, anche nel caso di suo arrivo tardivo.
1.2.1.6. Riordinamento dei pacchetti

Voce su IP Page 16
Nonostante non sia un fenomeno altamente

diffuso, esistono numerosi casi in cui la rete IP
procede ad un riordinamento dei pacchetti, vale a
dire che alcuni pacchetti, pur essendo stati
generati dopo di altri, vengono in realtà
consegnati per primi alla destinazione. Questo è
chiaramente un problema per i campioni vocali,
in quanto la loro riproduzione deve avvenire
strettamente nell'ordine con il quale sono stati
generati.
La soluzione al fenomeno è praticamente

identica al blocco de-jitter: i pacchetti vengono
inseriti in una coda (normalmente nello stesso
dispositivo di ricezione) e riordinati prima di
passarli all'utilizzatore finale. Valgono le stesse
considerazioni fatte per il blocco de-jitter in
relazione al dimensionamento della coda stessa.
In effetti, de-jitter e riordinamento sono
fenomeni che, spesso, vengono trattati dal medesimo blocco.
1.2.1.7. Decodifica
Il blocco di decodifica è quello che, partendo

dai pacchetti contenenti i campioni vocali,
procede alla loro trasformazione in un flusso
analogico, effettuando un lavoro speculare
rispetto ai blocchi di codifica e campionamento.
L'unica particolarità del blocco di decodifica è

la necessità di rimpiazzare eventuali pacchetti
mancanti nel flusso vocale in maniera da rendere
più possibile confortevole l'ascolto del flusso
vocale. Le soluzioni sono molteplici:
ripetizione dei campioni contenuti nel

pacchetto precedente
tecniche predittive, miranti a generare un
insieme di campioni "plausibili" partendo
da quelli già in possesso del ricevitore
generazione di silenzio (rumore bianco)
Anche in questo caso, le tecniche possono essere combinate insieme per

l'ottenimento di un risultato migliore.
Il ritardo di decodifica è normalmente abbastanza basso, tranne nel caso in

cui il campione attuale dipenda anche da quelli che arriveranno successivamente
(con una tecnica identica a quella già evidenziata per i codec). Normalmente la
decodifica richiede meno risorse computazionali, in quanto deve applicare un
algoritmo predefinito. La fase di codifica può invece essere più onerosa in quanto
spesso sono disponibili più tecniche di compressione e il codificatore deve
decidere, in tempo reale, quale adottare per ottenere i risultati migliori.
1.2.1.7.1. Tecniche di correzione dell'errore

Voce su IP Page 17
Alcuni tipi di codifiche vocali prevedono

esplicitamente la perdita di pacchetti e quindi il
codec si comporta in maniera da ovviare, ove
possibile al problema. Esistono molte tecniche
utilizzate, anche se sono tutte basate sul
principio della ridondanza.
Alcuni codec, ad esempio, prevedono la

codifica del campione N con 2 bit rate diversi: il
primo, a più alta qualità, è inserito nel pacchetto
corrente, mentre il secondo, a qualità (e bit rate)
ridotta, è inserito nel pacchetto successivo. Nel
caso di perdita del pacchetto corrente è possibile
comuque generare un segnale vocale a partire
dalla codifica degradata.
Queste tecniche inseriscono però alcune

problematiche:
si ha aumento di banda per portare il campione degradato

generalmente non coprono il caso di perdite "burst" di pacchetti (ossia
quando si perdono più pacchetti consecutivi)
generalmente richiedono un ritardo più stringente, in quanto è necessario
aspettare il pacchetto successivo (che deve, ovviamente, essere arrivato
nel tempo prefissato) per poter generare il segnale vocale
Spesso, quindi, queste tecniche non vengono utilizzate in pratica in quanto si

sfrutta la capacità di recupero dell'errore propria dell'orecchio umano.
1.2.2. Parametri caratteristici di una sessione vocale
Nel progetto di una rete VoIP è necessario tenere in considerazione i

seguenti parametri: banda, percentuale di pacchetti persi, ritardo.
1.2.2.1. Ritardo
Il parametro sicuramente più importante è il

ritardo. Come ritardo end-to-end si definisce il
lasso di tempo che trascorre tra la ricezione di
un'onda analogica da parte del campionatore alla
sua rigenerazione da parte del ricevitore.
Normalmente, si preferisce però parlare di ritardo
end-to-end riferito alla rete, che corrisponde al
tempo da quando il pacchetto viene ricevuto dal
pacchettizzatore a quando viene consegnato al
codificatore.
Dal punto di vista dell'interazione vocale,

però, il ritardo end-to-end è poco significativo ed
è necessario considerare quindi il round-trip
delay, ossia il ritardo di andata e ritorno. Infatti,
non è tanto importante il tempo necessario ad un
segnale per essere trasferito dall'utente A
all'utente B, ma il tempo necessario anche a
portare indietro la risposta ad A.
Questa latenza dipende da vari fattori riguardanti sia le prestazioni degli

end-point (ad esempio il codificare) che le prestazioni della rete.
L' ITU ha definito 3 fasce di ritardo end-to-end:

Voce su IP Page 18
dai 0 ai 150 ms. è accettabile per tutti i tipi di chiamata,
dai 150 ai 400 ms. è accettabile solo per collegamenti intercontinentali,
oltre 400 ms. è inaccettabile per comunicazioni vocali.
Ritardi elevati possono creare alcuni disagi come Talker il Overlap , in cui il
chiamante, che è abituato a ricevere una risposta entro un certo tempo, non
sentendola arrivare a causa degli elevati ritardi, ripete la domanda che si
sovrappone alla risposta che sopraggiunge. Questo può provocare problemi sulla
sincronizzazione degli interlocutori rendendo difficile la comunicazione.
Bisogna quindi evitare che i ritardi end-to-end dei pacchetti voce superino il
limite dei 150 ms. I componenti del ritardo, così come si può estrapolare dalle
varie fasi necessarie a trasferire un flusso VoIP, sono i seguenti:
ritardo di codifica
ritardo di pacchettizzazione
ritardo di accodamento
ritardo di trasmissione
ritardo di de-jitter (e di ordinamento)
ritardo di decodifica
1.2.2.2. Banda
Una caratteristica del traffico vocale è il fatto

di essere anelastico. In altre parole, il traffico
vocale ha la necessità di una certa banda che
deve essere sempre disponibile. Questa
caratteristica lo differenzia profondamente dal
traffico dati tradizionale che è di tipoelastico,
ossia non è particolarmente penalizzato se, in
alcuni istanti di tempo (di durata limitata) i
pacchetti di una determinata sessione vengono
ritardati dalla rete e non giungono a destinazione
se non dopo un certo tempo (ad esempio alcuni
secondi).
In altre parole, il traffico vocale non è in

grado di adattarsi alle condizioni della rete,
adattando il bitrate a seconda della banda
disponibile: una volta definito che una sessione
vocale ha la necessità di, ad esempio, 80kbps,
tale banda deve essere disponibile. In caso
contrario, i pacchetti vocali possono essere tranquillamente scartati.
Questo si ripercuote, ad esempio, nella fase di progetto della rete in quanto è

inutile procedere alla memorizzazione dei pacchetti vocali all'interno dei router
(buffering) in quanto ne si aumenterebbe il ritardo rendendoli inutili. Ad
esempio, nel caso di una rete con meccanismi di scheduling di tipo priority
queuing, le code per i dati possono avere una dimensione decisamente maggiore
rispetto alle code per i pacchetti vocali. Se si riceve un pacchetto vocale e la
coda ad alta priorità è ormai piena, è più conveniente scartarlo in quanto è molto
probabile che al suo arrivo alla destinazione avraà un ritardo troppo elevato.
Questa procedura permette di salvare banda perchè evita la trasmissione del
pacchetto (in ritardo) sulla rete, occupando risorse, quando lo stesso verrà
comuque scartato dal nodo ricevente.

Voce su IP Page 19
Un'altra caratteristica del traffico vocale è che, sebbene la banda richiesta sia
tutto sommato modesta (esistono ottimi codificatori con bit rate di uscita pari a
5.3kbps), questa deve essere disponibile per una maggiore durata temporale.
Infatti, le sessioni dati sono tendenzialmente più corte rispetto ad una sessione
voce.
1.2.2.3. Perdite
A differenza dei dati, l'orecchio umano (o

meglio, il cervello) reagisce bene anche al caso in
cui vi sia la mancanza di alcuni spezzoni di
comunicazione. Solitamente si pone la massima
percentuale tollerabile di pacchetti persi pari al
5% del totale dei pacchetti vocali. Sotto questa
soglia, la qualità per l'orecchio umano è
decisamente accettabile. In fondo, l'esperienza
delle reti mobili con frequenti disturbi insegna
che una percentuale limitata di perdite non è
affatto un problema.
I pacchetti persi sono sia quelli che, per

qualche motivo, vengono scartati all'interno della
rete (ad esempio in caso di congestione), sia i
pacchetti che arrivano oltre una soglia massima.
Infatti, il ritardo end-to-end ha un'importanza
molto maggiore rispetto alle perdite in
riferimento alla qualità della comunicazione
percepita dall'utente. E' quindi decisamente preferibile accettare un numero di
pacchetti persi maggiore rispetto ad imporre un più alto ritardo end-to-end.
Questa considerazione fa sì che, spesso, i componenti di de-jitter e di
riordinamento dei pacchetti vengano dimensionati con "budget di ritardo" molto
ridotti, preferendo quindi scartare paccetti giunti oltre il ritardo massimo
ammesso per non peggiorare le caratteristiche di interattività.
Altre tecniche sono quelle che vanno sotto il nome di layered encoding:
sostanzialmente si codificano le informazioni fondamentali in una trama, e le
informazioni "supplementari" in una successiva. Ad esempio, nel caso della
trasmissione video si potrebbe codificare il quadro video in bianco e nero in una
trama e l'informazione legata al colore in un'altra. Presupposto affinchè tutto
funzioni è che la rete sia in grado di riconoscere l'informazione principale e che
questa venga sempre recapitata a destinazione. In condizioni normali, sia la
trama base che il colore verranno recapitati. In caso di problemi, la rete
riconoscerà (in qualche maniera non meglio specificata e dipendente dalla rete
stessa) i pacchetti meno importanti e inizierà a scartarli.
1.2.3. Il trasporto della voce su IP: il protocollo RTP

Voce su IP Page 20
Il protocollo RTP (Real Time Protocol), definito

nella RFC 1889, riguarda le funzioni al terminale,
sorgente e ricevitore per il trasporto di
comunicazioni con requisiti di tempo-reale, quali
la telefonia o la videoconferenza.
Le funzioni svolte da questo protocollo

comprendono la ricostruzione al ricevitore della
corretta sequenza dei pacchetti e della loro
posizione nella scala dei tempi, consentendo
quindi la ricostruzione dei sincronismi. Questo
protocollo non permette, nativamente, di
sincronizzare più sessioni multimediali tra di loro
in quanto ogni sessione RTP è in grado di
trasportare un solo flusso. Questo non impedisce,
tuttavia, il dialogo tra N soggetti, che è anzi
supportato nativamente attraverso lo
sfruttamento di un'eventuale tecnologia multicast
sulla rete sottostante. Tuttavia in presenza di più
sessioni distinte (ad esempio audio e video) è necessario attivare più sessioni
RTP.
La sincronizzazione tra sessioni diverse è comunque possibile facendo leva

sul timestamp. RTP non fornisce però possibilità evolute quali "quando si arriva
al 5o minuto dell'audio, visualizza la slide successiva". Questo genere di
sincronizzazioni devono essere fatte dall'applicativo.
RTP gestisce anche un'entità chiamataRTP Mixer . Questa entità agisce come
un mixer, appunto, ricevendo le sessioni RTP da più sorgenti e combinandole
insieme in un'unica sorgente virtuale, il mixer, appunto. Questo oggetto è utile
per diminuire il traffico sulla rete in quanto permette di compattare molte
sorgenti in una sola. In questo caso, il pacchetto RTP inserisce gli identificativi
delle sorgenti originarie del pacchetto non nel campo SSRC (che è unico) ma nel
campo CSRC.
RTP fornisce un mezzo per controllare la trasmissione / ricezione dei dati di

tipo real-time, ma non è in alcun modo legato al tipo di codec o al tipo di mezzo
fisico (audio o video). RTP è un protocollo di trasporto che garantisce il recapito
dei pacchetti e la ricostruzione della corretta sequenza temporale, funzionalità
richiesta da qualunque meccanismo di tipo real-time. RTP non specifica però il
formato del payload (ad esempio quanti campioni vocali debbano essere
trasportati in ogni pacchetto RTP) e si limita a trasportare l'informazione di qual
è il payload trasportato, come se fosse un diverso tipo di protocollo.
La specifica delle caratteristiche di

pacchettizzazione, dipendenti dal particolare
codec utilizzato, sono poste in documenti
separati (chiamati audio / video profiles) che
definiscono il codice con cui sono identificati in
RTP (nel campo PT).
RTP non richiede obbligatoriamente

un'infrastruttura IP: può essere potenzialmente
trasportato su qualunque rete in quanto non è
legato ad un particolare formato degli indirizzi.
Richiede, però, che i protocolli di livello inferiore
siano in grado di effettuare la frammentazione e
il riassemblaggio dei pacchetti trasmessi. Nella
maggior parte dei casi RTP si appoggia sui
protocolli UDP/IP di cui sfrutta le operazioni di
multiplazione e (se opportune) di controllo
dell'errore.
La specifica contenuta nella RFC 1889 affianca a RTP il protocollo ausiliario

denominato RTCP (RTP Control Protocol) per monitorare la qualità del servizio,
per fornire informazione sui partecipanti e per il controllo della sessione. Ogni

Voce su IP Page 21
connessione RTP/RTCP è caratterizzata da una porta UDP, per l'RTP si usa una
porta pari, mentre per l'RTCP si usa la porta dispari consecutiva.
A differenza dei principali protocolli di livello applicativo, RTP non riserva

alcuna porta particolare all'interno dell'header UDP. Se questo può essere un
vantaggio dal punto di vista logistico in quanto permette di decidere la porta a
piacere, diventa una grossa limitazione nel momento in cui si voglia privilegiare
il flusso RTP all'interno della rete. Infatti, i router intermedi non hanno la
possibilità di discriminare il traffico real-time sulla base di una porta nota,
complicando notevolmente quindi la possibilità di riconoscimento del flusso
multimediale e rendendo difficoltoso, di fatto, il trattamento preferenziale dello
stesso.
Un problema analogo avviene nel caso di attraversamento di firewall dove,

non essendo disponibili porte note, diventa problematico prevedere su quali porte
avverrà il passaggio della sessione real-time. La soluzione proposta da molti
costruttori è quella di riservare un certo range di porte per il traffico RTP e
configurare gli applicativi ad utilizzare questi valori. Nel caso del firewall non ci
sono altre soluzioni; nel caso della differenziazione del traffico in rete è invece
possibile agire sul campo Traffic Class del pacchetto IP, forzando diversi valori a
seconda che il pacchetto contenga dati oppure traffico real-time.
1.2.3.1. Il formato dell'header
L'header di un pacchetto RTP è composto da

una parte fissa e un'estensione utilizzata per
scopi sperimentali, di cui è in genere sconsigliato
l'uso quando si possono inserire le informazioni
aggiuntive nel payload RTP del pacchetto.
La parte fissa dell'header si articola su 12

byte e contiene i seguenti campi:
V (Version): indica la versione di RTP

utilizzata. La versione contemporanea è la
2.
P (Padding): se il bit vale uno, il pacchetto

contiene almeno un byte addizionale di
riempimento non facenti parte del
payload, l'ultimo byte di padding contiene
il valore di quanti byte padding sono
presenti.
X (extension): se impostato ad uno, indica la presenza di un'estensione

dell'header.
CC (CSRC Count): è il numero di CSRC presenti dopo la parte fissa

dell'header.
M (Marker): l'interpretazione di questo bit è legata al profilo.
PT (Payload Type): identifica il contenuto del pacchetto, nel profilo è

fissata staticamente la corrispondenza tra il codice e il formato del
payload.
Numero di sequenza : è incrementato di uno per ogni pacchetto inviato;

può essere utilizzato dal destinatario per accorgersi della perdita di
pacchetti e per ricostruire l'ordine corretto della sequenza.
Timestamp: riflette l'istante di campionamento del primo ottetto dei dati.

L'istante di campionamento deve essere derivato da un clock che si
incrementa monotonamente e linearmente nel tempo per permettere i
controlli di sincronizzazione e le misure dell'incertezza sugli arrivi dei
pacchetti (arrival jitter).

Voce su IP Page 22
SSRC: identificata la stazione trasmittente.
CSRC: questo campo è opzionale ed è presente solo se un elemento della

rete ha unito in un unico flusso contributi provenienti da diverse sorgenti;
al suo interno sono elencati gli SSRC delle singole stazioni.
In ogni sessione la stazione che genera/riceve traffico RTP acquisisce un

codice univoco, il SSRC, che permette alla stazione stessa di essere
univocamente identificata all'interno della sessione real-time in esame.
1.3. Modello di una rete per VoIP

Prima di addentrarsi nelle varie soluzioni tecnologiche per la VoIP, è
opportuno introdurre un modello concettuale, di validità generale, per la
gestione di una rete VoIP, e orientato in particolar modo alla visione
"professionale" della VoIP.
1.3.1. Gateway tra la rete telefonica e la rete IP
L'interfacciamento tra una rete di tipo

telefonico e una rete IP è resa possibile da un
oggetto apposito, chiamato genericamente
Gateway. Logicamente, questo oggetto può
essere scomposto nei seguenti componenti:
Media Gateway
Signaling Gateway
Gateway Controller
Le Sezioni seguenti presenteranno le

caratteristiche di ognuno di questi componenti.
1.3.1.1. Media Gateway
Questo oggetto si occupa della traduzione dei

dati della sessione VoIP tra la rete telefonica e la
rete IP. In altre parole si occupa della eventuale
codifica dei dati, della loro pacchettizzazione,
eventualmente della soppressione dell'eco,
oppure delle operazioni inverse nel momento in
cui si voglia interfacciare una rete IP ad una rete
telefonica. Si ricordi infatti che, spesso, la rete IP
è utilizzata in sostituzione del backbone
telefonico, ma la periferia della rete (e quindi la
sorgente e la destinazione della telefonata) sono
ancora in tecnologia classica.
In alcuni casi ad esempio quando una delle

parti è un terminale intelligente quale in PC,
parte di queste funzionalità possono essere
inserite nell'end-system.
1.3.1.2. Signaling Gateway

Voce su IP Page 23
Questo componente si occupa

dell'interfacciamento tra reti IP e telefoniche dal
punto di vista della segnalazione. La più comune
procedura di segnalazione è il cosiddetto "call
setup", ossia quella procedura di preparazione
della rete affinchè la telefonata sia possibile e che
inizia con la composizione del numero sul
terminale chiamante e termina quando il
chiamante risponde alla comunicazione. Questo
compito, molto semplice concettualmente, è in
realtà abbastanza complicato a causa della
notevole complessità della segnalazione sulla
rete telefonica.
Le operazioni di segnalazione sono, in realtà

molte: la composizione del numero del chiamato,
l'operazione di sgancio/aggiancio della cornetta,
l'attivazione di un tono di chiamata (lo "squillo"
del telefono), la generazione del tono di libero/
occupato a seconda che la chiamata sia andata o meno a buon fine, etc. A queste
operazioni di base si aggiungono tutte le procedure di segnalazione proprie della
rete intelligente (richiamata su occupato, conversazione a tre, identificativo del
chiamante, e altro) che devono essere gestite anche dalla rete telefonica.
Da questo elenco di funzionalità si può dedurre come Signaling e Media

Gateway non possano essere entità completamente distinte. In altre parole, non
è possibile pensare il Signaling Gateway come il risponsabile della connessione di
controllo e il Media Gateway come il responsabile della connessione dati (audio).
Ad esempio, la generazione del tono di libero corrisponde alla generazione di una
serie di pacchetti audio con determinate caratteristiche, ossia è un segnale che
viene portato all'orecchio dell'utente e che vengono riconosciuti come "dati", non
"controllo".
1.3.1.3. Gateway Controller
Il controller si occupa della supervisione e del

monitoraggio dell'intero gateway; le principali
operazioni svolte sono:
tenere sotto controllo l'ammontare del

traffico (ad esempio, la percentuale di
traffico vocale su un canale IP potrebbe
non dover superare una certa soglia
rispetto all'intera banda disponibile, pena il
degradamento della qualità della
telefonata)
controllare se l'utente ha l'autorizzazione a
fare / ricevere una certa chiamata
controllare le generalità dell'utente (ad
esempio per aver la possibilità di
addebitare, ad ogni utente, una somma
pari al numero di telefonate effettuate)
1.3.2. Gateway in reti omogenee

Voce su IP Page 24
L'impiego di un gateway, contrariamente a

quanto si potrebbe pensare, non è limitato
all'interfacciamento tra la rete IP e la rete
telefonica. Infatti, esistono tutta una serie di
operazioni che, anche su una rete con tecnologia
omogenea (ad esempio una rete completamente
VoIP, compresi gli apparati terminali), devono
comunque essere portate a termine e che non
possono (o non devono) essere incluse nelle
capacità del terminale utente.
Un esempio per tutti è l'autenticazione del

chiamante. Nel caso di una telefonata classica, il
chiamante è univocamente determinato dal
doppino (ossia da un cavo fisico) che arriva nella
centrale. Essendoci una corrispondenza biunivoca
tra i cavi entranti in una centrale telefonica e gli
abbonati da essa servita, il controllo è molto
semplice e la telefonata verrà addebitata senza
problemi alla persona giusta. Si pensi ora alla stessa situazione in ambito IP e si
immagini un'azienda, con la comunissima infrastruttura di rete locale Ethernet,
che dota tutti i suoi dipendenti di un telefono IP. Ora, come è possibile impedire
ad un utente illegale di collegare il suo telefono IP alla LAN aziendale, per mezzo
(magari) di un hub?
E' chiaro come, nel caso VoIP, l'autenticazione dell'utente diventa più
problematica rispetto alla tecnologia classica. Non solo, ma questo genere di
operazioni devono essere fatte da macchine sotto il controllo del gestore della
rete: queste funzioni non possono, ovviamente, essere annegate all'interno del
terminale utente, contrariamente invece a quanto può essere fatto per la
codifica/decodifica della voce (il compito del Media Gateway).
L'esempio precedente illustra solo una delle funzioni che, per varie ragioni,
non devono essere delegate all'utente. Una seconda ragione particolarmente
importante risiede nella complicazione della segnalazione necessaria a poter
effettuare la chiamata all'interno della rete (prenotazione di risorse, etc).
Analogamente al modello utilizzato nel trasferimento dati classico (il principio
dell'instradamento indiretto, o esplicito, del protocollo IP), il terminale utente
dovrebbe preoccuparsi di gestire gli applicativi, ma non di capire come inoltrare i
pacchetti verso la destinazione finale della comunicazione: questo è il compito di
un altro apparato, il default router o gateway, appunto.
Per lo stesso principio, quindi, diventa conveniente far sì che il terminale

utente abbia una serie limitata di funzioni (sostanzialmente quelle relative al
media gateway) e che per altre funzioni più complesse (ad esempio alcune
problematiche di segnalazione, il routing) oppure non di sua pertinenza
(l'autenticazione) ci si rivolga ad un oggetto ad hoc che, per comodità, si indica
ancora come Gateway. Questo non avrà tutte le funzioni descritte nelle Sezioni
precedenti ma solo un sottoinsieme, ossia quelle che non sono state trasferite al
terminale utente.
1.3.3. Le architetture di rete
Esistono più modelli architetturali per la realizzazione di una rete VoIP. Le

seguenti sezioni illustreranno i vari scenari di migrazione, dando per scontato la
progressiva affermazione della tecnologia VoIP sulla tecnologia telefonica.
1.3.3.1. Rete IP come backbone

Voce su IP Page 25
Il primo modello, attualmente quello più in uso

presso i grossi gestori telefonici, prevede il
mantenimento della periferia della rete edge)
( in
tecnologia telefonica, mentre il backbone viene
convertito in tecnologia IP. Il dialogo tra queste
due entità viene fatto attraverso un gateway;
una normale telefonata dovrà quindi essere
convertita due volte, a meno che il chiamato
risieda nella stessa area servita dalla rete
telefonica di accesso del chiamante.
Questo modello segue, nel deployment della

nuova tecnologia, lo stesso modello adottato a
suo tempo per la trasformazione della rete
telefonica da analogica a digitale. La prima zona
interessata dall'aggiornamento fu il backbone in
quanto questo richiedeva la sostituzione di un
numero limitato di apparati: ad esempio, le
centrali telefoniche di transito sono qualche
decina su tutto un territorio nazionale. Con l'affermarsi della tecnologia, la
digitalizzazione (e quindi la VoIP) si è diffusa fino alla periferia fino a giungere,
con l'introduzione dei terminali ISDN, ad una completa digitalizzazione della
rete, terminale utente compreso.
1.3.3.2. Rete mista
Il secondo modello è attualmente adottato da

alcuni gestori telefonici alternativi i quali, non
dispondendo di una preesistente infrastruttura di
tipo telefonico, hanno deciso l'adozione della
tecnologia VoIP fino alla periferia. Un'altra
situazione nella quale si trova un'infrastruttura di
questo tipo è nel caso di un'azienda con una
nuova sede, dove si opta per un'unica
infrastruttura di rete IP sia per il traffico dati che
per il traffico telefonico.
E' interessante notare come una rete VoIP

moderna non prevede normalmente l'utilizzo di
PC come terminali utente di tipo telefonico, in
quanto l'utente si trova maggiormente a suo agio
con un terminale di sembianze "tradizionali". I
nuovi telefoni IP sono pertanto degli oggetti con
una forma simile a quella a cui si è abituati, ma
con un display multifunzione nel quale sono
disponibili una serie di opzioni prima impossibili: la rubrica, alcune pagine web di
consultazione, e altro a discrezione del fornitore dell'azienda. Nel caso di una
classica postazione di lavoro saranno pertanto disponibili sia un PC, che un
telefono, ambedue collegati alla rete aziendale in tecnologia IP.
E' tuttavia impensabile, allo stato attuale, la creazione di una rete globale IP.
Saranno pertanto presenti dei punti di interconnessione tra la rete telefonica (ad
esempio quella dei gestori tradizionali) e la rete IP. Nel caso dell'azienda citata in
precedenza, vi saà un apparato (ad esempio il gateway telefonico) che, da un
lato, gestirà la rete aziendale in tecnologia IP, mentre dall'altro curerà
interfacciamento con la rete telefonica, utilizzata per le telefonate che hanno
come destinazione utenti esterni.
In questa rete è presente un esempio di utilizzo di Gateway anche nel caso

della rete IP: i terminali VoIP si appoggeranno ad esso per una serie di funzioni
non previste all'interno dell'apparato, come si è visto nella sezione
Gateway in
reti omogenee.
1.3.3.3. Rete IP

Voce su IP Page 26
Il passo successivo è sicuramente la

trasformazione di tutti i terminali utente in
tecnologia IP. La rete adotta quindi una
tecnologia omogenea. Tuttavia esiste ancora un
problema, ossia la notevole mole di servizi di
rete intelligente che sono disponibili nella rete
telefonica. Per questi servizi, che si appoggiano a
grossi server e a grosse basi dati), la migrazione
alla tecnologia IP può non essere un'operazione
semplice ed indolore. E' quindi pensabile che,
almeno in un certo lasso di tempo, questi servizi
richiedano ancora un'interfaccia di tipo telefonico
almeno per la segnalazione.
Questo scenario prevede quindi che per

permettere le funzioni di rete intelligente sia
ancora necessario un gateway tra la rete e i
fornitori di questi servizi.
L'ultimo passo è, ovviamente, la completa trasformazione della rete in

tecnologia IP, dove con rete si intendono sia i terminali utente (e di conseguenza
anche il trasporto), sia i servizi della rete intelligente.
1.4. Principali protocolli di segnalazione

La segnalazione per la telefonia su reti IP
deve soddisfare ai seguenti requisiti:
indirizzamento: deve essere in grado di

localizzare il corretto apparato di
terminazione della telefonata; questo non
è un compito banale in quanto con
l'integrazione delle tecnologie è possibile
pensare che la telefonata possa essere
diretta ad un terminale di rete fissa, ad un
terminale mobile, alla segreteria, alla
casella di posta elettronica (o altro ancora)
a seconda delle preferenze (ad esempio in
base all'ora di chiamata) dell'utente
trasporto dei dati : deve essere in grado
di trasportare il segnale vocale dalla
sorgente alla destinazione con qualità
accettabile
sicurezza: il contenuto della telefonata
non deve essere intercettato; essendo le reti IP molto più aperte rispetto
alle reti telefoniche (si pensi alla possibilità di sniffare su una LAN), la
tecnologia deve garantire una certa riservatezza della comunicazione
supporto dei servizi di rete intelligente : è sempre difficile convincere
un utente che, a causa di un aggiornamento tecnologico, non è più
supportato un servizio prima disponibile. Di conseguenza, è necessario
prevedere, sulla rete VoIP, il supporto almeno al medesimo set di servizi
prima disponibili
semplicità e trasparenza : non deve appesantire inutilmente la rete e
deve essere trasparente a livello utente.
La segnalazione è principalmente divisa in due architetture distinte, che però

possono coesistere ma non cooperare (allo stato attuale): lo standard H.323,
proposto dall'ITU (International Telecommunication Union) per sistemi di
comunicazione multimediali a pacchetto, e la proposta SIP (Session Initiation
Protocol), definita in ambito Internet (IETF) e descritta nell'RFC 2543.
Allo stato attuale, la suite di protocolli H.323 è l'unica soluzione standard

adottata dai produttori di dispositivi per telefonia su IP e in generale per
applicazioni multimediali, ed è supportata sia da applicativi PC (ad esempio il

Voce su IP Page 27
Netmeeting di Microsoft), che da dispositivi di rete (router) e da terminali utenti

(IP Phone). La proposta SIP, però, sta incontrando sempre maggiore favore a
causa della sia ottima integrazione con gli altri protocolli della suite TCP/IP
(mentre H.323 nasce per una generica rete a pacchetto) e della sua maggiore
semplicità, sia dal punto di vista del protocollo in sè, sia delle specifiche. Infatti,
H.323 nasce in ambito telefonico dove le specifiche sono estremamente precise e
complete ma anche estremamente complicate; inoltre ingloba, al suo interno,
altri componenti precedentemente definiti dall'ITU, cosa che ne aumentano
notevolmente la complessità.
Nonostante il notevole supporto di H.323, quindi, il mondo si sta orientando

maggiormente verso SIP per tutte le nuove installazioni.

Voce su IP Page 28
Capitolo 2. La suite di protocolli H.323
2.1. Introduzione
La raccomandazione H.323 è orientata alla
definizione di uno standard per comunicazioni
multimediali basate su reti a commutazione di
pacchetto che non prevedono qualità del servizio,
con particolare riferimento alle reti IP. Lo
standard è stato originariamente pensato per
operare su LAN, ma è stato successivamente
adattato anche per l'utilizzo in ambienti WAN.
Le entità H.323 forniscono comunicazioni in

tempo reale di tipo audio, video e dati. Il
supporto dell'audio è obbligatorio, mentre dati e
video sono opzionali.
2.2. Componenti della specifica H.323

Voce su IP Page 29
La specifica H.323 prevede l'esistenza di quattro

oggetti fondamentali:
Terminale: dispositivo di interfacciamento

con gli utenti e può essere un PC o un
apparecchio telefonico; può anche essere
un dispositivo che fornisce
l'interfacciamento verso un telefono
analogico tradizionale
Gateway: è l'elemento necessario per

fornire la connettività tra reti di tipo
diverso. H.323 prevede la possibilità di
interconnettere più tipi di rete: la rete IP,
la rete telefonica tradizionale (GSTN,
General Switched Telephone Network), la
rete ISDN, etc. I gateway si occupano di
procedere alla traduzione sia dei protocolli
di segnalazione che del flusso dati.
Gatekeeper: è l'entità principale della segnalazione H.323. Non sono

obbligatori, ma forniscono la maggior parte dei servizi: la traduzione degli
indirizzi (E.164, alias H.323 e indirizzi IP), instradamento, accounting,
autorizzazione e autenticazione dei terminali e dei gateway, il controllo
della banda.
Multipoint Control Unit (MCU): gestisce le connessioni multipunto per le

conferenze di tre o più terminali.
2.2.1. Multipoint Control Unit
La Multipoint Control Unit è, secondo le

specifiche, l'insieme di due componenti
logicamente distinti:
Multipoint Controller (MC): componente

obbligatorio il cui compito comprende la
negoziazione delle capacità minime tra
tutti i terminali, in modo da poter
assicurare un livello minimo di
comunicazione; inoltre può tenere sotto
controllo le risorse impiegate nel caso di
una comunicazione multicast
Multipoint Processor (MP): componente
facoltativo il cui compito è quello di
procedere ad un eventuale adattamento
del flusso dati in modo da poter fornire un
servizio accettabile per tutti. Tra le
funzionalità ammesse in questo oggetto vi
è la possibilità di mixing / switching dei
flussi video, voce e dati, sotto la supervisione di un MC.
La MCU può trovare impiego nei seguenti scenari:
conferenza tra tre o più persone, in modalità unicast. In questo scenario,

la MCU comunicherà con i vari client in modalità punto-punto
conferenza tra tre o più persone, in modalità mista unicast / multicast: in
questo caso, la MCU diventa l'interfaccia tra i terminali unicast e
multicast; accetterà quindi i flussi unicast, distribuendoli (con la stessa
modalità) agli altri utenti unicast e traducendoli in multicast per il resto
della rete; farà operazioni analoghe alla ricezione di un flusso multicast.
La MCU, come oggetto distinto all'interno della rete, perde ovviamente di

significato nel momento in cui tutti i partecipanti utilizzino comunicazioni
multicast.

Voce su IP Page 30
2.2.2. Zone
Alla base della gestione è definita lazona

come l'insieme di elementi H.323 (gateway,
terminali e MCU) amministrati da uno e solo un
gatekeeper. In una zona devono esistere un solo
gatekeeper (non è prevista quindi la ridondanza)
e almeno un terminale. Il concetto di zona è
completamente indipendente dalla rete
sottostante: può essere semplicemente una LAN
oppure una topologia più complessa.
2.2.3. Formato dei messaggi
H.323, come spesso succede nei protocolli

definiti dall'ITU, utilizza una codifica di messaggi
basata su ASN.1 Questa codifica è tuttavia
estremamente complessa da gestire ed è una
delle critiche a cui è attualmente sottoposto
H.323 nel confronto con SIP. Tale codifica, infatti,
ha la caratteristica di inglobare tutta una serie di
operazioni (quali ad esempio la gestione del byte
ordering, e altro) che, nelle reti IP, devono
essere fatte manualmente. Il prezzo da pagare
per tutto questo è, appunto, una complicazione
maggiore nella fase di scrittura degli applicativi
H.323 e, soprattutto, in fase di debugging per
verificare la causa di un problema.
2.3. Architettura di H.323

I protocolli che fanno parte dello standard
H.323 si dividono in due categorie secondo il
protocollo di trasporto sul quale si appoggiano:
Protocolli che si appoggiano su un canale

connesso e quindi sicuro quale TCP:
H.225 Q.931 costituisce il protocollo

per l'instaurazione e l'abbattimento
di una chiamata attraverso le fasi di
set-up, connect e release.
H.245 è il mezzo di comunicazione

per lo scambio di parametri utili per
lo svolgimento della chiamata,
come ad esempio le informazioni sui
media utilizzati.

Voce su IP Page 31
Protocolli che si appoggiano su un canale non connesso e quindi

inaffidabile come UDP
RTP fornisce le funzionalità di trasporto end-to-end per applicazioni

multimediali in tempo reale.
RTCP il canale di controllo di RTP utile per monitorare la sessione, la

qualità del servizio e l'identità dei partecipanti.
H.225 RAS Registration Admission and Status protocol fornisce il

canale di comunicazione con il gatekeeper.
2.3.1. Architettura di un terminale H.323
Tutti i terminali H.323 devono possedere un

sistema di controllo, un livello H.225,
un'interfaccia di rete e un'unità di codifica audio.
2.3.1.1. Componenti non coperti dalle specifiche
La raccomandazione H.323 non specifica le caratteristiche dei seguenti

componenti:
Dispositivi audio: sovrintendono alla cattura e alla riproduzione di flussi

audio
Dispositivi video: sovrintendono alla cattura e allla riproduzione di flussi

video
Dispositivi dati: sovrintendono all'interazione di applicazioni dati (ad

esempio la lavagna condivisa) attraverso i protocollo H.323
Interfaccia utente: sovrintende alla visualizzazione dei flussi audio, video

e dati
Interfaccia di rete: è il componente che gestisce l'interfaccia con la rete,

per la trasmissione e ricezione di pacchetti IP
Interfaccia utente di controllo: sovrintende all'interazione tra l'utente e

l'applicativo per la gestione delle informazioni di controlo (apertura /
abbattimento chiamate, etc)
E' però evidente come questi componenti debbano essere presenti (tranne
nel caso del dispositivo video e di quello dati, che sono opzionali) affinchè il
terminale possa operare. Quindi, anche se non vengono coperti dalle specifiche,
devono obbligatoriamente essere presenti.

Voce su IP Page 32
2.3.1.2. Audio e video codec
Per quanto riguarda le specifiche audio, vengono previste le cinque codifiche

maggiori (G.711, G.722, G.723, G.728, G.729), di cui la prima obbligatoria
mentre le altre facoltative.
Per quanto riguarda le specifiche video, il terminale, se vuole instaurare una

comunicazione video, deve essere capace di codificare e decodificare le immagini
secondo le specifiche H.261 o H.263.
I flussi audio e video sono imbustati in pacchetti RTP e gestiti da coppie di

socket UDP, secondo il normale modo operativo di questo protocollo.
2.3.1.3. Receive Path Delay
L'audio e il video codec è integrato da un blocco denominato Receive Path

Delay, il cui compito è quello di de-jitting in modo da consentire sia l'ottenimento
di un flusso regolare, che la sincronizzazione tra i vari flussi della stessa
sessione.
2.3.1.4. Livello H.225
Mentre i canali logici di tipo video, audio, dati

e controllo sono instaurati in accordo con le
procedure specificate nella raccomandazione
H.245, il livello H.225 realizza la formattazione
dei canali logici. In altre parole, è il responsabile
della gestione della trasmissione / ricezione dei
pacchetti, creando un canale di comunicazione
tra le due parti (terminale - terminale, ad
esempio), e ricavando al suo interno una serie di
canali logici per le varie esigenze (canali di
controllo, etc).
Ad ogni canale viene associato un numero di

canale logico (LCN-Logical channel Number)
arbitrario tra 0 e 65535 e una massima larghezza
di banda in base alle caratteristiche del
trasmettitore e del ricevitore; il canale '0' è però
riservato al canale di controllo H.245.
In aggiunta, esso esegue la numerazione in sequenza, la rivelazione e la

correzione degli errori per ogni mezzo trasmissivo.
2.3.1.5. Controllore RAS

Voce su IP Page 33
Il controllore RAS utilizza i messaggi H.225 per

effettuare la registrazione, l'ammissione, i
cambiamenti di larghezza di banda, i controlli di
status e le procedure di sgancio tra endpoint e
Gatekeeper.
Il canale RAS è indipendente da quelli di

segnalazione chiamate e controllo H.245 e viene
aperto tra un endpoint ed un gatekeeper prima di
qualsiasi altro canale.
E' direttamente correlato al gatekeeper; nel

caso in cui questo componente non sia presente
(ad esempio in una comunicazione diretta
terminale - terminale) non vi sarà neppure il
canale RAS.
2.3.1.6. Controllore chiamate
Il controllore delle chiamate utilizza la

segnalazione H.225 per stabilire una connessione
tra due endpoint H.323.
Il canale di segnalazione chiamate viene

attivato dopo il canale RAS e prima di qualsiasi
altro canale tra un endpoint ed un gatekeeper o
tra due endpoint se non è presente il gatekeeper.
2.3.1.7. Controllore H.245
Il controllore H.245 usa un canale logico di

controllo per la gestione end-to-end dei messaggi
che governano le operazioni delle entità H.323,
incluso capacità di scambio, apertura e chiusura
dei canali logici, richiesta di modi operativi,
controllo di flusso, comandi e indicazioni generali.
La segnalazione H.245 viene stabilita tra due

endpoint o tra endpoint e gatekeeper; per ogni
chiamata a cui l'endpoint partecipa deve essere
presente un canale di controllo H.245. I terminali
che supportano più chiamate contemporanee
(gateway, gatekeeper, MCU) devono aprire più
canali di controllo.
Il canale di controllo H.245 si considera

permanentemente attivo per tutta la durata della
chiamata. Vi sono due modalità con cui questo
canale può essere gestito:

Voce su IP Page 34
come canale distinto

come canale logico 0 all'interno dei canali logici gestiti da H.225
(tunneling).
Le procedure di apertura e chiusura del canale logico non riguardano il

controllore H.245.
La raccomandazione H.245 specifica diverse entità di protocollo indipendenti

che supportano la segnalazione end-to-end. Ogni entità di protocollo è
caratterizzata da una sintassi, da una semantica e da un insieme di procedure
che specificano lo scambio di messaggi e l'interazione con l'utente.
Queste entità di protocollo sono:
Determinazione di Master Slave
Capacità di scambio
Segnalazione del Canale Logico
Segnalazione bidirezionale del Canale Logico
Richiesta del modo operativo
Determinazione del Round Trip Delay
Mantenimento della segnalazione di loop
2.3.2. Gateway
Un gateway possiede le caratteristiche di un

terminale H.323 sulla rete dati e le caratteristiche
di un terminale telefonico tradizionale su rete a
commutazione di circuito; in altre parole, riflette
le caratteristiche di un endpoint di rete dati ad
uno della rete telefonica e viceversa in modo
trasparente. Il compito del gateway è infatti di
provvedere all'appropriata traduzione di formati
di trasmissione (es. da G.729 in RTP a G.711 in
un canale B ISDN), dei canali di controllo (es. da
H.225 a H.221 e viceversa) e delle procedure di
segnalazione (es. da H.245 a H.242 e viceversa).
Tale sistema di traduzione è specificato dalla
raccomandazione H.246.
Un gateway, inoltre effettua il setup di una

chiamata e la successiva disconnessione sia dal
lato rete IP che rete telefonica.
I principali ambiti di impiego di un gateway sono i seguenti:
Interfaccia tra due reti in tecnologie differenti (ad esempio IP e PSTN):

sicuramente l'ambito di impiego più utilizzato
Meccanismo di "adattamento" tra due reti IP: ad esempio nel caso in cui si
debba passare per una rete con basse capacità dei link, nel qual caso è
conveniente inserire un gateway con il solo compito di compressione del
flusso audio/video (ad esempio da G.711 a G.729 per l'audio)
Sistema di backup di una rete IP su rete telefonica: è possibile connettere
due gateway attraverso una rete a commutazione di circuito per
consentire, ad esempio, la comunicazione tra i due terminali H.323 anche
in caso di guasto della rete IP nativa.

Voce su IP Page 35
Un endpoint H.323 può comunicare con un altro dello stesso tipo senza
invocare l'uso del gateway, il quale può essere omesso se non s'intende
effettuare comunicazioni con apparati su rete telefonica tradizionale.
2.3.3. Gatekeeper
Il gatekeeper è l'intelligenza della rete H.323,

in quanto gestisce una "zona" di terminali e
fornisce agli endpoint H.323 un meccanismo di
controllo delle chiamate. Un gatekeeper è
logicamente separato da un endpoint, ma la sua
implementazione fisica può coesistere con un
terminale, un gateway o con altri apparati di rete
non-H.323.
In un sistema possono essere presenti più

gatekeeper che comunicano tra loro, devono però
necessariamente lavorare in zone H.323 diverse.
Il gatekeeper deve provvedere alle funzioni

seguenti:
Traduzione degli indirizzi, da indirizzo alias

H.323 a indirizzo a livello di trasporto
Controllo d'ammissione alla rete, attraverso l'uso di messaggi RAS
Controllo di larghezza di banda
Gestione delle zone H.323
Il Gatekeeper può in aggiunta provvedere alle seguenti funzioni opzionali:
Autorizzazione delle chiamate, ovvero la possibilità di non accettare una

chiamata in base a diversi fattori quali origine, orari, politiche di
amministrazione
Gestione della banda, per esempio limitando il numero di terminali H.323

presenti contemporaneamente sulla rete
Gestione chiamate, per esempio mantenendo una lista dei terminali H.323
con una chiamata in corso per indicare più velocemente che il numero
chiamato è occupato
2.4. Indirizzamento
L'indirizzamento su una rete H.323 prevede l'impiego di due tipi diversi di
indirizzo: la coppia indirizzo di rete / identificatore TSAP, e gli indirizzi alias.
2.4.1. Indirizzi di rete e identificatori TSAP

Voce su IP Page 36
Ogni dispositivo H.323 deve possedere almeno un

indirizzo di livello rete (indirizzo IP) che lo
identifica unicamente all'interno della rete.
Questo indirizzo, però, non è sufficiente per

portare a termine la comunicazione: infatti sarà
necessario attivare, sulla stessa macchina, delle
connessioni di controllo e delle connessioni dati.
L'identificazione di queste connessioni viene fatto
con gli identificatori TSAP (Transport layer
Service Acces Point), che consentono la
coesistenza di più canali di comunicazione per lo
stesso indirizzo di rete.
Gli identificatori TSAP possono essere noti a

priori (sostanzialmente, lewell known ports del
TCP/UDP), oppure negoziati a run-time. Fanno
parte della prima categoria quelli per il canale di
segnalazione delle chiamate (per tutti i terminali
H.323), e quello per il canale RAS nel caso di gatekeeper. Infatti, questi indirizzi
vengono utilizzati per l'instaurazione della comunicazione e devono pertanto
essere di tipo well-known, pena l'impossibilità, da parte del chiamante, di poter
aprire la chiamata. Fanno invece parte della seconda categoria gli identificatori
TSAP per i canali di controllo H.245, audio, video e dati.
Nel caso della disponibilità di un Gatekeeper, gli identificatori well-known

TSAP del terminale possono essere impostati a valori non standard: sarà infatti
cura del Gatekeeper, nel caso di una chiamata diretta verso il terminale in
esame, ad istruire appropriatamente il chiamante ad usare i TSAP effettivi
anzichè quelli standard.
2.4.2. Indirizzi alias
Un endpoint può anche avere uno o più

indirizzi alias ad esso associati, rappresentanti
l'endpoint stesso, univoci all'interno di una zona
H.323. Un alias può essere un indirizzo E.164
(numero di telefono), un identificatore H.323 (es.
un indirizzo di e-mail o un nickname) o qualsiasi
altro indirizzo definito nella raccomandazione
H.225. Questi indirizzi hanno il compito di
rendere più semplice l'identificazione del
terminale utente mediante l'impiego di un nome
più conosciuto rispetto all'indirizzo IP.
Gli indirizzi alias sono disponibili solamente

nel caso in cui la rete preveda un Gatekeeper, il
quale, a fronte di una chiamata, si occupa della
loro traduzione in indirizzi IP.
2.5. Operazioni H.323

2.5.1. Attivazione del canale RAS e registrazione presso il Gatekeeper

Voce su IP Page 37
Il Canale RAS (Registration, Admission and

Status) è un canale di comunicazione inaffidabile
tra un endpoint e il Gatekeeper. Questo canale,
con finalità diverse, viene instaurato da
qualunque oggetto H.323, sia esso un terminale
utente, un gateway, una MCU, oppure un MC.
Infatti, il Gatekeeper agisce come un
"controllore" della zona di sua competenza e
deve avere il tutto sotto controllo.
L'attivazione del canale RAS passa

obbligatoriamente per l'individuazione del
Gatekeeper con cui aprire la comunicazione. Una
volta che il Gatekeeper viene localizzato, il
canale RAS viene aperto e, attraverso di esso,
viene fatta la registrazione del terminale al
Gatekeeper in questione con il conseguente
abbinamento degli indirizzi alias all'indirizzo di
rete appropriato.
I messaggi utilizzati sono quelli definiti nella raccomandazione H.225.
2.5.1.1. Ricerca del Gatekeeper
L'assegnazione di un Gatekeeper ad un
endpoint può avvenire in modo statico,
semplicemente dicendo a quest'ultimo l'indirizzo
del Gatekeeper a cui fare riferimento, oppure in
modo dinamico (automatico).
La ricerca automatica consente un carico di

lavoro minore dal punto di vista di
amministrazione della rete e permette inoltre di
sostituire in qualsiasi momento un Gatekeeper
senza dover riconfigurare manualmente tutti i
terminali che erano registrati su di esso.
La procedura dinamica prevede che un

endpoint invii ad un indirizzo di multicast
(Discovery Multicast Address, 224.0.1.41, con
porta UDP 1718) un messaggio di Gatekeeper
Request (GRQ), al quale uno o più Gatekeeper
potranno rispondere con un messaggio
Gatekeeper Confirmation (GCF), indicante la loro presenza nel sistema e la
disponibilità per un'eventuale registrazione, oppure con un messaggio
Gatekeeper Reject (GRJ) nel caso non intendano registrare il terminale. Nel caso
in cui un terminale riceva la conferma da più Gatekeeper deve sceglierne uno e
procedere alla registrazione con esso.
Allo scopo di fornire ridondanza all'interno di un sistema che lo preveda, il

messaggio GCF può indicare una lista di gatekeeper alternativi da utilizzare in
caso di guasto. Inoltre, il messaggio GCF include anche l'identificativo TSAP a cui
richiedere l'apertura del canale RAS del Gatekeeper, utile nel caso in cui questo
abbia un valore non standard.
Questo processo di ricerca automatica si ripete nel caso in cui un endpoint

verifichi un'assenza di risposta da parte di un gatekeeper entro lo scadere di un
timeout o un problema in fase di registrazione.
2.5.1.2. Registrazione al Gatekeeper
Il processo di registrazione consente ad un endpoint di comunicare ad un

gatekeeper la propria presenza all'interno di una zona ed il proprio identificatore
TSAP. Nel caso l'endpoint sia un terminale utente ha la facoltà di comunicare
anche i propri alias,che invece non sono supportati per Gateway, MCU e MC.

Voce su IP Page 38
Inoltre, l'endpoint comunica anche la natura del terminale stesso (terminale

utente, Gateway, etc).
Tale processo, simile al caso della procedura ricerca del gatekeeper, deve
avvenire prima che sia effettuata qualsiasi chiamata, ed inizia con l'invio da
parte di un endpoint di un messaggio Registration Request (RRQ) all'indirizzo del
Canale RAS di un gatekeeper, il quale potrà rispondere con un messaggio
Registration Confirmation (RCF) o Registration Reject (RRJ). Il pacchetto RRQ
contiene, tra le altre cose, anche un campo TimeToLive che specifica l'intervallo
di refresh desiderato, a cui segue la conferma (o la modifica) di tale valore nella
RCF.
La durata della registrazione può essere decisa in fase di setup specificando

un valore TimeToLive nel messaggio RRQ. Il messaggio RRQ deve essere ripetuto
periodicamente tramite messaggi RRQ più "leggeri", con il bit KeepAlive settato.
Inoltre, il gatekeeper è abilitato a processare richieste multiple dallo stesso
endpoint. La ripetizione periodica della registrazione (modello soft state),
permette di aumentare la robustezza del sistema in quanto i terminali inattivi
vengono riconosciuti dal Gatekeeper, impedendo quindi il tentativo di
instaurazione di chiamate verso un terminale inesistente. Inoltre, il Gatekeeper
si trova nelle condizioni di dover gestire solamente i terminali attivi, con gli ovvi
vantaggi del mantenere sempre uno stato coerente.
E' possibile annullare la registrazione al Gatekeeper utilizzando una

procedura analoga alla precedente con messaggi di tipo Unregister. Un terminale
che vuole cancellare la propria registrazione invia un messaggio di Unregister
Request (URQ) al gatekeeper che risponde con un messaggio di Unregister
Confirmation (UCF); se il terminale non era preventivamente registrato riceve
dal gatekeeper un Unregister Reject (URJ). La registrazione può essere annullata
anche dal Gatekeeper stesso (ad esempio se viene riconosciuta una fase di
shutdown): il Gatekeeper invierà un messaggio URQ al terminale, che risponderà
con un messaggio UCF.
2.5.1.3. Ammissione e cambiamento di banda
Il Canale RAS è utilizzato anche per l'invio di

messaggi con funzioni di controllo di accesso e
gestione della banda. In particolare, questa
procedura è richiesta per l'instaurazione di una
chiamata attraverso il Gatekeeper.
I messaggi di tipo Admission Request (ARQ)

sono utilizzati da un endpoint per indicare ad un
Gatekeeper l'autorizzazione ad effettuare una
chiamat; contestualmente viene anche
specificata la banda richiesta. A sua volta, il
Gatekeeper ha la facoltà di rispondere con
messaggi Admission Confirm (ACF) nei quali
comunica l'autorizzazione all'instaurazione della
chiamata (ad esempio l'utente potrebbe non
essere autorizzato a chiamare determinati
numeri telefonici); contestualmente può
accettare o ridurre il valore della banda richiesta.
Nel caso in cui la chiamata non sia possibile, il
Gatekeeper risponderà con un messaggio Admission Reject (ARJ) che terminerà il
processo.
La banda può anche essere rinegoziata durante la chiamata stessa tramite i

messaggi di cambiamento di banda Bandwidth Change Request (BRQ).
Il valore richiesto è un limite superiore aggregato del flusso di bit trasmessi e

ricevuti, dei canali audio e video escluso l'header RTP e ogni altro overheader di
controllo.
2.5.2. Instaurazione di una chiamata

Voce su IP Page 39
L'instaurazione di una chiamata consiste in più fasi che dipendono dalla

presenza o meno del Gatekeeper, e dalla configurazione che ad esso è stata
assegnata.
Si tratterà prima il caso dell'apertura di una chiamata diretta tra due

terminali utente, quindi si passerà a vedere cosa cambia nel caso in cui vi sia
anche un Gatekeeper.
Il canale di Segnalazione Chiamata è utilizzato per il trasporto affidabile di

messaggi H.225 di controllo chiamate. In reti in cui è assente un Gatekeeper, tali
messaggi sono scambiati direttamente dai due endpoint coinvolti in una
chiamata. Nel caso sia invece presente un Gatekeeper, i messaggi sono
inizialmente inviati a quest'ultimo, il quale poi indicherà se continuare l'invio al
medesimo o direttamente all'endpoint destinatario della chiamata.
2.5.2.1. Chiamata diretta tra due terminali
La fase di call setup inizia quando c'è la

richiesta, con un messaggio H.225 SetupRequest,
da parte di un'endpoint, di instaurare una
chiamata.
L'altro endpoint risponderà con un Call

Proceeding, indicante che la richiesta è stata
presa in considerazione. A questo punto, il
destinatario della chiamata deve essere in grado
di rispondere con un messaggio diAlerting per
comunicare al mittente di aver avvisato l'utente
finale. Nel caso di connessione tra reti di diversa
natura con un gateway, quest'ultimo deve
rispondere con un alerting solo dopo che ha
ricevuto un'indicazione di ring dalla rete
telefonica. In realtà, il messaggio di Alerting è
opzionale e il destinatario può rispondere anche
con messaggi diConnect o Release Complete,
purchè la risposta arrivi entro 4 secondi, dopo di
che, in mancanza di risposta, il chiamante genererà un nuovo messaggio di
Setup.
Il messaggio di Connect deve essere inviato solo se è possibile aprire un

canale di controllo H.245.
2.5.2.2. Gatekeeper Direct Endpoint
Nella configurazione in cui entrambi gli

endpoint sono registrati sullo stesso gatekeeper,
il gatekeeper stesso può scegliere, come già
visto in precedenza, due metodi di segnalazione,
direct endpoint o gatekeeper routed.
Nel primo caso, il primo terminale inizierà

una fase di Admission Control verso il
Gatekeeper (ARQ - ACF/ARJ) per la negoziazione
della banda della chiamata e per la
determinazione dell'indirizzo del terminale
chiamato. Ottenuta una risposta positiva, il
messaggio di Setup verrà inviato direttamente al
secondo terminale, usando l'indirizzo (IP + TSAP)
ottenuto dal Gatekeeper.
Nel caso in cui il terminale chiamato accetti

la richiesta, inizierà a sua volta uno scambio di
messaggi ARQ/ACF con il Gatekeeper; in caso di
conclusione positiva di questa fase, inverà un messaggio di Alerting (e poi

Voce su IP Page 40
Connect) direttamente al chiamante; in caso negativo invierà invece un

messaggio di Release Complete per chiudere la chiamata.
La fase di setup è conclusa quando il secondo terminale invia un messaggio

di Connect contenente l'identificativo TSAP del canale di controllo H.245,
necessario per poter attivare la segnalazione H.245.
Da questo momento in poi, la chiamata è

stabilita. Tuttavia, mentre il canale di controllo
RAS e i flussi multimediali sono instaurati
direttamente tra i due endpoint, i messaggi di
segnalazione H.245 vengono inviati comunque
attraverso il gatekeeper. Ovviamente, anche i
messaggi di chiusura vengono inviati attraverso il
gatekeeper: un primo endpoint invia un
messaggio DRQ all'altro endpoint (attraverso il
gaterkeeper) a cui seguirà un messaggio DCF/
DRJ (sempre attraverso il gatekeeper).
2.5.2.3. Gatekeeper Routed Call
Questa procedura è concettualmente analoga

alla precedente, con la differenza che in questo
caso i messaggi di chiamata passano
completamente attraverso il Gatekeeper, che
agisce pertanto come un "router" nei confronti
dei due endpoint. Viceversa, i flussi multimediali
sono instaurati direttamente end-to-end, senza
l'intermediazione del gatekeeper.
Esiste un ulteriore scenario, chiamato

Gatekeeper Proxy, che fa sì che anche i flussi
multimediali vengano inviati attraverso il
gatekeeper. Con quest'ultima modalità (spesso
implementata nei prodotti, ma non specificata
dallo standard) non vi è alcun scambio di dati
end-to-end.
2.5.2.4. Instradamento dei messaggi di controllo

Voce su IP Page 41
Dopo aver stabilito il canale di segnalazione, vi

sono due metodi, equivalenti ai due precedenti,
per instradare il canale di controllo H.245.
Nel primo caso il canale è instaurato

direttamente tra gli endpoint, nel secondo caso si
fa uso del Gatekeeper che gestisce direttamente
il controllo delle chiamate. Il primo metodo
(canale diretto) è utilizzato quando non si fa uso
di Gatekeeper nella rete; in presenza di
Gatekeeper si preferisce sempre il secondo
metodo (il primo è sperimentale).
2.5.2.5. Comunicazione iniziale e scambio informazioni di capacità
Il canale di controllo H.245, appena

instaurato, serve per aprire il canale dei media
(Media Channels) dove ci sarà il trasporto dei
dati multimediali.
Il primo messaggio H.245 inviato è il

TerminalCapabilitySet, che serve per annunciare
la capacità del terminale di ricevere e inviare il
flusso multimediale: descrive le caratteristiche
della compressione audio e video usata, il
massimo jitter supportato, la capacità di
multiplexare più flussi (nel caso di conferenza).
Ad ogni richiesta deve seguire un messaggio di
Ack.
Il messaggio OpenLogicalChannel contiene

invece informazioni sul canale di controllo del
flusso multimediale, l'indirizzo di rete e
l'identificatore TSAP usati dall'endpoint per le
comunicazioni RTCP. L'ACK di questo messaggio contiene sia i dati del canale di
controllo del flusso multimediale RTCP che i dati, TSAP e indirizzo di rete, del
canale multimediale RTP.
2.5.2.6. Comunicazioni multimediali
A questo punto, è possibile lo scambio dei dati multimediali (attraverso RTP e

RTCP) con l'endpoint remoto..
2.5.2.7. Terminazione chiamata

Voce su IP Page 42
La chiamata può essere terminata da un endpoint

o da un Gatekeeper. la chiamata viene abbattuta
seguendo questi passi:
Il flusso audio non è più continuo e

l'endpoint chiude il canale logico
dell'audio.
Deve trasmettere il messaggio,all'endpoint

con cui ha una chiamata attiva, sul canale
logico di controllo H.245, di
endSessionCommand per chiudere il
canale di controllo stesso.
Deve aspettare di ricevere il messaggio di

endSessionCommand dall'endpoint
remoto.
Se il canale di segnalazione H.225 è aperto deve chiuderlo con l'invio di un

messaggio di Release Complete.
I due endpoint devono notificare ai gatekeeper il rilascio della banda con

dei messaggi di BRQ (Bandwidth Change Request).
Se l'endpoint si stacca dalla rete, dovrà notificarlo al Gatekeeper con

messaggi di tipo DRQ (Disengage Request), a cui seguirà un messaggio
DCF (Disengage Confirmation) oppure DRJ (Disengage Reject).
2.6. Conclusioni
La suite di protocolli H.323 ha avuto una
notevole diffusione come soluzione per
implementare la telefonia su IP sia nel mondo
aziendale che nel mondo dei telecom provider.
Attualmente, la gran parte delle implementazioni
VoIP (anche di grandi operatori internazionali, ad
esempio quelli che offrono telefonate a lunga
distanza a costi ridotti) adotta questo standard.
Tuttavia, lo standard è estremamente

complesso e le nuove implementazioni stanno
progressivamente migrando alla tecnologia SIP.
Molti vendor, ad esempio, offrono apparati che
possono essere aggiornati alla tecnologia SIP con
un semplice cambio di release software. Dalla
parte di H.323 rimane una maggior solidità nelle
implementazioni; tuttavia, il futuro per questo
standard è ormai segnato.

Voce su IP Page 43
Capitolo 3. La suite di protocolli SIP
3.1. Introduzione
Il Session Initiation Protocol (SIP) nasce in
ambito IETF con la creazione del SIP Working
Group, in collaborazione con il MMUSIC Working
Group (Multiparty Multimedia Session Control).
La proposta nasce dall'esperienza di MBone dove
si erano implementati alcuni applicativi audio/
video, i quali avevano implementato delle
semplici primitive di segnalazione. SIP nasce
come alternativa alla suite H.323 ponendo, a suo
vantaggio, la semplicità.
SIP è un protocollo di segnalazione di livello

applicativo che ha come scopo l'instaurazione, la
modifica e la terminazione di una chiamata o di
una sessione multimediale/dati. Tra le
caratteristiche peculiari di SIP vi è l'idea di
inserire l'intelligenza (ove possibile) alla periferia
della rete lasciando al backbone il compito di
smistamento dei pacchetti; il risultato è
l'ottenimento di eccellenti caratteristiche di scalabilità. Inoltre, SIP può operare
con qualsiasi protocollo di livello inferiore (IP, Frame Relay, X.25, ATM...) ma,
essendo stato studiato per il mondo Internet, si interfaccia più facilmente con IP.
Anche se la suite SIP specifica numerosi protocolli (d'altro canto la

realizzazione di una telefonata non è un compito semplice), SIP definisce
componenti piccoli e mono-funzionali, in modo da evitare la duplicazione (o
commistione) di funzioni e fare si che siano modulari, a differenza di quello che
succede in H.323 dove per una funzione elementare sono necessarie interazioni
di più protocolli. Inoltre, il protocollo SIP, per questioni di semplicità, cerca di
riutilizzare altri componenti precedentemente definiti in ambito IETF e
sufficientemente disponibili e si limita a definire puramente funzioni di controllo.
Ad esempio, non specifica la trasmissione dei dati multimediali (audio, video),
demandando questo compito al già collaudato protocollo RTP/RTCP. Per lo stesso
motivo, SIP non si preoccupa di riservare la banda per una chiamata,
demandando questo compito al terminale utente, se questo è interessato: per
far questo, il terminale potrà sfruttare altri protocolli già definiti in ambito IETF.
In particolare, SIP può inviare al terminale chiamato invitato le informazioni
necessarie per l'allocazione di risorse sulla rete: è fortemente integrato, infatti,
con il protocollo SDP, Session Description Protocol, e con RSVP, Resource
reSerVation Protocol, che hanno il compito di dare una descrizione dettagliata
delle risorse necessarie all'instaurazione della chiamata e di riservarle. Infine,

Voce su IP Page 44
può utilizzare protocolli come SAP (eventualmente in multicast) per l'annuncio di

sessioni multimediali.
SIP offre un supporto trasparente di "name mapping" e adattamento dei

servizi per agevolare la "personal mobility". Gli utenti possono quindi originare e
ricevere chiamate e accedere i servizi telefonici da ogni terminale e in ogni
posto, e la rete ha l'abilità di identificare l'utente e i suoi spostamenti. La
mobilità personale è basata sull'uso di un'identificazione unica dell'utente.
Visto l'enorme successo del World Wide Web

dovuto all'estrema semplicità dei protocolli
utilizzati, il protocollo SIP segue la stessa
filosofia ed utilizza un modello di interazione di
tipo client-server, con messaggi la cui sintassi è
text-based sul modello del protocollo HTTP.
Inoltre, utilizzando molti dei concetti già noti,
l'integrazione con altre tecnologie ne risulta
facilitata. Ad esempio, gli indirizzi SIP sono molto
simili agli indirizzi di e-mail, semplificando
pertanto anche l'interazione con utente.
SIP può utilizzare come protocollo di livello di

trasporto sia UDP sia TCP: il primo offre il
vantaggio di un maggior controllo sui tempi di
trasmissione, la possibilità di ricerche parallele e
il multicast, mentre TCP offre un servizio
connesso utile per il passaggio, ad esempio,
attraverso i firewalls. Inoltre, il TCP permette di
utilizzare la stessa connessione per l'inoltro di più messaggi di Request/
Response, diminuendo l'overhead connesso all'apertura della connessione TCP.
In ogni caso, anche con UDP SIP garantisce l'affidabilità dei messaggi definendo
un meccanismo di three-way handshake (Request, Response, Ack).
Nel caso di UDP, SIP non ammette la frammentazione: tutto il messaggio

deve essere contenuto in un singolo pacchetto, la cui dimensione (a livello IP)
dovrà essere pari alla MTU della rete o pari al massimo a 1500 bytes.
3.1.1. SIP e sicurezza
Il protocollo SIP offre ovviamente anche

caratteristiche di sicurezza: in primo luogo
permette l'autenticazione dell'utente ma offre
anche meccanismi contro attacchi del tipo Denial-
of-service o contro l'equivalente delloSpam, le
mail commerciali non richieste.
In aggiunta, poiché i messaggi SIP sono

puramente testuali e quindi molto facilmente
decifrabili, c'è la possibilità di criptare il corpo del
messaggio o di nascondere i nodi intermedi
attraverso cui la richiesta è giunta a destinazione.
Una politica di questo tipo potrebbe generare
loop in quanto i nodi successivi non conoscono da
quali nodi è messaggio è transitato, e quindi
potrebbero rimandarlo erroneamente indietro;
sono però disponibili alcune strategie per
impedirlo.
3.1.2. Servizi principali previsti da SIP

Voce su IP Page 45
SIP offre cinque servizi principali per instaurare e

terminare una chiamata:
Localizzazione dell'utente: determina

quale sia l'end system da usare per la
comunicazione
Ricerca delle capacità dell'utente:

determina le caratteristiche dell'utente in
termini di risorse audio/video e i parametri
da usare
Disponibilità dell'utente: riconosce la

volontà del chiamato di comunicare o
meno
Setup della chiamata: stabilisce i

parametri della chiamata
Gestione della chiamata: include le operazioni di trasferimento e gestione

delle chiamate
3.2. La pila protocollare SIP

La pila protocollare SIP è decisamente
variegata e prevede l'utilizzo di numerosi
componenti. Da quanto punto di vista la
situazione può sembrare analoga a quella di
H.323; tuttavia, ogni componente è indipendente
(o quasi) dagli altri, la divisione delle funzionalità
è abbastanza netta, e la semplicità del tutto è
decisamente superiore. Pertanto, non si
verificano quelle commistioni di protocolli per cui
una singola funzionalità viene realizzata
attraverso l'impiego di differenti protocolli,
ognuno di essi utilizzato in minima parte rispetto
alle sue funzionalità globali.
3.2.1. SDP
Il protocollo SDP (Session Description

Protocol) è utilizzato per la descrizione della
sessione multimediale: descrive, ad esempio, il
numero di flussi multimediali impegnati e le
relative caratteristiche del codec, l'indirizzo/porta
utilizzata dalla sessione sulla rete, la banda
impiegata, l'originatore del flusso, e il tempo di
inizio / fine del flusso stesso.
L'ultimo parametro è significativo nel caso di

media streaming (ad esempio si potrà annunciare
che un concerto live inizia alle ore 21.00) e nel
caso di "invito" ad una conferenza, specificando
quindi l'ora di inizio e quella di fine.
Anche SDP, come SIP, definisce un formato

testuale per i messaggi; il messaggio SDP è
incluso come parte finale di un messaggio di SIP
INVITE.

Voce su IP Page 46
3.2.1.1. Formato dei messaggi SDP
Un messaggio SDP è diviso in più sezioni:

iniziamente vengono riportate le informazioni
relative all'intera sessione, quindi seguono (e
sono opzionali) quelle relative ai media fisici che
ci si propone di attivare. La sezione iniziale ha
sempre l'attributo di versione (" v = ") nella
prima riga; le sezioni dei media iniziano quando
viene incontrata una riga m " = ". Nella prima
sezione è obbligatorio almeno una riga relativa
alle impostazioni temporali della sessione t (" =
") che definisce l'istante di inizio e di fine della
sessione (con una sintassi un po' convoluta,
essendo il tempo espresso in secondi con la
stessa notazione utilizzata da NTP).
SDP definisce numerosi campi ("attributi")

che possono essere inclusi in un messaggio. Di
questi, alcuni sono obbligatori, mentre altri sono
a discrezione dell'utente.
Tra i campi a carattere generale riferiti

all'intera sessione si trovano il creatore della
sessione, la chiave di cifratura, la banda presunta
espressa o in modalità CT (Conference Total,
ossia l'intera banda occupata dalla sessione
multimediale), oppure AS (Application-Specific
Maximum, ossia la banda occupata dal solo
utente in esame), l'iundirizzo di mail e il numero
di telefono del creatore della sessione, ecc. Altri
campi sono invece riferiti al singolo media, ad
esempio il tipo di media, la porta UDP sulla quale
verrà recapitato, il Payload Type utilizzato in RTP,
etc.
Gli attributi sono associati alla sezione nella

quale sono presenti. Ad esempio, l'attributo k= ""
(chiave crittografica) o il generico attributo a=
" "
valgono per l'intera sessione se sono inseriti nella
sezione iniziale, oppure si riferiscono ad un singolo media se sono presenti in
una sezione "media". In generale i valori a livello di sessione sono validi anche
per tutti i media, a meno che siano esplicitamente ridefiniti all'interno della
descrizione del media stesso.
L'elenco dei messaggi ammessi in SDP è riportato in figura.
3.2.1.2. Esempio di messaggi SDP

Voce su IP Page 47
In figura sono riportati alcuni esempi di messaggi

SDP. E' possibile notare come nel primo esempio
venga annunciata una sessione di puro audio,
mentre nel secondo caso la sessione comprende
audio, video e una lavagna condivisa. Tra gli
attributi più importanti (e non immediatamente
intuitivi da interpretare), è possibile citare i
seguenti.
Attributo " o =": Identificativo del

creatore della sessione e identificativo della
sessione stessa.
La definizione del campo e un suo esempio di

utilizzo sono riportati di seguito:
<username> <session id> <version> <network type> <address type> <address>

mhandley 4858949 4858949 IN IP4 198.7.6.5
Sia per il campo "Session ID" che per il campo "version" è consigliato
utilizzare un numero derivato da NTP per garantire l'unicità della sessione.
Attributo "c =": Informazioni relative alla connessione.
La definizione del campo e un suo esempio di utilizzo sono riportati di

seguito:
<network type> <address type> <connection address>

IN IP4 132.151.1.19
Questo attributo deve essere sempre presente (o globalmente alla sessione,

oppure uno per media). In questo caso la sessione verrà attivata su internet
(IN), da una macchina IPv4 con indirizzo 132.151.1.19.
3.2.2. RTP/RTCP
Svolgono il compito solito, ossia il primo è responsabile del trasferimento dei

dati multimediali, mentre il secondo controlla l'andamento della sessione, in
particolar modo dal punto di vista della qualità. E' cioè in grado di accorgersi se
la chiamata ha una qualità accettabile; in caso negativo, questa informazione
può essere usata dai componenti di livello superiore per poter prendere gli
opportuni provvedimenti (ad esempio passare ad un codec con meno richieste di
banda).
3.2.3. RTSP
Il Real-Time Streaming Protocol controlla

l'interazione dell'utente con un server di
streaming multimediale, e controlla il modo con
cui uno spezzone multimediale viene riprodotto
sul terminale utente. E' in grado, ad esempio, di
inviare comandi di start/stop, pause,
avanzamento veloce, etc.
Un server RTSP è utile sia nel caso di media

streaming classico (ad esempio Video on
Demand), sia nel caso in cui l'utente voglia
ascoltare messaggi registrati, quali potrebbero
essere quelli memorizzati nella propria segreteria
telefonica.

Voce su IP Page 48
3.3. Componenti principali di SIP

L'architettura SIP prevede l'impiego di
numerosi componenti, elencati in figura.
3.3.1. User Agent
Questo oggetto è nient'altro che il terminale utente, che include

obbligatoriamente due componenti:
User Agent Client: si occupa delle procedure necessarie a far partire una
chiamata
User Agent Server: è in ascolto di eventuali chiamate in arrivo; si occupa
della gestione delle chiamate in ingresso
3.3.2. Proxy Server
La funzione del proxy server è quella solita, ossia un oggetto a cui è possibile
delegare in toto la gestione della chiamata. Questo server agirà come "server"
nei confronti della macchina originante la chiamata, e come "client" nei confronti
del terminale destinazione.
Il vantaggio nell'utilizzazione di un proxy server è che l'intelligenza bordo

del terminale utente può essere limitata, vantaggio che si presenta in particolar
modo per i telefoni IP. In questo caso, i terminali utente non devono
preoccuparsi di tutte le procedure di segnalazione nella loro interezza
(risoluzione del nome, etc), ma possono delegare il tutto al proxy.
Infatti, spesso il Proxy Server è utilizzato in aziende che fanno uso di telefoni
IP anzichè di PC come terminali utente.
3.3.3. Redirect Server

Voce su IP Page 49
Il Redirect Server agisce come un "deviatore" di

chiamata: accetta una chiamata in ingresso a cui
risponde con un messaggio indicante che non è il
server stesso il terminatore finale, ma la
chiamata deve essere rediretta verso un altro
oggetto.
Questo oggetto diventa estremamente utile

per poter implementare servizi a valore aggiunto
di redirezione della chiamata, in quanto questo
server diventa il terminatore di tutte le chiamate
di una certa zona. Se opportunamente
configurato, questo server potrà indicare al
chiamante che il chiamato risponde ad un
numero telefonico tradizionale, oppure ad una
casella di voice mail, o altro ancora, a seconda
delle caratteristiche della chiamata (ad esempio
in base all'orario della chiamata, oppure
all'originatore della stessa, etc.).
3.3.4. Media Server
Il Media Server si occupa della riproduzione / registrazione di flussi

multimediali sulla rete. Un impiego del Media Server può essere la generazione
di un ritornello audio di attesa nel momento in cui il chiamato è già impegnato in
un'altra comunicazione, oppure come segreteria telefonica nel quale registrare i
messaggi, etc. In generale, anche questo componente (come il Redirect Server)
permette l'implementazione di servizi a valore aggiunto.
3.3.5. Location Server
Il Location Server implementa un servizio di risoluzione degli indirizzi.

Infatti, è necessario, a fronte di un indirizzo del tiponomeutente@dominio.com
tradurlo nell'indirizzo IP effettivo del terminale che dovrà accettare la chiamata.
L'operazione di traduzione impiega i classici server già conosciuti: il DNS e

LDAP.
3.3.6. Server AAA
Il server di AAA (Authentication,

Authorization, Accounting) è necessario per
inserire, all'interno della rete, funzionalità di
gestione dal punto di vista della sicurezza.
Solitamente questo servizio viene implementato
da un server RADIUS, il quale si preoccuperà
prima di capire l'identità dell'utente, poi di
verificare se l'utente è autorizzato a far partire
una certa chiamata, quindi a tenere traccia della
chiamata stessa per le necessarie operazioni di
contabilizzazione.
3.3.7. Multi Conference Unit
E' un oggetto in grado di realizzare chiamate tra 3 o più persone, con le

stesse caratteristiche dell'omologo componente presente in H.323. Anche in

Voce su IP Page 50
questo caso, la MCU ha la possibilità di elaborare i flussi multimediali (mixing,

switching) per meglio gestire la conferenza.
3.4. Indirizzamento
SIP definisce che ogni utente deve avere un
indirizzo SIP. Questo implica che l'indirizzo non è
legato al terminale, ma individua l'utente. Un
terminale, a sua volta, avrà un indirizzo fisico,
ma normalmente questo è ricavato (ad esempio
attraverso la consultazione di un server DNS/
LDAP) dall'indirizzo dell'utente. Questa scelta
favorisce la mobilità degli utenti dal momento
che la chiamata per uno stesso utente verrà
diretta su terminali diversi (indirizzi fisici) a
seconda delle regole impostate.
Per comodità, si è ritenuto che il formato

adottato dagli indirizzi di e-mail
(nomeutente@dominio) fosse appropriato anche
per i servizi SIP. Non solo, ma si è ritenuto
opportuno estendere il formato dell'indirizzo e-
mail in modo da utilizzare lo stesso identificativo
personale per servizi diversi attraverso la
definizione di un opportuno prefisso applicativo. Così, ad esempio, l'indirizzo
mailto:mario.rossi@polito.it può essere utilizzato per inviare una email a
Mario Rossi, mentre l'indirizzo sip:mario.rossi@polito.it può essere usato
per attivare una sessione SIP. L'indirizzo SIP è, come anche gli indirizzi di posta
elettronica, case-insentitive.
La parte iniziale dell'indirizzo n( omeutente), è il nome dell'utente o un

numero telefonico, la parte finale (dominio.com), può essere il nome di dominio
oppure l'indirizzo di un server SIP (che comprende anche il caso in cui sia
l'indirizzo effettivo del terminale utente). Grazie a questo meccanismo molto
flessibile per la definizione degli indirizzi, SIP supporta anche l'interlavoro con la
rete telefonica classica: un'indirizzo nella forma0115647099@polito.it può
indicare la volontà di raggiungere l'utente telefonico indicato attraverso un
gateway tra mondo IP e mondo telefonico che sta presso il Politecnico di Torino.
In quest'ultimo caso si deve indicare, attraverso il parametro user=phone, che
l'identificativo è un numero telefonico.
Nel caso in cui l'URL SIP coincide con il nome della persona più il nome
dell'azienda la privacy dell'utente, che consiste nell'avere un numero privato,
può sembrare compromessa; tuttavia, a differenza della telefonia tradizionale, i
meccanismi di SIP consentono un livello di autenticazione e di controllo di
accesso che permettono comunque di regolare l'arrivo delle chiamate verso il
proprio numero. Il controllo può essere inserito sia un un server (ad esempio il
Redirect Server), sia direttamente all'interno del terminale utente, il quale può
rifiutare le chiamate non autorizzate o indesiderate.
L'URL SIP è usata nei messaggi per indicare la sorgente (From), la

destinazione corrente (Request-URI) e finale (To) della richiesta; è utilizzata
inoltre per indicare gli indirizzi verso cui reindirizzare i messaggi.
Il parametro password può essere presente nell'URL SIP, ma il suo uso è

fortemente sconsigliato nel caso in cui venga utilizzato un protocollo di trasporto
differente da TLS/TCP, poiché l'indirizzo del destinatario del messaggio è inviato
in chiaro.
3.4.1. Parametri di indirizzamento

Voce su IP Page 51
Anche se l'indirizzo è il parametro fondamentale

per la raggiungibilità di un utente, non è l'unico:
esiste tutta una serie di parametri opzionali che
possono definire meglio le caratteristiche della
chiamata.
Questi parametri sono inseriti nell'URL SIP

dopo l'indicazione dell'host e sono separati da
punti e virgole. Tra i parametri principali vi sono:
Parametri di trasporto: determinano il

protocollo di trasporto (UDP oppure TCP; il
protocollo di default è UDP)
Indirizzi multicast: il campo maddr indica
l'indirizzo del "server" da contattare per
questo utente, che si sostituisce
all'indirizzo del campo host ed è
tipicamente un indirizzo multicast.
Time To Live: il parametro ttl determina il valore time-to-live del
pacchetto UDP multicast, deve essere presente solo nel caso di indirizzo
multicast e protocollo UDP.
Il figura sono riportati alcuni esempi di URL SIP. Nel primo caso, ad esempio,
si cercherà di contattare l'utentenome.cognome@dominio.it usando il multicast
239.255.255.1 con un ttl di 15.
Nel caso in cui la porta non sia presente, la chiamata SIP procede utilizzando
la porta 5060 del protocollo di trasporto prescelto.
3.4.2. Configurazione dei server DNS per la gestione dell'indirizzamento
Mentre gli utenti conoscono l'esistenza di un

server attraverso il suo nome (es. www.polito.it),
la localizzazione del server stesso da parte della
rete viene fatta attraverso l'indirizzo numerico
(es. 130.192.73.1). Questo meccanismo
permette non solo di disaccoppiare la visione
dell'utente dal funzionamento interno alla rete,
ma anche di fornire all'utente un identificativo
mnemonico fisso, senza dover per questo
impedire all'amministratore della rete di
procedere ad un cambio di indirizzo IP della
macchina in esame. Per lo stesso motivo, anche
il nome del servizio deve essere separato dalla
macchina che fornisce il servizio stesso.
Questa filosofia è utilizzata da numerosi

servizi, primo fra tutti il servizio di e-mail. Anche
SIP utilizza questo approccio, che richiede però
un certo lavoro per "tradurre" un URI associato
ad un utente in un insieme di parametri (indirizzo IP della macchina da
contattare, protocollo di trasporto da usare, porta) necessari all'instaurazione
della chiamata. La RFC 3263 indica pertanto che l'indirizzo IP, la porta e il
protocollo di trasporto da usare per una sessione SIP debbano essere
determinate attraverso l'interazione con un server DNS. SIP richiede che venga
stabilito anche il protocollo di trasporto in quanto questo protocollo può essere
imbustato in UDP, TCP, SCTP, oppure TLS/TCP a seconda delle esigenze.
Il DNS fornisce due tipi di record che sono di interesse per il protocollo SIP:
SRV e NAPTR, che servono per ricavare (con una procedura piuttosto complessa
ma molto flessibile) i parametri necessari per localizzare il server SIP
responsabile di un certo dominio a cui appartiene l'utente chiamato. Tuttavia,
alcune implementazioni fanno uso del solo record SRV.

Voce su IP Page 52
3.4.2.1. Record SRV
I record SRV (specificati nella RFC 2782)

sono nella forma indicata in figura, dove il
significato dei campi è il seguente:
Service
Rappresenta il tipo di servizio da
risolvere; in questo caso e' SIP oppure
SIPS nel caso in cui si usi il trasporto
sicuro (TLS su TCP). Si noti come il
nome del servizio è conosciuto
dall'applicativo che sta effettuando la
risoluzione (ad esempio perchè è
contenuto all'interno dell'indirizzo, es.
sip:mario.rossi@polito.it)
Transport
Indica il protocollo di trasporto da
utilizzare, in questo esempio UDP; altri
valori sono TCP e SCTP.
Name
Dominio a cui il record in esame si riferisce: il record nell'esempio indica
che quel record si riferisce a tutte le richieste per il dominio .polito.it.
TTL
Indica la durata (in secondi) del record stesso ed è usato per definire la
massima durata della sua validità quando viene memorizzato all'interno
della cache di un altro DNS.
Class
Rappresenta la classe "Internet", quindi è sempre IN.
SRV
E' la parola chiave che identifica questo record come un record SRV.
Priority
La priorità può essere utilizzata per definire quale record ha la
precedenza, nel caso in cui ne esistano piu' di uno. Nel caso di due
record con diversa priorità, viene utilizzato sempre quello a priorità
maggiore (corrispondente al valore più basso); gli altri vengono utilizzati
solamente qualora attraverso il primo non si ottenga risposta.
Weight
Quando esistono più record SRV con la stessa priorità, questo parametro
determina proporzionalmente quale dei record dovrà essere utilizzato.
Ad esempio, in presenza di due record con la stessa priorità ma con pesi
10 e 20, il secondo verrà utilizzato il doppio delle volte del primo. Questo
meccanismo è utilizzato per fare bilanciamento di carico tra gli host.
Porta
Porta a cui il server è in ascolto per quel particolare servizio
(nell'esempio la 5060).
Target
Nome del server che è responsabile del servizio secondo i parametri
specificati. Questo nome può essere letterale, nel qual caso è necessario
una ulteriore risoluzione (di un record A / AAAA) per ottenerne l'indirizzo
IP.

Voce su IP Page 53
In figura è riportata un estratto della

configurazione del DNS per gestire una certa
affidabilità e il bilanciamento di carico tra due
server, server1 e server2. Dopo una parte
iniziale nel quale si indicano le informazioni
relative al dominio nel record SOA (Start Of
Authority) e i record A nel quale vengono
specificati gli indirizzi IP di alcune macchine (tra
le quali server1 e server2), i record seguenti
indicano che nel caso di chiamata SIP con
trasporto UDP è da preferireserver1 (che ha
priorità più bassa), mentre nel caso di chiamata
SIP con trasporto TCP le chiamate devono essere
inoltrate in proporzione di 2 a 1 rispettivamente a
server1 e a server2, ad esempio perchè la
prima macchina è decisamente più performante
della seconda.
3.4.2.2. Record NAPTR
I record NAPTR (specificati nella RFC 3263)

vengono utilizzati per determinare la tipologia di
trasporto da usare per accedere ad un servizio.
Infatti, i record SRV specificano il server (e la
porta) da contattare a fronte di un determinato
protocollo di trasporto che deve essere noto a
priori. Tuttavia, non danno la possibilità di
indicare quale protocollo di trasporto (TCP, UDP,
...) debba essere preferito.
I record NAPTR sono nella forma indicata in

figura, dove il significato dei campi è il seguente.
Domain-name
Indica il dominio a cui questo record si
riferisce e che corrisponde alla porzione
dell'indirizzo SIP che sta a destra del
segno @ ' ' (as esempio polito.it per
sip:mario.rossi@polito.it).
TTL
Indica la durata (in secondi) del record stesso ed è usato per definire la
durata della sua validità quando viene memorizzato all'interno della
cache di un altro DNS.
Class
Rappresenta la classe "Internet", quindi è sempre IN.
NAPTR
E' la parola chiave che identifica questo record come un record NAPTR.
Order
Indica l'ordine nel quale i record NAPTR devono essere esaminati nel
caso ne esistano più di uno, partendo dal valore più basso. Se il record
con ordine più basso contiene l'indicazione di utilizzare un trasporto che
non è supportato dall'applicativo (o che non può essere utilizzato per
esplicita volontà dell'utente), si passa ad esaminare il prossimo record
NAPTR, fino a quando se ne trova uno che può essere usato (oppure si
abortisce il servizio).
Preference
Come nei record SRV, i record NAPTR hanno un valore di preferenza
espressa in modo crescente. Nel caso in cui esistano più record NAPTR
compatibili con le richieste dell'applicazione, questo parametro
determina proporzionalmente quale dei record dovrà essere utilizzato.
Ad esempio, in presenza di due record con lo stesso valore di ordine ma
con preferenza 10 e 20, il secondo verrà utilizzato il doppio delle volte
del primo. Questo parametro è poco utilizzato nel caso di servizi SIP e

Voce su IP Page 54
normalmente tutti i record NAPTR vengono configurati con la stessa

preferenza, in quanto l'eventuale bilanciamento del carico viene fatto
attraverso i record SRV.
Flags
I Flag dipendono dall'applicazione; nell'esempio, il flag "s" indica che non
sono necessarie ulteriori operazioni di lookup per localizzare il record
SRV relativo; pertanto, tutte le informazioni necessarie sono presenti in
questo record NAPTR.
Service
Indica il protocollo di trasporto da utilizzare e può assumere i valori
SIP+D2U (per UDP), SIP+D2T (per TCP), SIP+D2S (per SCTP),
SIPS+D2T (per TLS/TCL).
RegExp
E' un campo che può essere utilizzato per contenere una espressione
regolare (regular expression ) che può essere utilizzata per rimpiazzare,
al volo, una parte del campo Target. Tuttavia, è consigliabile evitare di
impostare questo campo per evitare inutili complicazioni.
Target
Nome del record SRV che contiene i parametri per utilizzare il servizio
secondo il trasporto specificato.
In figura è riportato un estratto della

configurazione del DNS precedente con l'aggiunta
dei record NAPTR. Questi record specificano che
debba essere utilizzato, di preferenza, il trasporto
TLS/TCP, quindi TCP e, come ultima scelta, UDP.
I record NAPTR non sono strettamente

necessari; tuttavia, la RFC3263 definisce che,
qualora presenti, dovrebbero essercene almeno
tre per coprire i principali protocollo di trasporto
possibili (TLS/TCP, TCP, UDP), con l'ordine di
priorità indicato nell'elenco. In altre parole, ove
possibile si consiglia l'utilizzo di SIP sicuro,
lasciando SIP su UDP come ultima opzione.
3.4.3. Lo standard ENUM
Nonostante lo standard SIP preveda

l'adozione di indirizzi alfanumerici nella forma
sip:nome@dominio perchè di più facile
memorizzazione, il vecchio standard E-164 che
definisce un identificativo telefonico come una
sequenza di numeri a 12 cifre (es +39-011-
5647008) ha ancora delle ragioni per esistere. In
prima battuta, l'identificativo SIP non è familiare
alla stragrande maggioranza degli utenti che
sono abituati al numero telefonico. Inoltre (e più
importante), l'identificativo SIP non è compatibile
le tastiere numeriche dei telefoni tradizionali e di
molti telefoni SIP (la quasi totalità dispone
solamente di tasiera numerica).
Il problema è pertanto sia di tipo operativo

(non è pensabile di sostituire tutti i terminali
telefonici esistenti; inoltre, per problemi di
spazio, non è pensabile avere una tastiera
alfanumerica sui telefoni cellulari), che di tipo sociale: alcuni utenti mal
digerirebbero un telefono con tastiera alfanumerica (ad esempio persone
anziane), ed inoltre spesso l'utente si sente maggiormente a suo agio con una
telefono dotato di una tastiera numerica tradizionale.

Voce su IP Page 55
Lo standard ENUM (tElephone NUmber

Mapping, definito nella RFC 2916, poi aggiornata
con la RFC3761) offre una soluzione al problema
di capire se, dato un numero telefonico in
formato tradizionale E.164, questo numero
corrisponda ad un terminale che è raggiungibile
attraverso la rete IP e, in caso affermativo,
l'indirizzo IP del terminale stesso. Inoltre
permette anche di specificare differenti mezzi con
il quale l'utente stesso può essere contattato
(telefono, email, fax, etc) lasciando al chiamante
la possibilità di scegliere il mezzo più opportuno.
Questo permette ad un utente SIP di essere
associato ad un unico identificativo che può
essere rimappato su un certo numero di
dispositivi fisici a seconda delle preferenze
dell'utente stesso (es. ufficio/casa), e delle
necessità del chiamante (es. fax / telefonata).
Infatti, sulla rete telefonica coesistono numerosi servizi: ad esempio sia un

telefono che un fax sono identificati da un numero, ma il servizio che offrono è
ben diverso e un utente ha ben chiaro se vuole inviare un fax oppure telefonare.
La mera risoluzione del numero telefonico non è quindi sufficiente in quanto l'URI
da utilizzare dipende anche dal servizio stesso. Per questo motivo, a fronte di
una richiesta di tipo ENUM, la risposta conterrà sempre una lista di URI
disponibili per quell'utente: sarà poi a cura del chiamante selezionare quello
adatto relativo al servizio di cui intende usufruire.
ENUM è applicabile in due distinti scenari:
un utente SIP (con la sola tastiera

numerica) che chiama un altro utente SIP
un gateway PSTN-SIP, che riceve una
chiamata lato PSTN e la deve inoltrare
verso un utente SIP. In particolare, questo
scenario necessita di una preventiva
elaborazione della chiamata lato PSTN in
quanto la rete telefonica deve in qualche
modo identificare il gateway di uscita (ad
esempio, la numerazione E-164 assegnata
agli utenti SIP potrebbe essere disgiunta
da quella della telefonia tradizionale)
Il problema, però, è lo stesso,

indipendentemente dallo scenario considerato:
associare all'indirizzo E.164 il corrispondente
identificativo SIP. ENUM propone una soluzione
a questo problema attraverso l'impiego del DNS, ossia inserendo in esso
opportune informazioni che permettano la traduzione di un indirizzo E.164 in un
indirizzo SIP.
Lo standard ENUM non affronta invece un terzo scenario, apparentemente

simile ai precedenti (in quando richiede anch'esso una traduzione E-164 - SIP),
ossia la traduzione di un indirizzo E-164 nell'indirizzo di un opportuno gateway
VoIP da utilizzare qualora il destinatario finale sia un utente sulla rete PSTN. Il
problema principale è quello contabilizzazione delle chiamate: per inoltrare una
chiamata verso un numero PSTN è necessario selezionare un gateway di uscita e
pagare, al gestore del gateway, il costo della telefonata. Pertanto, la scelta del
gateway non è una scelta puramente tecnica ma dipende da altri fattori quali gli
accordi di interscambio di traffico, le procedure di addebito della chiamata (che
devono essere ribaltate dal gateway, che fisicamente effettua la chiamata verso
la PSTN, all'effettivo chiamante), etc. Pertanto, lo standard ENUM non affronta
questo problema.

Voce su IP Page 56
Lo standard ENUM non affonta il problema duale: tradurre un indirizzo SIP in

un indirizzo E.164: questo problema è gestibile attraverso le normali funzionalità
di "alias" di SIP, dove ad un utente possono corrispondere più nomi logici
associati allo stesso dispositivo fisico, oppure collegati tra di loro attraverso
operazioni di "redirect" delle chiamate.
3.4.3.1. Principi di funzionamento
Data una entità (che può essere un terminale

utente, un SIP proxy oppure un gateway) che
dispone di un indirizzo E.164, il primo passo
consiste nel ricavare da esso un identificativo con
cui interagire con il DNS, e quindi procedere ad
una serie di interrogazioni per ricavare l'indirizzo
SIP del chiamato.
La traduzione tra numero telefonico e

identificativo del dominio è indicata in figura: si
scrive per intero il numero telefonico (compreso
di prefisso nazionale), ne si invertono le cifre, si
inserisce il carattere "." tra ogni cifra, e si
appende in coda il suffissoe164.arpa. A questo
punto è possibile effettuare una query di tipo
NAPTR verso il DNS alla ricerca di tutti i record
DNS associati a tale entry.
All'interno del
DNS potranno essere trovati record NAPTR come
ad esempio quelli indicati in figura, dove il
significato dei campi è quello già visto in
precedenza; vi sono però alcuni valori nuovi che
assumono il significato seguente:
Flag
Vale sempre "u" e indica che la risposta
che si ottiene da questa query è di tipo
terminale (ossia non richiede una nuova
richiesta NAPTR per ottenere la risposta
definitiva); questo non esclude tuttavia
che si debba procedere a nuove query
(magari anche NAPTR), ma queste
saranno relative a record diversi rispetto
all'attuale
E2U+SIP
Indica la tecnologia utilizzata nella
traduzione del record; in questo caso si
traduce un indirizzo E164 in un URI ("E2U"), il quale è di tipo SIP
("+SIP")
"!^.*$!sip:info@foo.com!"
Indica una espressione regolare secondo lo standard POSIX e la stringa
nella quale verrà inserito il dell'espressione stessa; l'espressione
regolare e la stringa sono nella forma:
!regexp!string!
Nel caso dell'esempio, l'espressione regolare seleziona tutto il record iniziale

(seleziona tutti i caratteri (".*") che sono compresi tra l'inizio ("^") e la fine ("$")
della stringa ) che viene pertanto rimpiazzato dal valore indicato nella stringa che
segue l'espressione regolare, ottenendo la stringa sip:info@foo.com se si è
interessati ad un servizio SIP, e così via. L'utente che ha chiesto la risoluzione
utilizzerà (in funzione dell’applicazione e delle eventuali preferenze) l'indirizzo
più opportuno.

Voce su IP Page 57
3.4.3.2. Esempio di risoluzione con ENUM
La figura riporta un esempio di risoluzione

completa che fa uso dello standard ENUM. In
questo caso, il numero telefonico viene risolto
prima in un insieme di URI disponibili per
quell'utente (attraverso un certo numero di
richieste al DNS che dipendono dalla lunghezza
della catena di delega), quindi viene selezionato
l'URI preferito a seconda del servizio che si vuole
utilizzare per interagire. A questo punto sarà
necessario una nuova interazione con il DNS per
conoscere gli identificativi necessari
all'instaurazione del collegamento (ad esempio il
protocollo di trasporto, l'indirizzo IP e la porta
UDP/TCP) attraverso nuove risoluzioni DNS di
record NAPTR e SRV.
3.4.3.3. Creazione dell'infrastruttura DNS per ENUM
La creazione dell'infrastruttura per il supporto

di ENUM deve avvernire su scala mondiale.
Tuttavia, l'assegnazione della gestione del
dominio responsabile della risoluzione ENUM (poi
definito in e164.arpa) ha generato numerose
discussioni politiche. Ad esempio, c'era la
proposta di assegnarlo ad un'organizzazione
neutrale, senza interessi nè economici nè politici,
quella di assegnarlo all'ITU, e altro. La soluzione
è stata trovata definendo un dominio di primo
livello (Top Level Domain, in termini propri della
tecnologia DNS) chiamato e164.arpa,
definendone l'ITU come responsabile
amministrativo, ma assegnando il controllo dal
punto di vista operativo all'IAB che ha a sua volta
delegato le operazioni all'ente di registrazione
europeo (RIPE).
RIPE gestisce quindi la delega al TLD, ma

ogni nazione deve a sua volta implementare un record per quanto riguarda il
prefisso nazionale, e da qui seguono a cascata i vari operatori telefonici e i
singoli utenti. La risoluzione di record ENUM è pertanto effettuata a cascata,
nello stesso modo con cui viene implementata la risoluzione inversa degli
indirizzi IP/IPv6 (attraverso i domini in-addr.arpa e ip6.arpa ).
Il problema più grosso di questa soluzione è nel caso in cui gli spazi di
indirizzamento tra diversi soggetti (ad esempio diversi operatori) non siano
disgiunti, in quanto diventa problematico la creazione di un meccanismo di
delega basato su prefissi telefonici. In altre parole, non è più possibile dire che,
all'interno degli operatori italiani, se il numero inizia per "0" è necessario
rivolgersi all'operatore X1, mentre se inizia per "1" è necessario proseguire la
risoluzione con le strutture dell'operatore X2 e così via. Infatti, i vari meccanismi
di number portability impediscono questo tipo di soluzione.
3.4.3.4. Esempio di rete VoIP con un impiego minimale di ENUM

Voce su IP Page 58
La gestione dell'infrastruttura ENUM è

decisamente complessa e richiede l'interazione di
un mumero di soggetti molto elevato. Può quindi
presentarsi il caso di un'azienda che decide di
implementare una infrastruttura SIP al suo
interno e che ha pertanto la necessità di tradurre
dei numeri telefonici in indirizzi SIP solo se
l'utente chiamato appartiene alla rete interna (e
quindi risiede sulla stessa infrastruttura VoIP).
Anche se l'utilizzo di ENUM può essere una
soluzione, questa è decisamente complessa in
quanto è necessario prima effettuare una
risoluzione ENUM, quindi se la risposta è
affermativa inoltrare la chiamata attraverso SIP,
in caso contrario inoltrare la chiamata al PSTN
gateway.
In molte aziende si utilizza una soluzione

molto più semplice: si personalizza il SIP proxy
con una regola che permette di riconoscere i "numeri telefonici brevi" (la
numerazione interna all'azienda): se il numero digitato dall'utente è di questo
tipo, la chiamata deve essere inoltrata attraverso SIP (in quanto è diretta ad un
altro telefono VoIP dell'azienda), in caso contrario (se il numero chiamato ha un
numero di cifre superiori alla numerazione interna all'azienza) viene inoltrata
verso il SIP-PSTN gateway e da lì fatta proseguire come telefonata tradizionale.
Questo sistema evita sia l'uso di ENUM (intesa come infrastruttura globale;
risoluzioni NAPTR possono essere ancora necessarie), sia il problema della
fatturazione delle chiamate telefoniche originate da una rete VoIP: tutte le
chiamate uscenti dal SIP-PSTN gateway saranno originate dal utenti dell'azienda
stessa, quindi l'azienda pagherà solamente per le chiamate effettuate dai propri
dipendenti.
In questo esempio, il DNS potrebbe essere

configurato come in figura. Viene inserito
all'interno del DNS un solo record NAPTR che si
riferisce alla numerazione telefonica interna. Se il
record di cui si chiede la risoluzione appartiene a
questa zona, il DNS procederà alla sostituzione
della stringa in ingresso secondo l'espressione
regolare indicata, ottenendo l'URL SIP dell'utente
da chiamare.
3.5. I messaggi SIP

In questa sezione verranno presentati i principali messaggi del protocollo
SIP.
3.5.1. Struttura dei messaggi SIP

Voce su IP Page 59
Un messaggio SIP è di tipo:
Request: se diretto da client a server

Response: se diretto da server a client
Entrambi i tipi di messaggio consistono in

una start-line, uno o più campi di header, una
linea vuota di ritorno carrello (CRLF Carriage
Return Line Feed) che indica la fine degli header,
e un messagge-body opzionale, così come
l'esempio in Figura. Il corpo del messaggio può
essere, ad esempio, un messaggio SDP
contenente le specifiche del flusso multimediale.
Il tipo di messaggio trasportato all'interno di un
messaggio SIP è definito con lo standard MIME,
analogamente alla procedura in uso per la posta
elettronica.
Nella parte Header del messaggio si trovano

informazioni relative agli utenti interessati al messaggio, il percorso che esso
deve compiere prima di giungere alla destinazione, ecc.
Anche i messaggi di risposta riprendono la filosofia di HTTP ed includono

quindi un codice di errore (suddiviso in classi a seconda della tipologie
dell'errore) e una descrizione testuale dell'errore stesso.
3.5.2. Tipologie di messaggi
3.5.2.1. INVITE
La richiesta INVITE si usa per chiedere al

destinatario di partecipare ad una chiamata;
quest'ultimo, se accetta la chiamata, deve
rispondere con un ACK request, altrimenti invia
un BYE request.
La richiesta di tipo INVITE tipicamente

contiene, nel corpo del messaggio, una
descrizione della sessione multimediale che si
vuole instaurare mediante il protocollo SDP, al
fine di comunicare le informazioni necessarie
sulla capacità di trasmissione al chiamato. Nel
messaggio SDP sarà indicato il tipo di flussi di
dati che è in grado di ricevere e decodificare e,
possibilmente, quelli che egli intende inviare.
Una richiesta di INVITE può essere inviata

anche a connessione instaurata per poter
rinegoziare i parametri di una chiamata. In
questo caso, la richiesta avrà un Call-ID uguale al precedente, mentre il numero
contenuto in CSeq sarà maggiore: il chiamato sarà tenuto a controllare i
cambiamenti nella descrizione della sessione e rispondere opportunamente
(possibilmente dopo aver chiesto conferma all'utente).
3.5.2.2. ACK
E' utilizzato per comunicare l'accettazione di un messaggio di INVITE. Nel

messaggio di ACK può essere contenuto un payload di tipo SDP indicate la
descrizione della sessione, così come accettata dall'utente. Ad esempio, a fronte
di un codec audio G.711, il chiamato potrebbe indicare l'utilizzo di un codec
G.729.
Nel caso in cui questo dato venga a mancare, il chiamante utilizzerà la

descrizione della sessione a lui proposta nel messaggio SDP iniziale.

Voce su IP Page 60
Il messaggio di ACK (così come anche il messaggio di BYE) non è una

classica risposta al messaggio di INVITE. Infatti, il messaggio ACK viene inviato
dallo stesso soggetto che ha precedentemente inviato l'INVITE. Il messaggio di
INVITE ha una risposta che può essere, ad esempio, 200 OK; il messaggio ACK
viene generato dal chiamante se costui accetta la risposta, che può contenere,
ad esempio, una codifica diversa da quella originariamente prevista.
3.5.2.3. BYE
Il messaggio di BYE comunica al chiamante che la chiamata non è possibile.

Questo messaggio può essere generato da ambedue le parti (chiamato /
chiamante) e in qualunque momento (fase di instaurazione della chiamata
oppure con chiamata già attiva). Nel caso in cui la chiamata sia attiva, l'utente
che riceve un BYE deve cessare immediatamente l'invio dei flussi dati.
3.5.2.4. CANCEL
Il metodo CANCEL cancella una richiesta

ancora pendende, ed è utilizzabile solo nella fase
di apertura della connessione. Infatti, SIP
ammette l'apertura di una connessione verso più
terminali contemporaneamente (ad esempio il
telefono d'ufficio e il telefono mobile),
solitamente gestite da un server (proxy, ad
esempio). Nel momento in cui una delle due
richieste viene accettata e il pacchetto di ACK
torna al server (il quale lo propagherà all'utente),
il risultato della seconda richiesta perderà di
importanza. A questo punto, il server potrà
inviare un messaggio CANCEL verso la
destinazione da cui ancora attende risposta,
cancellando le richieste ancora pendenti ed
evitando un inutile sovraccarico della rete.
Questo metodo cancella tutte le richieste non

ancora soddisfatte, che abbiano gli stessi
parametri Call-ID, To, From e Cseq, ma non quelle definitive, e può essere
utilizzato in ogni momento della chiamata.
Nel caso in cui una delle due fallisca, questo non implica che la chiamata
debba essere abbattuta. In questo caso, il terminale che fa fallire la chiamata
genererà un CANCEL (o meglio, il terminale genererà un BYE, ma il proxy che ha
duplicato la chiamata lo trasformerà in CANCEL), permettendo al chiamante che
una possibile via di connessione è fallita, ma altre stanno ancora operando per
portare a termine la chiamata.
3.5.2.5. OPTIONS
Il metodo OPTIONS può essere utilizzato per richiedere informazioni sullo

stato di un server, sui tipi di flussi di dati che può accettare e generare, sui
metodi supportati. Un possibile impiego di questo metodo è per richiedere, ad un
terminale che è attualmente impegnato in una chiamata (e che quindi non può
rispondere positivamente ad messaggio INVITE), i parametri audio/video
compatibili con il terminale stesso, per poterli utilizzare in un successivo
messaggio di INVITE.
3.5.2.6. REGISTER
Questo messaggio è utilizzato da un client per registrare un indirizzo

all'interno di un SIP server; questa registrazione può essere fatta da locazioni
fisiche anche diverse. La registrazione può essere fatta sia in unicast, che in
multicast all'indirizzo well-known "all SIP server"sip.mcast.net (224.0.1.75). In
questo secondo caso, il dominio amministrativo di validità della registrazione

Voce su IP Page 61
deve essere in qualche modo limitato (ad esempio con un valore del campo Time
To Live del pacchetto IP), per evitare la registrazione in troppi server.
Un utente può inoltre registrarsi su diversi siti, usando diversi valori di Call-
ID, e definire vari servizi e preferenze tra questi.
3.5.3. I principali campi dell'header
3.5.3.1. From, To
Indicano l'originatore e il terminatore della

sessione SIP. I nomi indicati sono URL SIP,
secondo la terminologia già vista.
Una particolarità è che questi campi sono

legati alla sessione SIP, e non a chi ha generato il
messaggio in esame. Di conseguenza i campi
From e To rimangono invariati nel passaggio tra il
messaggio di richiesta e il messaggio di risposta.
3.5.3.2. VIA
Il campo VIA è usato nel caso in cui una transazione SIP richieda
l'interazione di parecchi server proxy. In questo caso ogni server introduce una
nuova riga (con l'indicazione di sé stesso) di tipo VIA all'interno dell'header SIP.
Questo permette di ricostruire il percorso del messaggio, consentendo al
messaggio di risposta di compiere lo stesso percorso, ma in senso inverso. Gli
header di tipo VIA sono aggiunti e tolti dinamicamente al messaggio: una nuova
riga VIA viene aggiunta man mano che il messaggio avanza verso la
destinazione, mentre le stesse righe vengono tolte nel percorso all'indietro.
3.5.3.3. Call-ID
E' una stringa che identifica univocamente

una sessione SIP (ad esempio una sessione di
invito oppure di registrazione). Normalmente ha
la forma di un URL, formato da un numero
identificativo progressivo e dal dominio in cui
questo valore è stato calcolato.
Il Call-ID può cambiare ad esempio nel caso

in cui, in una sessione, si generi un nuovo
messaggio di INVITE per cambiare i parametri
operativi (codec, ad esempio) della sessione.
3.5.3.4. Cseq

Voce su IP Page 62
Il campo Command Sequence include il comando che ha generato la

sessione e viene mantenuto per tutta la sua durata. In altre parole, in una
sessione INVITE questo parametro manterrà sempre lo stesso valore sia per i
messaggi di richiesta, sia per i messaggi di risposta.
3.5.3.5. Subject
Il campo Subject ha il significato a cui si è già abituati ed indica lo scopo

della sessione.
3.5.3.6. Content-Type, Content-Length, Content-Encoding
Questi campi presentano le principali

caratteristiche del payload del pacchetto SIP, ove
presente. Il campo Content-Type indica il tipo di
payload con una codifica di tipo MIME, ad
esempio una mail. Il campo Content-Length
indica la lunghezza del payload stesso. Infine, il
campo Content-Encoding indica le operazioni
che, eventualmente, devono essere fatte sul
payload per poterlo leggere. Ad esempio, una
mail può essere codificata in diversi formati
(UTF-8, UTF-7, etc) e questa informazione deve
essere conosciuta dal destinatario per poter
interpretare correttamente i dati trasmessi.
3.5.4. Codici di errore
Analogamente al protocollo HTTP, anche SIP

definisce delle classi di risposta che, con codici di
errore distinti, permettono di ricostruire meglio
l'accaduto.
3.5.4.1. Informational
La classe di tipo 1xx indica che il server o il proxy contattato deve compiere
ulteriori operazioni e non ha una risposta definitiva.
Il client deve attendere una ulteriore informazione dal server che è obbligato
a inviare una messaggio 1xx se ritiene di impiegare più di 200ms per ottenere
una risposta definitiva.

Voce su IP Page 63
Le risposte di tipo 1xx attualmente definite sono le seguenti:
100: Trying
180: Ringing
181: Call Is Being Forwarded
182: Queued
3.5.4.2. Success
La richiesta ha avuto successo e deve terminare la ricerca.
L'unico codice definito è 200; OK.
l'informazione contenuta nella risposta dipende dal metodo usato nella

richiesta:
BYE: la chiamata è stata terminata, il corpo del messaggio è vuoto
CANCEL: la ricerca è stata cancellata, il corpo del messaggio è vuoto
INVITE: il chiamato ha accettato di partecipare, il corpo del messaggio

indica le capacità di ricezione del chiamato
OPTIONS: il chiamato ha accettato di rendere disponibili le sue capacità di

ricezione, includendole nel corpo del messaggio
REGISTER: la registrazione ha avuto successo
3.5.4.3. Redirection
Le risposte 3xx divulgano informazioni sulla nuova localizzazione dell'utente

o sui servizi alternativi che possono soddisfare la richiesta attraverso l'impiego
del campo Contact dell'header SIP.
Ogni reindirizzamento non deve suggerire nessun indirizzo già contenuto nel
cammino definito dagli header Via della richiesta:
300: Multiple Choices
301: Moved Permanently
302: Moved Temporarily
303: See Other
305: Use Proxy
380: Alternative Service
3.5.4.4. Client-Error
Le risposte 4xx sono riferite a delle richieste fallite. Il client non deve
riprovare a inviare la richiesta senza modificarla (ad esempio, potrebbe dover
aggiungere l'appropriata autorizzazione).

Voce su IP Page 64
In ogni caso, la stessa richiesta potrebbe aver successo presso un altro

server. I codici previsti sono i seguenti:
400: Bad Request
401: Unauthorized
402: Payment Required
403: Forbidden
404: Not Found
405: Method Not Allowed
406: Not Acceptable
407: Proxy Authentication Required
408: Request Timeout
409: Conflict
410: Gone
411: Length Required
413: Request Entity Too Large
414: Request-URI Too Large
415: Unsupported Media Type
420: Bad Extension
480: Temporarily not available
481: Call Leg/Transaction Does Not Exist
482: Loop Detected
483: Too Many Hops
484: Address Incomplete
485: Ambiguous
486: Busy Here
3.5.4.5. Server-Error
Le risposte 5xx indicano un fallimento dovuto alla responsabilità di un

particolare server. Non sono fallimenti definitivi e non devono terminare una
ricerca se altri indirizzi non sono ancora stati provati:
500: Internal Server Error
501: Not Implemented

Voce su IP Page 65
502: Bad Gateway
503: Service Unavailable
504: Gateway Time-out
505: SIP Version not supported
3.5.4.6. Global-Failure
Le risposte di tipo 6xx indicano che un server ha una informazione definitiva

riguardo un particolare utente, non solo circa la richiesta specifica indicata nel
request-URI:
600: Busy Everywhere
603: Decline
604: Does not exist anywhere
606: Not Acceptable
3.5.4.7. Esempio di messaggi
In Figura sono riportati due messaggi di una

sessione di tipo INVITE. E' possibile notare come
tra il primo messaggio (Request) e il secondo
(Response) ci siano i campi From, To, Call-ID e
Cseq che rimangono invariati. Si può notare
anche come i parametri SDP della sessione
cambino tra i due messaggi: cambiano sia
parametri relativi all'audio, sia (ovviamente) le
informazioni del flusso audio in termini di
indirizzo/porta (in quanto in una telefonata vi
sono due flussi).
3.6. Le principali operazioni SIP

In questa sezione verranno illustrate le principali fasi del protocollo SIP.
3.6.1. Transazione

Voce su IP Page 66
Prima di poter illustrare le varie fasi di una

chiamata SIP, è opportuno definire la
transazione, che racchiude sostanzialmente una
chiamata SIP dal momento in cui il SIP Client
(UAC) emette un pacchetto di Invite.
Una volta che l'host è riuscito a risolvere

l'indirizzo del server SIP, il client SIP invia una o
più richieste SIP a questo server e riceverà una o
più risposte dallo stesso. L'insieme di queste
operazioni si identificano come transazioni SIP.
Tutte le risposte ad una richiesta devono
contenere gli stessi valori nei campi di Call-ID,
CSeq, To, e From.
3.6.2. Risoluzione di un indirizzo SIP
Quanto un client (che puà essere uno User

Agent oppure un SIP Proxy) si trova a dover
risolvere un indirizzo SIP, deve innanzitutto
controllare se l'URI contiene l'indicazione esplicita
della porta da utilizzare oppure un indirizzo
numerico. In questi due casi, l'URI indica l'host
finale e, al più, è richiesta una risoluzione DNS di
tipo A (oppure AAAA per indirizzi IPv6) per
ricavare l'indirizzo IP dell'host.
In caso contrario (l'indirizzo non è numerico,

oppure non vi è indicata alcun numero di porta),
il client SIP richiede la risoluzione di un record
NAPTR per il dominio richiesto, ricavando il
protocollo di trasport. Se questo è disponibile,
procede con il relativo record SRV, ricavando
l'host e la porta del server SIP da contattare. In
caso invece il record NAPTR non sia disponibile,
crea una richiesta direttamente per un record
SRV, indicando in essa i protocolli di trasporto ammessi dall'utente.
All'ottenimento di un record SRV può essere necessario ancora risolvere il nome
del server in un indirizzo numerico, con un ulteriore query di tipo A/AAAA.
Alcuni server DNS sono in grado di anticipare le mosse del client: a seguito
di una richiesta di tipo NAPTR, sono in grado di confezionare una risposta che
contiene tutti i record voluti, ossia NAPTR, SRV e A/AAAA. Questo consente di
ridurre il numero di interrogazioni al DNS necessarie per risolvere un indirizzo.
Nel caso in cui il record SRV non fosse disponibile, il client fa un ultimo
tentativo di risolvere il nome indicato nell'URI come se fosse un host, richiedendo
quindi la risoluzione di un record A/AAAA. In questo caso, il client contatterà la
controparte utilizzando il protocollo UDP che dovrebbe essere il minimo comun
denominatore tra tutte le implementazioni SIP, oppure il trasporto TLS/TCP nel
caso in cui l'utente richieda una sessione sicura. Tuttavia, potrebbe essere
possibile anche utilizzare il protocollo TCP in casi particolari, ad esempio quando
ci si rende conto di avere richieste la cui dimensione è superiore alla massima
MTU ammissibile sul percorso.
3.6.2.1. Esempio di risoluzione di indirizzo SIP

Voce su IP Page 67
Si supponga un host che deve contattare l'utente

SIP con identificativo sip:bob@foo.com. La sua
prima azione sarà di contattare il DNS
responsabile del dominiofoo.com, richiedendogli
l'elenco dei record NAPTR, ed ottenendo la
risposta seguente:
; order pref flags service regexp replacement

IN NAPTR 50 50 "s" "SIPS+D2T" "" _sips._tcp.foo.com
IN NAPTR 90 50 "s" "SIP+D2T" "" _sip._tcp.foo.com
IN NAPTR 100 50 "s" "SIP+D2U" "" _sip._udp.foo.com
Questa risposta indica che ikl server supporta

TLS su TCP, TCP e UDP, in questo ordine di
preferenza. Se, ad esempio, il client supporta
solamente TCP e UDP, verrà utilizzato il trasporto
TCP in quanto questo record ha ordine inferiore.
Il client proseguirà richiedenbdo la risoluzione del
record _sip._tcp.foo.com, di tipo SRV,
ottenendo la seguente risposta:
;; Priority Weight Port Target

IN SRV 0 1 5060 server1.foo.com
IN SRV 0 2 5060 server2.foo.com
Questa risposta farà si che il client contatterà probabilmente la macchina

server2 (in quanto ha un peso doppio diserver1, a parità di priorità) sulla porta
5060, con il protocollo TCP.
Nel caso in cui non fosse noto l'indirizzo IP della macchinaserver2.foo.com,

verrebbe nuovamente contattato il DNS con la richiesta di risoluzione del record
A/AAAA per server2.foo.com. Questa macchina, una volta contattata, dovrà
avere coscienza dell'esistenza dell'utente bob e dovrà essere in grado di
recapitare la chiamata a destinazione.
3.6.3. Chiamata con Proxy Server
In Figura è riportato un esempio di chiamata

con Proxy Server. Il server proxy accetta l'INVITE
request (passo 1), contatta il server delle
locazioni (passo 2), ottiene l'indirizzo preciso
della posizione attuale del chiamato (passo 3), e
invia un SIP INVITE request all'indirizzo ritornato
dal location server (passo 4).
L'user agent server allerta l'utente (passo 5)

e ritorna un success indication al proxy server
(passo 6) che, a sua volta, ritorna la risposta al
chiamante (passo 7).
La ricezione del messaggio è confermata dal

chiamante usando un messaggio di tipo ACK
(passo 8) che viene inoltrata al chiamato
attraverso il server proxy (passo 9) oppure
direttamente.
Per chiarezza nel disegno si è in realtà tralasciato un messaggio. Infatti,

l'utente impiega tipicamente parecchio tempo (confrontato alla velocità di reti ed
elaboratori) a rispondere alla chiamata. Tuttavia, mentre il messaggio 200 OK
può essere inviato solamente quando l'utente ha accettato la chiamata, SIP
impone un tempo massimo entro cui la risposta va data. In questo caso, il
terminale chiamato è tenuto a rispondere con un messaggio 180 Ringing,
informando il chiamante che l'operazione è ancora in corso, per poi inviare il
messaggio definitivo non appena ha ricevuto una conferma dall'utente.

Voce su IP Page 68
3.6.4. Chiamata con Redirect Server
Il Redirect Server è utilizzato per informare il

chiamante dell'effettiva locazione del chiamato.
In questo modo la chiamata potrà essere diretta
tra le due controparti, senza alcuna
intermediazione (proxy, etc).
In questo caso, il Redirect Server accetta la

chiamata (passo 1), verifica l'effettiva locazione
dell'utente contattando un Location Server (passi
2 e 3), quindi, anzichè contattare personalmente
il nuovo indirizzo trovato, lo notifica al chiamante
(passo 4). Il chiamante è tenuto, a questo punto,
a confermare al Redirect Server la risposta
ottenuta, inviando un messaggio ACK (passo 5).
A questo punto la chiamata procede secondo

i passi già visti in precedenza: un nuovo INVITE è
inviato direttamente alla destinazione (passo 6),
la quale procederà a far squillare il terminale
(passo 7), e ad inviare una risposta non appena sarà possibile (passo 8; anche
qui potrebbe esserci una risposta temporanea 180 Ringing).
di tipo
L'instaurazione della chiamata si conclude con l'invio di un messaggio di
acknowledge (passo 9) verso il chiamato.
3.6.5. Esempio di chiamata complessa
L'utente Watson che lavora sull'host

saturn.bell-tel.com si registra, nella fase di
inizializzazione della macchina, con una richiesta
multicast sul server SIP locale bell-tel.com. In
questa registrazione comunica, tra le altre cose,
che il suo User Agent si aspetta di ricevere le
richieste sulla porta 3890 di UDP. Tutti gli inviti
per l'utente watson@bell-tel.com che arriveranno
sul server sip.bell-tel.com saranno deviati a
watson@saturn.bell-tel.com utilizzanto il
protocollo UDP e la porta 3890.
La registrazione scade dopo due ore.
A questo punto di supponga che l'utente Bell

chiami Watson al suo indirizzo pubblico
watson@bell-tel.com. In questo messaggio sarà
incluso un messaggio SDP che indicherà le
caratteristiche della sessione; in questo caso è
presente solo audio e l'host mittente sarà kton.bell-tel.com utilizzzando la porta
3456. Le codifiche supportate saranno 0(PCMU), 3(GSM), 4(G.723), 5(DVI4). Di
conseguenza il canale RTCP sarà aperto sulla porta 3457.

Voce su IP Page 69
L'accettazione della chiamata è confermata dal

server (100 Trying), dopo una ricerca sui
database (passo 3). A questo punto, il server
comunica che la chiamata è stata inviata al
destinatario (passo 4). Sono tutavia presenti due
chiamate attualmente in coda per il presente
utente. E' quindi necessario aspettare che le
chiamate precedenti terminino; la chiamata
corrente è accodata alle precedenti (passo 5).
Nel momento in cui una delle precedenti

chiamate termina, il server notifica l'evento al
client: adesso ci sono solamente più due
chiamate in coda (passo 6).
Finalmente le chiamate precedenti sono

terminate: il server manda la risposta200 OK,
indicante che la chiamata è stata accettata dal
destinatario. Il corpo del messaggio indica le
capacità di ricezione del mittente: il destinatario
può ricevere solo PCMU e GSM (RTP Payload
Type 0 e 3) e il canale audio RTP è identificato
dalla porta 5004, mentre quello RTCP è sulla
porta 5005 (passo 7).
La chiamata è stata deviata sul server

boston.bell-tel.com, (header Contact). Ora
Watson può inviare il flusso audio alla porta 3456
di kton.bell-tel.com e Bell alla porta 5004 del
boston.bell-tel.com.
Dopo che i due utenti hanno concordato i

parametri del flusso audio, Bell conferma la
chiamata con un ACK (passo 8).

Voce Su IP2

Caricato da

Informazioni sul documento

Descrizione:

Titolo originale

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Descrizione:

Copyright:

Formati disponibili

Voce Su IP2

Titolo originale:

Caricato da

Descrizione:

Copyright:

Formati disponibili

Voce su IP Page 1

Capitolo 1. Voce su IP: i concetti fondamentali

1.1.1. La tecnologia di base

Prima di iniziare la trattazione dell'argomento VoIP, è opportuno fare un

1.1.1.1. Rete telefonica e commutazione di circuito

La rete PSTN (Public Switched Telephony

Ciò significa che per tutta la durata della

La banda costante e il collegamento diretto

file://localhost/C:/Inetpub/wwwroot/netlibrary/books/voip.htm 8.24.27 22/10/2005

interlocutori non parlano contemporaneamente: quando uno parla l'altro

Un altro limite della rete telefonica è l'utilizzo di un codec standard e

Questi motivi portano a concludere che, tecnicamente, la tecnologia su cui si

1.1.1.2. La rete dati e la commutazione di pacchetto

La totalità delle reti dati oggi esistenti si basa

La architettura di rete dati allo stato attuale è

Alcuni pacchetti di uno stesso flusso, però, possono percorrere cammini

La tecnologia a commutazione di pacchetto permette di ovviare facilmente ai

file://localhost/C:/Inetpub/wwwroot/netlibrary/books/voip.htm 8.24.27 22/10/2005

Il costo di una "chiamata" in tecnologia dati è quindi normalmente

Infine, la rete IP non ha il call setup, rendendo la gestione della chiamata

1.1.2. Le differenti visioni della Voce su IP

Della tecnologia Voce su IP si fa un gran

l'utente domestico (visione "consumer")

1.1.2.1. La visione "consumer" della Voce su IP

Probabilmente, la prima volta in cui il termine

La VoIP era quindi intesa come uno

file://localhost/C:/Inetpub/wwwroot/netlibrary/books/voip.htm 8.24.27 22/10/2005

macchina remota (ad esempio per risolvere problemi di configurazione),

I benefici della tecnologia VoIP "adattata" ad

D'altro canto, questa visione può essere

non tutti gli utenti dispongono di un PC,

il PC deve essere permanentemente

sono possibili solo chiamate PC-to-PC; manca la possibilità di chiamare un

il PC difficilmente gestisce la mobilità, caratteristica a cui sono ormai

Il problema fondamentale di questa visione è pertanto il fatto che vi sia un

1.1.2.2. La visione "telecom" della Voce su IP: Telephony over IP

Nella visione degli operatori telefonici, la

Con il termine VoIP si indica infatti un

file://localhost/C:/Inetpub/wwwroot/netlibrary/books/voip.htm 8.24.27 22/10/2005

prevedere un meccanismo di conversione della segnalazione SS#7 nella

Questo implica una serie di conseguenze:

anche un telefono tradizionale può

1.1.2.2.1. ToIP: le ragioni della scelta

Un dato di fatto è che, ormai, il traffico di

In passato (e spesso ancora oggi), il traffico

file://localhost/C:/Inetpub/wwwroot/netlibrary/books/voip.htm 8.24.27 22/10/2005

L'incremento del numero di utilizzatori di reti IP ha fatto sì che nascessero

Nel momento in cui la rete IP è in grado di differenziare il servizio fornito a

La rete IP può quindi trasformarsi in una rete multiservizio dove il cuore

Vi sono alcuni motivi che stanno frenando la

largo numero di persone (soprattutto negli

file://localhost/C:/Inetpub/wwwroot/netlibrary/books/voip.htm 8.24.27 22/10/2005

il conto della "convenienza" di una tecnologia rispetto all'altra non si fa sui

Queste problematiche fanno sì che gli operatori telefonici tradizionali siano

1.1.2.2.2. Esempio di rete ToIP

Nella visione degli operatori telefonici, quindi,

Il modello di adozione di VoIP da parte dei

Uno dei primi prodotti commerciali per realizzare questa infrastruttura è

1.1.2.3. La visione "enterprise" della Voce su IP