Load Balancing dinamico per servizi di presenza

Load Balancing dinamico per servizi di presenza Di Carella Giuseppe Antonio 0000348431 ABSTRACT Negli ultimi anni si assiste sempre più alla nascita di servizi riguardanti la diffusione di informazioni di vario genere sugli utenti. In quest ambito si diffondono sempre più quei componenti in grado di raccogliere informazioni su un certo utente o un certo dispositivo e diffonderle a tutti coloro che mostrano interesse verso di esse. Un caso particolare sono i cosiddetti servizi di presenza, i quali sono nati per venire incontro all esigenza sempre maggiore di fornire informazioni sempre aggiornate su un certo dominio d interesse, siano esse informazioni riguardanti lo stato o al contesto. In questa relazione saranno presentate le scelte progettuali per riuscire ad avere un servizio di presenza anche su larga scala con una buona qualità di servizio. Introduzione Il progetto realizzato si pone l obiettivo di rendere dinamica la gestione del carico relativo ad un servizio di presenza. In particolare il servizio dovrà essere fornito da varie macchine il cui compito sarà di gestire le richieste provenienti da vari utenti. Lo scenario è dunque quello in cui vi sono vari utenti che attraverso delle applicazioni client intendono sottoscriversi per ricevere informazioni di altri utenti o pubblicare le proprie informazioni. La presenza è un concetto ben conosciuto e utilizzato largamente in applicazioni di messaggistica istantanea e si basa sul meccanismo publish/subscribe in cui vi sono tre entità fondamentali: Presence server (PS): si tratta dell unità centrale, che riceve le richieste degli utenti e smista le informazioni. Presentity: utenti che pubblicano le proprie informazioni attraverso i messaggi PUBLISH del protocollo SIP. Watcher: utenti che si sottoscrivono per ricevere informazioni riguardanti le presentity, attraverso i messaggi di SUBSCRIBE. In generale gli scenari possibili sono svariati e molto variegati. L idea di base è di avere uno scenario distribuito in cui vi siano vari presence server in grado di fornire il servizio richiesto. Il problema però è un po più complesso. Per capire meglio il problema è necessario iniziare a focalizzarsi su cosa s intende per pubblicazione e sottoscrizione. Meccanismo di pubblicazione Il presence service è una particolare applicazione basata sulla struttura SIP per la notifica degli eventi. Come descritto nel paragrafo precedente, vi sono due entità, la presentity e il watcher, che svolgono il ruolo rispettivamente di fornitori e di osservatori. Lo IETF ha introdotto il metodo SIP PUBLISH nell RFC 3903. Lo scopo della PUBLISH request è di pubblicare un evento riguardante lo stato senza l utilizzo della struttura SIP per la notifica degli eventi. Figura 1. Architettura del Presence Service Figura 2. Pubblicazione di informazioni di presenza 1

In figura 2 si nota che il Presence User Agent, a conoscenza dello stato della presentity, invia una PUBLISH request, con informazioni sullo stato, al Presence Agent, che risponde con un 200 OK response. al Presence Agent in cui specifica attraverso l event header che si tratta di una sottoscrizione al servizio di presenza. La PUBLISH request contiene nel body del messaggio un documento Presence Information Data Format (PIDF) che contiene le informazioni di presenza della presentity. Il PIDF è specificato nell RFC 3863 e costituisce un profilo comune per la presenza, in modo tale che può esser utilizzato in vari protocolli, per il trasporto delle informazioni di presenza. È stato designato in maniera minimale proprio per renderlo maggiormente estensibile secondo le esigenze dei vari protocolli che ne fanno uso. Esso codifica le informazioni di presenza in un documento XML. Figura 4. Meccanismo di sottoscrizione Il Presence Agent una volta ricevuta la richiesta risponde con una 200 OK Response e da questo momento in poi il watcher è in grado di ricevere notifiche sullo stato delle presentity alle quali si è sottoscritto. In particolare il Presence Agent invia una NOTIFY request, con l Event header indicante un servizio di presenza, e le informazioni riguardanti lo stato contenute nel body del messaggio. Figura 3. Esempio di PIDF Il PIDF, come mostrato in figura 3, contiene le informazioni di una presentity. Consiste in una serie di elementi che fanno riferimento a una stessa tuple. Ogni tuple contiene lo status della presentity (che può essere open o closed, significante connesso o disconnesso rispettivamente), un elemento opzionale contact che fornisce l URI del contatto, un altro opzionale note e vari altri campi a seconda dell estensione. Meccanismo di sottoscrizione Il meccanismo di sottoscrizione permette ad un watcher di sottoscriversi al Presence Server per ricevere informazioni di una presentity. Il Presence User Agent del watcher invia una SUBSCRIBE request Ogni volta che lo stato della presentity cambia, essa pubblica il suo nuovo stato al Presence Agent che invierà le informazioni aggiornate attraverso la NOTIFY a tutti coloro che si sono sottoscritti per riceverle. Architettura Il progetto realizzato si compone di varie entità ognuna con un compito ben distinto. Innanzitutto è necessario delineare lo scenario. Il servizio di presenza come già accennato si basa sul modello Pub/Sub. Il Presence Service (PS) è intrinsecamente un servizio centralizzato, in cui watchers e presentities fanno riferimento a un unico server per sottoscriversi o pubblicare le proprie informazioni. In uno scenario a larga scala, non è possibile pensare a un architettura basata su un singolo server centrale che gestisce tutte le richieste provenienti dai vari client dislocati sulla rete. Per questo motivo è 2

necessario iniziare a immaginare uno scenario in cui non solo gli utenti siano partizionati in vari PS, ma anche i PS si coordinano tra di loro per fornire risposte corrette agli utenti che ne hanno fatta richiesta. È necessario capire fin da subito quali sono le problematiche riscontrate nell utilizzo di quest architettura. Il servizio di presenza si basa, come già descritto in precedenza, sulle informazioni delle presentity che sono distribuite ai vari watchers sottoscrittori, sotto forma di notifiche. In un architettura centralizzata questo consiste nel fatto che il presence server memorizza al suo interno una sorta di lista degli utenti che a seguito di una sottoscrizione sono autorizzati a ricevere informazioni riguardanti una determinata presentity, e ogni qualvolta una presentity aggiorna il suo stato queste vengano distribuite attraverso delle notifiche a tutti i sottoscrittori contenuti nella lista. In un architettura a larga scala, questo è un vincolo abbastanza pesante. Nel momento in cui una presentity pubblica una nuova informazione attraverso un messaggio di PUBLISH, il PS invia le informazioni ai sottoscrittori di quella presentity. In un architettura single server, questo non determina nessun problema, perché alla ricezione della richiesta di PUBLISH il PS non fa altro che scandire la lista di sottoscrittori alla ricerca di coloro che si erano sottoscritti per ricevere notifiche riguardanti quella determinata presentity. In un architettura single server è facile immaginare che questo è facilmente risolto con l utilizzo di hash table locali al PS che sono mantenute in memoria, in cui vengono salvate le informazioni riguardanti watchers e presentities, di volta in volta caricate o scaricate nel DB. Nel momento in cui invece abbiamo un architettura multi server il problema è più complicato. Se un watcher user invia la propria sottoscrizione ad un PS diverso da quello in cui la presentity invia le proprie pubblicazioni, allora non riceverà notifiche sullo stato aggiornato della presentity. Per risolvere questo problema, esiste la necessità di una nuova architettura in cui i vari PS si coordinano tra di loro per fornire un servizio di presenza affidabile ai vari utenti. La soluzione più semplice da pensare è quella in cui abbiamo uno scenario costituito da vari PS che fanno uso di un unico Database centralizzato. In pratica ogni PS quando riceve la richiesta, sia essa di Publish o di Subscribe, interroga un DB che condivide con gli altri PS del suo dominio. Questa soluzione però ha vari punti deboli: per prima cosa viene inserito un unico punto di centralizzazione, il DB, in una soluzione in cui l obiettivo primario è quello di raggiungere bilanciamento di carico fra varie macchine. Un altro punto a sfavore è che ogni PS dovrebbe essere costretto a lavorare in writethorugh, cioè ogni qualvolta riceve una richiesta oltre a lavorare con la cache locale, deve anche aggiornare il DB, in modo tale che gli altri PS trovino dati sempre aggiornati al suo interno. Un alternativa potrebbe essere quella di far sì che ogni qualvolta una presentity aggiorna il proprio stato, il messaggio di PUBLISH sia inviato agli altri presence server del dominio, in modo tale che essi siano in grado di notificare i vari sottoscrittori. Questa modalità è quella descritta nella figura seguente. 200 OK PUBLISH p@domain.com PUBLISH p@domain.com 200 OK NOTIFY 200 OK Figura 5. Scenario di migrazione delle PUBLISH Nell esempio la presentity p invia al server a lei più vicino il messaggio di PUBLISH ricevendo una response indicante che la richiesta è andata a buon fine. A questo punto il server deve comunicare agli altri server che la presentity p ha effettuato una pubblicazione, e lo fa inoltrando agli altri il messaggio di PUBLISH appena ricevuto. Naturalmente è necessaria una sostanziale modifica al presence server affinché siano gestiti correttamente tutti i messaggi di PUBLISH ridirezionati. Questa soluzione ha però alcuni aspetti negativi. Se da un lato può essere vantaggiosa dal punto di vista dell interoperabilità dei server dello stesso dominio, dall altro non risponde esattamente a quelli che sono i requisiti del load balancing, cioè quelli di dinamicità e mobilità. Questa soluzione si avvicina di più a quella di un load sharing, in cui si partiziona staticamente il dominio degli utenti tra più server, ma in realtà non si hanno garanzie sul fatto che 3

server dello stesso dominio abbiano carico equilibrato durante l esecuzione, e soprattutto non è possibile prevedere nessuna soluzione alternativa nel caso di guasti di uno dei server appartenenti al dominio. Un altro punto a sfavore di questa soluzione è che il più delle volte sarà necessario inviare un numero elevato di messaggi di PUBLISH anche nel caso in cui gli altri server appartenenti al dominio non hanno nessun watcher sottoscritto per quella presentity. Questa soluzione in uno scenario a larga scala, in cui il numero di server è elevato, comporta un appesantimento della rete dovuto alla ridirezione dei messaggi di PUBLISH, che in alcuni casi potrebbero essere superiori anche al numero di utenti realmente interessati a una presentity. In quest ottica quindi è possibile ipotizzare che invece di ridirigere le publish inviate dalle presentity, siano ridirette le subscribe degli utenti sottoscrittori sul server dove poi la presentity invierà gli aggiornamenti del proprio stato. Così facendo si riduce notevolmente il numero di messaggi scambiati tra i vari server. In realtà però così facendo si rientra nel caso precedente in cui si ha un partizionamento statico degli utenti sui vari PS del dominio. In poche parole non abbiamo nessuna garanzia che partizionando gli utenti in base al numero di server non avremo situazioni di sovraccarico, perché il carico di una macchina non dipende esclusivamente dal numero di utenti serviti, ma soprattutto dal numero di messaggi gestiti. Load Balancing Quello che noi vorremmo è invece un infrastruttura costituita da una serie di server che lavorino tra di loro in maniera indipendente, ma soprattutto un uso delle risorse più corretto ed efficiente, un overhead limitato e la possibilità di far fronte a situazioni di guasto. Lo scenario delineato è dunque quello in cui vi sono vari server di presenza che gestiscono le richieste di numerosi client dislocati in rete. Ipotizziamo, dunque, che per un determinato dominio vi siano una serie di PS incaricati a gestire le richieste provenienti dai vari client. In modo statico ogni richiesta verrà ridirezionata al server gestore di quel particolare utente. Ogni client invierà i suoi messaggi a un PS il cui ruolo sarà di ridirigere le richieste al PS di competenza. In pratica il PS inizialmente divide il carico di lavoro sui vari server in maniera statica secondo politiche di partizionamento del dominio di utenti. Quello che accade è che a un certo punto uno dei PS si trovi a gestire un numero di richieste elevato a tal punto che non sarà più in grado di gestirle correttamente e che il numero di messaggi persi inizi a crescere. Il load balancing è un operazione che viene eseguita nel momento in cui uno dei PS inizia a sovraccaricarsi a causa dell elevato numero di richieste ricevute. È necessario dunque fare in modo che quel PS sia scaricato, e per far ciò è necessario capire a chi ridirigere le richieste che lui non potrà più servire. Ciò che si vuole realizzare è una migrazione di un determinato range di utenti su un altro server del dominio al momento più scarico. Figura 6. Scenario di load balancing Nel momento in cui i valori di utilizzo della CPU superano una determinata soglia, viene avviata automaticamente la procedura di load balancing. L idea è di migrare le presentity in modo tale che il server si trovi a servire un numero minore di pubblicazioni e relative notifiche. Per far ciò è necessaria un protocollo di coordinazione che permetta ai vari server appartenenti al dominio di scambiarsi informazioni sul carico. Nel nostro caso si è scelto di utilizzare lo stesso meccanismo PUB/SUB per lo scambio d informazioni tra i vari server. Ogni server si sottoscrive inizialmente per ricevere le pubblicazioni degli altri. In ogni istante ogni server conosce la situazione degli altri. Nel momento in cui il carico di uno dei server supera una determinata soglia, sarà sufficiente ricercare all interno di una tabella che memorizza le 4

informazioni degli altri, qual è il server più scarico. Determinato il server più scarico il ruolo fondamentale svolto dal monitor sarà di scaricare un certo numero di watchers dal database del PS, e trasferirli all atro server segnalando al PS load balancer la migrazione effettuata. Tecnologie utilizzate Kamailio Figura 7. Migrazione utenti tra PS Per realizzare le procedure richieste in merito al servizio di presenza, è stato utilizzato il modulo di presenza fornito da kamailio, un progetto open source partito nel 2005, le cui origini risalgono al 2001-2002 quando venne sviluppato nei laboratori dell istituto di ricerca FhG FOKUS di Berlino. Scritto in linguaggio C per sistemi Unix/Linux con un architettura specifica per offrire elevate prestazioni, è formato da una serie di moduli in grado di svolgere varie funzioni di SIP server e gateway. Nel progetto realizzato è stato utilizzato il modulo di Presence fornito da Kamailio per svolgere le funzioni di Presence Server. In particolare esso implementa le funzionalità fondamentali della notifica degli eventi SIP. Esso gestisce le richieste di PUBLISH e SUBSCRIBE e genera NOTIFY response in maniera del tutto generale indipendentemente dal tipo di evento. È altamente estensibile e permette la registrazione di eventi da parte di altri moduli. Figura 8. Modulo di presenza di kamailio Il modulo, mostrato in figura 8, utilizza il salvataggio delle informazioni in database e in memoria cache per ottimizzare le prestazioni. In particolare le informazioni riguardanti le SUBSCRIBE request sono immagazzinate in memoria e aggiornate periodicamente nel database. Per la realizzazione del load balancing sono state necessarie alcune modifiche al normale funzionamento del Kamailio PS che verranno mostrate nei successivi paragrafi. IMS Bench SIPp Un altro strumento fondamentale utilizzato, è l IMS Bench SIPp. IMS Bench SIPp è una versione modificata del SIPp tool di test che permette la generazione di richieste e risposte in protocollo SIP. Scritto in linguaggio C++ è uno strumento semplice da utilizzare che permette attraverso l opportuno settaggio di file, scritti in linguaggio XML e definiti scenari, di simulare sia SIP client sia server. In particolare definendo uno scenario è possibile specificare quante chiamate per secondo si devono generare, quanto deve durare la simulazione, ed altre svariate configurazioni che permettono la simulazione ed il rispettivo reperimento dei risultati in maniera del tutto semplificata. Anche in questo caso per la procedura di load balancing è stato necessario apportare alcune modifiche alla versione originale. 5

Architettura JAIN SIP La seguente figura mostra l architettura principale della tecnologia JAIN SIP. su un SipProvider. In questo modo è in grado di inviare e ricevere messaggi, sotto forma di eventi, direttamente utilizzando il SipProvider in modalità stateless o usando le transazioni e i dialoghi in modalità statefull. Nel progetto, JAIN SIP viene utilizzato per realizzare il protocollo di coordinazione tra i monitorps installati sulle varie macchine. Implementazione Figura 9. Architettura JAIN SIP JAIN SIP fornisce metodi per la creazione dei messaggi SIP, ne permette l invio e la ricezione, permette di effettuare il parsing, di invocare gli event handler forniti dall applicazione e di fornire supporto alle transazioni e ai dialoghi. Il tutto si svolge attraverso le API JAIN SIP contenute nel package java.jain.protocol.ip.sip che contiene i seguenti package principali: Package generali: definiscono le interfacce dell architettura, dei dialoghi, delle transazioni e degli eventi. Package dei messaggi: contiene una serie di classi con metodi necessari alla creazione dei messaggi SIP e all attività di processo delle richieste e delle risposte. Ogni PS sarà affiancato da un installazione di un modulo scritto in linguaggio java, denominato monitorps, il cui ruolo fondamentale sarà quello di: - Analizzare i valori di utilizzo della CPU della macchina sul quale sta eseguendo. - Informare gli altri server appartenenti al dominio dello stato attuale del carico della macchina. - Avviare la procedura di load balancing nel momento in cui la macchina locale è sovraccarica. Analisi della CPU usage All avvio del monitorps viene inizializzato un Thread Sender il cui compito è quello di monitorare la percentuale di utilizzo della CPU della macchina sulla quale sta eseguendo. Per far ciò è stato necessario l utilizzo della classe di sistema Runtime per mettere in esecuzione lo script monitor_cpu che ogni 2 secondi restituisce il carico della CPU e l utilizzo della memoria da parte dei processi in esecuzione sul server. Package degli indirizzi: contiene i vari wrapper per gli URI. In particolare definisce le interfacce per i SIP URI e i TEL URI. Runtime r = Runtime.getRuntime(); Process p = r.exec("./monitorcpu_memorymod.sh kamailio"); Package degli header: fornisce una serie di classi con metodi utili per creare e processare gli header SIP. Definisce interfacce necessarie alla creazione degli header standard e di molte estensioni del protocollo SIP. A questo punto per non avere situazioni in cui il monitor venga attivato in situazioni di picchi istantanei si è fatto in modo che questi valori vengano di volta in volta inseriti in un array, e su questi ci si calcoli una media in modo da vedere se per intervalli abbastanza ampi il server è sovraccarico. Ogni applicazione che vuole utilizzare le API JAIN SIP deve innanzitutto implementare l interfaccia SipListener, in quanto JAIN SIP associa un unico SipListener per ogni SipStack, e in seguito registrarla 6

Informazioni di stato I dati relativi all utilizzo della CPU oltre ad essere utilizzati localmente per monitorare il server, vengono di volta in volta comunicati agli altri server. Il meccanismo di comunicazione delle informazioni di stato previsto è quello delle Publish/Subscribe. Come accennato in precedenza, la procedura di balancing si basa sulla migrazione di un certo numero di utenti da un PS a un altro, cioè sulla migrazione d informazioni riguardanti i vari client. Ogni PS solitamente per ottimizzare le prestazioni, lavora memorizzando le informazioni in cache, che di tanto in tanto vengono trasferite nel DB. Ogni server all avvio si sottoscrive agli altri server appartenenti al dominio per ricevere informazioni riguardanti il carico della CPU, e il range di utenti fino a quel momento serviti. I server sfruttano il meccanismo delle PUBLISH per pubblicare informazioni riguardanti l utilizzo della CPU agli altri server del dominio. In particolare queste informazioni sono inserite nel body XML del messaggio. Figura 10. Diagramma di sequenza del load balancing A ogni NOTIFY ricevuta, queste informazioni vengono estratte e inserite all interno del database nella tabella monitor che conterrà i seguenti campi. Nella figura 10 viene mostrato un diagramma di sequenza delle operazioni svolte nel momento in cui il carico della CPU di un PS supera una determinata soglia. Id Ip Porta cpuusage Min Max State - ID: è l identificatore del server - IP: ip del server - Porta: porta del server - cpuusage: valore di utilizzo della CPU - min e max: range di utenti serviti all interno del dominio. - State: identifica lo stato in cui si trova il server. Se occupato vuol dire che quel server non può essere utilizzato per il meccanismo del load balancing Procedura di load balancing Nel momento in cui il valore di carico della CPU supera una determinata soglia, viene avviata la procedura di load balancing. Per prima cosa sarà necessario individuare il server più scarico all interno del dominio. Per far ciò sarà necessario scandire la tabella monitor alla ricerca del server meno carico al momento nel dominio. Test Per utilizzare questo tool per testare l architettura progettata, è stato necessario effettuare una modifica ai sorgenti: ogni qualvolta viene ricevuto un messaggio la risposta viene inviata non al remote controller prestabilito in fase di avvio tramite il comando rmctrl ma a colui che ha inviato il messaggio. Questo è necessario nel nostro sistema in quanto durante l esecuzione un client potrebbe trovarsi a dover cambiare l indirizzo di destinazione delle risposte da lui generate. In questo caso è stato necessario definire due scenari. In uno sono stati simulati una serie di client che inizialmente inviano una serie di richieste di SUBSCRIBE a un server. Una volta effettuata la SUBSCRIBE e ricevuto la 202 Response, i client rimangono in attesa di successive notifiche da parte del PS relative allo stato degli utenti a cui si sono sottoscritti. Una volta effettuate le SUBSCRIBE è stato avviato lo scenario di PUBLISH, in cui una serie di client inizia ad inviare pubblicazioni al PS. 7

Il testbench è stato settato in modo tale che inizialmente vengono inviate un massimo di 399 richieste, con 19 cps per la durata di 20 s. I test sono stati effettuati su tre macchine con cpu Pentium4 Intel. In una sono stati installati l IMS bench, e il server kamailio con funzione di redirect server. Negli altri due il PS kamailio e il modulo in java necessario al balancing. Figura 11. Architettura di testing Figura 13. Utilizzo della CPU con load balancing Come si nota dal grafico, nel momento in cui il carico della cpu supera una determinata soglia, automaticamente viene avviata la procedura di migrazione con relativa segnalazione dei vari PS. In particolare come si nota dal grafo in figura 13, la procedura ha un costo iniziale dovuto alla cancellazione degli utenti dalla cache e il reperimento delle informazioni dal DB, e infine allo scambio delle liste tra PS, però è un costo abbastanza limitato se confrontato con i risultati ottenuti dalla soluzione con singolo server. Nei test è stato simulato uno scenario in cui vi sono 400 utenti che inizialmente inviano le loro sottoscrizioni al server. Sono stati effettuati vari test per cercare di capire realmente il comportamento del sistema a fronte di un elevato numero di messaggi generati. Un primo test effettutato prevedeva l esistenza di un singolo PS. Il PS dopo aver ricevuto le prime sottoscrizioni, inizia a ricevere i messaggi di PUBLISH, con un incremento di 4 cps per step, per un numero di 55 step. In realtà come si può notare dal grafico in figura 12, il PS satura dopo appena 270 s, dall avvio della simulazione. Figura 12. Utilizzo della CPU nel caso di un singolo PS Il secondo test effettuato mostra invece cosa accade in presenza del monitorps che effettua la migrazione degli utenti da un server a un altro. Lo scenario simulato è identico a quello del caso di un singolo server. Conclusioni e sviluppi futuri Con lo sviluppo di questo progetto si è realizzata un infrastruttura che permette di raggiungere maggiori performance nell ambito dei servizi di presenza. Per garantire ampia applicabilità la soluzione proposta è basata su un modulo JAVA facilmente integrabile con servizi di presenza già esistenti. Il servizio realizzato permette la coordinazione tra server di presenza appartenenti allo stesso dominio, in modo tale da avere una conoscenza completa e reciproca delle condizioni di carico dei vari componenti. Inoltre questo servizio permette di effettuare una migrazione, e quindi un load balancing, in quelle macchine che operano in situazioni di sovraccarico. Il risultato ottenuto sottolinea quanto sia importante avere a disposizione meccanismi di questo tipo soprattutto in ambienti in cui il numero degli utenti, e le rispettive richieste cresce esponenzialmente. I risultati sperimentali confermano anche le scelte progettuali fatte, in quanto è possibile delegare il servizio di presenza di un determinato range di utenti ad un altro server, con tempi relativamente ristretti e soprattutto con una bassa perdita di messaggi. La soluzione proposta si presta in ogni caso ad altre possibilità di ampliamento. Un possibile sviluppo 8

futuro potrebbe essere quello di prevedere un load balancing anche inter dominio, ad esempio prevedendo un meccanismo di coordinazione tra server di domini differenti ed effettuarne una relativa migrazione anche a livello di dominio. Inoltre un'altra estensione possibile potrebbe riguardare le modalità con cui i vari PS si coordinano, cioè le modalità con cui scambiano le informazioni relative al carico. In questo progetto per semplicità è stato utilizzato il meccanismo Pub/Sub, però in realtà esistono delle soluzioni con un costo relativamente più basso. Riferimenti [RFC 3261] J. Rosenberg, H. Schulzrine, G. Camarillo, A. Johnston, J. Peterson, R. Sparks, M. Handley, E. Schooler, RFC 3261, Sip: Session Initiation Protocol, Giugno 2002. [3GIMS] G. Camarillo e M. A. Garcia Martin, The 3G IP Multimedia Subsytem Merging the Internet and the Cellular Worlds, 2. Ed., Hoboken, NJ:Wiley, 2006. [RFC 3325] C. Jennings, J. Peterson, M. Watson, Private Extensions to the Session Initiation Protocol (SIP) for Asserted Identity within Trusted Networks, Novembre 2002. [J2SE]Java, http://java.sun.com [3GPP] 3GPP, http://3gpp.org [WFA] Wi Fi Alliance, http://www.wi-fi.org [WIKI] Wikipedia, http://www.wikipedia.org 9