1.1 IP TELEPHONY
8
Nell’IP-Telephony quindi esistono tipologie di telefoni in grado di interfacciarsi
direttamente ad un collegamento IP come ad esempio la LAN aziendale o alla
propria connessione internet e sono in grado di effettuare chiamate e inviare
messaggi verso tutti i dispositivi raggiungibili tramite la rete stessa. Inoltre sono
in grado di interoperare con altri tipi di apparecchiature, come ad esempio
computers, videocamere ,segreterie telefoniche IP, e altri tipi di dispositivi.
Le chiamate nel mondo della IP-Telephony quindi non vengono più gestite
tramite le vecchie centraline telefoniche ma vengono elaborate da veri e propri
sistemi chiamati ”proxy” e “gateway” che implementano tutte le stesse
funzionalità delle centraline di un tempo oltre che a nuove funzioni. I proxy
svolgono più che altro funzioni di instradamento mentre i gateway svolgono
anche funzione di conversione su altre tecnologie. Ad esempio un gateway
PSTN si occupa di convertire le chiamate telefoniche dalla rete IP alla rete
PSTN normale. Questo quindi permette l’affiancamento delle nuove reti di IP-
Telephony alle reti PSTN pre-esistenti.
E crescendo l’affidabilità del servizio – oggi si può ragionevolmente affermare
che il «passaggio» della voce su reti IP gestite è paragonabile in termini di
qualità a quella delle reti pubbliche – ecco che le grandi organizzazioni in
procinto di sostituire i vecchi sistemi telefonici hanno strizzato l’occhio a
soluzioni complete di IP telephony, così come i carrier di telecomunicazione
hanno iniziato a trasferire le proprie reti Pots verso architetture di nuova
generazione con l’obiettivo di integrare le nuove tecnologie di trasporto dati
preservando allo stesso tempo gli investimenti pregressi.
Le barriere che per anni hanno impedito l’adozione allargata del IP Telephony
all’interno dei network enterprise sono quindi cadute una dopo l’altra.
Gli esperti di settore si aspettano, dopo l’entrata in scena dei grandi nomi del
networking, che anche gli operatori di rete mobile possano abbracciare la
tecnologia IP Telephony, magari come logica evoluzione di architetture di
unified enterprise messaging ormai destinate a essere aggiornate per supportare
meglio volumi di trasmissione dati molto cospicui.
1.1 IP TELEPHONY
9
Il funzionamento dei nuovi apparati di IP Telephony si basa oltre che
ovviamente all’utilizzo delle reti IP alla definizione di un protocollo comune
che permette alle varie entità di rete di comunicare tra loro, sia per quanto
riguarda quello che è la segnalazione sia per quanto riguarda il trasporto dei
canali.
Oggigiorno esistono molte e diverse implementazioni nel campo dell’IP-
Telephony, parte di queste sono proprietarie, e altre no. Per cercare di arginare
la giungla delle implementazioni differenti anche a livello protocollare si sono
definiti protocolli standard per la comunicazione tra enti che appunto lavorano
nel campo dell’ IP-Telephony.
Figura 1 Esempio di un’architettura IP-Telephony tra due aziende e il loro collegamento
con reti PSTN.
1.1 IP TELEPHONY
10
In particolare tra tutti i protocolli “standard” per IP-Telephony, ne emergono 2,
si parla di H.323 e SIP.
Il primo protocollo che è più anziano, al contrario di SIP è un protocollo
binario, tuttavia occupa notevolmente meno spazio di un protocollo di tipo
testuale, a parità di informazione, ed è più rapidamente elaborabile dalla
macchina. SIP essendo un protocollo testuale rende però più facile lo sviluppo e
il debugging delle applicazioni (in quanto è possibile leggere facilmente il
contenuto di un messaggio testuale), tuttavia questo implica che gli applicativi
che utilizzano sip hanno un codice più complesso per parsificare i messaggi.
Attualmente, il rilassamento dei vincoli di banda e di capacità elaborative sta
vanificando gli effetti positivi di una codifica binaria.
H.323 inoltre è un protocollo che si basa sull’utilizzo di un architettura
precedentemente sviluppata non per IP, di conseguenza rispetto a SIP risulta
molto più complessa e corposa. Oltre alla codifica binaria H.323 fa utilizzo di
un set di protocolli di supporto anch’essi complessi (H225, H245, H450, H460
etc).
SIP è molto più aperto rispetto allo sviluppo di nuove estensioni, infatti
definisce solo la standardizzazione dei messaggi e non uno standard per
estensioni al contrario di H.323.
Le funzionalità di H.323 (capability exchange,conference control,maintenance
operations, signaling, QoS, registration, and service discovery) sono fornite in
blocco, e difficilmente divisibili, mentre in SIP sono ben delineate e affidate a
protocolli separati.
Entrambi i protocolli utilizzano come trasporto UDP e TCP, tuttavia SIP
predilige UDP mentre H.323 per motivi di compatibilità con versioni precedenti
utilizza TCP. Sappiamo bene che la comunicazione tramite TCP aumenta il
tempo di attesa per l’instaurazione di una comunicazione.
1.2 CONTESTO E OBBIETTIVI DEL LAVORO DI TESI
11
Per queste caratteristiche sopra elencate il mondo dell’IP-Telephony sta
cominciando a preferire SIP rispetto ad H.323, anche se le implementazioni di
H.323 sono ancora presenti e utilizzate.
Quindi si può ragionevolmente ipotizzare che SIP è uno dei protocolli prescelti
per garantire l’interoperabilità dei futuri apparati di IP-Telephony.
1.2 Contesto e obbiettivi del lavoro di tesi
Il lavoro di questa tesi si colloca in primo piano, nell’ambito delle
telecomunicazioni con particolare riferimento ai protocolli per IP Telephony (in
questo caso SIP), alle architetture di rete IP e alle tecniche utilizzate su di loro (
come appunto NAT e NPAT)1.Tuttavia copre ampiamente argomenti
d’informatica per quanto riguarda appunto sistemi embedded e sistemi
operativi.
Attualmente la suite di protocolli SIP non è in grado di funzionare correttamente
quando ci sono apparati che effettuano NAT in mezzo al cammino dei due
terminali.
Il lavoro di tesi quindi si muove in due direzioni diverse, la prima è quella
appunto di compiere uno studio dei protocolli, delle architetture di rete IP, in
particolare analizzando le problematiche dei protocolli con architetture che
utilizzano “traduzione” di indirizzi di rete (natting).
Questa tesi si prefigge di studiare nel dettaglio il funzionamento sia della suite
di protocolli SIP, sia delle tecnologie di traduzione degli indirizzi , mettendo
anche in luce non solo aspetti teorici ma evidenziando anche differenze
implementative, che spesso non seguono correttamente le specifiche.
1
Network Address Translation : Tecniche utilizzate per mascherare o per utilizzare meno ip
pubblici in una rete aziendale o domestica.
1.3 OBBIETTIVI IMPLEMENTATIVI
12
Tutto questo mettendo in evidenzia il funzionamento di SIP , SDP e il
protocollo RTP in correlazione con le tecniche di traduzioni di indirizzi (detta
anche in inglese come natting), al fine di mettere in luce i motivi dell’incorretto
funzionamento della suite di protocolli in presenza di NAT. Sempre nella prima
direzione verranno poi visitate le soluzioni già esistenti mettendone in luce
aspetti positivi e negativi.
La seconda direzione invece è quella dell’innovazione, in altre parole
analizzate le soluzioni già esistenti, cerca di proporre una nuova soluzione che
sia più trasparente e allo stesso tempo implementi funzionalità di load balancing
che sotto descriveremo. Seguirà quindi l’implementazione della soluzione e un
analisi mettendo in luce quali miglioramenti ed eventuali peggioramenti ci sono
stati in riferimento alle soluzioni precedenti.
1.3 Obbiettivi implementativi
L’obbiettivo implementativo di questa tesi è di creare una estensione del
kernel linux che permetta di effettuare ALG per il protocollo SIP, vale a dire
una estensione in grado di interpretare il payload dei datagrammi UDP, che
contengono messaggi SIP e li modifichi qualora ci fosse necessità al fine di
renderli conformi con gli indirizzi di rete modificati per via della traduzione
degli indirizzi (NPAT).Tutto questo mentre l’elaboratore effettua routing IP.
Oltre a questo il kernel deve essere in grado di relazionare i flussi RTP alla
sessione SIP che li ha generati, per rendere possibili regole avanzate di
firewalling. Deve quindi cercare di ovviare a tutti i problemi che rappresenta il
NAT per SIP.
Due apparecchiature che utilizzano come protocollo SIP devono riuscire a
comunicare correttamente anche se tra gli apparati di rete viene interposto un
dispositivo linux che effettua NAT con la suddetta estensione e le due reti non
siano propriamente visibili direttamente. Questo implica che l’estensione
1.4 CONTENUTO DELLA TESI
13
sviluppata deve rendere trasparente il network address translation tra le due reti
anche a dispositivi che non sono in grado di rilevarlo.
Per finire l’obbiettivo consiste anche di permettere l’utilizzo di questa estensioni
ai fini di effettuare bilanciamento del carico, cioè proporre un estensione,
sempre per il kernel linux, in grado di utilizzare il network address translation
come metodo per bilanciare e per celare dietro un singolo indirizzo IP una
batteria di servers SIP. L’estensione quindi dovrà essere in grado di ricevere
richieste SIP sull’indirizzo IP pubblico e inoltrarle verso il server SIP meno
carico.
1.4 Contenuto della tesi
Questa tesi si compone di 7 capitoli. Nel secondo capitolo verrà illustrata la
suite di protocolli SIP, e verranno fatti alcuni esempi. Nel capitolo 3 invece
verrà analizzato i problemi della suite di protocolli quando questa viene
utilizzata su reti che utilizzano tecniche di “NAT”. Per quanto riguarda invece il
contenuto del capitolo 4 , esso verrà dedicato a proporre una soluzione del
problema in ambiente Linux, oltre che a descriverne la implementazione. Nel
quinto capitolo, invece verranno fornite informazioni basilari su come utilizzare
gli strumenti prodotti, senza illustrare in modo tecnico come questi poi
funzionino. Il capitolo 6 invece è dedicato interamente al testing e alla
validazione dell’implementazione prodotta evidenziando punti di forza e punti
di debolezza riscontrati dell’implementazione riscontrati durante lo svolgimento
della fase di test.
L’ultimo capitolo trae le conclusioni del lavoro di tesi effettuato, e cerca di
delineare quali effettivi ampliamenti può avere in un futuro.
2.1 IL PROTOCOLLO SIP (SESSION INITIATION PROTOCOL)
14
Capitolo 2 La suite di protocolli SIP
Il seguente capitolo si pone l’obbiettivo di fare una panoramica sulle tecnologie
su cui appunto questo lavoro è stato svolto, in particolare mettendo in luce tutti
gli aspetti protocollari correlati all’ IP Telephony per quanto riguarda il mondo
“SIP” . In questo caso quindi andremo a trattare quindi non solo il protocollo
SIP ma anche gli altri protocolli su cui si appoggia [6].
Vedremo quindi cos’è SIP, a cosa serve e come è strutturato, dopodiché
andremo anche a vedere i protocolli come SDP su cui appunto SIP si appoggia
per completare le funzionalità di descrizione del contenuto di una sessione.Il
contenuto dei media , cioè dei flussi audio video invece viene trasportato
attraverso il protocollo RTP.
2.1 Il protocollo SIP (Session Initiation Protocol)
SIP è un protocollo di segnalazione il cui standard è definito dal IETF
(Internet Engineering Task Force) per stabilire delle connessioni real-time e
conferenze su reti IP [1]. Ogni sessione può includere diversi tipi di flussi dati
come audio e video, sebbene ora la maggior parte delle estensioni SIP
riguardino le comunicazioni audio. E’ un protocollo di tipo testuale e si avvicina
molto ad HTTP (hypertext transfer protocol) come struttura, anche se a livello
di trasporto utilizza UDP anziché TCP (anche se tra proxy di solito la
connessione può essere effettuata in TCP, ma questo non è oggetto dei nostri
studi in quanto di solito il NAT avviene attraverso i nodi foglia della rete). SIP è
indipendente dal tipo di rete su cui si appoggia, è stato strutturato per essere uno
standard aperto e scalabile, in modo che possa essere utilizzato per diversi
scopi. Tra quelli già citati ricordiamo ad esempio l’IP-Telephony, la
2.1 IL PROTOCOLLO SIP (SESSION INITIATION PROTOCOL)
15
videoconferenza, il multiplayer, la chat, l’email ma anche streaming di eventi
live o webtv.
Figura 2 Stack Protocollare di SIP
2.1.1 Struttura e architettura
Come già detto, SIP è un protocollo di tipo testuale ispirato ai protocolli HTTP
e SMTP (Simple Mail Transfer Protocol), dei quali è simile sia la sintassi sia il
sistema di funzionamento, e anch’esso lavora con un’architettura client/server.
Lo scopo di SIP è la gestione delle chiamate, l’attivazione delle sessioni e la
chiusura delle stesse, SIP non si occupa del trasporto dei dati (audio/video) ma
solo della segnalazione, la comunicazione vera e propria avviene attraverso altri
protocolli come RTP (Real Time Protocol). Nella fase di setup della chiamata
vengono definite le caratteristiche della connessione da stabilire, queste
informazioni si trovano all’interno del payload2 del pacchetto.
2
Rappresenta la parte dei dati del pacchetto. Ogni pacchetto è diviso in due parti: l’intestazione
(header) che contiene tutti i campi utilizzati per l’instradamento della chiamata e le informazioni
di servizio del protocollo, e la parte dati (payload) che contiene le informazioni trasportate.
2.1 IL PROTOCOLLO SIP (SESSION INITIATION PROTOCOL)
16
Le entità principali che interagiscono attraverso SIP sono:
• SIP User Agent (UA) Chiamato anche terminale, rappresenta
un’estremità di una comunicazione, è un dispositivo hardware o
software che è in grado di iniziare e ricevere una chiamata utilizzando
SIP come protocollo di segnalazione. Esistono programmi che possono
simulare un terminale SIP in un PC, questi vengono anche chiamati
softphone, oppure possono essere dei dipositivi simili a telefoni
tradizionali, che invece di appoggiarsi ad una rete telefonica tradizionale
(PSTN o ISDN), utilizzano una connessione IP. Gli UA possono
funzionare sia come server, sia come client a seconda se ricevono o
iniziano una chiamata.
• SIP Proxy Server Si occupa di gestire le chiamate per una determinata
area, inoltra, smista e rielabora le chiamate che gli arrivano secondo le
politiche definite. Normalmente gestisce tutti gli utenti / UA di un
dominio SIP, e smista le chiamate in arrivo sui relativi UA, o in maniera
più complessa se viene definito un criterio per la gestione personalizzata
dei profili per ogni utente. Se non è in grado di servire la chiamata,
questa è inoltrata al proxy successivo o verso il dominio specifico, in
questo modo il proxy funziona sia da client sia da server. La gestione
delle chiamate può essere fatta tenendo conto dello stato delle stesse,
quindi il proxy memorizza queste informazioni per tutta la durata della
sessione della chiamata.
• SIP Redirect Server Reindirizza le chiamate SIP verso altre
destinazioni, viene utilizzato per associare serie di indirizzi differenti, la
differenza sostanziale rispetto al proxy è che questo non si occupa di
inoltrare la chiamata all’indirizzo specificato, ma notifica allo UA (o ad
un proxy precedente) l’indirizzo da chiamare e effettivamente, e il client
si occupa di rifare la chiamata a questo nuovo indirizzo. La procedura
2.1 IL PROTOCOLLO SIP (SESSION INITIATION PROTOCOL)
17
può essere, infatti, simile a quella utilizzata dai server DNS in modo
iterativo.
• SIP Registrar Mantiene un database delle registrazioni degli utenti,
questo elemento viene interrogato da un proxy o da un redirect server
per conoscere informazioni riguardo agli utenti chiamati. E’ utilizzato ad
esempio per notificare all’infrastruttura SIP l’attuale locazione
dell’utente (ad esempio se questo si trova in ufficio o è rintracciabile
tramite cellulare o tramite un altro indirizzo SIP), così che si possa
instradare la chiamata verso il terminale attualmente attivo. Attualmente
nella maggior parte delle implementazioni software il registrar è
direttamente implementato all’interno del proxy.Tuttavia come vedremo
più in seguito, si farà distinzione tra Registrar e semplice proxy nelle
politiche di load balancing, questo per smistare meglio richieste di
registrazione e le successive chiamate entranti/uscenti.
Il funzionamento di SIP si basa su architettura di tipo richiesta – risposta [2].
Ogni UA può effettuare una richiesta sia tramite proxy che non, a un altro UA ,
e ricevere una risposta. Ogni richiesta deve essere sempre seguita da una
risposta.
Figura 3 Esempio di richiesta-risposta in SIP
In questa caso ad esempio il telefono A sarà un UAs in altre parole svolgerà la
funzione di server mentre il telefono B sarà un UAc cioè un client.
Come avviene una chiamata nel contesto dell’IP Telephony? Ad esempio
facendo riferimento alla Figura 3 possiamo immaginare che il telefono SIP del
dominio A, voglia chiamare il telefono SIP B dello stesso dominio attraverso un
SIP server.
Ricevi informazioni sui nostri servizi, sulle offerte e non perdere news e consigli su università e lavoro.
