Università degli Studi di Roma

La Sapienza”

Facoltà di Ingegneria

Anno Accademico 2003-2004





SapienTel :

Progetto e sperimentazione di una architettura VoIP basata su Protocollo SIP per organizzazioni di natura accademica.

Relatore

Prof. Alessandro Falaschi

Laureando

Alessandro Calvo




Indice delle figure 4

Introduzione 6

Contesto 7

Il VoIP 7

Il Progetto SapienTel 8

Cos’è SapienTel 8

Analisi degli istituti di natura accademica. 10

Risorse informatiche e di rete disponibili. 10

Studio delle possibili esigenze in ambito di telecomunicazioni 11

Perché organizzazioni di natura accademica dovrebbero interessarsi al VoIP ? 11

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

Skype 14

Inter-Asterisk eXchange (IAX) Versione 2 17

Il protocollo SIP (Session Initiation Protocol) 18

ENUM e La convergenza con le linee PSTN 31

SIP Express Router 34

Analisi comparativo-funzionale 47

I criteri discriminanti 47

Analisi comparativa dell’architettura protocollare 47

Analisi comparativa dei VoIP server 50

Realizzazione 53

Conclusioni 73

Appendici 77

Appendice A 78

Strumenti usati 78

SSH(Secure Shell) 78

SIPSAK (SIP swiss army knife) 79

SERCTL 79

ETHEREAL 80

Appendice B 82

Il Test Bed 82

Appendice C 84

Glossario 84

Bibliografia 94


Indice delle figure

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

Figura 2: Interfaccia di skype 14

Figura 3 : Architettura della rete Skype 15

Figura 4: Protocollo IAX 2 in azione 18

Figura 5:Schema di azione detto trapezoide 24

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

Figura 7: Se A dialoga direttamente con B 24

Figura 8: Registrazione di uno User Agent 29

Figura 9: Messaggi scambiati per una chiamata tramite proxy 30

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

Figura 11: Confronto tra architettura Skype ed architettura SIP 48

Figura 12: Confronto tra protocollo IAX e protocollo SIP 49

Figura 13: Confronto tra Asterisk e SER 51

Figura 14:Schema dell’infrastruttura software di SapienTel 54

Figura 15: MediaProxy in azione 61

Figura 16: Architettura di Rete di SapienTel 67

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

Figura 18: Architettura del Test Bed 83






























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.

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:


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


Tecnologie

proprietarie

Tecnologie standardizzate

Inter-Asterisk eXchange (IAX)

SIP/SDP/RTP

SKYPE

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:

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:


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 è:

più in dettaglio, permette di:

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:

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:







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:


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



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).


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è:


mentre il SIP è un protocollo stateful cioè:


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:

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.


Indica un’operazione avvenuta con successo.


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.


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.


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


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:


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:


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:



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):



Supporto Client SIP:



Supporto per telefonia analogica (utilizzando interfacce PSTN):



Supporto per Client MGCP:

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:



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:


   Context "menuGenerale":
     Extension   Description
         s       Messaggio di Benvenuto ed istruzioni
         1       Segreteria didattica
         2       dipartimento INfOCOM
         3       progetto OCDN
         9       Prof Falaschi
         #       Termina conversazione

include => ”nomeContesto2”

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:




più praticamente un contesto si definisce come segue:


[ bloccoChiamatePerStudenti]

exten => s,1,risposta
   exten => s/044,2,SetCIDName(studente)
   exten => s,2,SetCIDName(professore)
   exten => s,3,Dial(SIP/professore)

; questo è un commento


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:


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:

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


Skype

SIP

È una tecnologia proprietaria

È uno standard IETF

È una realtà chiusa non esistono Gateway verso le altre realtà di VoIP

È una realtà completamente aperta ed integrabile con tutte le altre tecnologia VoIP(fatta eccezione per Skype)

Non permette il controllo di banda

Permette il controllo di banda

Permette di gestire i client dietro NAT

Permette di gestire i client dietro NAT

Non gestisce il video

Gestisce il video

Comprende l’integrazione con i servizi di presenza e l’Istant Messaging

Comprende l’integrazione con i servizi di presenza e l’Istant Messaging

Pochissime soluzioni hardware e software che implementano questa tecnologia lato client.

Moltissime soluzioni hardware e software che implementano questa tecnologia lato client.

Permette Gateway PSTN solo in uscita (skype OUT)

Permette la gestione di Gateway PSTN sia IN che OUT

Molto facile da utilizzare (si auto configura alla registrazione)

Facile da utilizzare sui client SIP

(richiede un minimo di configurazione)

Struttura fortemente decentralizzata, permette facilmente la scalabilità ma in modo meno controllabile(no controllo di banda, no dimensionamento dei super nodi)

Si basa sulla centralità di alcuni elementi (proxy, registrar,etc..), permette quindi una scalabilità consapevole e programmabile

Figura 11: Confronto tra architettura Skype ed architettura SIP





Confronto tra IAX e SIP


IAX

SIP

È un protocollo proprietario non standardizzato.

È uno standard IETF

È un protocollo destinato ai Server Asterisk ma tramite esso è integrabile con tutte le altre realtà VoIP

È una realtà completamente aperta ed integrabile con tutte le altre tecnologia VoIP(fatta eccezione per Skype)

Pemette il controllo di banda

Permette il controllo di banda

Permette di gestire i client dietro NAT

Permette di gestire i client dietro NAT

Gestisce il video

Gestisce il video

Non comprende l’integrazione con i servizi di presenza e l’Instant Messaging

Comprende l’integrazione con i servizi di presenza e l’Instant Messaging

Pochissime soluzioni hardware e software che implementano questa tecnologia lato client.

Moltissime soluzioni hardware e software che implementano questa tecnologia lato client.

Permette Gateway PSTN sia IN che OUT

Permette la gestione di Gateway PSTN sia IN che OUT

Non permette la negoziazione di codec Audio /Video

Permette la negoziazione di codec Audio /Video

Struttura centralizzata, permette quindi una scalabilità consapevole e programmabile

Si basa sulla centralità di alcuni elementi( proxy, registrar,etc..), permette quindi una scalabilità consapevole e programmabile

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:


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.


Asterisk

Sip Express Router

Progetto Open Source

Progetto Open Source

Disponibilità dei codici sorgenti

Disponibilità dei codici sorgenti

NON agisce da Sip Proxy(agisce da man-in-the-middle)

Agisce da Sip Proxy

Agisce da Sip Registrar

Agisce da Sip Registrar

Agisce da Location Server

Agisce da Location Server

Supporta SIP SOLO tramite UDP

Supporta SIP tramite TCP e UDP

Ha una struttura modulare

Ha una struttura modulare

Facilmente personalizzabile per creare soluzioni ad Hoc

Facilmente personalizzabile per creare soluzioni ad Hoc

Si sono riscontrati problemi di stabilità

Molto stabile

Installazione molto semplice

(con i parametri predefiniti)

Installazione molto semplice

(con i parametri predefiniti)

Occupazione di risorse media

Bassissima occupazione delle risorse

Interoperabillità con standard le line PSTN(unito ad apposite schede si occupa anche della transcodifica del segnale)

Interoperabillità con standard le line PSTN(ma necessità di gateway-pstn hardware)

Gestisce Voice Mail

Gestisce Voice Mail

Implementa Interactive Voice Response(IVR)

Può implementare Interactive Voice Response(IVR) tramite moduli esterni

Gestisce Caller ID

Gestisce Caller ID

Supporta Video

Supporta Video

Gestisce facilmente client dietro NAT ponendosi come Proxy RTP

Gestisce facilmente client dietro NAT utilizzando moduli esterni che supportano diversi Proxy RTP

NON Gestisce il bilanciamento del traffico su cluster di proxy RTP esterni

Esiste la possibilità di gestione del bilanciamento del traffico su cluster di proxy RTP esterni

Supporta ENUM

Supporta ENUM

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:






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


#-------------------------------------------

#1) Definizioni globali:

#-------------------------------------------

fifo_db_url=”mysql://ser:heslo@localhost/ser”


#-------------------------------------------

#2) Gestione Moduli esterni

#-------------------------------------------

loadmodule “/usr/local/lib/ser/modules/mysql.so”

loadmodule “/usr/local/lib/ser/modules/auth.so”

loadmodule “/usr/local/lib/ser/modules/auth_db.so”

loadmodule “/usr/local/lib/ser/modules/uri_db.so”


#-------------------------------------------

#3) Configurazione moduli:

#-------------------------------------------

modparam(“auth_db|uri_db|usrloc”, “db_url”, “mysql://utente_root:pswd@localhost/ser”)

modparam(“auth_db”, “alcolate_ha1”, 1)

modparam(“auth_db”, “password_column”, “password”)

modparam(“usrloc”, “db_mode”, 2)



#-------------------------------------------

#4) Blocco principale di instradamento:

#-------------------------------------------

if (uri==myself) {

if (method==”INVITE”) {

route(3);

break;

} else if (method==”REGISTER”) {

route(2);

break;

};


#-------------------------------------------

#5) Blocchi secondari di instradamento:

#-------------------------------------------

route[2] {

sl_send_reply(“100”, “Trying”);

if (!www_authorize(“ing.uniroma1.it”,”subscriber”)) {

www_challenge(“ing.uniroma1.it”,”0”);

break;

};

if (!check_to()) {

sl_send_reply(“401”, “Unauthorized”);

break;

};

consume_credentials();

if (!save(“location”)) {

sl_reply_error();

};







route[3] {

if (!proxy_authorize(“”,”subscriber”)) {

proxy_challenge(“”,”0”);

break;

} else if (!check_from()) {

sl_send_reply(“403”, “Use From=ID”);

break;

};

consume_credentials();

lookup(“aliases”);

if (uri!=myself) {

route(1);

break;

};

if (!lookup(“location”)) {

sl_send_reply(“404”, “User Not Found”);

break;

};

route(1);

}



#-------------------------------------------

#6) Blocchi di instradamento di risposta:

#-------------------------------------------


#-------------------------------------------

#7) Blocco di instradamento in caso di insuccesso:

#-------------------------------------------





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).


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.


#-------------------------------------------

#1) Definizioni globali:

#-------------------------------------------

debug=3

fork=yes #FA PARTIRE SER COME demone

log_stderror=yes # PERMETTIAMO CHE I MESSAGGI DI DEBUG SI PRESENTINO SU CONSOLE


listen=151.100.122.144 #E’ l’indirizzo IP del nostro SERVER

port=5060 #E’ LA PORTA DI ASCOLTO

children=4


dns=no

rev_dns=no

#-------------------------------------------

#2) Gestione Moduli esterni

#-------------------------------------------


#-------------------------------------------

#3) Configurazione moduli:

#-------------------------------------------



#-------------------------------------------

#4) Blocco principale di instradamento:

#-------------------------------------------


#-------------------------------------------

#5) Blocchi secondari di instradamento:

#-------------------------------------------



#-------------------------------------------

#6) Blocchi di instradamento di risposta:

#-------------------------------------------


#-------------------------------------------

#7) Blocco di instradamento in caso di insuccesso:

#-------------------------------------------





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



#-------------------------------------------

#1) Definizioni globali:

#-------------------------------------------

log_stderror=no



#-------------------------------------------

#2) Gestione Moduli esterni

#-------------------------------------------

loadmodule “/usr/local/lib/ser/modules/uri.so”

loadmodule “/usr/local/lib/ser/modules/mediaproxy.so”

loadmodule “/usr/local/lib/ser/modules/nathelper.so”

loadmodule “/usr/local/lib/ser/modules/textops.so”



#-------------------------------------------

#3) Configurazione moduli:

#-------------------------------------------

modparam(“nathelper”, “rtpproxy_disable”, 1)

modparam(“nathelper”, “natping_interval”, 0)

modparam(“mediaproxy”,”natping_interval”, 40)

modparam(“mediaproxy”,”mediaproxy_socket”, “/var/run/mediaproxy.sock”)

modparam(“mediaproxy”,”sip_asymmetrics”,”/usr/local/etc/ser/sip-clients”)

modparam(“mediaproxy”,”rtp_asymmetrics”,”/usr/local/etc/ser/rtp-clients”)

modparam(“registrar”, “nat_flag”, 6)


#-------------------------------------------

#4) Blocco principale di instradamento:

#-------------------------------------------

if (method==”INVITE” && client_nat_test(“3”)) {

record_route_preset(“151.100.122.144:5060;nat=yes”);

} else if (method!=”REGISTER”) {

record_route();

};


if (method==”BYE” || method==”CANCEL”) {

end_media_session();

};


if (loose_route()) {

if (has_totag() && (method==”INVITE” || method==”ACK”)) {

if (client_nat_test(“3”) || search(“^Route:.*;nat=yes”)) {

setflag(6);

use_media_proxy();

};

};

route(1);

break;

};


if (uri!=myself) {

route(1);

break;

};

if (uri==myself) {

if (method==”CANCEL”) {

route(3);

break;

} else if (method==”INVITE”) {

route(3);

break;

} else if (method==”REGISTER”) {

route(2);

break;

lookup(“aliases”);

if (uri!=myself) {

route(1);

break;

};

if (!lookup(“location”)) {

sl_send_reply(“404”, “User Not Found”);

break;

};

};


route(1);

}

#-------------------------------------------

#5) Blocchi secondari di instradamento:

#-------------------------------------------


route[1] {

t_on_reply(“1”);

if (!t_relay()) {

if (method=”INVITE” || method==”ACK”) {

end_media_session();

};

sl_reply_error();

};

}



route[2] {

sl_send_reply(“100”, “Trying”);

if (!search(“^Contact:\ +\*”) && client_nat_test(“7”)) {

setflag(6);

fix_nated_register();

force_rport();

};

if (!www_authorize(“ing.uniroma1.it”,”subscriber”)) {

www_challenge(“ing.uniroma1.it “,”0”);

break;

};

if (!check_to()) {

sl_send_reply(“401”, “Unauthorized”);

break;

};

consume_credentials();

if (!save(“location”)) {

sl_reply_error();

};

}


route[3] {

if (client_nat_test(“3”)) {

setflag(7);

force_rport();

fix_nated_contact();

lookup(“aliases”);

if (uri!=myself) {

route(1);

break;

};

if (!lookup(“location”)) {

sl_send_reply(“404”, “User Not Found”);

break;

};

if (method==”CANCEL”) {

route(1);

break;

};

if (!proxy_authorize(“”,”subscriber”)) {

proxy_challenge(“”,”0”);

break;

} else if (!check_from()) {

sl_send_reply(“403”, “Use From=ID”);

break;

};

consume_credentials();

if (isflagset(6) || isflagset(7)) {

use_media_proxy();

};

route(1);

}



#-------------------------------------------

#6) Blocchi di instradamento di risposta:

#-------------------------------------------

onreply_route[1] {

if ((isflagset(6) || isflagset(7)) && (status=~”(180)|(183)|2[0-9][0-9]”)) {

if (!search(“^Content-Length:\ +0”)) {

use_media_proxy();

};

};

if (client_nat_test(“1”)) {

fix_nated_contact();

};

}

#-------------------------------------------

#7) Blocco di instradamento in caso di insuccesso:

#-------------------------------------------




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:

<?

// Variabili contenenti le informazioni relative al DB


// nome del server in cui risiede Myql

//potrebbe essere anche lo stesso in quel caso localhost

$nome_server = "151.100.122.144";

// nome del database cui connettersi

$nome_db = "ser";

// nome dell'utente del database

$nome_utente = "root_ser";

// password utente

$db_password = "password_ser";

//nome della tabelle da usare (uso location perché mi da tutti i dettagli dell’utente registrato, possiamo anche decider edi filtrare i risultati $tabella1 = "location";

// MYSQL_CONNECT (indirizzo_server,nome_utente,password)

// è l'istruzione che stabilisce la connessione con il server

// in caso di insuccesso lo script "muore" [ die () ]

// e stampa un piccolo messaggio d'errore

$connessione=mysql_connect($nome_server,$nome_utente,$db_password)

or die ("Non riesco a connettermi

con il Server $nome_server<br>");

// MYSQL_SELECT_DB (nome_database,connessione)

// questa istruzione seleziona il database da usare

// presente sul server e "muore" in caso di insuccesso.

$database = mysql_select_db ($nome_db, $connessione)

or die ("Non riesco a selezionare il db $nome_db<br>");


//seleziono tutti gli utenti registrati

$tutti_utenti_registrati = "SELECT * FROM $tabella1 where";


$tutto = mysql_query ($utenti_registrati, $connessione)

or die ("Non riesco ad eseguire la query $tutti_dati");


//poi bisogna occuparsi della formattazione dei risultati


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 (SIPPSTN e PSTNSIP) il Gateway si comporta come un Sip Client:


SIPPSTN


PSTNSIP


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) :

#-------------------------------------------

#1) Definizioni globali:

#-------------------------------------------


#-------------------------------------------

#2) Gestione Moduli esterni

#-------------------------------------------

loadmodule "/usr/local/lib/ser/modules/avpops.so"

loadmodule "/usr/local/lib/ser/modules/domain.so"

loadmodule "/usr/local/lib/ser/modules/permissions.so"

loadmodule "/usr/local/lib/ser/modules/enum.so"



#-------------------------------------------

#3) Configurazione moduli:

#-------------------------------------------

modparam("auth_db|permissions|uri_db|usrloc","db_url","mysql://root_ser:pswd@localhost/ser")

modparam("tm", "fr_inv_timer", 27)

modparam("tm", "fr_inv_timer_avp", "inv_timeout")

modparam("permissions", "db_mode", 1)

modparam("permissions", "trusted_table", "trusted")

modparam(“enum”,”domain_suffix”,”e164.arpa.”)



#-------------------------------------------

#4) Blocco principale di instradamento:

#-------------------------------------------

#-------------------------------------------

#5) Blocchi secondari di instradamento:

#-------------------------------------------

route[3] {

if (client_nat_test("3")) {

setflag(7);

force_rport();

fix_nated_contact();

};

if (method=="INVITE" && !allow_trusted()) {

if (!proxy_authorize("","subscriber")) {

proxy_challenge("","0");

break;

} else if (!check_from()) {

sl_send_reply("403", "Use From=ID");

break;

};

consume_credentials();

};

if (uri=~"^sip:003906499[0-9]{4}*@") {

route(4);

break;

};


#PERMETTIAMO CHIAMATE IN USCITA PSTN SOLO VERSO

# NUMERI CHE VANNO DA +39064990000 A +39064999999 QUINDI SOLO QUELLI DELL’UNIVERSITA’


# utilizzo enum se prefisso internazionale
if (method=="INVITE" && uri=~"^sip:[0-9]{14}*@") {
       if (!enum_query("voice")) # vado a cercare il valore nel NAPTR "e2u+sip"
           enum_query(""); # E2U+sip
   };



if (uri=~"^sip:112*@") {

route(4);

break;

};

#PERMETTIAMO COSI ALLE CHIAMATE DI EMERGENZA DI USCIRE VERSO LINEE PSTN


lookup("aliases");

if (uri!=myself) {

route(5);

route(1);

break;

};

if (!lookup("location")) {

if (uri=~"^sip:[0-9]{10}@") {

route(4);

break;

};

sl_send_reply("404", "User Not Found");

break;

};

if (method=="CANCEL") {

route(1);

break;

};

route(5);

route(1);

}


route[4] {

# -----------------------------------------------------------------

#GESTIONE TRAFFICO PSTN

# -----------------------------------------------------------------

rewritehost("XXX.XXX.XXX.XXX"); # INIDIZZO IP DEL GATEWAY PSTN

avp_write("i:45", "inv_timeout");

route(5);

route(1)

}


#-------------------------------------------

#6) Blocchi di instradamento di risposta:

#-------------------------------------------


#-------------------------------------------

#7) Blocco di instradamento in caso di insuccesso:





per esempio :

1.9.2.5.3.7.3.5.5.4.4.e164.arpa. 0 IN NAPTR 0 0 "U" "E2U+SIP" "!^.*$!sip:utente2@universita.uk!" .


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:



Apparati e Software

Tempo necessario per la configurazione

(per ogni componente)

Costo

Software Server SIP

(Sip Express Router)

15 Giorni

0 €

Proxy RTP

(MediaProxy)

5 giorni

0 €

Client Sip Software

(kphone,Xlite, Windows Messenger)

2-10 minuti

0—200€

Client Sip hardware

(sipura 2000)

2-10 minuti

50---300€

Database management system

(Mysql o PostgreSQL)

1-4 giorni

0€

Sistema Operativo Linux (Fedora Core 3)

1-4 giorni (istallazione)

0€

Personal Computer che ospiti SapienTel

(almeno uno ma si potrebbe pensare ad una gestione a cluster)

0-1 giorno

1500€ --4000€

Gateway IP-PSTN

(per esempio AS53000 o CISCO 2611 o semplicemente server linux -Astersik con schede ZapTel di interfaccia )

10-20 giorni

3000€--30000€

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 analy
zer, 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:







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