Kamailio: una modi ca per Load Balancing e QoS · 2010-09-22 · CAPITOLO 1. PRESENTAZIONE 5 1.2...

Universita degli studi di Bologna

Alma Mater Studiorum

Facolta di Ingegneria

Corso di Laurea in Ingegneria informatica

Progetto in

Reti di Calcolatori M

Kamailio:

una modifica perLoad Balancing e QoS

Docente Autore

Prof. Antonio Corradi 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 (pre-

sentity) e fruitori (watcher) dei dati di presenza, anche quando presentity

e watcher si trovano su server differenti. Oltre a cio, si vuole progettare

un’infrastruttura di supporto in grado di abilitare alta scalabilita di tutto il

sistema attraverso tecniche di bilanciamento del carico.

Infine, si vuole dare la possibilita 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 e composto da tre entita 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.


I watcher

I watcher, in modo duale rispetto presentity, rappresentano le entita interes-

sate 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 e che si vuole garantire la possibilita 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 e 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 possibilita di gestire

livelli di qualita di servizio differenziati).

Ogni server di presenza deve:

• all’atto di una pubblicazione, salvare lo stato della presentity e notifi-

care eventuali watcher;


• all’atto di una sottoscrizione fornire lo stato piu 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 seg-

nalazione 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 dovra seguire i seguenti vincoli tecnologici:

• i client di presenza potranno essere sviluppati in C o in Java ma la parte

di comunicazione dovra utilizzare esclusivamente il protocollo SIP (Ses-

sion Initiation Protocol). In particolare si chiede che i client supportino

solo tre tipi di messaggio (SUBSCRIBE, PUBLISH e NOTIFY) nella

loro versione piu semplice;

• per i server e richiesto l’uso di un server OpenSER (a scelta tra Open-

SIPS o Kamailio), disponibile in versione OpenSource in linguaggio C.

I server OpenSER gia 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).


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 realiz-

zazione di questo progetto.

Nel capitolo 5 verra illustrata la soluzione proposta per raggiungere gli obi-

ettivi enunciati nel paragrafo 1.1.

Capitolo 2

Protocollo SIP

SIP e 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 piu interlocutori. Per

permettere l’inizio, la modifica, e il termine di tale scambio, e necessario che

il mittente segnali al destinatario la volonta di instaurare una sessione con

esso, ricorrendo all’uso di un protocollo di segnalazione.

SIP e standardizzato dall’Internet Engineering Task Force (IETF) e le sue

applicazioni includono voce, video, gaming, controllo di chiamata, servizio di

presenza, ecc.

SIP e un protocollo di segnalazione adottato, per la sua semplicita, come

protocollo di segnalazione del Voice over IP (VoIP), e diventato poi standard

nel 1999 e descritto nella [6]. Esso e stato ridisegnato piu volte per aggiungere

al suo interno nuove funzionalita, generando il nuovo standard definito in [9].

9

CAPITOLO 2. PROTOCOLLO SIP 10

2.1 Architettura SIP

SIP e basato sul Hypertext Transfer Protocol (HTTP) e sul Simple Mail

Transfer Protocol (SMTP) ed e stato creato per raggiungere i seguenti obi-

ettivi:

• indipendenza dal protocollo di trasporto – SIP puo utilizzare sia il

protocollo TCP che UDP;

• instradamento in base alla richiesta – un messaggio SIP puo essere

instradato direttamente verso il destinatario, o instradato da un proxy

intermedio;

• separazione tra informazioni di segnalazione e contenuti multimediali;

• estensibilita;

• utilizzabile in mobilita.

L’architettura SIP prevede degli User Agents (UAs) e degli intermediari

(servers). Lo UA e 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 entita 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; puo

modificare alcune parti del messaggio senza interferire con lo stato della

richiesta o del dialogo tra i due interlocutori;


• 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 so-

prattutto se gli utenti sono in mobilita;

• Registrar Server – accetta le richieste di tipo REGISTER; viene utiliz-

zato 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 – e un’entita di rete che fornisce servizi agli utenti;

un tipico esempio e il Presence Server, che offre il servizio di presenza.

• Back-to-back-user-agent (B2BUA) – agisce come un User Agent a en-

trambe le estremita di una sessione o chiamata SIP. Il B2BUA e respon-

sabile per la gestione della segnalazione della chiamata (instaurazione,

mantenimento, chiusura) sia sul chiamante che sul chiamato. Ogni

chiamata e monitorata dall’inizio alla fine, permettendo agli operatori

di offrire attraverso il B2BUA una funzionalita aggiuntiva per la chia-

mata. 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, e un protocollo strutturato a livelli, i quali consentono di ottenere

indipendenza tra le funzionalita da esso offerte. La struttura a livelli e

rappresentata in figura 2.1.


Figura 2.1: Struttura SIP a livelli

2.2.1 Syntax and Encoding layer

Il livello piu basso della struttura, e denominato Syntax and Encoding, e ha

il compito di definire la sintassi e la codifica di un messaggio SIP. La codifi-

ca, e 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, e l’introduzione degli headers Via.


2.2.3 Transaction layer

Il terzo livello, prende il nome di Transaction layer. Una transazione SIP (SIP

transaction), e 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 piu 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 por-

ta, 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, e composto da tre parti:


• 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 desti-

natario.

Un esempio di richiesta SIP e il seguente:

INVITE sip:[email protected] 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:[email protected]>;tag=312345

To: Bob Smith <sip:[email protected]>

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 e costituita da tre componenti:

• Method – indica il tipo di richiesta;

• Request URI – indirizzo SIP del destinatario della richiesta;


• Protocol version – versione del protocollo SIP utilizzato; la versione

specificata in [9] e la 2.0.

Il Method, puo 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 capacita del

terminale dell’utente chiamato, senza instaurare una sessione.

Un esempio di request line e il seguente:

INVITE sip:[email protected] SIP/2.0

Questo esempio, si riferisce ad un messaggio di tipo INVITE (definito nel

Method), cioe destinato ad instaurare una comunicazione con il destinatario

(definito nella Request URI).

2.3.2 Response-Line

La response line e costituita da tre componenti:

• Protocol version – identica alla request line;

• Status code – codice di tre cifre che identifica il tipo di risposta;


• Reason phrase – testo libero per una descrizione piu precisa dello status

code.

Lo status code e classificato in sei categorie:

• 1XX – indica che la richiesta e stata ricevuta ed in fase di elaborazione;

• 2XX – indica che la richiesta e 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 puo essere servita da

nessun server.

Un esempio di Response line, e 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 e il seguente:

Header-name: header-value

Alcuni headers sono obbligatori sia nelle richieste che nelle risposte:


• 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 massi-

mo di nodi che il messaggio puo 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 e possibile aggiungere alcuni parametri

separati da punto e virgola.

Un esempio di header SIP e il seguente:

Via: SIP/2.0/UDP 192.168.0.101:5062

Questo header indica che il messaggio in cui e contenuto deve passare per

il nodo 192.168.0.101 sulla porta 5062 utilizzando il protocollo UDP.


2.3.4 Corpo del messaggio

Il corpo del messaggio puo contenere qualsiasi tipo di informazione dipenden-

temente dal tipo di richiesta o risposta per cui il messaggio e 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 e possibile raggiungere

un terminale dell’utente. Esso ha la forma di un indirizzo e-mail:

sip:[email protected]

Il SIP URI puo essere di due tipi:

• Address Of Record (AOR) – e un indirizzo SIP che identifica un utente;

e piu facile da memorizzare, ed e quindi utilizzato principalmente dagli

utenti umani e gestito in modo simile ad un numero telefonico; un

esempio e


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 e


in questa forma, l’indirizzamento del messaggio non necessita di inter-

rogazioni al server DNS, in quanto l’indirizzo IP del dominio e specifi-

cato 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 capacita di far

comunicare persone collocate geograficamente molto lontane tra loro. Il con-

cetto di presenza puo essere visto come la capacita 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’aper-

to, in ufficio, ecc.), le capacita 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’uf-

ficio, ecc.), i servizi che l’utente e disposto ad utilizzare (servizi voce, video,

di messaggistica istantanea, ecc.), le attivita 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 possibilita e la volonta dell’utente

di comunicare attraverso un insieme di dispositivi.

Il servizio di presenza, poggia sul modello publish/subscribe. Il model-

lo publish/subscribe, e un paradigma di interazione che vede coinvolte due

entita: 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 no-

tificati 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 piu sem-

plicemente 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-


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

puo, ad esempio, pubblicare un messaggio che specifica su quali dispositivi

puo essere contattata in quel momento (telefono cellulare, computer dell’uf-

ficio, ecc.); Bob, che vuole contattare Alice, riceve le sue informazioni di

presenza, e valuta in che modo contattarla (se Alice e disponibile). Il concet-

to di presenza si concretizza quindi in un profilo dinamico dell’utente visibile

ad altri, e in grado di rappresentare se stesso, condividere informazioni e

controllare servizi.

Il servizio di presenza puo essere utilizzato da chiunque, sia esso un in-

formatico, un impiegato, un cuoco, un anziano o un bambino. Si presta a

diverse applicazioni, e non solo al servizio di messaggistica istantanea per

cui e stato originariamente pensato, ma anche, ad esempio, ai servizi che

offrono la possibilita di videogiocare in rete, o ai servizi che consentono di

incrementare l’efficienza sul lavoro. Il servizio di presenza rappresenta in-

oltre un business non sottovalutabile per i fornitori di servizi, che possono

contare quindi su un’importantissima funzionalita aggiuntiva per rendere le

loro offerte piu complete e accattivanti. I fornitori di servizi possono, infat-

ti, contare su un supporto base di molti servizi. Pensiamo, ad esempio, al

servizio di messaggistica istantanea: un utente deve sapere se puo 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 mes-

saging. Disporre del servizio di presenza rappresenta percio, per il fornitore,

la base per poter offrire un servizio di messaggistica istantanea. Pensando poi


a nuovi servizi, possiamo immaginare l’implementazione di un meccanismo

di segnalazione di emergenze: un utente in difficolta, premendo un semplice

tasto sul telefono cellulare, e 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 e 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 av-

vantaggiare 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 ag-

giungervi QoS.

Come descritto in [5] esistono due tipi di utilizzatori non esclusivi (cioe

un utilizzatore puo 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 pre-

sentity o prelevate da dispositivi esterni come PC, cellulari, sensori, antenne

GPS, ecc. (figura 3.2). Di questo si parlera nel paragrafo 3.2.


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 puo fornire, possono

essere difficili da gestire per un watcher, in quanto errate, contraddittorie o

ridondanti. Un utente umano e in grado di risolvere questi problemi anal-

izzando le informazioni ricevute, ma un utente costituito da un’applicazione

software puo scontrarsi con molte difficolta. Questi problemi saranno trattati

nel paragrafo 3.4.

Il protocollo utilizzato dal servizio di presenza e il SIMPLE (Session ini-

tiation protocol for Instant Messaging and Presence Leveraging Extensions),

standard gestito dalla IETF. Il formato generale delle informazioni di pre-

senza e descritto in [10] ed e 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 e in possesso.

Tutto questo sara trattato nel paragrafo 3.3.


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 quan-

to l’utente potrebbe avere difficolta ad aggiornare costantemente le

informazioni;

• segnalati in modo pianificato, consistono nelle informazioni che ven-

gono aggiornate automaticamente in base alla pianificazione dei pro-

pri impegni da parte dell’utente utilizzando applicazioni come il cal-

endario elettronico. L’affidabilita di queste informazioni dipende dal-

la scrupolosita dell’utente nell’aggiornare i propri calendari e sorgenti

simili;

• ricavati dall’utilizzo di un dispositivo, sono dedotti dall’impiego di dis-

positivi di comunicazione come l’atto di inoltrare o ricevere una chia-

mata o dalla potenza del segnale di un cellulare. In questo caso la

principale motivazione di errore puo essere data dal fatto che l’utiliz-

zatore potrebbe non corrispondere alla persona della quale si vogliono

pubblicare le informazioni;

• ricavati da sensori, sono estrapolati da sensori e consistono in infor-

mazioni come la posizione geografica, il tipo di ambiente (abitazione,

automobile, ecc.), l’attivita dell’utente, ecc. Esempi di sensori sono

il GPS o segnalazioni Bluetooth che indicano il tipo di ambiente cir-

costante. Il vantaggio dei sensori e che non fanno affidamento sull’ag-


giornamento delle informazioni da parte dell’utente, ma sono soggetti

ad errori di misurazione. Ad esempio un sensore PIR (Passive InfraRed

sensor), puo rilevare la presenza di un soggetto in ufficio, ma non ac-

certare se si tratta della persona interessata o dell’addetto alle pulizie.

Un sensore GPS non puo rilevare se il cellulare e utilizzato dal suo

proprietario o da qualcun altro;

• dedotti indirettamente da una sorgente di informazioni, ad esempio

non interessa se l’utente e 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 messag-

gio 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) e un protocollo standard basato su SIP e utilizza-

to per la messaggistica istantanea e per il servizio di presenza. SIMPLE

estende il protocollo SIP per adattarlo alle esigenze del servizio di presen-

za. Sostanzialmente aggiunge una nuova tipologia di evento denominata

presence. Il documento [7], individua due tipi di entita per il servizio di

presenza:

• Presence Agent (PA), il quale e in grado di memorizzare le sottoscrizioni

e generare le notifiche;


• Presence User Agent (PUA), il quale manipola e pubblica le infor-

mazioni di presenza per un presentity.

Il processo di pubblicazione, e 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 cor-

po 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 possibilita di

inserire nel corpo del messaggio diversi tipi di dati, e 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 al-

l’evento presence.winfo, riceve le informazioni riguardanti lo stato dei watch-

ers a lui sottoscritti e quelle riguardanti l’evento che ha causato la modifi-

ca dello stato. Gli stati che un watcher puo 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’attivita

del watcher all’interno del servizio di presenza. Un presentity, puo decidere

di limitare la consegna delle notifiche relative al proprio stato, soltanto a

determinati watcher. Un presentity ha quindi la possibilita di creare delle

regole (o policy) che hanno il compito di determinare chi puo sottoscriversi

al servizio di presenza del presentity stesso. Ad esempio, Alice puo 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


stati sono descritti in [8] e sono i seguenti:

• Init : nessuno stato del watcher disponibile. Init e uno stato transito-

rio, che viene assunto dal watcher nel momento della sottoscrizione al

servizio di presenza del presentity, poi verra 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 res-

ta, 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 sot-

toscriversi al servizio di presenza del presentity e che tale sottoscrizione

e scaduta prima che venisse creata una regola. In ogni momento il serv-

er di presenza puo 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 puo assumere, e riportato in

figura 3.3.


Figura 3.3: Diagramma degli stati dei watcher

La figura, mostra i motivi per cui un watcher puo cambiare stato. Al mo-

mento 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 puo, pero, restare nello stato

di Waiting all’infinito, quindi, se dopo un determinato periodo di tempo non

e 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 e scaduta prima che sia stata accettata o rifi-

utata esplicitamente dal presentity. Le sottoscrizioni, hanno un determinato

periodo di validita, al termine del quale il watcher passa dallo stato Active,

allo stato di Terminated.


3.3.1 Metodi PUBLISH, SUBSCRIBE e NOTIFY

Come anticipato nel paragrafo precedente, per poter pubblicare il proprio

stato e 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 falli-

mento della procedura. L’utente al quale si riferisce la pubblicazione e spec-

ificato 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 noti-

fiche 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

puo essere positiva (la sottoscrizione e andata a buon fine) o negativo (la

sottoscrizione e fallita). La sottoscrizione al servizio di presenza, ha una du-

rata limitata e deve quindi essere rinnovata prima della sua scadenza. Per

cancellare una sottoscrizione prima della sua scadenza, e necessario inviare

un messaggio di SUBSCRIBE contenente l’header Expires uguale a zero.

Il metodo NOTIFY viene ricevuto dall’utente che si e sottoscritto ad

un servizio di presenza, e ha lo scopo di notificare il cambiamento di sta-

to da parte dell’utente osservato. Le informazioni di stato, sono contenuto

all’interno del corpo del messaggio in formato XML. Alla ricezione del mes-

saggio NOTIFY, il client deve rispondere con un messaggio di conferma, per

avvertire la sorgente (tipicamente un presence server) dell’avvenuta ricezione.


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 e strutturato in elementi definiti dal Presence Information Data Format

(PIDF) [13] che e poi stato esteso dal Rich presence extensions to the Presence

Information Data format (RPID) [11]. I principali elementi predefiniti sono:

• presence: e l’elemento radice. Contiene un attributo entity il cui val-

ore 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 puo contenere gli

elementi contact, note, timestamp ed altri elementi di estensione;

• status : puo contenere un elemento basic e una serie di altri elementi di

estensione.

• basic: puo contenere la stringa open o closed per indicare se il contatto

associato e raggiungibile o meno.

• contact : e 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 e stato

modificato;


• person: descrive le caratteristiche di un utente umano. Deve con-

tenere un attributo id che lo identifica dagli altri elementi person. Puo

contenere piu elementi note e un elemento timestamp;

• device: descrive le caratteristiche di un terminale in possesso del pre-

sentity. Deve contenere un attributo id che lo identifica dagli altri

elementi device all’interno dello stesso presentity. Deve contenere un el-

emento deviceID. Puo 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 e il seguente:

<?xml version="1.0" encoding="UTF-8"?>

<presence xmlns="urn:ietf:params:xml:ns:pidf"

entity="sip:[email protected]">

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


<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 names-

pace del documento:

xmlns="urn:ietf:params:xml:ns:pidf"

inoltre e presente un altro attributo obbligatorio:

entity="pres:[email protected]"

che definisce l’entita cui appartengono le informazioni di presenza. Il

valore di tale attributo e 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 de-

scrive lo stato di un servizio, quindi possiamo concludere che il servizio identi-

ficato dalla stringa “sg89ae” per l’utente “sip:[email protected]” e disponi-

bile (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 e

al momento disponibile (closed).

Proseguiamo analizzando la sezione device: l’utente dispone di un dis-

positivo il cui id e rappresentato dalla stringa “urn:device:0003ba4811e3”


contenuta nell’elemento deviceID. Notiamo che l’elemento device e identifi-

cato dalla stringa “pc147” per differenziarlo da eventuali altri elementi device

inseribili nel documento XML.

Dall’elemento note, un utente umano puo dedurre che il dispositivo in ques-

tione e un PC; l’elemento note, come gia detto, ha l’unico scopo di aggiungere

informazioni comprensibili soltanto da un utente umano. Il PC non e attual-

mente utilizzato, come si puo dedurre dal contenuto dell’elemento user-input,

che indica lo stato di utilizzo del dispositivo a cui e associato. L’ultima volta

che il PC e stato utilizzato e in data 2009-09-08 alle ore 13:20:00.

3.4 Gestione dei conflitti delle informazioni

Come gia accennato, un presentity puo 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, pub-

blica automaticamente lo stato di non disponibilita di Alice a ricevere tele-

fonate. Supponiamo che Bob, marito di Alice, prenda in prestito l’auto della

moglie e, contemporaneamente, Alice pubblichi la sua disponibilita a ricevere

telefonate: a questo punto Alice e 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 puo essere rappresentato da numerosi elementi, alcuni dei quali

possono contraddirsi a vicenda. Ad esempio, una persona non puo essere in

due luoghi differenti nello stesso momento, quindi, se due elementi place-is

hanno valori diversi, significa che uno dei due e errato. Per altri tipi di infor-


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 puo assumere contemporaneamente i valori “office”

e “outdoors”, ma potrebbe assumere i valori “outdoors” e “stadium”. La dif-

ficolta sta quindi nel capire quando un elemento assume valori contraddittori

o soltanto differenti nella loro specificita.

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 e dato sapere quali valori sono in conflitto per gli el-

ementi activities o mood, a causa dei molteplici valori che possono assumere.

Un approccio conservativo per gestire alcuni conflitti, potrebbe essere sem-

plicemente listare tutti i valori. In questi casi, vengono presentati al watcher

versioni multiple dello stesso elemento e stara quindi a lui il compito di deter-

minare quello corretto. Per limitare il numero di informazioni recapitate al

watcher si puo scegliere un solo valore escludendo tutti gli altri. Per prendere

questa decisione, si puo procedere in modi differenti:

• scegliere il valore dell’elemento piu recente: si tratta di optare per il

valore pubblicato piu di recente. In questo caso, si rischia di scartare

un valore corretto e mantenere quello errato;

• scegliere l’elemento piu affidabile: l’affidabilita puo essere basata sul-

l’identita della sorgente, come ad esempio il cellulare dell’utente. In

alternativa si puo dare un ordine di fiducia ai tipi di sorgente delle

informazioni, ad esempio, “segnalati in tempo reale”, “ricavati dal-

l’utilizzo di un dispositivo”, “ricavati da sensori”, “segnalati in modo

pianificato”;

• scegliere in base al valore di un altro elemento: gli altri elementi potreb-


bero indicare un valore che potrebbe essere piu affidabile. Ad esempio,

l’elemento user-input, potrebbe indicare che un dispositivo che fornisce

indicazioni di presenza e 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 piu

recentemente.

3.5 Metodi per l’utilizzo del servizio di pre-

senza

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 e 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 ac-

cetta la sottoscrizione rispondendo con un messaggio di tipo 200 OK per

indicare a Bob che la richiesta e 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.


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 e cosı formato:

SUBSCRIBE sip:[email protected] SIP/2.0

Via: SIP/2.0/UDP host.example.com;branch=z9hG4bKnashds7

To: <sip:[email protected]>

From: <sip:[email protected]>;tag=12341234

Call-ID: [email protected]

CSeq: 1 SUBSCRIBE

Max-Forwards: 70

Expires: 3600

Event: presence

Content-Length: 0


Descriviamo brevemente il contenuto del messaggio.

Nella prima riga (Request-Line) compaiono il metodo (SUBSCRIBE), la Re-

quest URI (sip:[email protected]) 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 sottoscriver-

si, mentre l’header From contiene l’URI del mittente (watcher nel caso di

messaggi SUBSCRIBE).

Altro header importante e 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 dovra essere seguito

(a ritroso) dai futuri messaggi di risposta.

Infine descriviamo l’header Expires, che informa circa il periodo di valid-

ita della sottoscrizione: il valore 3600 indica che per i prossimi 3600 seondi

Bob ricevera notifiche riguardanti i cambiamenti di stato di Alice, dopodiche

la sottoscrizione scadra e Bob dovra rinnovarla. Questo header, se settato

a 0, indica al Presence Server che il mittente non vuole piu ricevere noti-

fiche riguardanti il servizio di presenza circa il presentity specificato nella

Request-Line.

PUBLISH

In figura 3.5 e 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.


Figura 3.5: Processo di PUBLISH

Il messaggio di PUBLISH e cosı formato:

PUBLISH sip:[email protected] SIP/2.0

Via: SIP/2.0/UDP pua.example.com;branch=z9hG4bK652hsge

To: <sip:[email protected]>

From: <sip:[email protected]>;tag=1234wxyz

Call-ID: [email protected]

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.


L’Header Content-Type indica il tipo di contenuto del corpo del messaggio;

essendovi contenuto un testo XML con struttura adeguata al servizio di pre-

senza, il valore di tale header e application/pidf+xml.

L’header Content-Lenght specifica la lunghezza in byte del corpo del messag-

gio.

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

e stato scelto Kamailio (OpenSER) [3] per la sua completezza e solidita.

In realta, OpenSER e 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 e scritto in linguaggio C, ed e 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 funzionalita 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 gia anticipato, Kamailio e strutturato in moduli, ognuno dei quali

implementa funzionalita specifiche ai fini di integrare piu servizi in un unico

server.

Ogni modulo e indipendente dagli altri e sta a noi scegliere come configurare

l’istanza di Kamailio perche 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, denom-

inato appunto presence e scritto interamente in linguaggio C.

4.2 JAIN-SIP

JAIN (Java in Advanced Intelligent Networks) e una comunita di aziende

creata con lo scopo specifico di definire delle API [1] per raggiungere la

portabilita dei servizi, convergenza e accessi sicuri verso reti telefoniche e

dati (Internet). Si basa esclusivamente sulla tecnologia Java, ed anche il suo


sviluppo segue le specifiche di sviluppo e licenza SUN (JSPA Java Specifi-

cation 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

funzionalita per il controllo delle chiamate e quindi fornendo un’infrastrut-

tura 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 puo essere creato rapidamente, provato e integrato

in una gran varieta di piattaforme avendo a gia 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 puo essere scritta come programma, applet,

servlet o bean. Le API mettono a disposizione le potenzialita 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 e visibile la struttura di una generica applicazione che si


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 possibilita di accesso al servizio

di presenza in ambienti distribuiti nei quali presentity e watcher afferiscano

a server diversi. Altro scopo della sincronizzazione, e quello di bilanciare il

carico degli utenti utilizzando le informazioni che ogni nodo e in grado di

raccogliere. (figura 5.1).

44

CAPITOLO 5. SOLUZIONE DEL PROGETTO 45

Figura 5.1: Sistema

Client SIP

Il client SIP e stato sviluppato in linguaggio Java utilizzando la tecnologia

JAIN SIP gia citata nel paragrafo 4.2. Tale client implementa le funzionalita

di base per l’utilizzo del servizio di presenza, il quale e offerto da una rete di

presence server Kamailio.

Modifiche al modulo di presenza presence

Il modulo di presenza presence integrato in Kamailio realizza le funzionalita

necessarie per offrire il servizio di presenza, ed e il cuore del nostro progetto.

Modificando tale modulo, e possibile sviluppare un meccanismo di bilanci-

amento del carico di lavoro in modo che le varie richieste entranti vengano

smistate su piu 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


del modulo di presenza integrato in Kamailio. Tale modulo e suddiviso in

sottomoduli, ognuno dei quali implementa un sottoinsieme ben preciso di

funzionalita.

Le nostre modifiche coinvolgono il processo di gestione delle richieste di

pubblicazione e quello di gestione delle richieste di sottoscrizione. In par-

ticolare e 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

potra gestire l’errore a suo piacimento, ad esempio inoltrando la richiesta ad

un altro presence server.

Come gia 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 mec-

canismo puo 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 infor-

mazioni molto frequentemente, il presence server evita di attuare il processo

di notifica a tutti i sottoscrittori per ogni pubblicazione ricevuta, ma lo at-

tua 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 gia molti sottoscritti, la richiesta viene rifiutata dal serv-

er, il quale provvede a rispondere al client richiedente con un messaggio che


gli indica uno stato di temporanea indisponibilita 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 quantita 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 piu nodi interconnessi tra loro, che offrono

un servizio di presenza a tutti i client. Da questo, nasce il problema della de-

centralizzazione 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 conoscen-

za delle ultime informazioni pubblicate da ciascun presentity, e ognuno puo

attuare il processo di notifica a tutti i watcher sottoscritti a quel presen-

tity 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 sot-

toscrittori. Abbiamo, quindi, una centralizzazione delle informazioni di pre-

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


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 e stato sviluppato in linguaggio Java utilizzando la tecnologia

JAIN SIP. Il client deve:


• sottoscriversi al servizio di presenza presso un presence server;

• pubblicare informazioni di presenza presso un presence server;

• ricevere notifiche da uno o piu presence server;

• eventualmente, ridirezionare le sue richieste di sottoscrizione e pubbli-

cazione su presence server differenti in caso di indisponibilita di quello

scelto.

In figura 5.3 e riportata una schermata del client.

Figura 5.3: Sistema

Il client e 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;


• una text field (From) in cui viene visualizzato il proprio indirizzo sip;

• una text field (To) in cui specificare l’indirizzo sip del contatto a cui ci

si vuole sottoscrivere;

• una combo box (PS ) in cui selezionare il presence server a cui inoltrare

la richiesta.

Esaminiamo ora il comportamento del client a seguito dei vari comandi

impartiti dall’utente, ed in particolare le azioni di PUBLISH, SUBSCRIBE

e UNSUBSCRIBE.

5.2.1 PUBLISH

Premendo il pulsante Pub del client, l’applicazione invia un messaggio SIP

di tipo PUBLISH al presence server specificato nella combo box PS. Nel caso

in cui il server risponda con un messaggio di errore, il client provvede ad

inoltrare automaticamente il messaggio di PUBLISH ad un presence server

differente che, se non e in uno stato critico di possibile sovraccarico, accetta

e gestisce adeguatamente la richiesta (figura 5.4).


Figura 5.4: Richiesta di PUBLISH

Nel caso in cui tutti i server siano indisponibili, il client interrompe l’invio

automatico delle richieste e mostra un avviso all’utente.

5.2.2 SUBSCRIBE e UNSUBSCRIBE

Analogamente a quanto avviene per la pubblicazione, premendo il pulsante

Sub del client si avvia il processo di sottoscrizione. L’applicazione inoltra un

messaggio di SUBSCRIBE verso il presence server selezionato nella combo

box PS e relativo al presentity specificato nella text field To e, se il server

non e disponibile, invia automaticamente la richiesta ad un altro nodo (figura

5.5).


Figura 5.5: Richiesta di SUBSCRIBE

Il processo di UNSUBSCRIBE scatenato dalla pressione del pulsante Un-

Sub, provvede ad inviare una richiesta di SUBSCRIBE con header Expires a

0 (cancellazione della sottoscrizione) verso il presence server selezionato nella

combo box PS e relativo al presentity specificato nella text field To.

Nel caso in cui tutti i server siano indisponibili, il client interrompe l’invio

automatico delle richieste e mostra un avviso all’utente.

5.3 Presence Server Kamailio

Come gia accennato in precedenza, per raggiungere gli obiettivi preposti, la

nostra soluzione si concentra sulla modifica del modulo di presenza presence

di Kamailio scritto interamente in linguaggio C.


Per la configurazione completa del modulo di presenza modificato si ri-

manda all’appendice B.

5.3.1 Modifica della gestione dei messaggi SUBSCRIBE

Una delle modifiche apportate al modulo di presenza, consiste nell’implemen-

tazione di un meccanismo che controlli e limiti la frequenza ed il numero di

richieste di sottoscrizione che arrivano al server. Per fare questo, definiamo

una frequenza massima di ricezione delle richieste che, se superata, deter-

mina una risposta di redirezione al client da parte del server. Questo ha lo

scopo di evitare un sovraccarico del server nel breve periodo, nel caso in cui

le richieste entranti siano in numero troppo elevato per poterle gestire tutte

correttamente.

In figura 5.6 e rappresentato un esempio in cui presentity 1, presentity 2 e

presentity 3 determinano un superamento della frequenza massima tollera-

bile di ricezione di richieste SUBSCRIBE da parte del PS, portando quindi

il server a rifiutare la richiesta di presentity 4.


Figura 5.6: Rifiuto delle richieste di SUBSCRIBE

Analogamente al meccanismo appena descritto, il server e stato mod-

ificato inserendo un controllo sul numero di watcher “globalmente” attivi

sul server stesso al momento della ricezione di una nuova richiesta di sotto-

scrizione, ed un controllo sul numero di watcher attivi verso il presentity per

il quale arriva la richiesta di sottoscrizione. Troppi watcher attivi possono,

infatti, portare ad una congestione del server durante il processo di notifica

delle informazioni pubblicate dai presentity. Supponiamo, ad esempio, che un

presentity abbia 1000 utenti sottoscritti al proprio servizio di presenza: quan-

do il presentity pubblica informazioni, il PS deve inviare una notifica verso

ogni watcher attivo, ovvero 1000 notifiche. Questo puo portare ad un sovrac-

carico del server e ad una congestione del canale di comunicazione, quindi la


soluzione prevede di limitare il numero massimo di watcher attivi per ogni

presentity. Nel momento in cui arriva una richiesta di sottoscrizione relativa

al servizio di presenza di un presentity P (figura 5.7), il server controlla il

numero di watcher “globalmente” attivi che possiede e:

• se e sopra la soglia massima rifiuta la richiesta rispondendo al client

con un messaggio di tipo 302 Moved temporarily ;

• se e sotto la soglia massima controlla il numero di watcher attivi che

possiede verso il presentity P per cui e arrivata la nuova richiesta e:

– se e sopra la soglia massima rifiuta la richiesta rispondendo al

client con un messaggio di tipo 302 Moved temporarily ;

– se e sotto la soglia massima accetta la nuova richiesta.

Figura 5.7: Controllo sul numero di watcher attivi


5.3.2 Modifica della gestione dei messaggi PUBLISH

La soluzione proposta prevede anche la modifica del meccanismo di gestione

delle pubblicazioni implementato nel modulo di presenza integrato in Ka-

mailio. Tale modulo e stato modificato inserendo un controllo sulla frequen-

za di arrivo dei messaggi PUBLISH, in modo da salvaguardare il server da

possibili congestioni dovute alla loro gestione. Il controllo viene effettua-

to sia sulla frequenza di arrivo delle pubblicazioni indipendentemente dal

presentity che le pubblica, sia sulla frequenza di pubblicazione di un sin-

golo presentity. All’arrivo di un messaggio di tipo PUBLISH, il presence

server provvede a verificare la frequenza “globale” di pubblicazione (frequen-

za di pubblicazione di tutti i presentity del PS) registrata in un intervallo

temporale subito precedente (figura 5.8), e:

• se supera la frequenza massima tollerabile di pubblicazione, il PS risponde

al client con un messaggio di tipo 302 Moved temporarily ;

• se non supera la frequenza massima, il PS controlla la frequenza di pub-

blicazione (nell’ultimo intervallo temporale) del presentity richiedente

e:

– se supera la frequenza massima tollerabile di pubblicazione, il

PS registra la pubblicazione senza inviare le notifiche, che invi-

era in intervalli di tempo prestabiliti per ottimizzare il numero di

messaggi scambiati;

– se non supera la frequenza massima, il PS accetta la richiesta,

avvisa gli altri server del sistema dell’avvenuta pubblicazione di

nuove informazioni ed invia le notifiche ai watcher sottoscritti

presso di lui.


Figura 5.8: Controllo sulla frequenza di pubblicazione (solo comunicazione

PS - presentity)

Nelle figure successive e riportato lo schema completo dei messaggi scam-

biati nel sistema nel caso in cui la frequenza “globale” di pubblicazione non

sia superata.


Figura 5.9: Scambio di messaggi per il processo di pubblicazione (frequenza

presentity non superata)

Dalla figura 5.9 notiamo che, nel caso in cui la frequenza “globale” di pub-

blicazione non sia stata superata e la frequenza di pubblicazione del presentity

richiedente sia sotto la soglia massima, il PS accetta la richiesta, inoltra le

notifiche ai watcher ed avvisa gli altri server dell’avvenuta pubblicazione di

nuove informazioni di presenza, in modo che ognuno possa notificare i propri

sottoscrittori.


Figura 5.10: Scambio di messaggi per il processo di pubblicazione (frequenza

presentity superata)

Dalla figura 5.10 notiamo che, nel caso in cui la frequenza “globale” di

pubblicazione non sia stata superata e la frequenza di pubblicazione del pre-

sentity richiedente sia sopra la soglia massima, il PS accetta la richiesta, at-

tende per un periodo di tempo prestabilito (in cui potrebbero arrivare nuovi

PUBLISH dallo stesso presentity), inoltra le notifiche ai watcher ed avvisa gli

altri server dell’avvenuta pubblicazione di nuove informazioni di presenza, in

modo che ognuno possa notificare i propri sottoscrittori. L’attesa permette

di evitare la generazione e l’invio di notifiche troppo frequenti verso i watcher


di uno specifico presentity, escludendo cosı i rischi di congestione del server.

Tutti i messaggi di pubblicazione ricevuti durante il periodo di attesa verran-

no accettati dal PS (rispettando la frequenza “globale” di pubblicazione), e le

informazioni in essi contenute verranno salvate in un database centralizzato

accessibile poi da ogni altro server del sistema.

La soluzione prevede, inoltre, che ogni server sia in ascolto su un indirizzo

multicast per essere avvisato dagli altri PS sull’avvenuta pubblicazione di

informazioni di presenza da parte di un presentity. Come gia detto, infatti,

quando un PS riceve un messaggio PUBLISH da un presentity P, salva le

informazioni di presenza nel database centralizzato, notifica i propri watcher

ed avvisa gli altri PS che il presentity P ha pubblicato nuove informazioni; gli

altri PS recuperano le informazioni dal database e notificano i propri watcher

(figura 5.11).


Figura 5.11: Scambio di messaggi per il processo di pubblicazione

La soluzione prevede, in realta, due soglie di frequenza massima “glob-

ale” di pubblicazione, a seconda che il presentity sia “privilegiato” o meno.

Queste soglie distinte consentono di trattare con maggiore riguardo gli uten-

ti piu attivi rispetto a quelli che lo sono meno, aggiungendo un minimo di

qualita al servizio. Nello specifico, il server, all’arrivo di un messaggio PUB-

LISH proveniente dal presentity P, controlla il numero di pubblicazioni che

P ha effettuato nell’ultima ora e, se supera un certo livello L (configurabile


dal file di configurazione di Kamailio), P viene considerato “privilegiato”.

Successivamente, il PS controlla la frequenza “globale” di pubblicazione e,

se l’utente e “privilegiato”, la soglia massima da considerare e pari ad un

valore S (configurabile dal file di configurazione di Kamailio); se l’utente e

“non privilegiato”, la soglia massima da considerare e 23S.

5.4 Risultati sperimentali

Per testare il modulo di presenza presence di Kamailio da noi modificato,

abbiamo eseguito alcuni test e misurato i tempi di risposta del server.

Per il test abbiamo utilizzato un programma denominato sipp [4], che con-

sente di creare scenari personalizzati volti ad istruire l’applicazione riguardo

a quali messaggi inviare e a quali aspettarsi in fase di ricezione. L’appli-

cazione consente, inoltre, di configurare la frequenza di invio di messaggi, in

modo da poter testare il funzionamento del nostro server in casi estremi.

Per avere una migliore idea sul significato dei tempi di risposta, abbiamo

effettuato gli setssi test integrando in Kamailio il modulo di presenza origi-

nale, cioe non modificato da noi. Le tabelle sotto riportate mostrano i vari

risultati ottenuti per il processo di pubblicazione di informazioni di presenza.

Legenda colonne:

• RATIO: frequenza di invio messaggi ([msg/msec]);

• SENT: numero di messaggi inviati;

• TIME: tempo impiegato dal server per gestire tutti i messaggi ([sec]);

• 200: numero di risposte di tipo 200 OK da parte del server;

• 302: numero di risposte di tipo 302 Moved temporarily da parte del

server.


Messaggi PUBLISH

RATIO SENT TIME 200 302

100/1000 5000 50,01 5000 /

150/1000 5000 33,35 5000 /

200/1000 5000 25,01 5000 /

250/1000 5000 20,52 5000 /

300/1000 5000 30,13 5000 /

350/1000 5000 33,88 5000 /

400/1000 5000 33,16 5000 /

Tabella 5.1: Modulo di presenza originale

Messaggi PUBLISH

RATIO SENT TIME 200 302

100/1000 5000 50,01 5000 71

150/1000 5000 33,34 5000 1396

200/1000 5000 25,01 5000 1628

250/1000 5000 20,01 5000 2000

300/1000 5000 16,67 5000 2000

350/1000 5000 14,29 5000 3500

400/1000 5000 28,12 5000 2000

Tabella 5.2: Modulo di presenza modificato


Notiamo che, con il modulo di presenza originale, Kamailio inizia ad avere

difficolta a frequenze di 300 messaggi al secondo. Alla stessa frequenza,

il modulo di presenza modificato risponde in tempi decisamente inferiori,

in quanto rifiuta le richieste che possono causare congestione e lentezza di

risposta del server; in questo caso il client puo reinviare la stessa richiesta ad

un altro presence server per poter ottenere una risposta in tempi brevi.

Le tabelle successive mostrano i vari risultati ottenuti per il processo di

sottoscrizione.

Legenda colonne:

• RATIO: frequenza di invio messaggi ([msg/msec]);

• SENT: numero di messaggi inviati;

• TIME: tempo impiegato dal server per gestire tutti i messaggi ([sec]);

• 202: numero di risposte di tipo 202 OK da parte del server;

• 302: numero di risposte di tipo 302 Moved temporarily da parte del

server;

• NOT: numero di messaggi NOTIFY inviati dal server a seguito della

ricezione di un SUBSCRIBE;

• UN: numero di messaggi inaspettati inviati dal server a seguito della

ricezione di un SUBSCRIBE (causati da errori interni al server);

• TO: numero di richieste andate in timeout (non hanno ricevuto risposta

dal server).


Messaggi SUBSCRIBE

RATIO SENT TIME 202 302 NOT UN TO

100/1000 5000 50,02 5000 / 5000 0 0

150/1000 5000 33,34 5000 / 5000 0 0

200/1000 5000 25,01 5000 / 5000 0 0

250/1000 5000 20,01 5000 / 5000 0 0

300/1000 5000 27,15 4816 / 4815 184 0

350/1000 5000 26,15 4788 / 4785 212 0

400/1000 5000 16,82 4617 / 4615 383 0

Tabella 5.3: Modulo di presenza originale

Messaggi SUBSCRIBE

RATIO SENT TIME 202 302 NOT UN TO

100/1000 5000 50,01 2725 2275 2725 0 0

150/1000 5000 33,34 2008 2992 2008 0 0

200/1000 5000 25,00 2104 2896 2104 0 0

250/1000 5000 20,01 3144 1856 3144 0 0

300/1000 5000 16,67 3403 1597 3403 0 0

350/1000 5000 14,76 3772 1228 2772 0 0

400/1000 5000 12,51 4004 743 4004 253 0

Tabella 5.4: Modulo di presenza modificato


Notiamo come il modulo di presenza modificato gestisca le richieste di

sottoscrizione meglio dell’originale, perdendo (colonna TO) o rispondendo

in modo errato (colonna UN ) a molti meno messaggi e in tempi inferiori. I

client che ricevono un messaggio 302 Moved temporarily in risposta, possono

reinoltrare la richiesta di sottoscrizione ad un altro presence server con un

carico di lavoro inferiore.

Appendice A

Configurazione di kamailio

Per i nostri scopi, e sufficiente configurare Kamailio come standalone Presence

Server. I paragrafi successivi illustrano i vari passi da seguire per scaricare,

installare e configurare correttamente il nostro Presence Server.

A.1 Prerequisiti

Kamailio funziona su sistema operativo Linux, come ad esempio Linux Ubun-

tu 9.10.

Per poter compilare con successo i file sorgenti di Kamailio, e necessario in-

stallare i software gcc, flex, bison e make; e inoltre necessario procurarsi la

libreria libmysqlclient15-dev.

Su un sistema Linux Ubuntu, e possibile recuperare tutti i requistiti attraver-

so il comando

sudo apt-get install gcc flex bison make libmysqlclient15-dev

Soddisfatti questi requisiti, e possibile procedere con il download, la

compilazione e la configurazione del presence server.

67

APPENDICE A. CONFIGURAZIONE DI KAMAILIO 68

A.2 Download

I sorgenti di Kamailio sono scaricabili dal sito ufficiale al link

http://www.kamailio.org/mos/view/Download/ attraverso diversi meccanis-

mi. Avendo precedentemente installato Subversion, possiamo scaricare i sor-

genti utilizzando tale software. I sorgenti di Kamailio sono pre-configurati

per lavorare da un percorso standard. Possiamo quindi creare la cartella

/usr/local/src/kamailio-1.5.2 dove preferiamo, e spostarci all’interno di essa;

procediamo poi con il download via svn:

mkdir -p /usr/local/src/kamailio-1.5.2

cd /usr/local/src/kamailio-1.5.2

svn co

http://openser.svn.sourceforge.net/svnroot/openser/branches/1.5

sip-server

Effettuato il download, possiamo procedere alla compilazione dei sorgenti.

A.3 Compilazione e installazione

Per configurare correttamente Kamailio come standalone Presence Server,

dobbiamo seguire i seguenti passi:

• includere i moduli di presenza e mysql nella compilazione, modificando

il file Makefile.vars ;

• compilare i file sorgenti;

• installare i file binari.

Per includere il modulo di presenza, dobbiamo modificare il file Make-

file.vars situato nella cartella principale, decommentando la riga


MODS_PRESENCE=on

Per permettere a Kamailio di utilizzare il database MySQL, e necessario

decommentare anche la riga

MODS_MYSQL=on

Fatto questo, possiamo procedere alla compilazione dei sorgenti eseguendo

il comando

sudo make all

Questo ultimo comando, potrebbero richiedere molto tempo, a seconda

delle prestazioni della macchina sulla quale viene eseguito.

Procediamo ora all’installazione dei file appena compilati, eseguendo il co-

mando

sudo make install

Lo script di installazione, provvede a creare una serie di cartelle nelle

quali inserisce i file di Kamailio:

• /usr/local/sbin: inserisce i binari e gli script di avvio kamailio, kamctl,

kamdbctl ;

• /usr/local/lib/kamailio/modules/ : inserisce i moduli necessari a ka-

mailio;

• /usr/local/etc/kamailio/ : inserisce il file di configurazione kamailio.cfg.

A questo punto, possiamo passare alla configurazione di Kamailio come

standalone Presence Server ed alla creazione del database necessario.


A.4 Configurazione

Come gia detto, ci interessa configurare Kamailio come semplice Presence

Server.

Per fare questo, e necessario modificare il file kamailio.cfg che si trova nella

cartella /usr/local/etc/kamailio/. Risulta piu facile e veloce sostituire il sud-

detto file con il file di esempio presence.cfg situato nella cartella /usr/local/src/kamailio-

1.5.2/test, ed andare poi a modificare tale file per settare i parametri che ci

interessano. Andiamo, infine, a creare il database necessario a kamailio.

Innanzitutto effettuiamo un backup del file originale kamailio.cfg

mv /usr/local/etc/kamailio/kamailio.cfg

/usr/local/etc/kamailio/kamailio.cfg.bk

Copiamo il file di esempio al posto dell’originale

cp /usr/local/src/kamailio-1.5.2/test/presence.cfg

/usr/local/etc/kamailio/kamailio.cfg

Sostituiamo il file sostituendo la riga

port=5059

con la riga

port=5060

Questa modifica, indica al server di presenza, di mettersi in ascolto di

nuove richieste entranti sulla porta 5060.

Sostituiamo poi la riga

modparam("presence", "server_address", "sip:10.10.10.10:5060")


con la riga


Questo ci consente di settare una variabile interna a Kamailio che indi-

ca quale indirizzo SIP inserire nell’header Contact dei messaggi inviati da

Kamailio stesso.

A questo punto, kamailio e configurato per funzionare come standalone

presence server in ascolto all’indirizzo 127.0.0.1 (localhost) sulla porta 5060.

Passiamo ora alla configurazione del database. Innanzitutto, dobbiamo

modificare il file kamctlrc situato nella cartella /usr/local/etc/kamailio/ per

specificare il DBMS utilizzato e il dominio della nostra rete, poi andiamo a

creare il database.

Entriamo nella cartella /usr/local/etc/kamailio/

cd /usr/local/etc/kamailio/

modifichiamo la riga

SIP_DOMAIN=kamailio.org

con

SIP_DOMAIN=kamailio.test

aggiungiamo, o decommentiamo se gia presente, la riga

DBENGINE=MYSQL

la quale consente di specificare il DBMS che Kamailio deve utilizzare.

A questo punto possiamo passare alla creazione del database. Kamailio offre

uno script che configura automaticamente il database, digitiamo quindi il

comando


sudo kamdbctl create

Abbiamo ora terminato la configurazione di Kamailio, e possiamo quindi

farlo partire con il comando

sudo kamctl start

Per fermarlo digitiamo

sudo kamctl stop

In questo modo possiamo far partire una sola istanza di Kamailio su

questa macchina, in quanto la porta di ascolto del server e specificata nel file

di configurazione. Se vogliamo avviare piu istanze di Kamailio sulla stessa

macchina, possiamo fare riferimento al paragrafo A.4.1.

A.4.1 File di configurazione per ogni istanza

Se vogliamo far girare piu istanze di Kamailio sulla stessa macchina e neces-

sario seguire i seguenti passi:

• creare un file di configurazione per ogni istanza di Kamailio;

• creare un file di script per l’avvio di ogni istanza di Kamailio.

Ogni istanza di Kamailio necessita di un file di configurazione che deve

essere in parte diverso da ogni altro file di configurazione delle varie istanze.

In particolare e necessario che ogni istanza sia in ascolto su una porta diversa.

Per fare questo, possiamo creare, per ogni istanza che vogliamo, un file di

configurazione a partire da quello creato precedentemente:

cd /usr/local/etc/kamailio/

cp kamailio.cfg kamailio1.cfg

cp kamailio.cfg kamailio2.cfg


In questo modo abbiamo creato due file di configurazione identici per

avviare due istanze di kamailio sulla stessa macchina. Ora procediamo alla

modifica della porta di ascolto dei due server modificando, nel secondo file

(kamailio2.cfg), la riga

port=5060

con

port=5070

e la riga


con


In questo modo, la seconda istanza di Kamailio sara in ascolto sulla porta

5070 di localhost.

A questo punto procediamo creando gli script di avvio per le due istanze.

Innanzitutto creiamo uno script denominato kamailio.base contenente le seguen-

ti righe:

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

#### Common functions

mdbg() {

if [ "0$VERBOSE" -ne 0 ] ; then


if [ -t 1 -a -z "$NOHLPRINT" ] ; then

echo -e "\033[1m$1\033[0m"

else

echo "$1"

fi

fi

}

mwarn() {


echo -e ’\E[37;32m’"\033[1mWARNING: $1\033[0m"

else

echo "** WARNING: $1"

fi

}

minfo() {


echo -e ’\E[37;33m’"\033[1mINFO: $1\033[0m"

else

echo "** INFO: $1"

fi

}

mecho() {


echo -e "\033[1m$1\033[0m"


else

echo "$1"

fi

}

merr() {


echo -e ’\E[37;31m’"\033[1mERROR: $1\033[0m"

else

echo "** ERROR: $1"

fi

}

print_usage() {

mwarn "usage: $0 (start|stop|restart)"

}

#

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

### openser_start

#

openser_start() {

echo

minfo "...Starting Kamailio... "

echo

/usr/local/sbin/kamailio -f $CONFIG_FILE -P $PID_FILE


sleep 3

echo

minfo "started (pid: ‘cat $PID_FILE‘)"

echo

}

#

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

### openser_stop

#

openser_stop() {

echo

minfo "...Stopping Kamailio... "

echo

if [ -r $PID_FILE ] ; then

kill ‘cat $PID_FILE‘

minfo "stopped"

echo

else

merr "No PID file found ($PID_FILE)! Kamailio not running"

echo

#minfo "check with ’ps axw | $EGREP kamailio’"

exit 1

fi

}

Queste sono le funzioni comuni ai due script di avvio.

Creaimo poi lo script di avvio kamailio1.sh contenente le seguenti righe:


#!/bin/bash

#

## Init script for kamailio

## With this script you can run more kamailio instances

## N.B. Remember to generate kamailio configuration file

## (i.e. kamailio3.cfg) in /usr/local/etc/kamailio/

#

#

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

### Script configuration parameters

#

KAMAILIO="kamailio1"

PID_FILE="/var/run/kamailio1.pid"

CONFIG_FILE="/usr/local/etc/kamailio/kamailio1.cfg"

MYLIBDIR="."

VERBOSE=1 # 1-Print debug messages

# 0-Don’t print debug messages

#NOHLPRINT=1 # Decomment for not colored text

#

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

### load base functions

#


if [ -f "$MYLIBDIR/kamailio.base" ]; then

. "$MYLIBDIR/kamailio.base"

else

echo -e "Cannot load core functions

’$MYLIBDIR/kamailio.base’ - exiting ...\n"

exit -1

fi

#

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

### Parameters check

#

if [ $# -ne 1 ]

then

echo

print_usage

echo

exit 1

fi

#

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

### dispatcher

#

case $1 in

start)

openser_start


;;

stop)

openser_stop

;;

restart)

openser_stop

sleep 3

openser_start

;;

*)

echo

print_usage

echo

;;

esac

Notiamo che lo script contiene tre variabili




che riferiscono alla prima istanza di Kamailio.

Creaiamo, ora, un file identico ma nominato kamailio2.sh e modifichiamo le

suddette variabili con





riferendoci cosı alla seconda istanza di Kamailio.

Possiamo ora far partire le due istanze di Kamailio digitando i seguenti

comandi:

./kamailio1.sh start

./kamailio2.sh start

Per fermare le istanze:

./kamailio1.sh stop

./kamailio2.sh stop

Per riavviare le due istanze:

./kamailio1.sh restart

./kamailio2.sh restart

Appendice B

Modulo di presenza modificato

In questa appendice descriviamo come installare e configurare il modulo di

presenza da noi modificato. Per farlo dobbiamo:

• compilare il modulo di presenza modificato;

• installare il modulo di presenza modificato;

• configurare il modulo di rpesenza modificato.

B.1 Compilazione ed installazione

Per compilare ed installare il modulo di presenza modificato, dobbiamo:

• entrare nella cartella presence mod ;

• compilare i sorgenti con lo strumento make;

• copiare il modulo presence.so nella cartella modules/presence di Ka-

mailio sostituendo quello esistente.

Iniziamo dunque spostandoci nella cartella presence mod e lanciando il

comando make:

81

APPENDICE B. MODULO DI PRESENZA MODIFICATO 82

cd /path/presence_mod/

make

terminata la compilazione, copiamo il modulo presence.so nella cartella

modules/presence di Kamailio sostituendo quello gia esistente:

cp /path/presence_mod/presence.so

/usr/local/lib/kamailio/modules/presence.so

Abbiamo cosı installato il modulo di presenza modificato.

B.2 Configurazione

Per configurare il modulo di presenza modificato, e necessario modificaze

il file di configurazione di Kamailio nella cartella /usr/local/etc/kamailio/.

Se abbiamo installato piu istanze di Kamailio sulla stessa macchina come

descritto in appendice A.4, dobbiamo modificare il file di configurazione di

ogni istanza. Un esempio di file di configurazione e il seguente:

#

# $Id$

#

# simple quick-start config script - Stand-alone presence server

#

# ----------- global configuration parameters -------------------

debug=1 # debug level (cmd line: -dddddddddd)

fork=yes


log_stderror=no # (cmd line: -E)

children=4

log_facility=LOG_LOCAL0

listen=127.0.0.1

port=5060

dns=no

rev_dns=no

# ------------------ module loading -----------------------------

#set module path

mpath="/usr/local/lib/kamailio/modules/"

loadmodule "db_mysql.so"

loadmodule "sl.so"

loadmodule "maxfwd.so"

loadmodule "textops.so"

loadmodule "tm.so"

loadmodule "rr.so"

loadmodule "presence.so"

loadmodule "presence_xml.so"

loadmodule "avpops.so"

loadmodule "mi_fifo.so"

# ----------------- setting module-specific parameters ----------


# -- rr params --

# add value to ;lr param to make some broken UAs happy

modparam("rr", "enable_full_lr", 1)

# -- presence params --

modparam("presence|presence_xml", "db_url",

"mysql://openser:openserrw@localhost/openser")

modparam("presence_xml", "force_active", 1)


modparam("presence", "max_publ", 1500)

modparam("presence", "max_publ_pres", 100)

modparam("presence", "intervallo_timer", 60)

modparam("presence", "max_sub", 2500)

modparam("presence", "interval", 10)

modparam("presence", "max_watchers", 2000)

modparam("presence", "max_watchers_pres", 1000)

modparam("presence", "soglia_privileg", 100)

modparam("mi_fifo", "fifo_name", "/tmp/kamailio_fifo_presence")

modparam("presence", "fallback2db", 0)


# ------------------------- request routing logic --------------

# main routing logic

route{

# initial sanity checks -- messages with

# max_forwards==0, or excessively long requests

if (!mf_process_maxfwd_header("10")) {

sl_send_reply("483","Too Many Hops");

exit;

};

if (msg:len >= 2048 ) {

sl_send_reply("513", "Message too big");

exit;

};

if (!is_method("SUBSCRIBE|PUBLISH")) {

sl_send_reply("488", "Not Acceptable Here");

exit;

}

# presence handling

if (! t_newtran())

{

sl_reply_error();

exit;


};

if(is_method("PUBLISH"))

{

handle_publish();

t_release();

}

else

if( is_method("SUBSCRIBE"))

{

handle_subscribe();

t_release();

};

exit;

}

Con le istruzioni modparam(...) andiamo a modificare il valore di alcuni

parametri interni ai vari moduli.

Notiamo che, in questo file di esempio, i vari parametri del modulo di presenza

modificato sono settati come segue:

• max publ = 1500: si accettano al massimo 1500 pubblicazioni nell’in-

tervallo di tempo ‘interval’;

• max publ pres = 100: se un presentity invia meno di 100 pubbli-

cazioni nell’intervallo ‘interval’, allora in corrispondenza di ognuna ven-

gono inviate le varie notifiche ai watcher, altrimenti le notifiche vengono

inviate dopo un tempo ‘intervallo timer’;


• intervallo timer = 60: tempo di attesa in secondi dopo cui inviare le

notifiche ai watcher nel caso in cui la frequenza di pubblicazione di un

presentity superi la soglia ‘max publ pres’;

• max sub = 2500: si accettano al massimo 2500 sottoscrizioni nell’in-

tervallo di tempo ‘interval’;

• interval = 10: intervallo di 10 secondi entro cui verificare il numero di

PUBLISH e SUBSCRIBE ricevuti;

• max watchers = 2000: si accettano al massimo 2000 watcher attivi

su questo server;

• max watchers pres = 1000: si accettano al massimo 1000 watcher

attivi per ogni presentity su questo server;

• soglia privileg = 100: se un presentity invia almeno 100 PUBLISH

in un’ora, allora viene considerato “privilegiato”.

Bibliografia

[1] JAIN. http://java.sun.com/products/jain/.

[2] JAIN-SIP. https://jain-sip.dev.java.net/.

[3] Kamailio (openser). http://www.kamailio.org.

[4] SIPp. http://sipp.sourceforge.net/.

[5] M. Day, Lotusa, J. Rosenberg, dynamicsoft, H. Sugano, and Fujitsu. A

model for presence and instant messaging, February 2000.

[6] M. Handley, ACIRI, H. Schulzrinne, Columbia U., E. Schooler, CalTech,

J. Rosenberg, and Bell Labs. SIP: Session Initiation Protocol, March

1999.

[7] J. Rosenberg and dynamicsoft. A presence event package for the session

initiation protocol (sip), August 2004.

[8] J. Rosenberg and dynamicsoft. A watcher information event template-

package for the session initiation protocol (sip), August 2004.

[9] J. Rosenberg, dynamicsoft, H. Schulzrinne, Columbia U., G. Camarillo,

Ericsson, A. Johnston, WorldCom, J. Peterson, Neustar, R. Sparks,

dynamicsoft, M., ICIR, E. Schooler, and AT&T. SIP: Session Initiation

Protocol, June 2002.

88

BIBLIOGRAFIA 89

[10] J. Rosenberg and Cisco Systems. A data model for presence, July 2006.

[11] H. Schulzrinne, Columbia U., V. Gurbani, Lucent, P. Kyzivat, J. Rosen-

berg, and Cisco. Rpid: Rich presence extensions to the presence

information data format (pidf), July 2006.

[12] Ron Shacham and Henning Schulzrinne. Compisition for enhanced sip

presence.

[13] H. Sugano, S. Fujimoto, Fujitsua, G. Klyne, Nine by Nine, A. Bateman,

VisionTech, W. Carr, Intel, J., and NeuStar. Presence information data

format (pidf), August 2004.

Kamailio: una modi ca per Load Balancing e QoS · 2010-09-22 · CAPITOLO 1. PRESENTAZIONE 5 1.2...

Documents

Transcript of Kamailio: una modi ca per Load Balancing e QoS · 2010-09-22 · CAPITOLO 1. PRESENTAZIONE 5 1.2...