Indice delle figure

Introduzione

Contesto

Il VoIP

Il Voice over Internet protocol è da considerarsi uno degli argomenti più interessanti, al momento, nel settore delle telecomunicazioni.

Questa tecnologia sta riscuotendo un successo sempre più grande negli ultimi anni è sta attirando sempre più attenzione sia nel settore delle piccole e grandi aziende, sia in ambito residenziale.

Contribuiscono a tutto questo molti fattori: Un’architettura Voip può essere plasmata al meglio anche sulle più particolari esigenze in fatto di telecomunicazioni, da una semplice conversazione all’interno della stessa azienda ,ad una teleconferenza multipunto tra diverse aziende dislocate in diversi continenti.

Ma nonostante le potenzialità siano grandi ,i costi di sviluppo delle infrastrutture restano molto bassi.

Sicuramente anche l’affermarsi delle connessioni a banda larga ha avuto un ruolo chiave maggiormente, però, in ambito di telefonia residenziale. Alcuni tipi di organizzazioni già si avvantaggiano di connessioni a banda larga “always on” :multinazionali, organismi di tipo governativo ed anche istituzioni quali le università potrebbero quindi facilmente usufruire del valore aggiunto che porta con se l’utilizzo della rete IP .

Il Progetto SapienTel

Cos’è SapienTel

È un’architettura VoIP per permettere alle organizzazioni di natura accademica di usufruire di servizi di telecomunicazioni a valore aggiunto .

Ciò significa che avendo studiato le particolarità degli istituti universitari ed avendo individuato le specifiche necessità nell’ambito delle telecomunicazioni, si è sviluppato un progetto che potesse soddisfarle con le tecnologie più innovative , scalabili ed affidabili di cui si disponeva allo stato dell’arte.

Quindi le fasi procedurali per la realizzazione di SapienTel sono state le seguenti:

• Analisi degli istituti di natura accademica

  • Funzionamento

  • Risorse informatiche e di rete disponibili

• Studio delle possibili esigenze in ambito di telecomunicazioni

  • Individuando i settori principali (didattica, ricerca, divulgazione scientifica)

• Analisi delle tecnologie più rilevanti per il Voice over IP allo stato dell’arte

  • Tenendo in considerazione principalmente le scelte più innovative , scalabili, stabili ed aperte alla ricerca universitaria

• Analisi comparativo-funzionale di alcune delle possibili soluzioni Server

  • Utilizzando un test bed creato ad hoc

• Realizzazione del progetto SapienTel

  • La parte principale di questa fase è stata anch’essa svolta nel test bed

  • Una seconda parte di questa fase ha invece coinvolto le risorse informatiche e di rete dell’Università di Roma “La Sapienza” in particolare del dipartimento INFOCOM.

Analisi degli istituti di natura accademica.

L’Università è una comunità di docenti e studenti che costituisce un patrimonio per la crescita culturale, sociale ed economica per l’intero paese, di cui è anche motivo di prestigio. I settori più importanti in ambito accademico sono la didattica, la ricerca e la divulgazione scientifica.

Questi 3 settori sono strettamente legati, infatti, è grazie alla ricerca che si aggiornano i percorsi didattici, ed è grazie alla divulgazione scientifica che i risultati della ricerca trovano affermazione e confronto, anche in ambiti internazionali.

I rapporti internazionali universitari rivestono dunque un ruolo fondamentale, ed essi si realizzano su più livelli: partecipazione di ricercatori a progetti di ricerca con collaboratori stranieri, interazione con altre università nell’ambito di progetti per favorire la mobilità degli studenti. (Erasmus, Socrates, Leonardo....), istituzione di percorsi didattici congiunti quali dottorati internazionali ed eventi di divulgazione scientifica quali conferenze e congressi.

Risorse informatiche e di rete disponibili.

Gli istituti accademici riconoscono l’efficienza dei sistemi informatici e di telecomunicazione e sono sedi di ricerca e d’innovazione in tali ambiti.

Soprattutto negli ultimi anni si è visto un aumento d’investimenti per le architetture di rete e sistemi informatici per migliorare la didattica, dare strumenti alla ricerca e per snellire la burocrazia.

Tutti gli istituti accademici, oramai, dispongono di connessioni LAN, accessi ad internet e laboratori informatici. E’ evidente che l’elemento tecnologico che lega tutti gli istituti di natura accademica è una architettura di inter-networking. In alcuni ambiti la potenzialità che permette l’interconnessione di rete viene utilizzata solo in piccola parte. Infatti, per l’utente medio l’utilizzo di internet si riduce per lo più all’utilizzo della posta elettronica, alla condivisione di dati nella LAN dipartimentale, e all’accesso ad informazioni scientifiche (e non), tramite internet.

Studio delle possibili esigenze in ambito di telecomunicazioni

Perché organizzazioni di natura accademica dovrebbero interessarsi al VoIP ?

La crescente mobilità internazionale in ambito accademico andrebbe supportata con un’infrastruttura di telecomunicazioni appropriata. Ovviamente le linee telefoniche tradizionali possono solo in parte soddisfare tale esigenza.

Sarebbe, infatti, molto utile che gli studenti, i professori o ricercatori potessero comunicare tramite voce o video indipendentemente dalla loro posizione: casa, ufficio, campus universitario, istituto di ricerca, congresso internazionale.

Un possibile scenario potrebbe essere il seguente:

• il Professor Einstein e il Professor Meucci lavorano nello stesso istituto di ricerca.

• Il Professor Einstein si reca ad una conferenza negli Stati Uniti d’America, mentre il professor Meucci rimane in sede.

• Il professor Meucci vuole comunicare con il prof Einstein, ma non sa dove si trovi quets’ultimo.

• Tuttavia, tramite il suo client VoIP (che supporta Istant Messaging e agente di presenza) sa che è connesso in rete.

• Decide quindi di chiamare per comunicargli un’idea.

• Più tardi Einstein, tornato dalla conferenza, vuole rispondere a Meucci, ma non sa dove si trovi.

• Tuttavia, tramite il client VoIP, ed anche se Meucci è a casa (utilizzando un sistema di convergenza dei sistemi di telecomunicazione), Einstein può chiamarlo per chiedere consiglio sulla sua presentazione.

Si vede in questo esempio che sarebbe auspicabile creare un servizio che supportasse la mobilità degli appartenenti alla comunità accademica, fornendogli un servizio che potesse agevolare la comunicazione ,gestendo anche l’integrazione con altri istituti universitari ed occupandosi della convergenza con le linee telefoniche tradizionali.

Analisi delle tecnologie più rilevanti per il Voice over IP allo stato dell’arte

Questo fermento ha riguardato molti vendor commerciali ma anche egregi gruppi di ricerca universitaria. Quindi ci troviamo di fronte ad una dicotomia tra le tecnologie proprietarie e quelle standardizzate

Figura 1: Alcune delle tecnologie principali per lo sviluppo di servizi VoIP

Considerando la vasta e variegata offerta per il voice over IP ci si è posto il problema di una scelta consapevole dell’architettura di progetto migliore.

Quindi il lavoro di tesi è proceduto con un’ analisi delle offerte più autorevoli anche considerando gli sviluppi futuri.

Le proposte di tecnologie VoIP sono, in realta’, molteplici, ma non era scopo di questa tesi analizzarle tutte, invece si e’ tenuto conto di quelle ,che, per alcune caratteristiche risultavano piu’ interessanti e le abbiamo analizzate e confrontate fino a scegliere quelle che piu’ potevano essere adatte all’architettura del nostro progetto di VoIP.

Un volta scelti gli elementi di progetto abbiamo seguito una analisi ancora piu’ accurata di questi per produrre una modellazione migliore.

Skype

Al momento in cui si scrive ci sono più di 12 milioni di persone che utilizzano skype e più di un milione contemporaneamente.

Questa tecnologia è stata sviluppata da Niklas Zennstrom and Janus

Friis, cioè dallo stesso gruppo che ha prodotto Napster e KAzaa ed ovviamente riprende da questi progetti l’architettura Peer To Peer, infatti si definisce “…the first P2P telephony network… “

Figura 2: Interfaccia di skype

Skype è un software prodotto per piattaforme diverse: Mac, Linux, Windows e pocket PC (per la tesi è stato testato su Fedora Core 3 test 3 e MS Windows XP Pro ).

La qualità del suono è molto buona (50-8,000 Hz) e le comunicazioni sono criptate con il sistema 256 bit AES (Advanced Encryption Standard);

Skype utlizza TCP come protocollo di segnalazione , e UDP o TCP per il trasporto dei dati, con porte diverse per le due finalità.

L’archittetura della rete Skype ,come si vede dalla figura…, eredita la struttura dal peer to peer.

Figura 3 : Architettura della rete Skype

La rete skype si presenta decentralizzata e quindi facilmente scalabile, l’unico elemento centralizzato è il LOGIN SERVER.

Il Login Server (molto probabilmente risiedente in Danimarca)[ ] mantiene un database aggiornato degli utenti e delle password, assicurando l’unicità di queste informazioni.

Le altre entità della rete skype sono i nodi ed i super nodi.

Per nodo s’intende un qualunque utente che utilizza skype sul proprio pc ed in genere si trova in una rete protetta da firewall o NAT.

Un super nodo è un qualunque nodo con un buon quantitativo di Memoria Ram, una CPU di adeguata frequenza e che dispone di una connessione a banda larga con IP pubblico.

Per il trasferimento dei dati skype sembra preferire il protocollo UDP.

Infatti:

• se i due nodi utilizzano un IP pubblico, il trasferimento dei dati avviene P2P utilizzando UDP ( la porta la si può scegliere )

• se i due nodi sono dietro un firewall/NAT ,entra in gioco un terzo nodo che funziona come mediaproxy tra i due, ma comunque si utilizza il protocollo UDP

• se i due nodi si trovano dietro un firewall/NAT che blocca il protocollo UDP, entra sempre in gioco un terzo nodo che, in questo caso, utilizza il TCP (anche su porta 80).

Una caratteristica importante di Skype che si evince anche da tutto cio’ appena detto, è la trasparenza rispetto a firewall e NAT: risulta plausibile pensare[ ] che per fare in modo che tutto cio’ avvenga si utilizza una variante dello STUN[ ] tra nodo e super nodo.

Questo fattore unito all’auto configurazione in avvio del programma fa di skype una soluzione appetibile anche per l’utente medio.

Inoltre il software fornisce anche altri servizi:

• Chat

• Audio conferenza

• Trasferimento e scambio file

• Annuncio di presenza

• Skype-out cioè Telefonate verso linea PSTN

Ed è anche in fase di test SkypeLN cioè la possibilità di ricevere chiamate da utenti PSTN tramite la creazione di un numero di rete fissa virtuale.

Inter-Asterisk eXchange (IAX) Versione 2

IAX è un protocollo creato dalla Digium fondata da Mark Spencer colui che ha sviluppato Asterisk (ne parleremo a fondo nei prossimi capitoli).

Questo protocollo, giunto alla versione 2 nel gennaio 2005, si occupa del controllo e della trasmissione di flussi audio e video attraverso la rete IP ponendo particolare attenzione alla riduzione dell’occupazione di banda(è un protocollo binario) ed alla trasparenza rispetto a firewall/NAT.

La semplicità di questo protocollo oltre a limitare problemi d’incompatibilità tra implementazioni diverse, lo rende anche robusto ad attacchi di tipo “buffer overrun” perchè non è richiesta nessuna interpretazione di testo per la sua implementazione.

Viene utilizzato per comunicazioni tra server Asterisk oppure tra server Asterisk e client (software ed Hardware) che utlizzano IAX.

Figura 4: Protocollo IAX 2 in azione

La segnalazione ed il trasporto dei media sono multiplati utilizzando un’unica associazione UDP tra i due host (la stessa porta UDP 4569) ed un unico datagramma IP trasporta le informazioni per più conversazioni riducendo overhead IP; questa soluzione risulta vantaggiosa perchè diminuisce l’utilizzo di banda e questo è utile quando si gestiscono molti utenti.

Lo IAX per la sua semplicità, robustezza, riduzione di banda utilizzata e semplicità di gestione nelle politiche di sicurezza (Firewall/NAT), aspira ad essere la scelta migliore per implementazioni di tipo VoIP su WI-FI.

L’unico neo dello IAX è che, per ora, è un protocollo proprietario ed inoltre non supporta negoziazioni per la scelta del codec migliore.

Questi due motivi uniti alla difficoltà di trovare adattatori VoIP oppure client software che implementino lo IAX ci hanno spinto a non tenerlo in considerazione per il nostro progetto; Riconosciamo, pero’, in questo protocollo grosse potenzialita’ che potrebbero essere sfruttate al meglio anche soltanto rendendolo uno standard aperto.

Il protocollo SIP (Session Initiation Protocol)

SIP è un protocollo di segnalazione definito dal IETF (Internet Engineering Task Force)[ ] (RFC 3261 che sostituisce RFC 2543)per stabilire delle connessioni real-time e conferenze su reti IP. Ogni sessione può includere diversi tipi di usi dati come audio e video, sebbene ora la maggior parte delle estensioni SIP riguardino le comunicazioni audio .

SIP è un protocollo ispirato ai protocolli HTTP e SMTP (Simple Mail Transfer Protocol), dei quali è simile sia la sintassi sia il sistema di funzionamento.

Lo scopo di SIP è:

• la gestione delle chiamate

• l’attivazione delle sessioni

• la chiusura delle sessioni

più in dettaglio, permette di:

• determinare la locazione di un utente;

• contattare l’utente per controllare la disponibilita’ a stabilire una sessione;

• scambiare informazioni per fare in modo che la sessione si stabilisca;

• modificare sessioni multimediali preesistenti;

• concludere un sessione multimediale preesistente;

SIP e’ stato esteso[ ] ed adesso supporta la richiesta ed il trasporto di informazioni di presenza e gestisce sessioni per la messagistica istantanea (IM);Adesso include:

• Pubblicazione ed aggiornamento d’ informazioni di presenza;

• Richiesta di trasporto d’ informazioni di presenza;

• Notifica per evento di presenza;

• Trasporto di messaggi istantanei.

Nonostante l’estensione il 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 payload del pacchetto.

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( softphone). Sono anche disponibili dipositivi simili a telefoni tradizionali, che invece di appoggiarsi ad una rete telefonica tradizionale (PSTN o ISDN), utilizzano una connessione IP inoltre ci sono anche degli adattatori SIP (per esempio Sipura 2000) che permettono l’utilizzo di normali telefoni. Gli UA possono funzionare sia come server (SIP UAS), sia come client (SIP UAC) 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, controllando gli header del pacchetto. Risponde solo alle richieste degli UA (vedremo la sola eccezione per il metodo CANCEL). Se non è in grado di servire la chiamata, questa viene 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.un Proxy Server puo’ essere Stateless ed allora processa ogni richiesta o risposta SIP ma nessuna informazione sul messaggio viene immagazzinata; un Sip Proxy puo’ anche essere Stateful in questo caso tiene traccia delle richieste e risposte ricevute ed usa queste informazioni per processare i messaggi futuri.

• 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 effettivamente, e il client che si occupa di rifare la chiamata direttamente a questo nuovo indirizzo.

• 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. Viene 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), cosi` che si possa instradare la chiamata verso il terminale attualmente attivo.

In genere gli sviluppatori che producono server SIP tendono ad includere il SIP Redirect Server ed il SIP Registrar nel SIP Proxy server.

Il protocollo SIP utilizza come indirizzi gli URI (Uniform Resource Identifier)

standard , come ad esempio:

sip:alef@uniroma1.it

Oltre al caso più semplice sovresposto, è possibile aggiungere delle informazioni aggiuntive utilizzando la sintassi (GET E POST) di passaggio dei parametri del protocollo http:

sip:voicemail@sip.uniroma1.it?subject=callme

Inoltre è possibile aggiungere ulteriori informazioni in un altro formato come ad

Esempio:

• l’indirizzo di posta elettronica:

che puo’ essere utilizzato dallo UA per mandare e ricevere messaggi di posta elettronica; eccone un esempio:

sip:alef@uniroma1.it; mailto: alef@uniroma1.it

• la locazione geografica:

che può essere utilizzato per definire un indirizzo in funzione della sua posizione spaziale; eccone un esempio:

sip: alef@uniroma1.it; geo.position:=45.94_-128.0_130

(per questo caso si immagini uno scenario in cui l’utente da raggiungere sia dotato di un terminale wireless o gps).

• Il numero telefonico classico:

Questo dato e’ di rilievo nel contesto di tesi infatti, potrebbe essere utile, all’interno di un’infrastruttura SIP ,utilizzare altre tecnologie permettendo la convergenza di altre reti di telecomunicazioni,in questo caso la rete che utilizza SIP deve disporre di un router o gateway PBX che instradi le chiamate su rete PSTN o ISDN.

Quindi è possibile trovare richieste SIP verso indirizzi del tipo:

sip:alef@uniroma1.it; tel:00390649001

Normalmente in questi casi le richieste vengono mappate su una serie di indirizzi SIP tradizionali cosi’ da permettere l’interoperabilità tra i due tipi di rete.

In realtà è possibile utilizzare qualunque tipo di URL (Uniform Resource Lo-cator) classico all’interno di una chiamata SIP , in questo modo l’User Agent (o il proxy) dovrebbe gestire la gestione corretta dell’indirizzo a seconda della situazione.

Figura 5:Schema di azione detto trapezoide

Figura 6: Se A dialoga direttamente con il Proxy di B

Figura 7: Se A dialoga direttamente con B

SIP è un protocollo simile ad HTTP, ma differiscono dal fatto che l’http e’ stateless cioè:

• gestisce ogni richiesta utente in sessione diversa perche’ non ha memoria delle precedenti richieste utente;

mentre il SIP è un protocollo stateful cioè:

• permette di gestire risposte a richieste che dipendono dal contenuto della richiesta e dai risultati di precedenti richieste

• gestisce un canale (virtuale) di comunicazione che permette di vedere richieste e risposte multiple come parte della stessa connessione tra client e server.

Il fatto che il SIP sia stateful lo si vede oltre che nella struttura del protocollo, anche nelle architetture dei client e dei proxy.

Le comunicazioni SIP avvengono con un meccanismo di richiesta - risposta, le

richieste possono essere di 6 tipi a seconda del tipo di operazione:

1. INVITE

2. ACK

3. BYE

4. CANCEL

5. OPTION

6. REGISTER

Vediamo le richieste in dettaglio.

INVITE:

Richiede l’inizio di una sessione di comunicazione, in particolare e’

specificato l’indirizzo SIP del destinatario che deve ricevere la richiesta. In

questo tipo di messaggio è presente un payload al cui interno troviamo

le informazioni per l’instaurazione della comunicazione, quindi il tipo

di protocollo utilizzato per la sessione vera e proprio e i relativi parametri,

(il tipo di codifica e le informazioni di rete come ad esempio la porta di

Comunicazione ) .

ACK:

Conferma l’instaurazione di una sessione, è utilizzato soltanto insieme ad

INVITE, e avvisa lo UA che riceve la chiamata che la sessione è stata aperta

con successo; non e’ un messaggio di risposta in quanto rappresenta la conferma che entrambi i terminali sono a conoscenza dell’attuale stato raggiunto;è l’unico messaggio che non necessita di un messaggio di risposta.

BYE:

Richiede la chiusura di una sessione di comunicazione, una volta che la comunicazione è stata instaurata, questa richiesta avvisa la controparte che la

sessione è terminata.

CANCEL:

Annulla la creazione di una sessione, a differenza di BYE questo comando termina la fase di instaurazione, annullando il precedente INVITE da parte dello UA che ha generato la richiesta di INVITE. Se lo UA che riceve la chiamata, volesse terminare la fase di handshaking non utilizzerebbe CANCEL, ma risponderebbe con l’opportuno codice di risposta all’INVITE specificando il rifiuto della chiamata.

OPTION:

è utilizzato per interrogare un UA riguardo le sue funzionalità, in questo modo un UA chiamante può decidere che tipo di comunicazione instaurare, in base alle informazioni che riceve, cosi` che si possa ottimizzare il tipo di sessione instaurata in base alle capacità dei terminali utilizzati. Quando un proxy riceve questo tipo di richiesta, la inoltra allo UA destinazione.

REGISTER:

è utilizzato per informare un registrar della propria presenza.

Tipicamente lo UA utilizza questo comando quando questo viene attivato, in questo modo viene notificata la presenza di un utente, il suo indirizzo (oppure i

suoi indirizzi) attuale.

Quando arriva una chiamata verso un relativo indirizzo SIP, il proxy interroga il registrar per conoscere i dati dell’utente chiamato e quindi inoltrare la chiamata.

Lo stesso discorso può essere fatto per un redirect server. Le registrazioni normalmente hanno una scadenza, al termine della quale un terminale deve rinnovare la richiesta di registrazione per un altro periodo di tempo. Questo meccanismo viene utilizzato per evitare che rimangano informazioni di utenti non più raggiungibili o con terminale disattivato.

Ad ogni richiesta effettuata, il terminale SIP si aspetta una risposta, ad ognuna è associato un codice numerico di tre cifre che ricalca la struttura dei codici del protocollo HTTP.

In particolare esistono 6 famiglie di codici che raggruppano risposte di tipo simile:

• 1xx Informational

Risposta di tipo informativo, cioè viene utilizzata per informare che un’operazione è in corso, in generale viene mandata in attesa di conoscere una risposta definitiva che è dipendente da una terza entità, questa può essere una UA a cui viene inoltrata la chiamata, o per un utente che fisicamente deve rispondere.

• 2xx Success

Indica un’operazione avvenuta con successo.

• 3xx Redirect

Viene trasmesso quando viene attivata una redirezione della chiamata, in questo caso è il client, (lo UA che ha iniziato la chiamata) o il proxy (che ha inoltrato la chiamata), che si deve occupare di richiamare l’indirizzo specificato.

• 4xx Server error

Indica un errore legato al protocollo SIP, da parte di un determinato server, che può essere un UA (UAS) oppure un proxy che riceve la chiamata.

• 5xx Server internal error

Corrispondono ad errori interni al server, ma non sono legati al SIP ma piuttosto all’implementazione del server.

• 6xx Global failure

Rappresentano errori globali relativi ad un determinato utente (legati al SIP). Questi errori vengono specificati nel caso il sistema abbia una conoscenza globale della situazione di un determinato utente.

La notazione dei codici di ritorno non e’ uniforme nella numerazione; in particolare spesso si vede che da numerazioni basse si passa a valori con decine pari a 80, questo accade per mantenere la compatibilità verso i codici di errore del protocollo HTTP.

Figura 8: Registrazione di uno User Agent

Figura 9: Messaggi scambiati per una chiamata tramite proxy

Gli unici tipi di pacchetti che portano con se un campo dati (payload) sono INVITE e OPTION, nei quali sono spedite le informazioni ed i parametri riguardanti la sessione di comunicazione da instaurare.

In questo caso le informazioni utilizzate per instaurare una comunicazione (tramite RTP) sono codificate secondo lo standard SDP(Session Definition Protocol) che definisce il formato in cui vengono scritte queste informazioni.

SDP in particolare si occupa di specificare:

• Il tipo di media da utilizzare

• Il destinatario della chiamata (indirizzo IP e porta).

• Il nome della sessione e lo scopo.

• Informazioni temporali sull’attivazione della sessione.

• I dati sul contatto (il nome utente ed URI SIP).

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.

Questo protocollo sta diventando lo standard de facto per la telefonia su IP, è stato largamente utilizzato da fornitori di servizi telefonici, sono presenti moltissime implementazioni di questo protocollo server e client.

ENUM e La convergenza con le linee PSTN

I servizi di fonia più utilizzati fino ad ora utilizzano numerazione telefonica standard E.164 per l’indirizzamento delle chiamate (per esempio il numero +39-06-4991 è un numero E.164) mentre le comunicazioni basate su IP utilizzano un sistema di indirizzamento completamente diverso (per esempio per il protocollo SIP un indirizzo potrebbe essere sip:alef@sapientel.it o per il protocollo SMTP semplicemente alef@sapientel.it)

Il progetto SapienTel si basa sicuramente su una concezione IPcentrica delle telecomunicazioni ma vuole, comunque, assicurare la convergenza tra la rete PSTN ed i sevizi di VoIP fruibili tramite rete IP.

Per assicurare tale convergenza bisogna occuparsi della traduzione della numerazione telefonica E.164 (la classica numerazione telefonica ) in un formato gestibile nel protocollo di segnalazione (nel nostro caso SIP).

Questa problematica è stata fortemente sentita tanto che l’IETF [ ] ha deciso occuparsi della realizzazione di uno standard (RFC 2916) per la traduzione degli indirizzi PSTN (Public Switched Telephone Network) a quelli per i servizi IP ed è nato ENUM [11] .

L’ENUM, cioè “E.164 Number Mapping” è quindi uno standard per gestire numeri E.164 come indirizzi internet URI (Uniform Resource Identifier)

Il funzionamento (come si vede dalla figura) si basa sull’utilizzo della ben nota tecnologia DNS(Domain Name System).

Il numero E164 è tradotto in un nome di dominio questo dominio (di tipo ENUM) è memorizzato in un record del server DNS il cosiddetto NAPTR (Naming Authority Pointer) che contiene informazioni sui diversi tipi di indirizzi che possono essere usati per raggiungere il numero E.164 su rete IP.

Figura 10 Esempio di traduzione dei numeri E.164 in URI SIP, tramite ENUM

SIP Express Router

SER (Sip Express Router) è un Sip Proxy, ma anche un Sip Redirect e un Sip Registrar Server. E’ un progetto open-source di Iptel.org. In particolare Ser è un Sip Router che processa i messaggi Sip. Tutte le altre funzionalità e tutti gli altri servizi possono essere messi a disposizione e/o implementati tramite l’utilizzo di applicazioni esterne. SER gira su diverse varietà di distribuzioni Linux e Unix. Essendo open-source mette a disposizione il codice sorgente (C) per lo sviluppo o la personalizzazione dei servizi di Server. Alcuni dei servizi che mette a disposizione sono:

• Sip Registrar

• Sip Proxy

• Sip Redirect

• Voicemail

• Instant messaging

• Accounting

• Authorization

• Autentication

• Jabber Gateways

• Sms Gateways

• Gestione dell’annuncio di presenza

• Gestione di domini multipli

Questi ed altri servizi sono offerti da SER tramite l’utilizzo di moduli esterni; in effetti SER si presenta come un nucleo che si occupa della gestione dei messaggi SIP. Intorno a questo nucleo, leggero, veloce e stabile, si affiancano dei moduli in formato shared object (estensione .so) che possono essere opportunamente combinati, modificati o sviluppati (essendo tutto open source) per la realizzazione di un qualsivoglia servizio di telefonia IP.

Questa architettura modulare fa di SER una soluzione facilmente scalabile e versatile, inoltre va detto che i requisiti hardware che deve avere un pc sul quale far girare SER sono abbastanza modesti (ci riferiamo ovviamente al caso in cui sul Pc non sia installata la funzionalità di mediaproxy o RTP proxy. In quel caso, dovendo gestire il traffico dati, bisognerebbe essere più esigenti sui requisiti hardware).

Ad esempio [ ], come spiega la documentazione, per gestire il traffico voce nelle ore di picco dell’intera area di San Francisco, basterebbe un Server biprocessore (all’incirca 2 Ghz) connesso a banda larga di 10 Mb con almeno 512 MB di RAM (10000 utenti registrati con 20 chiamate concorrenti). Nel caso di organizzazioni di natura accademica, in cui plausibilmente si ha a che fare con un largo numero di utenti, bisogna considerare un ammontare maggiore di RAM (1 o 2 GB) perché è vero che per l’accounting si utilizzano sistemi DBMS (assicurando così la persistenza dei dati), ma è anche vero che, nei momenti in cui gli utenti si registrano, le tabelle degli alias sono mantenute in RAM.

Il vero cuore di SER è il file di configurazione ser.cfg, questo seleziona e controlla i moduli esterni da utilizzare e definisce come vadano configurati questi moduli, quindi si può pensare a questo file come al cervello di Sip Express Router.

Per maggiore chiarezza si può considerare ser.cfg diviso in sette sezioni logiche:

1. Definizioni globali: questa sezione contiene, in genere, l’indirizzo IP, la porta di ascolto del server, il livello di debug e le impostazioni per avviare o meno SER come demone;

2. Gestione Moduli esterni: questa sezione contiene una lista di librerie esterne (moduli in formato shared object)) di cui si ha bisogno per aggiungere funzionalità non offerte dal nucleo di SER;

3. Configurazione moduli: questa sezione contiene le impostazioni dei parametri che si utilizzano per configurare propriamente i moduli. Questi vengono impostati con il comando “modparam” nella seguente forma: modparam (“nome_modulo”,”parametro_modulo”,valore_parametro);

4. Blocco principale di instradamento: è il punto iniziale per la gestione dei messaggi SIP e il controllo di come i messaggi ricevuti sono trattati;

5. Blocchi secondari di instradamento: si aggiungono al Blocco principale e sono da questo chiamati tramite delle etichette (label del tipo route[3]) che li identificano;

6. Blocchi di instradamento di risposta: in questa sezione sono presenti dei blocchi di codice che gestiscono le risposte ai messaggi SIP. Molto spesso sono messaggi del tipo “200 ok”;

7. Blocco di instradamento in caso di insuccesso: questa sezione contiene blocchi di instradamento che possono essere usati in casi particolari come ad esempio risposta “busy” o “timeout”.

I blocchi di instradamento possono essere considerati uno script che viene eseguito ogni volta che un nuovo messaggio SIP viene ricevuto. Il processamento parte dall’inizio del blocco principale di instradamento e attraverso i comandi che si trovano lì o negli altri blocchi, chiamati da quello principale, si gestiscono i messaggi SIP; per questa tipologia di funzionamento questo software si definisce un “SIP-router”.

In questi blocchi sono anche presenti chiamate a funzioni dei moduli esterni .

La spiegazione di ogni modulo e la lista delle sue funzioni e dei relativi parametri sono contenute nella cartella omonima del modulo

Per essere più approfonditi nell’analisi facciamo seguire la lista dei moduli presenti nell’ultima versione stabile di Sip Express Router:

• Modulo acc: supporto per l’accounting

• Modulo auth: modulo generale per l’autenticazione

• Modulo auth_db: per la gestione del database di autenticazione

• Modulo auth_radius : per la gestione dell’autenticazione Radius

• Modulo auth_diameter: per la gestione dell’autenticazione sui server DIAMETER

• Modulo avp: per modificare il periodo di attesa dopo un INVITE (nei casi di dialogo con reti PSTN che hanno latenza maggiore)

• Modulo avpops: per la gestione dell’intestazione dei messaggi SIP

• Modulo avp_radius: per la gestione dei parametri avp provenienti da server Radius

• Modulo cpl: permette l’utilizzazione del Call Processing Language

• Modulo cpl-c: permette l’utilizzazione del Call Processing Language

• Modulo dbtext: permette l’utilizzo dei file di testo come database

• Modulo dispatcher:permette di utilizzare un indirizzo come outbound proxy

• Modulo diversion: permette di gestire al meglio l’inoltro di chiamata

• Modulo domain: per gestire la tabella dei domini serviti dal Sip Server

• Modulo enum: permette l’implementazione di ENUM

• Modulo exec: permette l’utilizzo del comando Exec dalla shell UNIX/Linux

• Modulo flatstore: permette di implementare accounting senza utilizzare DBMS esterni

• Modulo gflags: permette la manipolazione dei flag esternamente (linea di comando o interfaccia web)

• Modulo group: permette l’autenticazione di gruppi

• Modulo group_radius: permette l’autenticazione di gruppi in Radius

• Modulo jabber: permette l’integrazione di Jabber

• Modulo mangler: per la corretta gestione di SDP in connessioni NAT

• Modulo maxfwd: per tenere traccia dei messaggi di forward

• Modulo mediaproxy: permette l’utilizzazione di un mediaproxy esterno (molto spesso per implementare soluzioni di NAT trasversal

• Modulo msilo: per l’immagazzinamento dei messaggi.

• Modulo mysql: permette l’utilizzo di MySQL per la memorizzazione dei database

• Modulo nathelper: per la corretta rivelazione gestione dei client dietro un NAT

• Modulo options: permette di rispondere al messaggio SIP OPTIONS

• Modulo pa : agente di presenza

• Modulo pdt: per il corretto instradamento della chiamata verso altri Domini SIP

• Modulo permissions: per la gestione dei permessi (negazione/concessione) di connessione (utile per l’utilizzo di gateway PSTN)

• Modulo pike: per tenere sotto controllo ore di picco per il traffico

• Modulo postgres: permette l’utilizzo dei database PostgresSQL

• Modulo print: permette di stampare messaggi sullo stdout

• Modulo registrar: questo modulo contiene la logica per il processamento del messaggio SIP REGISTER

• Modulo rr: per gestire gli instradamenti e tenerne traccia

• Modulo sl: gestisce le risposte Stateless

• Modulo sms: permette l’implementazione di SMS Gateway

• Modulo speeddial: permette l’associazione (tramite una tabella) di URI SIP e numeri decimali di due cifre per una composizione più veloce del numero

• Modulo textops: permette operazioni sui testi (messaggi SIP ed URI)

• Modulo tm: per la gestione delle transazioni SIP

• Modulo uri: per la corretta gestione dell’URI

• Modulo uri_db: per la gestione dell’autenticazione tramite URI

• Modulo uri_radius: per il controllo dell’URI in Radius

• Modulo usrloc: gestisce la location dell’utente

• Modulo vm: permette l’implementazione di dei servizi di casella vocale

• Modulo xlog: permette la creazione di file di log per il corretto monitoraggio di SER

SER rispetta le specifiche definite nel RFC3261 nel senso che può gestire ogni tipologia di messaggio SIP, ma un errore nel file di configurazione ser.cfg può far perdere a SER il rispetto di tali specifiche.

Asterisk
Asterisk è un open source software PBX, creato da Digium. Digium produce anche le periferiche per l’interfaccia PSTN da utlizzare con Asterisk il quale comunque supporta anche interfacce PSTN di Vendor diversi (CISCO per esempio). Asterisk può essere utilizzato anche senza hardware che lo connette alle linee telefoniche tradizionali. E’ un prodotto pensato per Linux ma esistono versioni per l’utilizzo su Mac OSX e su Windows (AstWind, ma bisogna installare cooperative Linux).

Il nome Asterisk si riferisce al simbolo * che è usato negli ambienti UNIX e DOS come “wilde card”, implicitando già nel nome la sua estrema versatilità per le soluzioni di VoIP. Questo software non nasce come SIP server, nasce invece dall’esigenza del suo creatore, Mark Spencer, di creare una soluzione per gestire la telefonia più versatile ed economica di un tradizionale PBX.

Lavorando in gruppo con Jim Dixon, della Zapata Telephony Project, crearono delle schede di espansione FXO/T1/E1, l’idea era di combinare insieme un server Linux, con Asterisk installato, e una scheda interfaccia PSTN per creare così una nuova tipologia di PBX. Il protocollo scelto per comunicare con il mondo IP fu ridisegnato, abbandonando la scelta di H.323, e si giunse all’ Inter Asterisk eXchange Protocol (IAX). Questo protocollo gestisce, come visto nella relativa sezione di questa tesi, sia la segnalazione sia il trasporto dei pacchetti tra due nodi connessi. Più tardi, per assicurare l’interoperabilità con i sistemi VoIP più affermati, fu aggiunto il supporto per altri protocolli, quali il SIP, H323, MGCP. Con questo supporto Asterisk è in questo momento un IP PBX ideale per ambienti di telefonia mista.

Infatti esso permette le seguenti funzioni:

Supporto generale (telefonia analogica e digitale per tutti i protocolli supportati):

• Registrazione di chiamata, utilizzando l’applicazione “monitor”;

• Conferenza telefonica, usando l’applicazione “meetMe”;

• Attesa musicale, implementata direttamente in Asterisk;

• Gestione risposta vocale interattiva (IVR)

• Parcheggio delle chiamate, implementata direttamente in Asterisk;

Supporto Client SIP:

• Chiamata in attesa;

• Inoltro di chiamata incondizionato;

• Inoltro di chiamata in assenza di risposta;

• Inoltro di chiamata se occupato;

• Gestione estensioni per linea unica;

• Monitoraggio delle chiamate in ingresso;

• Monitoraggio delle chiamate in uscita;

• Richiamata automatica;

• Richiamata manuale;

• Messaggio “Do not disturb”;

• Messaggio di attesa;

• Gestione risposta vocale interattiva (IVR)

• Gestione delle chiamate in attesa;

Supporto per telefonia analogica (utilizzando interfacce PSTN):

• Chiamata in attesa;

• Inoltro di chiamata incondizionato;

• Inoltro di chiamata in assenza di risposta;

• Inoltro di chiamata se occupato;

• Gestione estensioni per linea unica;

• Monitoraggio delle chiamate in ingresso;

• Monitoraggio delle chiamate in uscita;

• Richiamata automatica;

• Richiamata manuale;

• Messaggio “Do not disturb”;

• Messaggio di attesa;

• Gestione delle chiamate in attesa;

Supporto per Client MGCP:

• Inoltro di chiamata;

• Richiamata manuale;

• Messaggio “Do not disturb”;

• Messaggio di attesa;

• Gestione delle chiamate in attesa;

Anche Asterisk ha un’architettura modulare. Differenti funzioni del server sono implementate come moduli che vengono caricati ed inizializzati durante l’esecuzione. Per aumentare le funzionalità di base, si utilizzano alcune tipologie di interfacce:

• Channell API: per assicurare la connettività telefonica vengono utilizzati i canali Asterisk (Asterisk channels). I telefoni e i client-software si collegano ad un canale, in questo modo possono comunicare. Esistono canali differenti e molti canali supportano anche più protocolli.

• Codec Traslator API: permette una gestione flessibile dei Codec alleggerendo così di il nucleo del Server.

• File Format API: in questo file si possono utilizzare suoni in formato differente ( .waw, .au, .mp3).

• Application API: tramite questa interfaccia si possono facilmente utilizzare applicazioni esterne (per esempio come succede per il riconoscimento vocale).

• Asterisk Gateway Interface (AGI): che è il meccanismo per lanciare applicazioni esterne direttamente dal nucleo di Asterisk.

Questi due ultimi elementi rendono possibile, da parte degli sviluppatori, la scrittura di nuove applicazioni telefoniche e servizi innovativi.

Per la gestione delle chiamate è utilizzato un “Dial-Plan” che permette una metodologia flessibile dell’ instradamento della chiamata. Nel dial plan si impostano tutte le azioni che devono essere intraprese per le diverse situazioni che possono presentarsi; il dial plan è memorizzato in un file di testo exstensions.conf.

Questo file di testo riveste quindi un ruolo importante e analizzandolo si vede una divisione in 3 sezioni logiche:

[general]

in questa sezione si trovano le impostazioni per il salvataggio del dialplan e quindi la consecutiva sovrascrittura dello stesso file exstensions.conf.

[globals]

In questa sezioni si definiscono le variabili globali e le costanti, per esempio si gestiscono quali interfacce si utilizzano in ingresso e quali in uscita oppure quale messaggio si vuole utilizzare per l’attesa.

Contexts ed Extensions

Per meglio chiarire questa sezione si può dire che un dial plan è un insieme di context e che un context è un insieme di exstension

Un possible context potrebbe essere:

Come si vede da questo esempio didattico , un contesto può anche includere un altro contesto e le estensioni sono nominabili con caratteri alfanumerici va solo ricordato che alcuni nomi sono predefiniti e per esempio:

• s (Start):.usato in principalmente per I messaggi di benvenuto e per gestire I dialplan di chiamate che non intercettano I’ID del chiamante

• t (Timeout): usato per gestire le chiamate che sono rimaste inattive dopo il messaggio di benevenuto

• h (Hangup): può risultare utile nel caso di terminazione di chiamata per far sentire un messaggio di

• i(invalid extension): si usa nel caso venga digitata una estensione sconosciuta

più praticamente un contesto si definisce come segue:

Cioè si possono anche inserire comandi nella definizione del contesto, in questo esempio abbiamo inserito un blocco per le chiamate provenienti da Caller ID 044 (per esempio quello di uno studente) .

Oltre questo file di configurazione sono presenti altri file di configurazione per esempio quelli di canale, quindi troveremo sip.conf, iax.conf ecc…

Quindi come si vede per utilizzare il Sip si usa il canale impostato con il file sip.conf.

Grazie ad esso Asterisk implementa le funzionalità di Sip UA, anche in modo molto efficiente, ma non quelle di Sip Proxy. Infatti, come si vede nella sezione di descrizione del protocollo SIP, un Sip Proxy si occupa di gestire il controllo della chiamata (solo la segnalazione), non è mai il punto finale della chiamata e non gestisce mai il flusso dei media. Invece un server Asterisk si pone come tramite tra chiamante e chiamato e controlla completamente traffico ed anche per questo utilizza maggiori risorse hardware rispetto a SER.

Ad onor del vero le ultime versioni permettono, con una specifica configurazione del file sip.conf (disabilitando il tansfer e rinegoziando i parametri tramite un re-INVITE), che Asterisk si occupi solo della segnalazione ma ci sono alcuni telefoni Sip che non funzionano ancora bene con questa impostazione. Sicuramente è un SIP Server nel senso che implementa la funzione di SIP Registrar e Location Server ma, al momento Asterisk supporta Sip solo su UDP non su TCP e quando agisce da server da problemi con telefoni SIP che utilizzano la soppressione del silenzio

Analisi comparativo-funzionale

I criteri discriminanti

Accingendoci a fare una scelta sugli elementi per la realizzazione del servizio è stato doveroso stabilire quali criteri erano discriminanti nell’analisi comparativa.

Si è quindi deciso che i fattori da tenere in considerazione erano:

• stabilità,

• scalabilità,

• innovazione,

• standardizzazione

• apertura allo sviluppo ed alla ricerca

Si è tenuto in considerazione quindi che il servizio che si voleva offrire era destinato ad istituti di natura accademica in cui è presente il settore di ricerca scientifica e tecnologica.

Analisi comparativa dell’architettura protocollare

Partendo dalla considerazione che non esiste l’architettura perfetta per implementare tutte le soluzioni di networking sono stati messi a confronto i pro ed i contro delle seguenti tecnologie:

• Session Initiation Protocol (SIP)

• Skype

• Inter-Asterisk eXchange (IAX)

Parlando di architettura di rete tramite SIP include anche l’SDP, RTP,RTCP per il trattamento del traffico dati e quando si parla di Skype si intende non il Client Software ma l’infrastruttura di rete che c’è dietro (come visto nei paragrafi precedenti).

Confronto tra Sip e Skype

Figura 11: Confronto tra architettura Skype ed architettura SIP

Confronto tra IAX e SIP

Figura 12: Confronto tra protocollo IAX e protocollo SIP

Come si vede dalle precendenti tabelle comparative sia IAX, sia Skype , sia SIP, sono tecnologie valide ma sicuramente per il nostro scopo SIP risulta la scelta migliore, sopratutto perché non è una tecnologia proprietaria .

Anche perchè l’evoluzione di internet ci insegna che l’innovazione passa spesso attraverso la standardizzazione e l’apertura all’interoperabilità.

Analisi comparativa dei VoIP server

Una volta scelta l’architettura di rete (SIP,SDP,RTP) abbiamo messo a confronto i due software più innovativi ed affermati in questo momento che implementano le funzionalità di Server per il Voice over IP:

• Sip Express Router

• Asterisk

Per questa fase abbiamo proceduto anche con una analisi funzionale , cioè abbiamo installato e provato entrambi i Server nel Test Bed (vedi appendice C) e provato effettivamente le funzionalità.

Questa analisi ci ha permesso la stesura della seguente tabella comparativa.

Figura 13: Confronto tra Asterisk e SER

Per la scelta del software da utilizzare come server si è tenuto in considerazione che gli istituti di natura accademica assegnano spesso indirizzi IP pubblici ai loro utenti e quindi il chiamato ed il chiamante non si trovano dietro NAT ,in questi casi, quindi basterebbe semplicemente un Sip Proxy.

Asterisk mancando di questa funzionalità è stato penalizzato. Questo non significa che non può gestire una chiamata SIP, significa che lo fa ma utilizza più risorse Hardware del server (rispetto a SER configurato come SIP Proxy) anche quando non servirebbe.

Inoltre in Asterisk, anche se la gestione di utenti NAT risulta molto semplificata rispetto a SER ,non si può (ancora) avere il controllo completo sul carico del traffico RTP su server diversi che agiscono da proxy.

Mentre invece in SER questa funzionalità di gestione dei cluster di MediaProxy è facilmente implementabile con un script di poche righe nel file ser.cfg.

Analizzando entrambi i software ci si è accorti che anche se alcuni dei servizi che offrono sono simili essi nascono da esigenze diverse e quindi si specializzano su aree di servizio diverse e compatibili.

Quindi si è giunti alla considerazione (anche grazie al confronto con numerosi sviluppatori di servizi VoIP) che potrebbe essere interessante utilizzarli insieme.

Realizzazione

Dall’ analisi dei componenti disponibili per lo sviluppo dell’architettura VOIP, è parso chiaro che per realizzare il nostro progetto bisognasse utilizzare una struttura composta dai seguenti elementi:

• Architettura di rete:

  • Protocollo di segnalazione SIP

  • Protocollo per trasferimento dati (voce) RTP (/SDP)

  • DNS

  • Standard ENUM

• Architettura di sistema:

  • Sistema operativo Server Linux (per il test si è utilizzato Fedora Core 3)

  • DBMS MYSQL

  • Server Web APACHE

  • Middleware PHP

  • SERWEB

• Software Server per la gestione del protocollo SIP:

  • SipExpressRouter

• Software per la realizzazione di un servizio trasparente al NAT:

  • MediaProxy

  • Modulo SER nathelper

• Software per il debugging, la diagnostica e l’amministrazione del servizio( vedi appendice A):

  • SSH

  • ETHEREAL

  • SIPSAK

  • SERCTL

• Software per il test e per la simulazione del traffico:

  • RTPGENERATOR.PY E FAKECONVERSATION.PY

  • SIPP

Figura 14:Schema dell’infrastruttura software di SapienTel

La realizzazione ha conosciuto due fasi:

1. la prima ha riguardato il test e la realizzazione del servizio nel Test Bed(vedi appendice C),

2. la seconda invece ha riguardato la realizzazione parziale del servizio sulla rete universitaria; creando un buon punto di inizio per la realizzazione professionale che ha bisogno di permessi ed autorizzazioni da parte degli organi di gestione dei servizi universitari.

Dopo aver istallato in un Personal Computer una delle ultime release di Linux ( nel nostro caso abbiamo lavorato prima su Fedora Core 3 Test 3 e poi sulla versione stabile Fedora Core 3 stabile ) ci siamo occupati dell’Installazione e configurazione di Sip Express Router .

Ci si è subito resi conto che per offrire un servizio VoIP per istituti Universitari bisognava focalizzare i seguenti punti:

1. gestire la registrazione degli utenti in modo persistente

2. gestire client con IP pubblico senza appesantire inutilmente il server

3. permettere l’accesso al servizio anche da client che si trovano dietro reti che utilizzano NAT.

4. Permettere di sapere chi è registrato (Presenza) ed essere visibili da altri istituti accademici per la divulgazione del progetto.

5. Permettere agli utenti registrati di inviare e ricevere messaggi istantanei

6. Convergenza con le linee PSTN ed in numeri tradizionali.

Le soluzioni con l’architettura che avevamo scelto erano le seguenti:

A)

Per gestire l’Accounting e le Autorizzazioni abbiamo utilizzato il DataBase Management System MySQL anch’esso Open-Source e quindi aperto allo sviluppo ed alla ricerca, ma anche molto stabile, semplice da utilizzare e gratis.

Per utilizzare MySQL abbiamo dovuto impostare i seguenti parametri nel ser.cfg

Nota: Per motivi di chiarezza indicheremo solo le voci che abbiamo modificato e/o aggiunto rispetto al file ser.cfg predefinito, nelle 7 sezioni logiche in cui è diviso.

Immagazzinare tutte le informazioni di registrazione nelle tabelle di un database è anche un modo per permettere ai soli utenti accreditati di accedere al nostro servizio (utenti, ricercatori etc).

Quindi in generale i messaggi SIP che dobbiamo gestire in modo differente sono i messaggi REGISTER (perchè non vogliamo che utenti anonimi possano registrarsi al nostro sip proxy) e messaggi INVITE (perchè non vogliamo che utenti non autenticati possano fare chiamate, importante nel caso volessimo aprire il nostro dominio VoIP ad un gateway PSTN).

• La prima modifica che abbiamo apportato è stata quella di aprire una fifo (fifo_db_url) che ci permettesse tramite strumenti di amministrazione (serctl) di lavorare sull’accounting e sull’autenticazione.

• Per supportare il database MySQL abbiamo dovuto aggiungere il modulo mysql.so nella sezione 1 (gestione moduli esterni). Dato che tutti i moduli che afferiscono al database dipendono da mysql.so, è importante che esso venga caricato per primo.

• Per gestire invece le modalità di autenticazione, abbiamo dovuto inserire il caricamento dei moduli auth.so, auth_db.so, uri_db.so (che si occupa delle modalità di autenticazione tramite la URI).

• Nella sezione 3 (configurazione moduli) abbiamo permesso l’accesso al database per i moduli auth_db, uri_db e usrloc tramite il quale si gestiscono le informazioni di localizzazione del client SIP. Ovviamente abbiamo utilizzato un sistema di criptaggio delle password ponendo sempre nella sezione 3 il parametro riferito alcolate_ha1 al valore 1 (di default il parametro predefinito è 0 = no criptaggio password).

• Abbiamo implementato, sempre nella sezione 3, il recupero delle passwords degli utenti registrarti dalla colonna password_column del database server (che abbiamo precedentemente configurato tramite MySQL). In questo modo abbiamo anche informato ser che il nome della colonna delle password è cambiato. Abbiamo modificato il valore del parametro di db_mode riferito alla voce del usrloc da 0 a 2 per la persistenza delle informazioni degli utenti e di autenticazione.

• Nel blocco principale di instradamento abbiamo definito una differente procedura per i due differenti messaggi su cui andiamo a lavorare nel caso dell’autenticazione : REGISTER ed INVITE.

• Per il REGISTER utilizzeremo il seguente instradamento: appena ricevuto tale messaggio risponderemo con un messaggio “100 Trying” per fare in modo che non continui a mandare messaggi di registrazione e intanto cominceremo a processare la richiesta di registrazione. Quindi controlleremo se lo user name dell’utente si trova nella tabella del database e a seconda dell’esito positivo o negativo del controllo permetteremo o negheremo la registrazione. Se all’utente viene permessa la registrazione allora si salvano le informazioni di localizzazione nella tabella location; in questo modo si può anche riavviare il server in modo completamente trasparente al client SIP registrato.

• Nel blocco secondario di instradamento ci siamo occupati della gestione dell’INVITE. Anche in questo caso, ricevuto un INVITE si applica un controllo delle credenziali incluse nella richiesta e si confrontano con le informazioni memorizzate nella tabella subscriber (gli utenti del nostro servizio). Se l’utente è accreditato salviamo le informazioni per la localizzazione nella tabella location.

B)

Per la gestione di chiamate tra client SIP con IP pubblico (la maggior parte degli utenti che utilizzeranno il servizio dalla sede universitaria) il nostro server deve agire come Sip Proxy occupandosi solo della segnalazione. In questo modo le risorse hardware del server vengono ottimizzate.

SER come configurazione predefinita funziona proprio come SIP Proxy (differentemente da Asterisk) e quindi sono bastate pochissime modifiche (aggiunte a quelle precedenti) per la gestione di questa tipologia di comunicazione.

Le modifiche si sono quindi ridotte all’impostazione del parametro di ascolto su un indirizzo IP pubblico e sulla porta predefinita 5060; abbiamo inoltre fatto agire SER come demone (in background) ed abbiamo permesso che i messaggi di errore fossero presentati in console. Per il resto valevano le configurazioni del file predefinito.

C)

Questa problematica è molto rilevante all’interno del progetto, perché è quella che afferisce alla sfera di mobilità degli utenti, infatti permettere agli utenti di accedere al servizio anche da client dietro un NAT significa permettere loro di effettuare una chiamata anche da casa, internet point, hotspot in aeroporti, in caffetterie e in generale in tutte quelle infrastrutture di reti in cui l’utente non possiede un IP pubblico.

Ci sono diverse modalità per offrire il servizio anche a client che si registrano in situazioni di questo tipo. Alcune aggiungono complessità sulla configurazione client (STUN) altre, invece, aggiungono complessità sul nucleo dell’architettura server; ci si è concentrati su quest’ultima soluzione facendo in modo di realizzare una soluzione trasparente all’utente, cosicché la configurazione client risulta semplificata.

Ci sono diversi software che, in abbinamento a SER, possono svolgere questa funzione. Noi abbiamo utilizzato MediaProxy (AG Projects).

Esso svolge da Proxy server per il traffico RTP (deve essere installato sun un server con indirizzo IP pubblico) si occupa di determinare gli indirizzi dai quali i flussi sono originati (i client dietro NAT). Questa informazione è sconosciuta quando inizia la segnalazione SIP (infatti nella messaggistica SIP è presente l’indirizzo IP privato del client) perché non si può determinare fino a quando non inizia veramente il traffico RTP.

Questo software si pone all’interno della comunicazione tra i due client ed inoltra il traffico RTP dall’uno verso l’altro facendo in modo che il chiamante ed il chiamato lavorino come se davvero stessero comunicando direttamente. Più in dettaglio MediaProxy alloca due socket ( uno per RTP, l’altro per RCTP) per ciascun flusso di dati per sessione e invia il suo indirizzo IP e una lista di porte a SER (tramite modulo mediaproxy.so), il quale utilizza queste informazioni per modificare i valori nel messaggio SDP.

A questo punto MediaProxy è in ascolto su questi socket ed aspetta che giungano pacchetti dai due. Una volta giunti questi pacchetti, mediaproxy può conoscere dove inoltrare i pacchetti ,quindi inizia il traffico RTP tramite mediaproxy.

Questo funzionamento si avrà anche se solo uno dei client SIP è dietro NAT.

Figura 15: MediaProxy in azione

• Abbiamo quindi modificato il file ser.cfg nel seguente modo: dato che ser funziona in background abbiamo tolto la segnalazione dell’errore tramite console nella sezione 1 definizioni globali. Nella sezione moduli esterni abbiamo aggiunto il modulo nathelper.so il modulo mediaproxy.so che gestiscono il primo l’individuazione del SIP client, il secondo la comunicazione con il mediaproxy. Abbiamo anche aggiunto il modulo textopt.so che viene utilizzato per manipolare i testi molto utile per la gestione di sottostringhe e per la modifica della messaggistica SIP.

• Nella sezione 3 configurazione moduli, abbiamo avvertito il modulo nathelper che stiamo utilizzando mediaproxy e non RTTP proxy. Inoltre dovendo mantenere aperte le porte dei client SIP che sono dietro nat, dobbiamo impostare un meccanismo di “keep alive”. Quindi impostiamo un intervallo di ping di quaranta secondi (questo imporrà a ser di mandare pacchetti di quattro byte UDP a ciascuno dei client SIP ogni quaranta secondi). Sempre nella stessa sezione indichiamo a ser quale è il soket UNIX tramite il quale comunicare con mediaproxy. Aggiungiamo le informazioni per permettere a media proxy di comprendere quando uno user agent SIP è asimmetrico rispetto alle sue porte RTP e SIP. Utilizziamo anche un flag (valore 6) per indicare quali client SIP registrati si trovano dietro una architettura e quali no.

• Nel sezione 4 (blocco principale di instradamento) abbiamo considerato anche la gestione di invite provenienti da client in architettura nat. La modifica apportata al file predefinito considera anche il caso in cui messaggio SIP sia un bye ed un cancel. In questo caso viene chiamata la chiusura della sessione tramite mediaproxy. Utilizzando le funzioni del modulo nathelper determiniamo se il client SIP non utilizza un indirizzo pubblico ed in quel caso utilizziamo mediaproxy tramite la funzione user_media_proxy(). Come si vede ogni volta che ci troviamo di fronte un client in rete nat, lo individuiamo impostando il suo flag a 6 così, con una semplice funzione di controllo, quando utilizziamo la funzione lookup(“location”) sappiamo già che quel client va utilizzato tramite mediaproxy.

• Nella sezione 5 (blocchi secondari di instradamento) si operano i cambiamenti delle URI SIP in modo da impostare il giusto indirizzo IP e la porta (che rappresenta l’interfaccia pubblica del client SIP nattato) per implementare la comunicazione tramite proxy RTP. Tali informazioni vengono immagazzinate nel database MySQL. In questo modo possiamo inviare in modo sicuro il messaggio invite a destinazione.

• Nella sezione 6 (blocchi di instradamento di risposta) utilizzando le espressioni regolari, ci occupiamo della gestione dei messaggi di risposta. Nel caso di client nat, siamo interessati soltanto 180, 183 e tutti quelli della serie 200. Anche in questo caso riscriviamo header del messaggio contact per contenere l’indirizzo IP della porta della interfaccia pubblica del nostro SIP client nattato.

La nostra architettura prevede mediaproxy installato nello PC in cui è installato SER (utlizzando un socket UNIX tra i due ), in realtà tramite l’utilizzo del file proxydispatcher.py si puo’ gestire mediaproxy remoti e cluster di mediaproxy(aggiungendo poche righe di scripting a file ser.cfg) per non appesantire una macchina soltanto quando si deve processare molto traffico RTP.

D)

Si è visto che per rendere possibile a tutti la lista degli utenti registrati servisse un pagina web (PHP) che premettesse di utilizzare le informazioni che SER immagazzina nel database mysql

(tramite fifo_db_url="mysql://root_SER:password@localhost/ser")

La creazione di una lista di utenti registrati si implementa con il seguente script PHP:

Abbiamo anche implementato l’utlizzo di SERWEB.

SERWEB (un interfaccia web per SER)che permette inoltre agli utenti di registrarsi autonomamente e gestire il proprio profilo.

Le pagine web sono utili anche per la divulgazione del progetto e per rendere facilmente fruibili i servizi fornendo supporto agli utenti.

E)

In effetti per implementare questa funzione è sufficiente che essa sia supportata dal lato client SIP (Kphone,Xlite, Eyebeam, MS Windows Messanger..etc)

In più l’interfaccia SERWEB permette l’invio I Messaggi Istantanei direttamente dal Web dalla pagina personale(dopo il Log IN). Ma non lo abbiamo testato

Implementando questi servizi il modello che ne risulta è il seguente:

Figura 16: Architettura di Rete di SapienTel

F)

Questa tipologia di servizio è stata solo studiata e simulata nel Test Bed(vedi appendice B) (utilizzando come GW il sipura 3000) anche per motivi di mancanza di hardware che potesse implementare GW PSTN sul PBX universitario. L’Hardware in questione potrebbe essere un CISCO 2610 oppure CISCO AS5300 (con un interfaccia E1 ed una Voice Card) oppure semplicemente un server Linux con Asterisk e con le opportune schede ZapTel per il transcoding TDM.

Il reindirizzamento in caso di numero destinato a linee PSTN potrebbe essere per esempio implementato in uscita solo per numeri destinati ai numeri gestiti dal PBX universitario (centralino +3906499….) e per i numeri locali (ROMA prefisso +3906…) e si potrebbero autorizzare solo alcuni utenti (professori e ricercatori).

Potrebbe anche essere implementato in ingresso assegnando agli utenti SapienTel uno user name numerico per esempio 09097321 .In questo modo anche chi chiama da telefono PSTN può chiamare un numero SIP utilizzando il gateway dell’istituto accademico.

In generale (SIPPSTN e PSTNSIP) il Gateway si comporta come un Sip Client:

SIPPSTN

• Per chiamare un telefono PSTN sarebbe sufficiente che un utente SapienTel digitasse sul proprio client SIP il numero telefonico. Infatti in quel momento il client manda un INVITE al SER (sul quale è registrato)

• A quel punto SER, dopo aver compreso (tramite il controllo sulla Request URI) che si tratta di un numero PSTN, cambia l’indirizzo IP richiesto con quello del gateway PSTN. Successivamente si procede come se fosse una semplice chiamata “SIP to SIP”.

PSTNSIP

• Al contrario quando si riceve una chiamata da linea PSTN, tramite il gateway, a una URI SapienTel sarà il gateway PSTN (registrato sul SER come client SIP) ad inviare un messaggio di INVITE al SIP proxy. Successivamente si procede come in una semplice chiamata “SIP to SIP”.

Le modifiche principali che bisognerebbe apportare al file SER.cfg dovrebbero essere le seguenti (anche in questo caso aggiungiamo solo le modifiche rispetto al caso precedente) :

• Come si vede nella sezione “Gestione moduli” sono state apportate alcune modifiche:

  • è stato aggiunto il modulo avpops.so che permette di manipolare l’intestazione del messaggio SIP ed infatti viene usato (come si vede nelle successive sezioni) per modificare il tempo di attesa del messaggio INVITE (questo si fa perché quando si passa da linee IP a linee PSTN ci potrebbero essere problemi di latenza maggiore).

  • viene aggiunto anche il modulo domain.so per utilizzare funzioni di validazione della chiamata.

  • inoltre si aggiunge anche il modulo permissions.so il quale permette a SER di accedere alla tabella “trusted”(che va precedentemente creata in mysql), in cui aggiungeremo il riferimento al gateway PSTN per prevenire SER dal richiedere l’autenticazione delle sue credenziali.

  • Abbiamo inserito il modulo enum.so, per implementare le regole dello standard ENUM in caso di URI che siano numeriche ma per le quail non siamo autorizzati all’uscita tramite PSTN (è il caso di numeri internazionali).

  • Nella sezione configurazione moduli esterni, oltre alle modifiche ai parametri per la gestione di attese più lunghe (latenza PSTN) abbiamo aggiunto l’impostazione del parametro del modulo enum , “domain_suffix” con la zona “e164.arpa”. (il suo valore predefinito)

• In genere si sono considerate le URI di utenti non registrati e con indirizzo numerico, indirizzi della rete PSTN ;

  • infatti nel Blocco secondario di instradamento e precisamente nella route 3 è stato aggiunto il controllo delle uri , permettendo solo a quelle che hanno una URI compatibile con l’espressione regolare sip:003906499[0-9]{4}*@ (plausibilmente un numero interno all’università) ad accedere alla route 4 e cioè l’instradamento verso gateway PSTN

  • prevediamo anche il caso di prefissi internazionali,in questo caso utilizziamo il campi del DNS e lo standard enum tutto questo grazie alla funzione enum_query(). Questa funzione applicata alla URI numerica implementa prima la trasformazione dal numero a zona dns puntata con il suffisso e164.arpa e poi invia una richiesta verso il DNS. Questo confronta la zona inviata da SER con quelle contenute nei campi NAPTR(Naming Authority Pointer)e restituisce il primo campo che ha il valore “u” e quelli del tipo “E2U+SIP”

per esempio :

• enum_query sostituisce il valore numerico(Request-URI) con il valore restituito dal server DNS che è una URI SIP.

• sono state permesse anche le chiamate verso il numero di emergenza 112 tramite linea PSTN

la funzione rewritehost() modifica la R-URI con l’indirizzo del gateway.

In realtà per migliorare la convergenza è stata studiata l’ implementazione dello E.164 Number Mapping (ENUM). Abbiamo inserito infatti il modulo enum.so nella sezione2 (Gestione moduli esterni)

Come regola generale bisogna perpetuare un controllo delle credenziali su tutti gli INVITE che giungono a SER e che vogliono afferire al gateway PSTN(per evitare frodi telefoniche).

Conclusioni

Un progetto di questo tipo sicuramente offre una moltitudine di servizi mirati a migliorare e semplificare le dinamiche degli istituti universitari.

Ed è una ricerca (quella dello sviluppo dei servizi tramite rete IP) che non ha mai conosciuto momento migliore.

Per questo è auspicabile, continuando la ricerca nel settore, passare dalla analisi e sperimentazione (in cui ha trovato spazio questo lavoro di tesi) alla fase produttiva di SapienTel ( quella che invece ha bisogno di permessi ,di contratti e fondi) .

I più prestigiosi istituti universitari del mondo si stanno muovendo in questo senso ,il fenomeno si chiama SIP.edu.

SIP.edu indica l’implementazioni di servizi, tramite Protocollo SIP, per quegli organismi che nelle Zone DNS vengono indicati come edu (educational).

Ecco alcune delle sperimentazioni correnti:

Harvard University

Domains served: harvard.edu

Indiana University

Domains served: indiana.edu; iupui.edu; iu.edu

Colorado State University

Domains served: colostate.edu

University of California, Los Angeles

Domains served: ucla.edu

University of Alaska Fairbanks

Domains served: alaska.edu; uaf.edu

University of Hawaii

Domains served: hawaii.edu

Woods Hole Oceanographic Institution

Domains served: whoi.edu

Swiss Federal Institute of Technology (ETH Zurich)

Domains served: ethz.ch and 450 additional subdomains of ethz.ch

Internet2

Domains served: internet2.edu

Columbia University

Domains served: columbia.edu

University of Pennsylvania

Domains served: upenn.edu

Yale University

Domains served: yale.edu

Massachusetts Institute of Technology

Domains served: mit.edu

S.W.I.T.CH.

Sipedu.ch

Questa lista ci mostra ancora di più quanto è stato importante intraprendere l’ analisi e sperimentazione del servizio SapienTel. Una delle necessità che si voleva soddisfare era quella di migliorare la comunicazione tra tutti gli organi di natura accademica;analizzando il precedente elenco si evince che passando dalla fase sperimentale alla fase produttiva di SapienTel si aprirebbe facilmente il dialogo con alcune delle università più prestigiose del mondo e si potrebbe offrire il servizio anche per altri istituti universitari o di ricerca italiani.

Una fattore importante è che per passare alla fase produttiva ovviamente significherebbe investire fondi.

Il lavoro di tesi ha permesso anche di poter fare una stima della tempistica e dei costi del processo produttivo; i risultati sono esposti seguente tabella:

Figura 17: Stima dei costi per il passaggio dalla fase Sperimentale alla fase Produttiva di SapienTel

Anche passando alla fase produttiva non ci sono grandi investimenti da fare. Le uniche voci che hanno un peso importante dal punto di vista economico sono gli apparati (hardphone,pc, server, Gateway) ed il costo ore/lavoro (per il resto rimangono le stesse componenti della sperimentazione).

In chiusa va però detto che i costi potrebbero essere in parte ammortizzati dal risparmio proveniente dall’utilizzo del Voice over IP in ambito accademico (non si pagherebbe per chiamare il MIT o Yale o la Columbia University o anche altre Università Italiane che volessero aderire.)

Appendici

Appendice A

Strumenti usati

SSH(Secure Shell)

SSH e` un programma che consente di effettuare sessioni remote interattive di tipo terminale, analoghe a quelle consentite da TELNET, ma criptate. In questo modo le password usate per l'autenticazione viaggiano in rete crittografate e quindi, anche se intercettate, non possono essere utilizzate.

Ovviamente sul server acui ci si collega deve essere presente il Server e deve essere abilitato un utente all’accesso, a quel punto si può utlizzare il client.

SSH si è rivelato molto utile perché ha permesso di intervenire da remoto sul server potendo così ottimizzare i tempi di sviluppo!!

SIPSAK (SIP swiss army knife)

La cui traduzione significa il coltellino svizzero per il SIP, è uno strumento per gli sviluppatori ed amministratori di servizi VoIP tramite protocollo SIP.

Lo si puo’ installare su Linux,Unix,e Windows.

Si utilizza da linea di comando, alcuni esempi di comandi sono:

visualizza il percorso fino a alex@smile.ing.uniroma1.it

sipsak -T -s sip: alex@smile.ing.uniroma1.it

Per mandare un messaggio istantaneo "ciao!!" to alex@smile.ing.uniroma1.it :

sipsak -M -v -s sip: alex@smile.ing.uniroma1.it -B "ciao!!"

Manda una richiesta OPTIONS a alex@smile.ing.uniroma1.it e mostra la risposta:

sipsak -vv -s alex@smile.ing.uniroma1.it

SERCTL

Serctl è uno strumento che si utlizza da linea di commando , e permette di monitorare e configurare Sip Express Router ,

le funzionalità che puo’ svolgere sono riassunte nella seguente screenShot:

Come si vede si possono aggiungere utenti, modificare le password e molto altro, ma prima pero di utilizzarlo, si deve impostare la variabile di sistema $SIP_DOMAIN tramite il comando export.

ETHEREAL

Descrizione:
Ethereal è un network packet analyzer, cioè un software in grado di catturare i pacchetti trasmessi in una rete e di analizzare ogni pacchetto in modo dettagliato.

Ethereal è in grado di riconoscere ed analizzare una enorme varietà di protocolli differenti, e fornisce all'utente l'accesso a tutte le informazione pertinenti a ciascun protocollo. Ethereal è dotato di una interfaccia grafica che rende l'operazione di analisi del traffico in rete semplice, veloce ed intuitiva. Si tratta di uno strumento molto potente e di indubbia utilità per l'amministratore di rete, per l'ingegnere ed il programmatore di rete, ma anche per l'utente comune che vuole studiare ed imparare il funzionamento dei protocolli di rete.

Ovviamente Ethereal gestisce anche il protocollo SIP e RTSP , quindi e’ stato utile per testare le performance dei server SIP analizzati e per capire le ottimizzazioni da produrre per migliorare i servizi che volevamo offrire.

Vantaggi:

• Supporta diversi tipi di rete, tra cui Ethernet, 802.11, FDDI, Token Ring e ATM

• Supporta innumerevoli protocolli a vari livelli (collegamento, rete, trasporto, applicazione)

• Permette di catturare e di salvare su file il traffico in rete per analisi future

• Permette di importare ed esportare i dati catturati con molti altri analizzatori di rete

• Consente di filtrare i pacchetti e di effettuare ricerche tra i pacchetti secondo molti criteri

• Supporta la colorizzazione dei pacchetti basata sull'impostazione dei filtri

• Genera utili statistiche sul traffico analizzato

Appendice B

Il Test Bed

Il Test Bed ha rivestito un ruolo fondamentale sia nella fase di analisi comparativo- funzionale sia nella prima realizzazione del servizio.

La strumentazione di cui era composto può essere facilmente riassunta nello schema che segue:

Figura 18: Architettura del Test Bed

Grazie al Sipura 3000 abbiamo anche potuto studiare la gestione di un Gateway PSTN e quindi la convergenza tra la rete IP e le linee telefoniche tradizionali.

Appendice C

Glossario

A

ADSL

Asymmetric Digital Subscriber Line, tecnologia a banda larga che realizza la connettività alla rete Internet utilizzando una linea di comunicazione asimmetrica. Caratteristica: una banda trasmissiva maggiore in download, rispetto a quella di upload, cosa che la rende adatta ai collegamenti ad Internet da parte degli utenti, per i quali è maggiore la quantità di dati richiesti e quindi trasmessi dalla rete all'utente. Sfrutta le normali linee telefoniche. Le alte frequenze utilizzate dall'ADSL convivono con le frequenze della fonia, consentendo l'utilizzo in contemporanea dei servizi telefonici di base e della connessione ad Internet ad alta velocità.

B

Banda Larga

Questo termine identifica un vasto insieme di tecnologie accomunate da una peculiarità: quella di consentire il collegamento a Internet e alle reti locali ad una velocità di trasmissione dei dati largamente superiore a quelle supportate dai modem tradizionali. Queste tecnologie potranno garantire la realizzazione di servizi più semplici, efficaci e meno costosi.

BRI

Basic Rate Interface. Interfaccia ISDN che comprende due canali B per la trasmissione di voce, video e dati chiamati B-channel, a 64 Kbps) ed un canale D (chiamato D-channel, a 16 Kbps) di servizio per i segnali di controllo.

Bridge
Termine inglese utilizzato per indicare un'apparecchiatura che sposta i pacchetti tra i segmenti multipli di una rete utilizzando lo stesso protocollo di comunicazione. Se un pacchetto è destinato ad un utente situato nello stesso segmento di rete del mittente, il bridge mantiene il pacchetto a livello locale. Se il pacchetto è invece destinato ad un altro segmento, il bridge lo passa ad un'altra dorsale di rete. Il bridge opera al livello 2 (Collegamento Dati) del modello OSI.  

Broadband

Banda larga. Indica la larghezza della banda di rete ossia la capacità di convogliare con un unico mezzo diversi segnali allo stesso tempo. Generalmente si tratta di cavi coassiali. Viene anche chiamata "Wideband".   

Broadcast

Pacchetto di dati che viene mandato a tutti i nodi di una rete. I pacchetti di dati sono identificati attraverso un indirizzo di broadcast.

Browser

Applicazione software basata su un'interfaccia GUI che consente di visualizzare le pagine HTML di Internet e del WWW. Microsoft Internet Explorer e Netscape Navigator sono i due browser più diffusi al mondo.

C

Client

Termine che indica un PC o un terminale collegato in rete che condivide "servizi" con altri PC. I servizi sono memorizzati o amministrati su un server. Quando la rete si ingrandisce e si aggiungono altri computer, uno di essi può diventare il cosiddetto server, cioè un punto centrale per l'archiviazione dei file o dei programmi applicativi in rete. Dal server partono anche le connessioni verso le risorse comuni come le stampanti o i fax. Trasformare un computer in un server dedicato consente di risparmiare sia sui costi aggiuntivi di nuove infrastrutture di rete, sia sui costi di gestione delle stesse. I computer collegati al server vengono chiamati client.

CPE

Customer Premises Equipment. Apparecchi quali terminali e gateway, forniti dalla compagnia telefonica, installati presso l'utente e connessi alla rete telefonica.

D

DHCP

Dynamic Host Configuration Protocol. Tipologia di server in grado di assegnare automaticamente agli host collegati (PC di una rete LAN) indirizzi IP validi.

E

Ethernet

Tipo di LAN che rispetta lo standard IEEE 802.3; in una rete Ethernet i dati transitano tipicamente tramite cavo coassiale o di tipologia RJ

F

FXO

Foreign eXchange Office sono in genere le prese degli apparecchi telefonici che si collegano, tramite un cavo alle FXS. In genere comunque si intendono, con questa sigla anche le porte di un gateway o centralino alla quale si collegano i telefoni degli utenti

FXS

Foreign eXchange Subcriber non e’ altro che l’interfaccia che porta i servizi dell’operatore telefonico all’utente. Un esempio di porta FXS e’ la presa al muro a cui collegare gli apparecchi telefonici.Ma in genere si chiamano cosi anche le porte che portano l servizio esterno in un gateway o in un centralino.

G

Gateway

"porta d'ingresso", dispositivo che mette in comunicazione reti differerenti.

I

ISDN

Integrated Services Digital Network, rete digitale integrata nei servizi. Tecnologia per l'accesso alla rete. Consente di avere fino a 2 linee telefoniche, ovvero 2 canali da 64 Kbps per un totale di 128 kbps.

L

LAN

Local Area Network. Sistema di comunicazione per connettere in rete locale computer (server e client), stampanti, ecc.

N

Numero geografico

Numero telefonico con prefisso riconducibile ad uno specifico distretto geografico (es. 06.40404XXX per Roma, 02.4003XXXX per Milano). Ogni numero geografico è raggiungibile dalla rete telefonica pubblica e fa parte del Piano Nazionale di Numerazione.

Numero virtuale

Numero telefonico assegnato dall'operatore che permette di essere chiamati solo dalla comunità di appartenenza, cioé dagli altri abbonati allo stesso servizio.

NAT

Network Access Translation. Converte l'indirizzo IP riferito alla rete Internet in indirizzi IP appartenenti alla rete locale.

P

Protocollo IP

Internet Protocol: è l'insieme di regole di che governa la comunicazione base tra due computer connessi ad una rete internet o privata basata appunto sul protocollo IP.

POTS

Plain Old Telephone Service. Indica il servizio telefonico canonico. Il Pots Splitter è un apparato che separa a monte dell'impianto telefonico il flusso della fonia da quello dati dell'ADSL.

PBX

Private Branch Exchange. È un sistema telefonico che permette lo scambio di telefonate tra utenti di un'impresa che utilizzano linee interne ma permette anche la gestione di telefonate verso linee esterne. Si tratta del centralino telefonico che utilizza la tecnologia analogica o digitale.

Peer-to-peer

Architettura di rete nella quale tutti i computer possono essere sia client che server.

PRI

Primary Rate Interface. Interfaccia ISDN per l'accesso "primary rate". Questo tipo di accesso consiste in un singolo canale D a 64 Kbps per i segnali di controllo più 23 (T1) o 30 (E1) canali B per il passaggio di dati o voce. Negli Stati Uniti i canali B sono 23. Questa linea permette di attivare 30 router indipendenti per 30 linee in entrata o uscita, con una singola connessione con un singolo server.       

Protocollo

Descrizione formale di un set di norme e convenzioni che regolano il modo in cui i dispositivi di rete devono scambiarsi le informazioni. I computer per comunicare tra loro hanno bisogno di un codice di trasmissione che sia in grado di "interpretare" i segnali emessi dai vari PC. Pensiamo allo scambio di dati tra due computer non compatibili: se il file inviato da un computer viene trasmesso in codice ASCII e l'altro computer è disposto a ricevere solo file in codice "ASCII non puro" allora la comunicazione anche se avviene può risultare indecifrabile per l'altro utente.

Proxy Server

I Proxy Server sono dei server che "filtrano" le informazioni che arrivano da Internet attraverso il firewall. Quando ci si connette ad un proxy con il proprio software client, il server avvia il suo software client (proxy) e fornisce i dati. Dal momento che i proxy server duplicano tutte le comunicazioni, sono in grado di mantenere il logging di tutto quello che fanno. Un grande vantaggio dei proxy server sta nel fatto che sono completamente sicuri, se configurati correttamente, non avendo instradamenti IP diretti.

PSN

Packet-Switched Network. Rete che utilizza la tecnologia "packet switching" per il trasferimento dati. Talvolta è chiamata anche PSDN (Packet-Switched Data Network).  

PSTN

Public Switched Telephone Network. Rete telefonica analogica. La normale rete telefonica per le trasmissioni vocali. Può essere utilizzata per l'invio di dati tramite router (o modem). Talvolta è chiamata anche

R

Router

Termine che indica un dispositivo che sposta i dati tra segmenti di rete diversi ed è in grado di leggere l'header del pacchetto di dati per determinare il percorso di trasmissione migliore. I router possono collegare segmenti di rete che utilizzano protocolli diversi. Essi permettono inoltre a tutti gli utenti di una rete di condividere un unico collegamento verso Internet o verso una WAN. I router sono ancora più intelligenti degli hub e degli switch. Basandosi su una mappa di rete denominata tabella di routing, i router possono fare in modo che i pacchetti raggiungano le loro destinazioni attraverso i percorsi più idonei. Se cade la connessione tra due router, per non bloccare il traffico, il router sorgente può creare un percorso alternativo. I router definiscono anche i collegamenti tra reti che utilizzano protocolli diversi, come ad esempio l'IPX (Internet Packet Exchange) e l'AppleTalk. Il router mantiene costantemente un elenco delle possibili vie di inoltro dei pacchetti di dati, verificando l'occupazione delle linee e scegliendo la soluzione migliore (incrociando sia le informazioni sui tempi, che quelle sui costi). Infine, i router gestiscono anche i trasferimenti mobili, come lo spostamento continuo di un PC portatile.  

Router-based firewall

Sono firewall dove la sicurezza è implementata utilizzando filtri a livello di pacchetto come primo stadio di protezione della rete.  

RTC o RTG

Rete Telefonica Commutata. La normale rete telefonica. 

S

Soft-Phone

E' un applicativo software che, opportunamente configurato, permette di effettuare e ricevere chiamate telefoniche.

Server

Termine che indica un computer e un software che offrono servizi ai client quali la memorizzazione dei file (file server), i programmi (application server), la condivisione di stampanti (print server), fax (fax server) o modem (modem server). Quando la rete si ingrandisce e si aggiungono altri computer, uno di essi diventa il cosiddetto server, cioè un punto centrale per l'archiviazione dei dati o dei programmi applicativi in rete. Trasformare un computer in un server dedicato (cioè un PC su cui non ci lavora nessuno e che rimane a disposizione di tutti) consente di risparmiare sia sui costi aggiuntivi di nuove infrastrutture di rete, sia sui costi di gestione delle stesse. I computer collegati al server vengono chiamati client. Non è comunque necessario disporre di un server dedicato nella propria rete. Tuttavia, se alla rete si aggiungono sempre più utenti, un server dedicato può fungere da centrale per i compiti amministrativi come il backup dei file e gli upgrade dei programmi.

Switch

Dispositivo che connette tra loro i computer analogamente a quanto fa un hub, ma in modo più efficiente e flessibile. Migliora le prestazioni di una rete segmentandola in sottoreti e attribuendo la banda disponibile in modo intelligente. Quando la porta di uno switch riceve i pacchetti di dati, li invia alle porte specifiche dei destinatari, sulla base delle informazioni contenute nell'header di ogni pacchetto. In tal modo si ottimizza l'uso della larghezza di banda disponibile tra client, server o workgroups collegati ad ogni porta dello switch. Gli switch quindi sono più intelligenti degli hub e offrono una larghezza di banda dedicata più grande. Uno switch stabilisce una connessione temporanea tra la sorgente e il punto di destinazione, chiudendola al termine del collegamento. Lo switch migliora le prestazioni di una rete segmentandola e riducendo la contesa per l'utilizzo della larghezza di banda. Le porte dello switch sono collegate tramite cavo UTP ai dispositivi di rete. I dispositivi connessi ad uno switch fanno parte dello stesso segmento di rete e più switch possono essere collegati in serie per formare una rete più complessa, a volte mischiando hub e switch secondo necessità. Lo switch è più semplice e veloce del router, il quale sceglie l'instradamento anche giudicando in base ad un resoconto dei costi e dei tempi di trasmissione.  

T

TCP/IP

Trasmission Control Protocol / Internet Protocol. E' l'insieme fondamentale di protocolli utilizzati per il trasferimento di dati in Internet, e sempre più spesso anche nelle reti locali. I protocolli fondamentali sono il TCP, che organizza la frammentazione in pacchetti dei dati da inviare, e l'IP, che controlla e verifica il corretto instradamento dei pacchetti stessi.

U

Username o User-id

Parola che identifica l'utente di una rete, di un servizio telematico o di un sito Internet. Bisogna digitarla esattamente, assieme alla password. Alcuni software distinguono fra lettere maiuscole e minuscole. Lo username può essere composto da sole lettere, da soli numeri, oppure lettere e numeri insieme; è pubblico e sempre accessibile, anzi è indispensabile conoscere quello di un altro utente per potergli indirizzare un messaggio di e-mail (negli indirizzi di posta elettronica, lo username costituisce la prima parte: username@provider.it).       

V

VoIP

Voice Over IP. Tecnologia digitale che consente la trasmissione di pacchetti vocali attraverso reti Internet, Intranet, Extranet, e VPN. Il segnale vocale viene digitalizzato e compresso. La serie di bit risultante viene posta in un pacchetto, il pacchetto IP. Questo pacchetto può viaggiare su una normale rete dati Internet ed essere decodificato una volta ricevuto, in modo da riottenere la voce originale

VPN

Virtual Private Network. Rete privata virtuale che permette al traffico IP di viaggiare in modo sicuro su una rete TC/IP pubblica (Internet, Intranet o Extranet) grazie alla codifica di tutto il traffico da una rete ad un'altra. La VPN utilizza il "tunneling" per codificare tutte le informazioni a livello IP e rappresenta l'alternativa economica alle più costose linee dedicate.       

Bibliografia

[1] The IP Telephony Project TERENA, The IP Telephony Cookbook . Marzo 2004

[2] H. Schulzrinne ,Codecs VoIP , www.cs.columbia.edu/~hgs/audio/codecs.html

[3] Documentazione per sviluppatori Skype www.skype.com/community/devzone

[4] Salman A. Baset and H. Schulzrinne , An Analysis of the Skype Peer-to-Peer Internet Telephony Protocol Settembre 2004

[5] Mark Spencer and Frank W. Miller, IAX Protocol Specification. Marzo 2004

[6] Mark Spencer and Frank W. Miller, IAX 2 Protocol Specification. Gennaio 2005

[7] Internet Engineering Task Force (IETF): http://www.ietf.org/

[8] . J. Rosenberg, H. Schulzrinne, G. Camarillo, A. Johnston, J. Peterson, R. Sparks, M. Handley, E. Schooler SIP: Session Initiation Protocol RFC 3261, Giugno 2002

[9] A. Grillini, A Falaschi Il protocollo SIP e le sue estensioni per Presence e Instant Messaging, 2003

[10] Session Initiation Protocol (SIP): http://www.ietf.org/html.charters/ sipcharter.html

http://www.softarmor.com/sipwg/ , http://www.cs.columbia.edu/~hgs/sip/

[11] J. Rosenberg, H. Schulzrinne, S. Casner, R. Frederick, V. Jacobson,RTP: A Transport Protocol for Real-Time Applications RFC 3550 Luglio 2003

[12] B. Höneisen SWITCH, ENUM – the E.164 NumberMapping Standard, Giugno2003

[13]E.164NumberMapping(ENUM):http://www.ietf.org/html.charters/enumcharter.html http://www.enum.org/information/faq.cfm

[14] SIP for Instant Messaging and Presence Leveraging Extensions (simple): http://www.ietf.org/html. charters/simple-charter.html , http://www.softarmor.com/simple/

[15] P. Faltstrom, E.164 number and DNS (RFC 2916) Settembre 2000

[16] M.Mealling. Dynamic Delegation Discovery System (DDDS) Part Three: The Domain Name System (DNS) Database (RFC 3403). http://www.ietf.org/rfc/rfc3403.txt, Ottobre 2002

[17] Jiri Khutan, Jan Janak, Yacine Rebahi Sip Express Router , Admin’s Guide. http://www.iptel.org/

[18] P. Hazlett, S. Miles, and G. Teigre, Sip Getting Started. Maggio 2005

[19] M. Sobolev, nathelper Module 2003

[20] D. Pascu, Mediaproxy SER module. 2004

[21] J. Heinanen, Enum Module. 2003

[22] D. Baron, B. Teitelbaum, The Sip.Edu CookBook. Massachusetts Institute of Technology

[23] D. Austin, N. Ohlmeier,SER HowTo,2003

[24] M. Mealling, R. Daniel, The Naming Authority Pointer (NAPTR) DNS Resource Record. Settembre 2000

[25] A. Gulbrandsen, P. Vixie, A DNS RR for specifying the location of services (DNS SRV), Febbraio 2000

[26] K. Egevang, P. Francis,The IP Network Address Translator (NAT) Maggio 1994

[27] J. Rosenberg , R. Mahy Traversal Using Relay NAT (TURN) Ottobre 2003