Università degli studi di Bologna Alma Mater Studiorum Facoltà di Ingegneria Corso di Laurea in Ingegneria informatica Progetto in Reti di Calcolatori M Kamailio: una modifica per Load Balancing e QoS Docente Prof. Antonio Corradi Autore Stefano Poli Anno Accademico 2009/2010
Indice 1 Presentazione 4 1.1 Obiettivi.............................. 4 1.2 Presentity, Watcher e Presence Server.............. 5 1.3 Vincoli tecnologici........................ 7 1.4 Panoramica su questa relazione................. 8 2 Protocollo SIP 9 2.1 Architettura SIP......................... 10 2.2 Struttura SIP........................... 11 2.2.1 Syntax and Encoding layer................ 12 2.2.2 Transport layer...................... 12 2.2.3 Transaction layer..................... 13 2.2.4 Transaction User layer.................. 13 2.3 Messaggio SIP........................... 13 2.3.1 Request-Line....................... 14 2.3.2 Response-Line....................... 15 2.3.3 Headers.......................... 16 2.3.4 Corpo del messaggio................... 18 2.3.5 SIP URI.......................... 18 1
INDICE 2 3 Presence Service 19 3.1 Introduzione............................ 19 3.2 Sorgenti delle informazioni di presenza............. 24 3.3 Standard per protocolli di presenza: SIMPLE......... 25 3.3.1 Metodi PUBLISH, SUBSCRIBE e NOTIFY...... 29 3.3.2 Presence Information Data Format........... 30 3.4 Gestione dei conflitti delle informazioni............. 33 3.5 Metodi per l utilizzo del servizio di presenza.......... 35 4 Tecnologie utilizzate 40 4.1 Presence Server Kamailio..................... 40 4.2 JAIN-SIP............................. 41 5 Soluzione del progetto 44 5.1 Introduzione............................ 44 5.2 Client SIP............................. 48 5.2.1 PUBLISH......................... 50 5.2.2 SUBSCRIBE e UNSUBSCRIBE............. 51 5.3 Presence Server Kamailio..................... 52 5.3.1 Modifica della gestione dei messaggi SUBSCRIBE... 53 5.3.2 Modifica della gestione dei messaggi PUBLISH..... 56 5.4 Risultati sperimentali....................... 62 A Configurazione di kamailio 67 A.1 Prerequisiti............................ 67 A.2 Download............................. 68 A.3 Compilazione e installazione................... 68 A.4 Configurazione.......................... 70 A.4.1 File di configurazione per ogni istanza......... 72
INDICE 3 B Modulo di presenza modificato 81 B.1 Compilazione ed installazione.................. 81 B.2 Configurazione.......................... 82 Bibliografia 88
Capitolo 1 Presentazione 1.1 Obiettivi Il progetto si propone di sviluppare un sistema di supporto per la distribuzione di dati di presenza (ad esempio stato e contatti dell utente, informazioni di localizzazione, informazioni sul contesto di esecuzione,...) su larga scala. Tale sistema deve essere in grado di mettere in comunicazione fonti (presentity) e fruitori (watcher) dei dati di presenza, anche quando presentity e watcher si trovano su server differenti. Oltre a ciò, si vuole progettare un infrastruttura di supporto in grado di abilitare alta scalabilità di tutto il sistema attraverso tecniche di bilanciamento del carico. Infine, si vuole dare la possibilità anche a terminali mobili di accedere in modo continuativo al servizio di presenza (sia in spedizione che in ricezione) nonostante possibili disconnessioni. 4
CAPITOLO 1. PRESENTAZIONE 5 1.2 Presentity, Watcher e Presence Server Il sistema è composto da tre entità principali: le presentity, i presence server (servizio di presenza) e i watcher (figura 1.1) Figura 1.1: Sistema Le presentity In generale si ipotizzi di avere diverse fonti di informazioni di presenza che, agendo da presentity, generano i dati di presenza da distribuire a tutti i sottoscrittori registrati. Ogni presentity deve essere in grado di: collegarsi a un server di presenza e inviare un messaggio contenente il suo stato (es. online, non al computer, a pranzo); migrare su di un server alternativo in caso il server non sia disponibile o sovraccarico.
CAPITOLO 1. PRESENTAZIONE 6 I watcher I watcher, in modo duale rispetto presentity, rappresentano le entità interessate alla ricezione delle informazioni di presenza. Ogni watcher deve essere in grado di: collegarsi a un server di presenza e sottoscrivere lo stato della sua lista di contatti; ricevere le informazioni di presenza dei propri contatti dal server; migrare su di un server alternativo in caso il server non sia disponibile o sovraccarico. Il Presence Server Il presence server ha lo scopo di portare le informazioni di presenza dalle presentity ai watcher. Aspetto importante nella realizzazione/configurazione del servizio di presenza è che si vuole garantire la possibilità di accesso al servizio di presenza in ambienti distribuiti nei qualle presentity e watcher afferiscano a server diversi. In aggiunta, ogni server deve avere un ruolo attivo nel bilanciare il carico degli utenti utilizzando le informazioni che è in grado di raccogliere. In particolare, le varie istanze del sistema devono adattare il servizio in base alle abitudini degli utenti favorendo, ad esempio, gli utenti molto attivi o quelli che hanno un contratto particolare (si pensi alla possibilità di gestire livelli di qualità di servizio differenziati). Ogni server di presenza deve: all atto di una pubblicazione, salvare lo stato della presentity e notificare eventuali watcher;
CAPITOLO 1. PRESENTAZIONE 7 all atto di una sottoscrizione fornire lo stato più aggiornato relativo alla presentity sottoscritta; profilare i client, ossia raccogliere informazioni circa il numero dei watcher interessati allo stato del client, il numero dei contatti del client e la frequenza di pubblicazione delle informazioni; utilizzare le informazioni precedenti per minimizzare i messaggi di segnalazione attuando eventualmente politiche di migrazione. Per la realizzazione del presence service si considerino le specifiche SIP (Session Initiation Protocol) dei Presence Service. 1.3 Vincoli tecnologici Il progetto dovrà seguire i seguenti vincoli tecnologici: i client di presenza potranno essere sviluppati in C o in Java ma la parte di comunicazione dovrà utilizzare esclusivamente il protocollo SIP (Session Initiation Protocol). In particolare si chiede che i client supportino solo tre tipi di messaggio (SUBSCRIBE, PUBLISH e NOTIFY) nella loro versione più semplice; per i server è richiesto l uso di un server OpenSER (a scelta tra Open- SIPS o Kamailio), disponibile in versione OpenSource in linguaggio C. I server OpenSER già implementano tutta la parte di comunicazione con i client e la persistenza delle informazioni. Per i protocolli di comunicazione server-to-server non si impongono vincoli progettuali ma si raccomanda l utilizzo di semplici meccanismi come socket UDP (eventualmente multicast).
CAPITOLO 1. PRESENTAZIONE 8 Le tecnologie coinvolte sono: Presence Server: OpenSER, da poco suddiviso nei progetti OpenSIPS e Kamalio; JAIN SIP e JSR281 API (esistono alcune prime implementazioni come quella di Ericsson). 1.4 Panoramica su questa relazione Nel capitolo 2 verranno illustrate le caratteristiche principali del protocollo SIP. Nel capitolo 3 verranno illustrate le caratteristiche principali del servizio di presenza. Nel capitolo 4 verranno illustrate le tecnologie utilizzate durante la realizzazione di questo progetto. Nel capitolo 5 verrà illustrata la soluzione proposta per raggiungere gli obiettivi enunciati nel paragrafo 1.1.
Capitolo 2 Protocollo SIP SIP è un protocollo applicativo usato per instaurare, modificare e terminare sessioni multimediali in una rete basata su IP. Una sessione multimediale, consiste in uno scambio di flussi multimediali tra due o più interlocutori. Per permettere l inizio, la modifica, e il termine di tale scambio, è necessario che il mittente segnali al destinatario la volontà di instaurare una sessione con esso, ricorrendo all uso di un protocollo di segnalazione. SIP è standardizzato dall Internet Engineering Task Force (IETF) e le sue applicazioni includono voce, video, gaming, controllo di chiamata, servizio di presenza, ecc. SIP è un protocollo di segnalazione adottato, per la sua semplicità, come protocollo di segnalazione del Voice over IP (VoIP), e diventato poi standard nel 1999 e descritto nella [6]. Esso è stato ridisegnato più volte per aggiungere al suo interno nuove funzionalità, generando il nuovo standard definito in [9]. 9
CAPITOLO 2. PROTOCOLLO SIP 10 2.1 Architettura SIP SIP è basato sul Hypertext Transfer Protocol (HTTP) e sul Simple Mail Transfer Protocol (SMTP) ed è stato creato per raggiungere i seguenti obiettivi: indipendenza dal protocollo di trasporto SIP può utilizzare sia il protocollo TCP che UDP; instradamento in base alla richiesta un messaggio SIP può essere instradato direttamente verso il destinatario, o instradato da un proxy intermedio; separazione tra informazioni di segnalazione e contenuti multimediali; estensibilità; utilizzabile in mobilità. L architettura SIP prevede degli User Agents (UAs) e degli intermediari (servers). Lo UA è il terminale della comunicazione, come ad esempio un telefono cellulare, e si divide in: User Agent Client (UAC) il mittente della richiesta; User Agent Server (UAS) il destinatario della richiesta, colui che la accetta, rifiuta o ridirige ed invia le risposte. Gli intermediari, sono entità logiche attraverso le quali passa la richiesta per raggiungere il destinatario. Gli intermediari si dividono in: Proxy Server o SIP Server riceve ed inoltra la richiesta SIP; può modificare alcune parti del messaggio senza interferire con lo stato della richiesta o del dialogo tra i due interlocutori;
CAPITOLO 2. PROTOCOLLO SIP 11 Redirect Server ha il compito di sostituire l indirizzo destinatario della richiesta, con un nuovo indirizzo; non partecipa alla transazione; Location Server tiene traccia della posizione degli utenti; utile soprattutto se gli utenti sono in mobilità; Registrar Server accetta le richieste di tipo REGISTER; viene utilizzato per memorizzare l associazione tra indirizzo dell utente e indirizzo del terminale da cui esso effettua la richiesta o su cui vuole ricevere nuove richieste; Application Server è un entità di rete che fornisce servizi agli utenti; un tipico esempio è il Presence Server, che offre il servizio di presenza. Back-to-back-user-agent (B2BUA) agisce come un User Agent a entrambe le estremità di una sessione o chiamata SIP. Il B2BUA è responsabile per la gestione della segnalazione della chiamata (instaurazione, mantenimento, chiusura) sia sul chiamante che sul chiamato. Ogni chiamata è monitorata dall inizio alla fine, permettendo agli operatori di offrire attraverso il B2BUA una funzionalità aggiuntiva per la chiamata. Per i client SIP, il B2BUA agisce come un UAS su un lato e come un UAC sugli altri lati. 2.2 Struttura SIP SIP, è un protocollo strutturato a livelli, i quali consentono di ottenere indipendenza tra le funzionalità da esso offerte. La struttura a livelli è rappresentata in figura 2.1.
CAPITOLO 2. PROTOCOLLO SIP 12 Figura 2.1: Struttura SIP a livelli 2.2.1 Syntax and Encoding layer Il livello più basso della struttura, è denominato Syntax and Encoding, e ha il compito di definire la sintassi e la codifica di un messaggio SIP. La codifica, è specificata con una grammatica di tipo augmented Backus-Naur Form (BNF), definita in [9]. La grammatica BNF, definisce in che modo devono essere codificate le informazioni, ad esempio con la sintassi name: value 2.2.2 Transport layer Il livello di trasporto, o Transport layer, specifica come i clients devono inviare richieste e ricevere risposte, e come i servers devono ricevere richieste ed inviare risposte. Basandosi sulla sintassi e sulla codifica di un messaggio SIP definiti al livello sottostante, il livello di trasporto introduce gli headers SIP necessari all instradamento di richieste e risposte da parte degli interlocutori. Un esempio tipico, è l introduzione degli headers Via.
CAPITOLO 2. PROTOCOLLO SIP 13 2.2.3 Transaction layer Il terzo livello, prende il nome di Transaction layer. Una transazione SIP (SIP transaction), è costituita da una richiesta e dall insieme delle risposte ad essa associate. Il Transaction layer ha il compito di mantenere le associazioni tra richieste e risposte. Le transazioni SIP si dividono in: transazioni client instaurate dal client che vuole inviare una richiesta e ricevere delle risposte; transazioni server instaurate dal server che riceve una richiesta ed invia le risposte. Questo livello, utilizza il Transport layer per inviare e ricevere richieste e risposte. 2.2.4 Transaction User layer Il livello più alto della struttura SIP, prende il nome di Transaction User layer. Questo livello, ha il compito di instaurare transazioni client e server. Quando un client vuole inviare una richiesta SIP, crea un istanza di una transazione client, ed invia la richiesta insieme all indirizzo IP del destinatario, alla porta, e al nome del protocollo di trasporto da utilizzare. I Transaction User, sono definiti per essere UAC e UAS. Gli UAC creano ed inviano richieste, e ricevono risposte, mentre gli UAS ricevono richieste, e creano ed inviano risposte, utilizzando il Transaction layer. 2.3 Messaggio SIP Un messaggio SIP, è composto da tre parti:
CAPITOLO 2. PROTOCOLLO SIP 14 request line (per le richieste) o status line (per le risposte) contengono le informazioni relative al tipo di richiesta o risposta; headers aggiungono informazioni al messaggio; corpo del messaggio contiene informazioni di interesse per il destinatario. Un esempio di richiesta SIP è il seguente: INVITE sip:bob.smith@open-ims.test SIP/2.0 Via: SIP/2.0/UDP cscf1.open-ims.test:5060;branch=z9hg4bk8542.1 Via: SIP/2.0/UDP [5555::1:2:3:4]:5060;branch=z9hG4bK45a35h76 Max-Forwards: 69 From: Alice <sip:alice@open-ims.test>;tag=312345 To: Bob Smith <sip:bob.smith@open-ims.test> Call-ID: 105637921 CSeq: 1 INVITE Contact: sip:alice@[5555::1:2:3:4] Content-Type: application/sdp Content-Length: 159 [body] 2.3.1 Request-Line La request line è costituita da tre componenti: Method indica il tipo di richiesta; Request URI indirizzo SIP del destinatario della richiesta;
CAPITOLO 2. PROTOCOLLO SIP 15 Protocol version versione del protocollo SIP utilizzato; la versione specificata in [9] è la 2.0. Il Method, può assumere i seguenti valori: REGISTER usato da un UAC per notificare il suo indirizzo IP e l URL per il quale vuole ricevere chiamate; INVITE usato per instaurare una sessione multimediale; ACK usato per confermare l avvenuto scambio di messaggi; CANCEL usato per cancellare una richiesta pendente, ovvero non ancora accettata; BYE usato per terminare una sessione multimediale; OPTION usato per richiedere informazioni relative alle capacità del terminale dell utente chiamato, senza instaurare una sessione. Un esempio di request line è il seguente: INVITE sip:bob@reteb.com SIP/2.0 Questo esempio, si riferisce ad un messaggio di tipo INVITE (definito nel Method), cioè destinato ad instaurare una comunicazione con il destinatario (definito nella Request URI). 2.3.2 Response-Line La response line è costituita da tre componenti: Protocol version identica alla request line; Status code codice di tre cifre che identifica il tipo di risposta;
CAPITOLO 2. PROTOCOLLO SIP 16 Reason phrase testo libero per una descrizione più precisa dello status code. Lo status code è classificato in sei categorie: 1XX indica che la richiesta è stata ricevuta ed in fase di elaborazione; 2XX indica che la richiesta è stata ricevuta, processata e accettata; 3XX indica una redirezione della richiesta per ulteriori elaborazioni; 4XX indica un errore di sintassi nella richiesta; 5XX indica un errore da parte del server; 6XX indica un errore globale; la richiesta non può essere servita da nessun server. Un esempio di Response line, è il seguente: SIP/2.0 480 Temporarily Unavailable riferito ad una risposta di errore di tipo 480 (Status code) descritta dalla Reason phrase Temporarily Unavailable. 2.3.3 Headers Gli headers, contribuiscono ad aggiungere informazioni alla richiesta, come ad esempio, il mittente, il destinatario e gli identificatori degli utenti. Il formato di un header è il seguente: Header-name: header-value Alcuni headers sono obbligatori sia nelle richieste che nelle risposte:
CAPITOLO 2. PROTOCOLLO SIP 17 To header - To: SIP-URI(;parametri) indica il nome del destinatario del messaggio; From header - From: SIP-URI(;parametri) indica il nome del mittente del destinatario; Call-ID header - Call-ID: unique-id identifica un messaggio all interno di una sessione; CSeq header - CSeq: digit method identifica una risposta ad una precisa richiesta; Via header - Via:SIP/2.0/[transport-protocol] sent-by(;parametri) consente di instradare le risposte attraverso lo stesso percorso seguito dalla richiesta; Max-Forwards header - Max-Forwards: digit indica il numero massimo di nodi che il messaggio può attraversare prima di raggiungere la destinazione; Contact header - Contact: SIP-URI(;parameters) indica l indirizzo (generalmente SIP), del mittente del messaggio. Dove appare (;parametri), significa che è possibile aggiungere alcuni parametri separati da punto e virgola. Un esempio di header SIP è il seguente: Via: SIP/2.0/UDP 192.168.0.101:5062 Questo header indica che il messaggio in cui è contenuto deve passare per il nodo 192.168.0.101 sulla porta 5062 utilizzando il protocollo UDP.
CAPITOLO 2. PROTOCOLLO SIP 18 2.3.4 Corpo del messaggio Il corpo del messaggio può contenere qualsiasi tipo di informazione dipendentemente dal tipo di richiesta o risposta per cui il messaggio è stato generato. Nel nostro progetto, viene spesso inserito un documento XML contenente le informazioni di presenza. 2.3.5 SIP URI Il SIP URI, rappresenta l indirizzo SIP con il quale è possibile raggiungere un terminale dell utente. Esso ha la forma di un indirizzo e-mail: sip:bob.smith@realm.com Il SIP URI può essere di due tipi: Address Of Record (AOR) è un indirizzo SIP che identifica un utente; è più facile da memorizzare, ed è quindi utilizzato principalmente dagli utenti umani e gestito in modo simile ad un numero telefonico; un esempio è sip:bob.smith@realm.com in questa forma, l indirizzamento del messaggio necessita di interrogazioni al server DNS per individuare l indirizzo IP del dominio realm.com; Fully Qualified Domain Name (FQDN) o indirizzo IP identifica un dispositivo dell utente; un esempio è sip:bob.smith@127.233.4.12 in questa forma, l indirizzamento del messaggio non necessita di interrogazioni al server DNS, in quanto l indirizzo IP del dominio è specificato esplicitamente dopo il simbolo @.
Capitolo 3 Presence Service 3.1 Introduzione Il concetto di presenza (Presence) ha potenziato i servizi di messaggistica istantanea, oggi diffusissimi in tutto il mondo per la loro capacità di far comunicare persone collocate geograficamente molto lontane tra loro. Il concetto di presenza può essere visto come la capacità di un utente di percepire lo stato di altri, così come gli altri percepiscono quello dell utente stesso. In altre parole un utente viene rappresentato da una insieme di informazioni che definiscono il suo stato, e quello dei dispositivi di comunicazione cui ha accesso. Tale stato contiene quindi informazioni come la locazione geografica dell utente, il contesto in cui si trova (posizione fissa, in movimento, all aperto, in ufficio, ecc.), le capacità comunicative dei terminali in suo possesso (se supportano sessioni voce, video, sms, di messaggistica istantanea, ecc.), il metodo di contatto preferito (via telefono cellulare, fax, computer dell ufficio, ecc.), i servizi che l utente è disposto ad utilizzare (servizi voce, video, di messaggistica istantanea, ecc.), le attività che sta svolgendo in un certo momento (riunione, guida, pranzo, ecc.), ed altre. Come definito in [10], in 19
CAPITOLO 3. PRESENCE SERVICE 20 definitiva, il servizio di presenza esprime la possibilità e la volontà dell utente di comunicare attraverso un insieme di dispositivi. Il servizio di presenza, poggia sul modello publish/subscribe. Il modello publish/subscribe, è un paradigma di interazione che vede coinvolte due entità: produttori (publisher) e consumatori (subscriber, o sottoscrittori). Consente ai sottoscrittori di esprimere i propri interessi verso un certo tipo di evento o un pattern di eventi, con lo scopo di essere successivamente notificati con eventi compatibili con gli interessi espressi. In altre parole, i produttori pubblicano informazioni su un canale di eventi e i sottoscrittori si sottoscrivono al canale per ricevere informazioni di loro interesse (figura 3.1). Figura 3.1: Modello Publish/Subscribe Il modello base del sistema per l interazione publish/subscribe si basa su un servizio di notifica di eventi (event notification service, o più semplicemente event service), il quale memorizza e gestisce le sottoscrizioni e consegna gli eventi. L event service funge da mediatore tra i publisher, che svolgono la funzione di produttori di eventi, e i subscriber, che svolgono la funzione di consumatori di eventi. I subscriber registrano i propri interes-
CAPITOLO 3. PRESENCE SERVICE 21 si verso un certo tipo di evento attraverso la funzione subscribe() dell event service, senza essere a conoscenza dell effettiva sorgente dell evento. Seguendo questo modello, il servizio di presenza, consente ad un utente di far sapere, a chiunque voglia, come e quando essere contattato semplicemente pubblicando il proprio stato, che viene poi ricevuto dagli altri utenti. Alice può, ad esempio, pubblicare un messaggio che specifica su quali dispositivi può essere contattata in quel momento (telefono cellulare, computer dell ufficio, ecc.); Bob, che vuole contattare Alice, riceve le sue informazioni di presenza, e valuta in che modo contattarla (se Alice è disponibile). Il concetto di presenza si concretizza quindi in un profilo dinamico dell utente visibile ad altri, e in grado di rappresentare sé stesso, condividere informazioni e controllare servizi. Il servizio di presenza può essere utilizzato da chiunque, sia esso un informatico, un impiegato, un cuoco, un anziano o un bambino. Si presta a diverse applicazioni, e non solo al servizio di messaggistica istantanea per cui è stato originariamente pensato, ma anche, ad esempio, ai servizi che offrono la possibilità di videogiocare in rete, o ai servizi che consentono di incrementare l efficienza sul lavoro. Il servizio di presenza rappresenta inoltre un business non sottovalutabile per i fornitori di servizi, che possono contare quindi su un importantissima funzionalità aggiuntiva per rendere le loro offerte più complete e accattivanti. I fornitori di servizi possono, infatti, contare su un supporto base di molti servizi. Pensiamo, ad esempio, al servizio di messaggistica istantanea: un utente deve sapere se può avviare una sessione di messaggistica istantanea con un altro utente, e quindi deve essere a conoscenza dello stato di presenza relativo al servizio di instant messaging. Disporre del servizio di presenza rappresenta perciò, per il fornitore, la base per poter offrire un servizio di messaggistica istantanea. Pensando poi
CAPITOLO 3. PRESENCE SERVICE 22 a nuovi servizi, possiamo immaginare l implementazione di un meccanismo di segnalazione di emergenze: un utente in difficoltà, premendo un semplice tasto sul telefono cellulare, è in grado, senza parlare, di informare i soccorsi fornendo le sue coordinate geografiche. Anche per un servizio di questo tipo, la base implementativa sta nel servizio di presenza, che è in grado di ricevere le coordinate geografiche dell utente e notificarle ai soccorsi. Risulta chiaro che questi servizi aggiuntivi che poggiano sul servizio di presenza possono avvantaggiare un fornitore sugli altri, oltre ad incrementare il traffico tariffabile all interno della rete. Il nostro progetto si concentra proprio sul servizio di presenza per aggiungervi QoS. Come descritto in [5] esistono due tipi di utilizzatori non esclusivi (cioè un utilizzatore può essere di entrambi i tipi): presentity: chi fornisce le proprie informazioni di presenza per essere memorizzate e distribuite; watcher: chi richiede e riceve le informazioni di presenza riguardanti altri utenti e servizi. Le informazioni di presenza possono essere costruite direttamente dal presentity o prelevate da dispositivi esterni come PC, cellulari, sensori, antenne GPS, ecc. (figura 3.2). Di questo si parlerà nel paragrafo 3.2.
CAPITOLO 3. PRESENCE SERVICE 23 Figura 3.2: Relazione tra presentity e watcher La figura, mostra un possibile reperimento di informazioni di presenza da antenne e sensori. Notiamo che il modello segue il modello publish/subscribe sopra descritto. Le molte informazioni di presenza che un presentity può fornire, possono essere difficili da gestire per un watcher, in quanto errate, contraddittorie o ridondanti. Un utente umano è in grado di risolvere questi problemi analizzando le informazioni ricevute, ma un utente costituito da un applicazione software può scontrarsi con molte difficoltà. Questi problemi saranno trattati nel paragrafo 3.4. Il protocollo utilizzato dal servizio di presenza è il SIMPLE (Session initiation protocol for Instant Messaging and Presence Leveraging Extensions), standard gestito dalla IETF. Il formato generale delle informazioni di presenza è descritto in [10] ed è rappresentato da un documento XML diviso in tuple, ognuna delle quali contiene informazioni riguardanti l utente umano, i servizi utilizzati per comunicare e i dispositivi di cui l utente è in possesso. Tutto questo sarà trattato nel paragrafo 3.3.
CAPITOLO 3. PRESENCE SERVICE 24 3.2 Sorgenti delle informazioni di presenza Come descritto in [12], le informazioni di presenza possono essere ricavate da sorgenti esterne. Possiamo classificare i dati di presenza nelle seguenti categorie: segnalati in tempo reale, sono forniti dal presentity in tempo reale, ma sono considerati poco attendibili col passare del tempo in quanto l utente potrebbe avere difficoltà ad aggiornare costantemente le informazioni; segnalati in modo pianificato, consistono nelle informazioni che vengono aggiornate automaticamente in base alla pianificazione dei propri impegni da parte dell utente utilizzando applicazioni come il calendario elettronico. L affidabilità di queste informazioni dipende dalla scrupolosità dell utente nell aggiornare i propri calendari e sorgenti simili; ricavati dall utilizzo di un dispositivo, sono dedotti dall impiego di dispositivi di comunicazione come l atto di inoltrare o ricevere una chiamata o dalla potenza del segnale di un cellulare. In questo caso la principale motivazione di errore può essere data dal fatto che l utilizzatore potrebbe non corrispondere alla persona della quale si vogliono pubblicare le informazioni; ricavati da sensori, sono estrapolati da sensori e consistono in informazioni come la posizione geografica, il tipo di ambiente (abitazione, automobile, ecc.), l attività dell utente, ecc. Esempi di sensori sono il GPS o segnalazioni Bluetooth che indicano il tipo di ambiente circostante. Il vantaggio dei sensori è che non fanno affidamento sull ag-
CAPITOLO 3. PRESENCE SERVICE 25 giornamento delle informazioni da parte dell utente, ma sono soggetti ad errori di misurazione. Ad esempio un sensore PIR (Passive InfraRed sensor), può rilevare la presenza di un soggetto in ufficio, ma non accertare se si tratta della persona interessata o dell addetto alle pulizie. Un sensore GPS non può rilevare se il cellulare è utilizzato dal suo proprietario o da qualcun altro; dedotti indirettamente da una sorgente di informazioni, ad esempio non interessa se l utente è in macchina (informazione ricavata da un sensore), ma il fatto che sta guidando (informazione dedotta). I dati, una volta acquisiti, vengono incapsulati nel corpo del messaggio di presenza (vedere paragrafo 3.3) ed inviati al Presence Server per la pubblicazione. 3.3 Standard per protocolli di presenza: SIM- PLE SIMPLE (Session initiation protocol for Instant Messaging and Presence Leveraging Extensions) è un protocollo standard basato su SIP e utilizzato per la messaggistica istantanea e per il servizio di presenza. SIMPLE estende il protocollo SIP per adattarlo alle esigenze del servizio di presenza. Sostanzialmente aggiunge una nuova tipologia di evento denominata presence. Il documento [7], individua due tipi di entità per il servizio di presenza: Presence Agent (PA), il quale è in grado di memorizzare le sottoscrizioni e generare le notifiche;
CAPITOLO 3. PRESENCE SERVICE 26 Presence User Agent (PUA), il quale manipola e pubblica le informazioni di presenza per un presentity. Il processo di pubblicazione, è consentito dall esistenza del metodo PUB- LISH, mentre per potersi registrare al servizio di presenza di un certo utente per poterne ricevere le notifiche, si ricorre al metodo SUBSCRIBE. Il corpo del messaggio NOTIFY, contiene, invece, le informazioni di presenza riguardanti il presentity che le vuole pubblicare. Grazie all esistenza del MIME (Multipurpose Internet Mail Extension), che offre la possibilità di inserire nel corpo del messaggio diversi tipi di dati, è possibile codificare le informazioni di presenza utilizzando il linguaggio XML (extensible Markup Language). All interno dell evento presence, esiste un sottoevento denominato winfo (watchers informations) che viene identificato come presence.winfo. Questo evento, consente, ad un presentity, di ricevere informazioni circa lo stato dei watchers a lui sottoscritti. In particolare, se un presentity si sottoscrive all evento presence.winfo, riceve le informazioni riguardanti lo stato dei watchers a lui sottoscritti e quelle riguardanti l evento che ha causato la modifica dello stato. Gli stati che un watcher può assumere nei confronti di un presentity non sono gli stessi che possono essere pubblicati da un generico presentity, ma sono differenti in quanto hanno lo scopo di descrivere l attività del watcher all interno del servizio di presenza. Un presentity, può decidere di limitare la consegna delle notifiche relative al proprio stato, soltanto a determinati watcher. Un presentity ha quindi la possibilità di creare delle regole (o policy) che hanno il compito di determinare chi può sottoscriversi al servizio di presenza del presentity stesso. Ad esempio, Alice può negare il recapito a Bob delle notifiche relative al proprio stato, ma consentirlo a John. Ogni watcher, assume quindi uno stato nei confronti di Alice. Tali
CAPITOLO 3. PRESENCE SERVICE 27 stati sono descritti in [8] e sono i seguenti: Init: nessuno stato del watcher disponibile. Init è uno stato transitorio, che viene assunto dal watcher nel momento della sottoscrizione al servizio di presenza del presentity, poi verrà assunto lo stato in funzione delle regole esistenti; Terminated: esiste una regola che vieta al watcher di sottoscriversi al servizio di presenza del presentity; Active: esiste una regola che consente al watcher di sottoscriversi al servizio di presenza del presentity e ricevere le notifiche di cambiamento del suo stato; Pending: non esiste nessuna regola definita per il watcher che resta, quindi, in attesa della creazione di una politica di accesso ad esso associata; Waiting: simile al Pending, ma indica che un utente ha cercato di sottoscriversi al servizio di presenza del presentity e che tale sottoscrizione è scaduta prima che venisse creata una regola. In ogni momento il server di presenza può decidere di chiudere una sottoscrizione in stato di Pending o Waiting per liberare le proprie risorse interne, quali memoria e CPU. Riprendendo l esempio precedente, Bob entra nello stato Terminated, mentre John nello stato Active. Il diagramma degli stati che un watcher può assumere, è riportato in figura 3.3.
CAPITOLO 3. PRESENCE SERVICE 28 Figura 3.3: Diagramma degli stati dei watcher La figura, mostra i motivi per cui un watcher può cambiare stato. Al momento della sottoscrizione, un watcher entra nello stato Init. Se esiste una regola (policy), il watcher assume lo stato da questa imposto, ovvero Active se esiste una regola che consente al watcher di essere notificato sullo stato del presentity, oppure Terminated se esiste una regola che nega il recapito delle notifiche a quel preciso watcher. Se non esiste nessuna policy, il watcher assume lo stato di Pending, e vi resta fino a che non viene creata una regola che accetta o scarta il watcher. Il watcher non può, però, restare nello stato di Waiting all infinito, quindi, se dopo un determinato periodo di tempo non è ancora stata creata nessuna regola, passa nello stato di Waiting, per poi passare nello stato di Terminated. Lo stato di Waiting, ha quindi lo scopo di avvertire che la sottoscrizione è scaduta prima che sia stata accettata o rifiutata esplicitamente dal presentity. Le sottoscrizioni, hanno un determinato periodo di validità, al termine del quale il watcher passa dallo stato Active, allo stato di Terminated.
CAPITOLO 3. PRESENCE SERVICE 29 3.3.1 Metodi PUBLISH, SUBSCRIBE e NOTIFY Come anticipato nel paragrafo precedente, per poter pubblicare il proprio stato è necessario ricorrere al metodo SIP PUBLISH definito all interno di SIMPLE. Il procedimento di pubblicazione prevede una singola richiesta di PUBLISH e una singola risposta che informa il mittente del successo o fallimento della procedura. L utente al quale si riferisce la pubblicazione è specificato nella Request URI, mentre le informazioni di presenza sono inserite nel corpo del messaggio SIP. Il metodo SUBSCRIBE consente ad un utente di sottoscriversi al servizio di presenza di un altro utente, in modo da poter ricevere le successive notifiche circa il suo cambiamento si stato. Anche la procedura di SUBSCRIBE prevede l invio di una richiesta e la ricezione di una risposta, con lo scopo di informare il mittente sull esito dell operazione. Il messaggio di risposta può essere positiva (la sottoscrizione è andata a buon fine) o negativo (la sottoscrizione è fallita). La sottoscrizione al servizio di presenza, ha una durata limitata e deve quindi essere rinnovata prima della sua scadenza. Per cancellare una sottoscrizione prima della sua scadenza, è necessario inviare un messaggio di SUBSCRIBE contenente l header Expires uguale a zero. Il metodo NOTIFY viene ricevuto dall utente che si è sottoscritto ad un servizio di presenza, e ha lo scopo di notificare il cambiamento di stato da parte dell utente osservato. Le informazioni di stato, sono contenuto all interno del corpo del messaggio in formato XML. Alla ricezione del messaggio NOTIFY, il client deve rispondere con un messaggio di conferma, per avvertire la sorgente (tipicamente un presence server) dell avvenuta ricezione.
CAPITOLO 3. PRESENCE SERVICE 30 3.3.2 Presence Information Data Format Le informazioni di presenza vengono codificate in linguaggio XML per essere facilmente trasmesse ed elaborate dai vari organi della rete. Il documento XML è strutturato in elementi definiti dal Presence Information Data Format (PIDF) [13] che è poi stato esteso dal Rich presence extensions to the Presence Information Data format (RPID) [11]. I principali elementi predefiniti sono: presence: è l elemento radice. Contiene un attributo entity il cui valore rappresenta l URI del presentity che pubblica il documento. Deve specificare il namespace di default urn:ietf:params:xml:ns:pidf ; tuple: rappresenta un servizio. Deve contenere un attributo id il cui valore differenzia un elemento tuple dagli altri all interno dello stesso presentity. Deve inoltre contenere l elemento status e può contenere gli elementi contact, note, timestamp ed altri elementi di estensione; status: può contenere un elemento basic e una serie di altri elementi di estensione. basic: può contenere la stringa open o closed per indicare se il contatto associato è raggiungibile o meno. contact: è opzionale e definisce un indirizzo al quale poter contattare il presentity; note: contiene una stringa qualsiasi che serve soltanto all utente umano; timestamp: contiene la data e l ora in cui l elemento padre è stato modificato;
CAPITOLO 3. PRESENCE SERVICE 31 person: descrive le caratteristiche di un utente umano. Deve contenere un attributo id che lo identifica dagli altri elementi person. Può contenere più elementi note e un elemento timestamp; device: descrive le caratteristiche di un terminale in possesso del presentity. Deve contenere un attributo id che lo identifica dagli altri elementi device all interno dello stesso presentity. Deve contenere un elemento deviceid. Può contenere una serie di elementi note, un elemento timestamp ed altri elementi di estensione; deviceid: contiene una stringa identificativa del dispositivo in questione (ad esempio il codice seriale). Un esempio di codifica XML delle informazioni di presenza è il seguente: <?xml version="1.0" encoding="utf-8"?> <presence xmlns="urn:ietf:params:xml:ns:pidf" entity="sip:bobo@open-ims.test"> <tuple id="sg89ae"> <status> <basic>open</basic> </status> <contact>tel:+39012345678</contact> </tuple> <tuple id="rt62yp"> <status> <basic>closed</basic> </status> <contact>tel:+39087654321</contact> </tuple>
CAPITOLO 3. PRESENCE SERVICE 32 <device id="pc147"> <user-input last-input="2009-09-08t13:20:00-05:00"> idle <\user-input> <deviceid>urn:device:0003ba4811e3<\deviceid> <note>pc<\note> </device> </presence> Notiamo che l elemento presence contiene l attributo che definisce il namespace del documento: xmlns="urn:ietf:params:xml:ns:pidf" inoltre è presente un altro attributo obbligatorio: entity="pres:someone@example.com" che definisce l entità cui appartengono le informazioni di presenza. Il valore di tale attributo è solitamente un Public User Identity dell utente. Gli elementi tuple contengono entrambi l attributo obbligatorio id che permette di identificarli e distinguerli l uno dall altro. L elemento tuple descrive lo stato di un servizio, quindi possiamo concludere che il servizio identificato dalla stringa sg89ae per l utente sip:bob@open-ims.test è disponibile (open), e raggiungibile componendo il numero di telefono +39012345678 (campo contact). Al contrario, il servizio identificato dalla stringa rt62yp, raggiungibile al numero telefonico +39087654321, non è al momento disponibile (closed). Proseguiamo analizzando la sezione device: l utente dispone di un dispositivo il cui id è rappresentato dalla stringa urn:device:0003ba4811e3
CAPITOLO 3. PRESENCE SERVICE 33 contenuta nell elemento deviceid. Notiamo che l elemento device è identificato dalla stringa pc147 per differenziarlo da eventuali altri elementi device inseribili nel documento XML. Dall elemento note, un utente umano può dedurre che il dispositivo in questione è un PC; l elemento note, come già detto, ha l unico scopo di aggiungere informazioni comprensibili soltanto da un utente umano. Il PC non è attualmente utilizzato, come si può dedurre dal contenuto dell elemento user-input, che indica lo stato di utilizzo del dispositivo a cui è associato. L ultima volta che il PC è stato utilizzato è in data 2009-09-08 alle ore 13:20:00. 3.4 Gestione dei conflitti delle informazioni Come già accennato, un presentity può pubblicare le proprie informazioni di presenza in diversi modi e attraverso dispositivi differenti, generando così possibili conflitti di informazioni. Ad esempio, l auto di Alice dispone di un sensore che, quando rileva la presenza di una persona alla guida, pubblica automaticamente lo stato di non disponibilità di Alice a ricevere telefonate. Supponiamo che Bob, marito di Alice, prenda in prestito l auto della moglie e, contemporaneamente, Alice pubblichi la sua disponibilità a ricevere telefonate: a questo punto Alice è rintracciabile o no? Generalmente i conflitti di informazioni possono essere di varia natura, e il primo passo da eseguire per rimuovere le informazioni inaccurate consiste nell individuare tali conflitti. Come visto nel paragrafo precedente, lo stato di un utente può essere rappresentato da numerosi elementi, alcuni dei quali possono contraddirsi a vicenda. Ad esempio, una persona non può essere in due luoghi differenti nello stesso momento, quindi, se due elementi place-is hanno valori diversi, significa che uno dei due è errato. Per altri tipi di infor-
CAPITOLO 3. PRESENCE SERVICE 34 mazione che vengono prelevati automaticamente da sorgenti esterne, i valori che possono assumere potrebbero, in certi casi, essere esclusivi. Ad esempio, l elemento place-type non può assumere contemporaneamente i valori office e outdoors, ma potrebbe assumere i valori outdoors e stadium. La difficoltà sta quindi nel capire quando un elemento assume valori contraddittori o soltanto differenti nella loro specificità. Quando viene rilevato un conflitto bisogna prendere una decisione per gestirlo in modo adeguato. In alcuni casi non deve essere effettuata nessuna azione, ad esempio non è dato sapere quali valori sono in conflitto per gli elementi activities o mood, a causa dei molteplici valori che possono assumere. Un approccio conservativo per gestire alcuni conflitti, potrebbe essere semplicemente listare tutti i valori. In questi casi, vengono presentati al watcher versioni multiple dello stesso elemento e starà quindi a lui il compito di determinare quello corretto. Per limitare il numero di informazioni recapitate al watcher si può scegliere un solo valore escludendo tutti gli altri. Per prendere questa decisione, si può procedere in modi differenti: scegliere il valore dell elemento più recente: si tratta di optare per il valore pubblicato più di recente. In questo caso, si rischia di scartare un valore corretto e mantenere quello errato; scegliere l elemento più affidabile: l affidabilità può essere basata sull identità della sorgente, come ad esempio il cellulare dell utente. In alternativa si può dare un ordine di fiducia ai tipi di sorgente delle informazioni, ad esempio, segnalati in tempo reale, ricavati dall utilizzo di un dispositivo, ricavati da sensori, segnalati in modo pianificato ; scegliere in base al valore di un altro elemento: gli altri elementi potreb-
CAPITOLO 3. PRESENCE SERVICE 35 bero indicare un valore che potrebbe essere più affidabile. Ad esempio, l elemento user-input, potrebbe indicare che un dispositivo che fornisce indicazioni di presenza è attualmente in uso e un altro no. I valori che non vengono scelti, vengono definitivamente scartati. [12] Il meccanismo per risolvere i conflitti di informazione viene implementato all interno del Presence Server. Nel nostro progetto viene utilizzato il Presence Server Kamailio, il quale risolve i conflitti scegliendo, per ogni elemento, il valore pubblicato più recentemente. 3.5 Metodi per l utilizzo del servizio di presenza In questo paragrafo viene illustrato il contenuto dei metodi utilizzati per sfruttare il servizio di presenza. Sono illustrati i metodi PUBLISH, SUB- SCRIBE e NOTIFY. SUBSCRIBE e NOTIFY In figura 3.4 è raffigurato il processo di sottoscrizione da parte di un watcher (Bob) al servizio di presenza relativo ad un presentity (Alice). Bob si sottoscrive al servizio di presenza relativo ad Alice inviando un messaggio di tipo SUBSCRIBE al Presence Server (PS). Quest ultimo accetta la sottoscrizione rispondendo con un messaggio di tipo 200 OK per indicare a Bob che la richiesta è stata ricevuta e processata con successo. Il Presence Server provvede ad inviare subito a Bob un messaggio di tipo NOTIFY contenente le informazioni di presenza di Alice in suo possesso.
CAPITOLO 3. PRESENCE SERVICE 36 Figura 3.4: Processo di SUBSCRIBE Bob risponde con un messaggio di tipo 200 OK per confermare la ricezione del messaggio NOTIFY. Il messaggio di SUBSCRIBE è così formato: SUBSCRIBE sip:alice@example.com SIP/2.0 Via: SIP/2.0/UDP host.example.com;branch=z9hg4bknashds7 To: <sip:alice@example.com> From: <sip:bob@example.com>;tag=12341234 Call-ID: 12345678@host.example.com CSeq: 1 SUBSCRIBE Max-Forwards: 70 Expires: 3600 Event: presence Content-Length: 0
CAPITOLO 3. PRESENCE SERVICE 37 Descriviamo brevemente il contenuto del messaggio. Nella prima riga (Request-Line) compaiono il metodo (SUBSCRIBE), la Request URI (sip:alice@example.com) e la versione del protocollo (SIP/2.0). I successivi campi del messaggio sono gli headers, necessari per aggiungere informazioni di servizio al messaggio. L header To contiene l URI del presentity a cui il watcher vuole sottoscriversi, mentre l header From contiene l URI del mittente (watcher nel caso di messaggi SUBSCRIBE). Altro header importante è Event, il quale contiene l indicazione del tipo di servizio al quale Bob vuole sottoscriversi. Gli header Via (possono essercene anche molti) tengono traccia del percorso che il messaggio effettua per arrivare a destinazione e che dovrà essere seguito (a ritroso) dai futuri messaggi di risposta. Infine descriviamo l header Expires, che informa circa il periodo di validità della sottoscrizione: il valore 3600 indica che per i prossimi 3600 seondi Bob riceverà notifiche riguardanti i cambiamenti di stato di Alice, dopodiché la sottoscrizione scadrà e Bob dovrà rinnovarla. Questo header, se settato a 0, indica al Presence Server che il mittente non vuole più ricevere notifiche riguardanti il servizio di presenza circa il presentity specificato nella Request-Line. PUBLISH In figura 3.5 è raffigurato il processo di sottoscrizione da parte di un watcher (Bob) al servizio di presenza relativo ad un presentity (Alice). Alice pubblica le proprie informazioni di presenza inviando un messaggio di tipo PUBLISH al Presence Server (PS), il quale conferma la ricezione della richiesta rispondendo con un messaggio di tipo 200 OK.
CAPITOLO 3. PRESENCE SERVICE 38 Figura 3.5: Processo di PUBLISH Il messaggio di PUBLISH è così formato: PUBLISH sip:alice@example.com SIP/2.0 Via: SIP/2.0/UDP pua.example.com;branch=z9hg4bk652hsge To: <sip:alice@example.com> From: <sip:alice@example.com>;tag=1234wxyz Call-ID: 81818181@pua.example.com CSeq: 1 PUBLISH Max-Forwards: 70 Expires: 3600 Event: presence Content-Type: application/pidf+xml Content-Length:... [Published PIDF document] Notiamo che gli headers To e From contengono entrambi l URI di Alice, ovvero del presentity che pubblica il messaggio. Gli header Event e Expires e Via hanno significati analoghi a quelli degli stessi header contenuti nel messaggio di SUBSCRIBE.
CAPITOLO 3. PRESENCE SERVICE 39 L Header Content-Type indica il tipo di contenuto del corpo del messaggio; essendovi contenuto un testo XML con struttura adeguata al servizio di presenza, il valore di tale header è application/pidf+xml. L header Content-Lenght specifica la lunghezza in byte del corpo del messaggio.
Capitolo 4 Tecnologie utilizzate Di seguito vengono introdotte le principali tecnologie utilizzate all interno del progetto. 4.1 Presence Server Kamailio Questo progetto ha lo scopo di estendere il servizio di presenza offerto da un Presence Server introducendo Load Balancing. Come Presence Server è stato scelto Kamailio (OpenSER) [3] per la sua completezza e solidità. In realtà, OpenSER è un progetto che si pone l obiettivo di realizzare un software completo per l implementazione di un sistema basato su protocollo SIP, ovvero un SIP server. Esso è scritto in linguaggio C, ed è estensibile per consentire l aggiunta di moduli atti ad implementare nuovi servizi. OpenSER ha cambiato nome nel 2008 a causa di alcuni conflitti di interesse, diventando Kamailio. Alcune funzionalità di Kamailio sono: SIP registrar server SIP Location server 40
CAPITOLO 4. TECNOLOGIE UTILIZZATE 41 SIP Proxy server SIP Application server SIP Dispatcher server; SIMPLE Presence Server (rich presence) Presence User Agent supporto a XCAP Instant Messaging e molte altre. Come già anticipato, Kamailio è strutturato in moduli, ognuno dei quali implementa funzionalità specifiche ai fini di integrare più servizi in un unico server. Ogni modulo è indipendente dagli altri e sta a noi scegliere come configurare l istanza di Kamailio perchè carichi i moduli necessari ad offrire i servizi che vogliamo. I passi per configurare Kamailio sono riportati in appendice A. Per questo progetto ci siamo concentrati sul modulo di presenza, denominato appunto presence e scritto interamente in linguaggio C. 4.2 JAIN-SIP JAIN (Java in Advanced Intelligent Networks) è una comunità di aziende creata con lo scopo specifico di definire delle API [1] per raggiungere la portabilità dei servizi, convergenza e accessi sicuri verso reti telefoniche e dati (Internet). Si basa esclusivamente sulla tecnologia Java, ed anche il suo
CAPITOLO 4. TECNOLOGIE UTILIZZATE 42 sviluppo segue le specifiche di sviluppo e licenza SUN (JSPA Java Specification Participation Agreement, JCP Java Community Process, SCSL Sun Community Source Code Licensing). JAIN si occupa di definire due diverse serie di API riguardo le NGN: API verso i protocolli e API verso le applicazioni. Le prime specificano le interfaccie verso i protocolli di reti IP, wireless e telefoniche; le seconde vengono utilizzate per la creazione di servizi fornendo un framework java per l utilizzo dei protocolli che sono gestiti dal primo gruppi di API. L API JAIN SIP [2] fornisce un interfaccia Java standard e portabile per condividere informazioni tra client SIP e server SIP, mettendo a disposizione funzionalità per il controllo delle chiamate e quindi fornendo un infrastruttura per lo sviluppo di applicazioni su reti convergenti. Questa API permette la creazione rapida e l attivazione di servizi dinamici di telefonia all interno di piattaforme Java. Le applicazioni di telefonia hanno bisogno di risorse costose per il loro sviluppo, le prove a la messa in funzione. Un componente JAIN SIP può essere creato rapidamente, provato e integrato in una gran varietà di piattaforme avendo a già disposizione un buon numero di strumenti e utility. Una soluzione inter piattaforma basata su JAIN offre ai gestori telefonici, ai fornitori di servizi e di componenti di rete, un ambiente di sviluppo aperto e consistente dove sviluppare e integrare servizi di telefonia altamente riutilizzabili. Un applicazione JAIN SIP può essere scritta come programma, applet, servlet o bean. Le API mettono a disposizione le potenzialità presenti nelle diverse versioni di SIP in un interfaccia Java comune. JAIN SIP non fornisce l implementazione dello stack SIP, ma si occupa soltanto di fornire un interfaccia standard. Nella figura 4.1 è visibile la struttura di una generica applicazione che si
CAPITOLO 4. TECNOLOGIE UTILIZZATE 43 basa su questa API, in particolare vengono gestiti tutti gli aspetti relativi alla comunicazione attraverso SIP, come ad esempio la risposta alle richieste che arrivano al programma, attraverso opportune interfacce che gestiscono gli eventi relativi ai vari eventi SIP (come l arrivo di richieste o di risposte, o la scadenza di timeout), o la creazione e gestione degli indirizzi, messaggi ed elementi del pacchetto SIP. Figura 4.1: Schema di un applicazione JAIN-SIP
Capitolo 5 Soluzione del progetto 5.1 Introduzione La soluzione proposta per raggiungere gli obiettivi specificati nel paragrafo 1.1, consiste nella realizzazione di un client sviluppato in linguaggio Java utilizzando le API JAIN SIP [2], e nella modifica di alcune parti del modulo di presenza presence integrato in Kamailio. Topologia della rete di riferimento Per lo sviluppo di questo progetto, facciamo riferimento ad una ben definita rete di nodi sui quali girano diverse istanze del presence server Kamailio opportunamente configurate. I vari nodi della rete dovranno comunicare tra loro per sincronizzarsi, garantendo così la possibilità di accesso al servizio di presenza in ambienti distribuiti nei quali presentity e watcher afferiscano a server diversi. Altro scopo della sincronizzazione, è quello di bilanciare il carico degli utenti utilizzando le informazioni che ogni nodo è in grado di raccogliere. (figura 5.1). 44
CAPITOLO 5. SOLUZIONE DEL PROGETTO 45 Figura 5.1: Sistema Client SIP Il client SIP è stato sviluppato in linguaggio Java utilizzando la tecnologia JAIN SIP già citata nel paragrafo 4.2. Tale client implementa le funzionalità di base per l utilizzo del servizio di presenza, il quale è offerto da una rete di presence server Kamailio. Modifiche al modulo di presenza presence Il modulo di presenza presence integrato in Kamailio realizza le funzionalità necessarie per offrire il servizio di presenza, ed è il cuore del nostro progetto. Modificando tale modulo, è possibile sviluppare un meccanismo di bilanciamento del carico di lavoro in modo che le varie richieste entranti vengano smistate su più nodi della rete dediti a fornire il servizio di presenza. Il primo passo da affrontare per realizzare una soluzione funzionante che soddisfi gli obiettivi preposti, consiste nello studio del funzionamento
CAPITOLO 5. SOLUZIONE DEL PROGETTO 46 del modulo di presenza integrato in Kamailio. Tale modulo è suddiviso in sottomoduli, ognuno dei quali implementa un sottoinsieme ben preciso di funzionalità. Le nostre modifiche coinvolgono il processo di gestione delle richieste di pubblicazione e quello di gestione delle richieste di sottoscrizione. In particolare è necessario introdurre un controllo della frequenza di arrivo delle richieste e del numero di watcher presenti sul presene server. Nel caso in cui la frequenza di arrivo delle richieste di pubblicazine sia troppo elavata, il presence server rifiuta la pubblicazione comunicandolo al client che potrà gestire l errore a suo piacimento, ad esempio inoltrando la richiesta ad un altro presence server. Come già illustrato, all arrivo di un messaggio di PUBLISH da parte di un presentity, il presence server inoltra un messaggio di tipo NOTIFY a tutti i watcher sottoscritti al servizio di presenza di quel presentity. Questo meccanismo può congestionare il server nel caso in cui un presentity abbia un gran numero di sottoscritti o nel caso in cui pubblichi informazioni troppo frequentemente; si rivela quindi necessario gestire questi due casi. La soluzione proposta prevede un controllo sulla frequenza di pubblicazione del presentity ed il numero di watcher che vogliono sottoscriversi al servizio di presenza di un certo utente. Nel caso in cui un presentity pubblichi informazioni molto frequentemente, il presence server evita di attuare il processo di notifica a tutti i sottoscrittori per ogni pubblicazione ricevuta, ma lo attua soltanto ad intervalli prestabiliti, riducendo così il numero di notifiche generate. Qualora un utente voglia sottoscriversi al servizio di presenza relativo ad un presentity che conta già molti sottoscritti, la richiesta viene rifiutata dal server, il quale provvede a rispondere al client richiedente con un messaggio che
CAPITOLO 5. SOLUZIONE DEL PROGETTO 47 gli indica uno stato di temporanea indisponibilità del servizio presso il server stesso. Questo ha lo scopo di evitare che, all arrivo di un aggiornamento di stato da parte di un presentity, il server debba notificare una quantità di watcher molto elevata, cosa che potrebbe portare ad uno stato di congestione del server stesso e del canale di comunicazione. Il nostro sistema dispone di più nodi interconnessi tra loro, che offrono un servizio di presenza a tutti i client. Da questo, nasce il problema della decentralizzazione delle informazioni pubblicate su nodi differenti. Per ovviare a questo inconveniente, la nostra soluzione prevede la configurazione delle istanze di Kamailio in esecuzione, in modo che tutte si interfaccino ad un database centralizzato che contiene le varie informazioni utili ad attuare il servizio da offrire. In questo modo tutti i presence server sono a conoscenza delle ultime informazioni pubblicate da ciascun presentity, e ognuno può attuare il processo di notifica a tutti i watcher sottoscritti a quel presentity presso il server stesso. Ogni server, all arrivo di una pubblicazione da parte di un presentity, deve, inoltre, avvisare tutti gli altri server del sistema sull avvenuta pubblicazione di nuove informazioni da parte di quel preciso presentity, in modo che ognuno possa notificare l evento a tutti i propri sottoscrittori. Abbiamo, quindi, una centralizzazione delle informazioni di presenza per ogni presentity, ed una distribuzione dei sottoscrittori sui vari nodi del sistema. La soluzione prevede, inoltre, la distribuzione, sui vari nodi, del carico di lavoro portato dalla gestione di una pubblicazione di informazioni (figura 5.2).
CAPITOLO 5. SOLUZIONE DEL PROGETTO 48 Figura 5.2: Sistema con database centralizzato Per l installazione e la configurazione del modulo di presenza modificato, si rimanda all appendice B 5.2 Client SIP Il client SIP è stato sviluppato in linguaggio Java utilizzando la tecnologia JAIN SIP. Il client deve:
CAPITOLO 5. SOLUZIONE DEL PROGETTO 49 sottoscriversi al servizio di presenza presso un presence server; pubblicare informazioni di presenza presso un presence server; ricevere notifiche da uno o più presence server; eventualmente, ridirezionare le sue richieste di sottoscrizione e pubblicazione su presence server differenti in caso di indisponibilità di quello scelto. In figura 5.3 è riportata una schermata del client. Figura 5.3: Sistema Il client è munito di: una text area (Received Messages) nel quale vengono visualizzati tutti i messaggi ricevuti dai presence client; una text field (Set status) in cui settare il proprio stato;