Capitolo 2
Installazione e configurazione di
OpenIMSCore
In questo lavoro di tesi, è stato adoperato il software opensource OpenIMS per
implementare la struttura basilare di una architettura IMS.
Open Source IMS Core [22] è un software per il test dell’architettura IMS creato da
Fraunhofer Institute FOKUS. Gli sviluppatori di OpenIMSCore sottolineano che
OpenIMSCore non è destinato a diventare un prodotto commerciale. Il suo unico
scopo è quello di fornire una piattaforma IMS di riferimento per l'implementazione
della tecnologia IMS e per la sperimentazione di prototipi per scopi di ricerca.
Questo obiettivo ha inoltre motivato la decisione di rilasciare il codice
dell’applicativo sotto licenza GPL.
FOKUS ha sviluppato una piattaforma stabile che implementa le funzioni basilari
dell’architettura IMS. Ultimamente, la loro attenzione si sta focalizzando
58
sull’implementazione di applicativi opensource (Application Server), basati sugli
standard della IETF e di altri organi di standardizzazione.
L’Open Source IMS Playground@FOKUS è un ambiente opensource testbed in cui
implementare le funzionalità introdotte dagli standard IMS .
L’Open IMS Playground include i seguenti componenti:
Open Source IMS Core: è il cuore dell’Open IMS Playground e si compone di:
o Home Subscriber Server (HSS) – "FHoSS"
o Call Session Control Functions (CSCFs)
Open IMS Client – "OpenIC" : un client che gira sui terminali e apparati fissi e
mobili. Esso è disponibili in Java e .NET.
Open IMS SIP AS – "SIPSEE": è un SIP Application Server che fornisce un
ambiente di servizi convergenti SIP e HTTP per la creazione di nuovi servizi;
Parlay X Gateway – "OCS-X": il gateway fornisce agli sviluppatori le
interfacce API Parlay X Web Services utili per la creazione di nuovi servizi;
IMS Management: implementa il sistema di gestione della rete IMS al fine di
monitorare e controllare il funzionamento dei componenti cuore della
piattaforma IMS;
XML Document Management Server (XDMS): genera delle informazioni
accessibili per l’attivazione di servizi in riferimento ad un determinato
utente;
Presence Server: fornisce un servizio di presence per molteplici applicazioni
quali Instant Messaging, Push to Talk over Cellular, Video Calls/Conferences
e altri.
GBA - Generic Bootstrapping Architecture: abilita un sistema di
autenticazione forte (strong authentication);
59
PoCCA - Policy and Charging Control Architecture: fornisce i servizi di
controllo e gestione della risorse in base alle Policy e ai contratti stretti con
gli utenti [22].
1
Introduzione ad OpenIMSCore
Open Source IMS Core si compone di Call Session Control Functions (CSCFs), gli
elementi principali per il routing di messaggi di segnalazione all’interno della rete
IMS, e un Home Subscriber Server (HSS) per gestire i profili utente e le relative
regole di routing. I CSCF (Proxy, Interrogating, e Service) sono stati sviluppati da
FOKUS come estensioni del SIP Express Router (SER). Ma dal momento che anche la
funzionalità base di routing di messaggi di segnalazione in IMS richiede informazioni
look-up in un HSS. Per questo motivo, il FOKUS Home Subscriber Server (FHoSS) è
entrato a far parte del progetto OpenIMSCore.
Il progetto OpenIMSCore fornisce l’interfaccia 3GPP IMS Service Control (ISC) che
permette agli sviluppatori di usufruire delle funzioni di routing, delle funzioni di
applicazione dei trigger e altre funzioni ad essa legate [22].
In figura 2.1 viene presentata l’architettura IMS implementata dal progetto
OpenIMSCore.
60
Figura 2.1 – Architettura IMS implementata dal progetto OpenIMSCore
Sia i moduli CSCF che il FHoSS sono stati rilasciati sotto licenza GNU General Public
License v.2.
1.1
Open IMS Call Session Control Functions – CSCFs
Anche se l'IMS si basa su specifiche IETF, il protocollo SIP richiede determinate
estensioni per essere utilizzato in un ambiente IMS. Il principale requisito per
OpenIMS è stato quello di fornire un insieme di componenti base di IMS che
consentiranno lo sviluppo di altri componenti che si può poggiano su quest’ultimi.
L'obiettivo principale è quello di implementare le funzionalità CSCF richieste dalle
specifiche Release 6 dello standard 3GPP IMS.
61
Gli Open IMS CSCF sono costruiti su SIP Express Router (SER), che può agire come
SIP Registrar, SIP Proxy o Redirect Server ed è in grado di gestire la segnalazione di
di migliaia di chiamate al secondo. Ha una struttura modulare che permette di
estendere le funzionalità. Ogni CSCF entità della OpenIMSCore è stata
implementata come un modulo SER caricabile dinamicamente che aggiunge al SER
le operazioni richieste in modo che possa agire in base alle specifiche tecniche
3GPP. I moduli sono in grado di processare i dati in parallelo e mantenere le
informazioni di stato.
Un altro requisito per la CSCF è stato quello di mantenere il più possibile le
prestazioni del SER. Avendo SER ottenuto un vasto consenso nel mondo SIP,
diventando quasi uno standard per le sue prestazioni, l'OpenIMS CSCF ne ha
ereditato le stesse prestazioni [22].
1.1.1 P-CSCF
Il modulo P-CSCF svolge la funzione di firewall nella rete IMS: solo i terminali
registrati possono inviare messaggi all'interno della rete IMS. Inoltre, il P-CSCF
autentica gli utenti. Per questo, a seguito della registrazione, il P-CSCF stabilisce
canali garantiti individualmente per ogni User Endpoint (UE) e per ogni servizio. Per
tenere traccia degli utenti registrati, presenta un Registrar invertito, che viene
aggiornato attraverso la cattura dei messaggi del processo di registrazione. I dati
effettivi sono conservati in una tabella di hash per consentire un rapido recupero
delle informazioni.
Per la segnalazione di chiamate il P-CSCF genera un vettore di tariffazione e
inserisce gli identificatori di rete e di percorso che sono necessari per la corretta
ulteriore elaborazione dei messaggi SIP. Dopo il successo del processo di
registrazione a una rete IMS, i successivi messaggi sono trasmessi basandosi sulle
informazioni del DNS scambiante all’interno della rete IMS domestica. Per quanto
riguarda le questioni di NAT per la segnalazione SIP è in grado di agire come un
62
router in entrambe le reti. Inoltre, i moduli NAT Traversal sono stati adattati per
meccanismi di storage delle locazioni di uno specifico utente [22].
In figura 2.2 è presente la struttura del P-CSCF implementato dal progetto
OpenIMSCore.
Figura 2.2 – Struttura del modulo P-CSCF implementato dagli sviluppatori FOKUS
1.1.2 I-CSCF
Il Interrogating-CSCF (I-CSCF) ha il ruolo di un proxy stateless che, utilizzando
l'identità pubblica del chiamante o del chiamato, interroga l’Home Subscriber
Server (HSS) e si basandosi sulle risposte inoltra il messaggio al corretto S-CSCF. Il
progetto OpenIMSCore ha implementato l'interfaccia Cx tra l’I-CSCF e l’HSS.
Pertanto, supporta i comandi Diameter necessari per individuazione dell’S-CSCF
assegnato all’utente o per selezionare, sulla base dei dati di performance, un nuovo
S-CSCF e verificare le identità e le autorizzazioni di roaming così come specificato
nel 3GPP TS 29.228 [11].
Dopo aver ricevuto una risposta positiva ai messaggi Diameter inviati, l’I-CSCF
inoltra i messaggi SIP in una modalità transazionale. È stato ottimizzato per
aumentare la velocità di memorizzazione delle informazioni riducendole allo stretto
necessario. Per proteggere la rete, I-CSCF ha le funzioni di firewall che permette
63
l’invio di messaggi di segnalazione provenienti da reti di fiducia attraverso il
Network Domain Security (NDS) [22].
Le caratteristiche dell’I-CSCF sono:
Pieno supporto all’interfaccia Diameter Cx (LIR, UAR);
Selezione dell’S-CSCF basata sulle capability degli utenti;
Supporto agli header Visited-Network-ID e alla verifica dei diritti di roaming;
Capacità di nascondere la topologia di rete (THIG);
Network Domain Security (NDS).
In figura 2.3 è presente la struttura dell’I-CSCF implementato dal progetto
OpenIMSCore [22].
Figura 2.3 – Struttura del modulo I-CSCF implementato dagli sviluppatori FOKUS
1.1.3 S-CSCF
L’S-CSCF implementato dagli sviluppatori FOKUS comunica con l'HSS utilizzando
Diameter (per l'interfaccia Cx) al fine di recuperare i vettori di autenticazione, di
64
aggiornare informazioni di registrazione e di scaricare i profili utente, come
specificato nel 3GPP TS 23.228 [11]. L’S-CSCF può modificare il profilo utente
attraverso l’initial Filter Criteria (iFC) per far rispettare le specifiche di routing SIP.
Esso implementa il supporto per la realizzazione del IMS Digest AKA (Authentication
and Key Agreement) versione 1. Piuttosto che la generazione di vettori di
autenticazione esso si basa sulla HSS confrontando i valori ricavati dall’HSS con
quelli calcolati nella UE.
Per ottenere tempi di risposta rapidi, il Registar del S-CSCF ha una struttura
complessa basata su tabelle hash. L’informazione che è necessario per identificare
un utente relativo ad un determinato apparato (User Equipment) è memorizzato
nell’S-CSCF, e viene utilizzato successivamente per il routing della chiamata.
Le caratteristiche dell’OpenIMS S-CSCF sono [22]:
Supporto all’interfaccia Diameter Cx (MAR, RAS, PPR, RST);
Autenticazione attraverso AKAv1-MD5, AKAv2-MD5 e MD5;
Supporto agli header Service-Route;
Supporto agli header Path;
Supporto agli header P-Asserted-Identity;
Supporto agli header Visited-Network-ID;
Download degli User Profile dall’HSS;
Trigger degli intial Filter Criteria;
Supporto all’interfaccia ISC verso Application Server;
Server di notifica di eventi "Reg" con restrizioni di accesso;
Dialogo statefulness.
In figura 2.4 è presente la struttura dell’S-CSCF implementato dal progetto
OpenIMSCore.
65
Figura 2.4 - Struttura del modulo S-CSCF implementato dagli sviluppatori FOKUS
1.1.4 Moduli di OpenIMS CSCF
I moduli CSCF possono processare in parallelo le informazioni sullo stato. Inoltre, vi
è una particolare attenzione verso la scalabilità sia per la distribuzione del carico
che per la quantità di dati. I principali moduli di OpenIMS CSCFs sono:
CDiameterPeer Module (cdp): questo modulo è utilizzato per il routing nel
realm, dobbiamo specificare ogni volta il FQDN (Fully Qualified Domain
Name) dell’ host di destinazione quando il suddetto modulo viene utilizzato.
Si suppone che sia possibile instaurare comunicazioni Diameter efficenti da e
verso SER.
IMS Service Control Module (isc): è utilizzato per fornire il supporto per
l'interfaccia ISC tra il Serving-CSCF e l’Application Server. Per poterlo
utilizzare, abbiamo bisogno che il Serving-CSCF Module (scscf) sia stato
caricato in quanto esso utilizza il registrar e il filtro initial Filter Criteria.
Proxy-CSCF Module (pcscf): il Pcscf Module è utilizzato per fornire le
funzionalità necessarie per un Proxy-CSCF.
66
Interrogating-CSCF Module (icscf): fornisce le funzionalità richieste per uno
Interrogating-CSCF. Abbiamo bisogno che il Module cdp sia stato caricato in
quanto esso comunica con la Home Subscriber Server tramite l’interfaccia
Diameter.
Serving-CSCF Module (scscf): fornisce le funzionalità richieste da un ServingCSCF. Per poterlo utilizzare, il Module cdp deve essere caricato. Infatti, il
scscf comunica con HSS tramite l’interfaccia Diameter Cx.
SIP-to-IMS Gateway Module (sip2ims): essa fornisce il servizio di NAT Helper
per i client SIP. Ha le funzionalità di traduzione per permette ai client SIP
Endpoints di accedere all'OpenIMSCore tramite il Proxy-CSCF. L'open source
IMS SIP2IMS gateway consente la trasformazione di messaggi IETF SIP in
messaggi compatibili con IMS. Esso traduce i messaggi d’autenticazione
Digest MD5 in messaggi AKA compatibili con IMS [22].
1.2
FOKUS Home Subscriber Server (FHoSS)
Open Source Core IMS sarebbe incompleto senza una Home Subscriber Server.
FOKUS ha sviluppato un proprio prototipo HSS, la FOKUS HSS (FHoSS), che è
interamente scritto in Java e si basa su software Open Source. I profili utenti e le
configurazioni delle entità IMS sono memorizzate all'interno di un database MySQL.
Il FHoSS è indirizzato principalmente verso la conformità, piuttosto che le
prestazioni. Essa è soprattutto un configuratore per il Database Management
System e per le interfacce Diameter tra HSS e CSCF e tra HSS e gli Application
Server.
67
Figura 2.5 – Interfacce Diameter di comunicazione con le altre entità IMS
Dalla figura 2.5, possiamo constatare che gli attori che comunicano con il FHoSS
sono gli Application Server (AS) che ospitano e eseguono i servizi in un ambiente
IMS, il Security Domain e i Call State Control Function (CSCF). FHoSS memorizza le
configurazioni degli utenti presenti sugli Application Server attraverso l’interfaccia
Sh e comunica con i CSCF attraverso l’interfaccia Cx. Inoltre, si connette con il
Security Domain tramite interfaccia Zh [22].
FHoSS estende il progetto Open Source Open Diameter e implementa le funzionalità
specifiche dell’interfaccia Cx e Sh basate su Java. Il FHoSS memorizza i profili utente
per mezzo delle informazioni di autenticazione e autorizzazione e fornisce
informazioni di stato con un servizio di notifica agli Application Server attraverso
l’interfaccia Sh *24+.
In figura 2.6 è presente la struttura dell’FHoSS implementato dal progetto
OpenIMSCore.
68
Figura 2.6 - Struttura del modulo FHoSS implementato dagli sviluppatori FOKUS
1.2.1 Interface Layer
Il nucleo della FHoSS è il HssDiameterStack. Utilizza DiameterPeer per inviare le
richieste alle altre entità e recupera le richieste e le risposte attraverso il
CommandListener. Ci sono tre interfacce utilizzate in FHoSS: Sh, Cx, e Zh. Esse
possono essere trovate nel pacchetto de.fhg.fokus.cx, nel pacchetto de.fhg.fokus.sh
e nel pacchetto de.fhg.fokus.zh . Per ogni interfaccia vi è una implementazione
diretta.
Questa
implementazione
può
essere
ritrovata
nel
pacchetto
de.fhg.fokus.hss.server e nei successivi pacchetti. Per ogni metodo dell’interfaccia vi
sono delle classi di operazioni presenti nel pacchetto op.
Queste operazioni saranno chiamate dalle implementazioni delle interfaccia e, a sua
volta, essa sarà chiamata dai comandi Diameter. Per ogni interfaccia, a ogni metodo
è associata ad un certo numero di richieste Diameter. Tali richieste sono state
realizzate dall’implementazioni delle classi CommandAction e CommandListener.
69
Per ogni comando inviato attraverso i tre package (de.fhg.fokus.zh, de.fhg.fokus.cx
e de.fhg.fokus.sh), che saranno ricevuti dal Hss esiste un programma listener. Le
richieste saranno inviate ai rispettivi metodi usati dall'interfaccia [24].
1.2.2 Data Access Layer (DAL)
I dati degli utenti sono memorizzati in un database del FHoSS. Il framework
Hibernate è stato utilizzato per la costruzione del Data Access Layer. Esso è utile per
modificare il sistema del database. Le relative classi di dati si trovano nel pacchetto
de.fhg.fokus.hss.model.
Figura 2.7 – Struttura dei database presenti nel modulo FHoSS
I dati dell’utente sono mantenuti all'interno di un database MySQL. Tuttavia, vi è un
Data Access Layer (DAL), che è basato su JDBC (Java DataBase Connectivity), un
connettore per database che consente l'accesso alle basi di dati da qualsiasi
programma scritto con il linguaggio di programmazione Java, indipendentemente
dal tipo di DBMS utilizzato.
70
1.2.3 Graphical User Interface (GUI)
Per gestire il FHoSS, è stata implementata una interfaccia di gestione basata su una
interfaccia web. Questo fornisce una chiara struttura e la logica separazione dei task
connessi alla GUI. L’implementazione della GUI si trova nel pacchetto
de.fhg.fokus.hss.form e de.fhg.fokus.hss.action. Il rendering è costituito da molte
Java Server Page, che possono essere trovate nella cartella src-web [24].
2
Installazione e configurazione di OpenIMSCore
Adesso verrà presentata una guida di installazione e configurazione di
OpenIMSCore. Successivamente, verrà configurata l’OpenIMSCore in base alle
specifiche imposte da questo lavoro di tesi.
L’installazione di OpenIMSCore si compone delle seguenti fasi:
Installazione dei prerequisiti;
Installazione e configurazione di FHoSS;
Installazione e configurazione dei CSCF;
Configurazione del BIND DNS;
Attivazione delle entità IMS;
Configurazione degli utenti.
2.1
Installazione dei prerequisiti
Come si può notare dalla figura 2.8, prima di installare i componenti chiave di
OpenIMS, dobbiamo rispettare determinati prerequisiti hardware, software e di
rete.
71
Figura 2.8 – Setup del sistema OpenIMSCore
Per l'ambiente di hardware, abbiamo bisogno di un desktop Linux. Usiamo Ubuntu
7.10 scaricabile dal sito http://www.ubuntu.com/.
Inoltre, al fine di ottenere buone prestazioni, abbiamo bisogno di diversi gigabyte di
RAM e di una CPU performante.
Per quanto riguarda l'accesso alla rete, è sufficiente avere un indirizzo pubblico.
Al fine di garantire il buon funzionamento del sistema, sono necessari 100 MB di
spazio su disco. Inoltre sono necessari i software Subversion (o Svn), Gcc 3/4, JDK1.5
e ant.
Inoltre viene utilizzato MySQL come un sistema di gestione di database (DBMS)
all’interno di FHoSS, I-CSCF e altre funzioni che richiedono un DBMS. Sono
obbligatori i software libxml2 e libmysql. Il kernel Linux 2.6 e ipsec-tools, che viene
utilizzato per setkey, sono necessari per utilizzare IPSec SA. Inoltre, usiamo bind 9
come server DNS.
Una volta che tutti i requisiti sono stati soddisfatti, possiamo cominciare a installare
e configurare il FHoSS, che è la componente fondamentale di OpenIMS.
72
2.2
Installazione e configurazione di FHoSS
L’installazione e la configurazione di FHoSS si basa sui seguenti passi:
Scaricare il codice sorgente;
Compilare il codice sorgente;
Configurare il database;
2.2.1 Scaricare il codice sorgente
Possiamo
scaricare
il
codice
sorgente
http://svn.berlios.de/svnroot/repos/openimscore/FHoSS/trunk
dal
sito
utilizzando
Subversion. Il codice sorgente è pre-configurato per lavorare da uno percorso
standard.
Inzialmente creiamo la directory “OpenIMSCore” nella cartella “/opt/” e ci entriamo
dentro. Successivamente, creiamo la directory FHoSS e scarichiamo il codice
sorgente.
Le operazioni precedente descritte vengono tradotte dai seguenti comandi:
mkdir /opt/OpenIMSCore
cd /opt/OpenIMSCore
mkdir FHoSS
svn checkout http://svn.berlios.de/svnroot/repos/openimscore/FHoSS/trunk FHoSS
2.2.2 Compilare il codice sorgente
Prima di compilare il codice sorgente, dobbiamo accertarci di aver installato la JDK ≥
1.5 e di aver settato la variabile d’ambiente JAVA_HOME. Successivamente, compiliamo
e installiamo FHoSS utilizzando Ant.
Dobbiamo inizialmente eseguire il comando gen di Ant, per generare le classi di
dati:
ant gen
Dopo compiliamo i binari:
ant compile
e infine attraverso il comando deploy completiamo l’installazione di FHoSS:
ant deploy
73
Infine
modifichiamo
il
file
ZhDataType.xsd
presente
nella
cartella
“/opt/OpenIMSCore/FHoSS/xsd/”:
vi /opt/OpenIMSCore/FHoSS/xsd/ZhDataType.xsd
e sostituiamo la linea
schemaLocation="http://www.w3.org/2001/xml.xsd"/>
con
schemaLocation="file:///opt/OpenIMSCore/FHoSS/xsd/xml.xsd"/>
2.2.3 Configurare il database
Abbiamo bisogno di un database, al fine di utilizzare FHoSS. Possiamo trovare due
script sql per il database MySQL nella directory root della nostra installazione.
Utiliziamo questi script per creare un nuovo database MySQL e per popolarlo con i
valori di default.
Per la creazione del database e delle tabelle lanciamo il comando:
mysql –uroot –p < hss_db.sql
Per creare i due utenti demo e settare i valori iniziali per i Service Profile lanciamo:
mysql –uroot –p < user_data.sql
Adesso FHoSS è stato installato con una configurazione di default. Successivamente,
verrà configurato in base alle richieste imposte da questo lavoro di tesi.
2.3
Installazione e configurazione dei CSCF
L’installazione e la configurazione dei CSCF si basa sui seguenti passi:
Scaricare il codice sorgente;
Compilare il codice sorgente;
Configurare il database.
2.3.1 Scaricare il codice sorgente
Possiamo
scaricare
il
codice
sorgente
http://svn.berlios.de/svnroot/repos/openimscore/ser_ims/trunk
dal
sito
utilizzando
74
Subversion. Il codice sorgente è pre-configurato per lavorare da uno percorso
standard.
Inzialmente creiamo la directory “ser_ims” nella cartella “/opt/OpenIMSCore” e
scarichiamo il codice sorgente.
Le operazioni precedente descritte vengono tradotte dai seguenti comandi:
mkdir ser_ims
svn checkout http://svn.berlios.de/svnroot/repos/openimscore/ser_ims/trunk
ser_ims
2.3.2 Compilare il codice sorgente
La compilazione del codice sorgente avviene lanciando il comando
cd ser_ims
make install-libs all
cd ..
Questa operazione può completarsi dopo diversi minuti.
2.3.3 Configurare il database
Abbiamo bisogno di settare correttamente il database, al fine di permette al
modulo dell’I-CSCF di accedere al database:
mysql –uroot –p < ser_ims/cfg/icscf.sql
2.4
Configurazione del BIND DNS
Dobbiamo adesso configurare il server DNS BIND che è stato installato durante
l’installazione dei prerequisiti software.
All’interno del codice sorgente è presente un file “open-ims.dnszone” nella cartella
“/opt/OpenIMSCore/ser_ims/cfg/” utile per la configurazione del server BIND.
Ricordo che la configurazione base di OpenIMSCore impone che l’installazione delle
4 funzioni di IMS avvenga sulla stessa macchina e che ogni entità CSCF sia in ascolto
sull’interfaccia di loopback e su una porta UDP diversa:
P-CSCF: porta UDP 4060
I-CSCF: porta UDP 5060
75
S-CSCF: porta UDP 6060
In appendice B è presente il file “open-ims.dnszone” contenuto nel codice sorgente.
Copiamo il file “open-ims.dnszone” nella cartella “/etc/bind”:
cp /opt/OpenIMSCore/ser_ims/cfg/open-ims.dnszone /etc/bind/
Aggiungiamo al file “/etc/bind/named.conf.local” le seguenti righe:
zone "open-ims.test" {
type master;
file "/etc/bind/open-ims.dnszone";
};
Riavviamo il server DNS con il seguente comando:
/etc/init.d/bind9 restart
Dobbiamo fare in modo che le entità OpenIMSCore possano contattare il server
DNS BIND. Per questo motivo editiamo il file “/etc/resolv.conf” aggiungendo le
seguenti righe:
search open-ims.test
nameserver 127.0.0.1
2.5
Attivazione delle entità IMS
Per semplificare l’esecuzione delle entità, possiamo copiare i file “pcscf.cfg”,
“pcscf.sh”, “icscf.cfg”, “icscf.xml”, “icscf.sh”, “scscf.cfg”, “scscf.xml” e “scscf.sh”
nella cartella “/opt/OpenIMSCore”:
cp /opt/OpenIMSCore/ser_ims/cfg/*.cfg /opt/OpenIMSCore
cp /opt/OpenIMSCore/ser_ims/cfg/*.xml /opt/OpenIMSCore
cp /opt/OpenIMSCore/ser_ims/cfg/*.sh
/opt/OpenIMSCore
76
Successivamente, possiamo lanciare i 4 script di shell che rappresentano le 4 entità
IMS:
./pcscf.sh
./icscf.sh
./scscf.sh
./fhoss.sh
2.6
Configurazione degli utenti
Si può accedere alla console di gestione usando un web browser e inserendo
l’indirizzo http://localhost:8080/hss.web.console. Dopo essersi loggato con l’utente
“hssAdmin” e la password “hss”, possiamo navigare all’interno del sistema di
gestione dell’architettura IMS.
Di default, sono stati creati due utenti IMS il cui Public User Identity è
sip:[email protected] e sip:[email protected]. Come si può notare, il realm nel
quale questi due utenti sono stati definiti è open-ims.test, il realm di default.
Ora vediamo come può essere creato un nuovo utente sfruttando l’interfaccia web
di gestione.
Supponiamo di voler creare un utente con le seguenti caratteristiche:
IMSU (IMS Subscription): davide
IMPI (IMS Private Identity): [email protected]
IMPU (IMS Public Identity): sip:[email protected]
Secret Key: davide
Come si può notare, l’utente creato ha un username davide e appartiene al realm di
default.
Nelle figure 2.9, 2.10 e 2.11 sono presenti gli screenshot dell’interfaccia web di
gestione per la creazione, rispettivamente, dell’IMSU, dell’IMPI e dell’IMPU
dell’utente davide.
77
Figura 2.9 – Screenshot dell’interfaccia web di gestione riguardante la creazione dell’IMSU
dell’utente davide
Dopo aver settato il Name (figura 2.9), possiamo opzionalmente associare all’utente
davide un Capabilities Set e un Preferred S-CSCF. Inoltre all’IMSU creato viene
associato il IMPI identity [email protected].
78
Figura 2.10 – Screenshot dell’interfaccia web di gestione riguardante la creazione dell’IMPI
dell’utente davide
Nell’interfaccia web (2.10), dobbiamo settare l’Identity e la Secret Key. Inoltre,
possiamo scegliere tra gli schemi di autenticazioni (Authentication Schemes) forniti
dal sistema OpenIMS quello che desideriamo utilizzare per quel determinato
utente. Infine, dobbiamo settare le associazioni della IMPI dell’utente con l’IMSU e
con l’IMPU dell’utente. Cosi come è stato descritto nel paragrafo 6.1.3 del capitolo
1, ad un IMSU possono essere associati più IMPI e ad un IMPI possono essere
associati più IMPU.
79
Figura 2.11 - Screenshot dell’interfaccia web di gestione riguardante la creazione dell’IMPU
dell’utente davide
Anche nella creazione dell’IMPU (figura 2.11), dobbiamo settare l’Identity, il Service
Profile, il IMPU Type, e dobbiamo associare all’IMPU la Visited-Network a cui
l’utente appartiene (nel nostro caso, open-ims.test), l’IMPI Identity e l’IMPU
Identity.
3
Configurazione personalizzata di OpenIMSCore
In questo lavoro di tesi è stata installata una configurazione personalizzata di
OpenIMSCore. In particolare, sono state create 4 macchine virtuali utilizzando il
software Vmware Server Edition installato su un PC HP Proliant con le seguenti
caratteristiche:
CPU: Intel Xeon CPU 3.40 GHz
Ram: 3 GB
80
SO: Microsoft Windows Server 2003 Service Pack 2
Le 4 macchine virtuali presentano le seguenti caratteristiche:
P-CSCF
o CPU: Intel Xeon CPU 3.40 GHz (condiviso)
o Ram: 512 MB
o SO: Ubuntu Linux 7.10 Gutsy Gibbon
o IP: 192.168.10.92
S-CSCF
o CPU: Intel Xeon CPU 3.40 GHz (condiviso)
o Ram: 512 MB
o SO: Ubuntu Linux 7.10 Gutsy Gibbon
o IP: 192.168.10.93
I-CSCF
o CPU: Intel Xeon CPU 3.40 GHz (condiviso)
o Ram: 512 MB
o SO: Ubuntu Linux 7.10 Gutsy Gibbon
o IP: 192.168.10.91
FHoSS
o CPU: Intel Xeon CPU 3.40 GHz (condiviso)
o Ram: 1024 MB
o SO: Ubuntu Linux 7.10 Gutsy Gibbon
o IP: 192.168.10.90
Su ogni macchina è stato installato e configurato OpenIMSCore, così come è stato
descritto nel paragrafo 2 del capitolo 2. Dato che intendiamo utilizzare un unico
server DNS che risolva i nomi, esso è stato installato sulla macchina FHoSS. Per
questo motivo, nella fase di installazione dei prerequisiti (paragrafo 2.1 del capitolo
81
2), il server bind non deve essere installato sulle macchine P-CSCF, S-CSCF e I-CSCF.
Al contrario, sulla macchina FHoSS bisogna installare il server bind ma non
configurarlo, così come era stato descritto nel paragrafo 2.4 del capitolo 2.
Inoltre, il realm utilizzato nella configurazione personalizzata è snodo.
La configurazione personalizzata di OpenIMSCore si basa sui seguenti passi:
Configurazione della macchina virtuale FHoSS;
Configurazione delle machine virtuali CSCF;
o Configurazione della macchina virtuale P-CSCF;
o Configurazione della macchina virtuale I-CSCF;
o Configurazione della macchina virtuale S-CSCF;
Configurazione personalizzata del BIND DNS.
In figura 2.12 è mostrata la topologia della rete IMS configurata.
192.168.10.90
Legend
SIP
Diameter
TCP
3868
192.168.10.92
TCP
3868
HSS
192.168.10.92
192.168.10.91
TCP
3869
UDP
4060
P-CSCF
UDP
5060
UDP
5060
I-CSCF
TCP
3870
UDP
6060
S-CSCF
Realm snodo
Figura 2.12 – Topologia di rete IMS post-configurazione
82
3.1
Configurazione della macchina virtuale FHoSS
La configurazione di FHoSS può essere eseguita attraverso la modifica dei seguenti
file:
"DiameterPeerHSS.xml": in questo file possiamo configurare le informazioni
dei CSCF e del FHoSS quali FQDN, Realm, Acceptor Port e Authorized
Identifier.
"hibernate.properties": si possono configurare le informazioni relative
all’accesso al database MySql; implicitamente è configurato per connettere
al database MySql all’indirizzo 127.0.0.1 e la porta 3306). Altri parametri
modificabili
sono
hibernate.connection.url=jdbc:mysql://127.0.0.1:3306/hss_db
hibernate.connection.username=hss e hibernate.connection.password=hss.
"hss.properties": i parametri modificabili sono l’indirizzo e la porta sul quale
il server Tomcat è in ascolto (e.g. host=localhost, port=8080) e il relativo
percorso
dell’interfaccia
web
del
sistema
di
gestione
(e.g.
appPath=/hss.web.console). Altri parametri sono operatorId, amfId e
defaultPsiImpi.
"log4j.properties": Contiene le informazioni utili per configurare il logger. Le
più importarti informazioni presenti sono il percorso di output dei file di log
e il livello di logging desiderato.
I
file
appena
descritti
sono
contenuti
nella
cartella
“/opt/OpenIMSCore/FHoSS/deploy”. Inoltre è presente la configurazione di default
dei suddetti file in appendice B.
Nella configurazione della macchina virtuale FHoSS, all’interno del file
DiameterPeerHSS.xml sono state apportate le seguenti modifiche, indicate in
grassetto:
83
<?xml version="1.0" encoding="UTF-8"?>
<!-- HSS Server config -->
<DiameterPeer
FQDN="hss.snodo"
Realm="snodo"
Vendor_Id="10415"
Product_Name="JavaDiameterPeer"
AcceptUnknownPeers="1"
DropUnknownOnDisconnect="1"
Tc="30"
Workers="4"
QueueLength="32"
>
<Peer FQDN="icscf.snodo" Realm="snodo" port="3869" />
<Peer FQDN="scscf.snodo" Realm="snodo" port="3870" />
<Acceptor port="3868" bind="192.168.10.90" />
<Auth
<Auth
<Auth
<Auth
<Auth
id="16777216"
id="16777216"
id="16777216"
id="16777217"
id="16777221"
vendor="10415"/><!-- 3GPP Cx -->
vendor="4491"/><!-- CableLabs Cx -->
vendor="13019"/><!-- ETSI/TISPAN Cx -->
vendor="10415"/><!-- 3GPP Sh -->
vendor="10415"/>
</DiameterPeer>
Da notare, nel parametro FQDN viene indicato l’hostname di FHoSS (nel nostro caso
hss.snodo), nel parametro Realm viene settato il valore snodo. Al contrario, nei
parametri Peer vengono settati i valori attraverso i quali FHoSS può inviare le
richieste Diameter: gli hostname delle entità I-CSCF e P-CSCF (icscf.snodo e
scscf.snodo) e le loro rispettive porte TCP (3869 e 3870). Infine nel parametro
Acceptor viene indicato l’indirizzo IP di FHoSS (192.168.10.90) e la porta su cui
vengono ricevuti i messaggi Diameter (TCP 3868).
Nel file “hss.proprieties” sono state apportate le seguenti modifiche, indicate in
grassetto:
# FOKUS HSS Properties file
#----------------------------------------------------------------------------------------------------------------------------------# host & port : specify the IP address and the port where Tomcat is listening,
e.g. host=192.168.10.90; port=8080;
host=192.168.10.90
port=8080
# Authentication properties
#----------------------------------------------------------------------------------------------------------------------------------# default operator and amf values
84
#----------------------------------------------------------------------------------------------------------------------------------# operator_id, as hex bytes, required length 32 byte,
# e.g. 00000000000000000000000000000000
operatorId=00000000000000000000000000000000
# amf_id: Default amf id as hex bytes, required length 4 byte, e.g. 0000
amfId=0000
# configuration parameters relating to Milenage algorithm
#----------------------------------------------------------------------------------------------------------------------------------# Enable or disable the use of AK in the Milenage algorithm; if this flag is
enabled,
#then is mandatory to be enabled also on the client side
USE_AK=true
# IND_LEN property - contains the number of bits assigned for the Index; it is
used in the generation process of new SQN values
# We are using SQN values which are not time based, as is specified here C.1.1.2,
C.1.2, C.2, C3.2 and C.3.4 of TS 33.102
# (SQN = SEQ || IND)
IND_LEN=5
# delta value, assuring the protection against wrap around counter in the USIM
delta=268435456
# L - limit on the difference between SEQ_MS (Mobile Station) and SEQ_HE (HSS)
L=32
# Sh-Settings
#---------------------------------------------------------------------------------------------------------------------------------# Enable or disable IFC Notification mechanism. If you need this feature please
enable it. However, be aware that this feature imply
#important time for processing as more validation is required every time after an
update (for entities as: IFC, TP, SPT, AS, SP_IFC),
# and could affect the web console interface response-ness.
iFC_NOTIF_ENABLED=false
Come abbiamo detto precedentemente, in questo file sono contenute le
informazioni riguardanti l’interfaccia web. In particolare, viene modificato l’indirizzo
IP o host (192.168.10.90) e lasciata inalterata la porta (TCP 8080).
I file modificati, con le rispettive modifiche, sono presenti in appendice B.
Una volta terminata la configurazione, bisogna riaggiornare il database seguendo la
procedura descritta 2.2.3 e 2.3.3 del capitolo 2.
3.2
Configurazione delle macchine virtuali CSCF
La configurazione dei CSCF può essere eseguita attraverso la modifica dei seguenti
file:
85
“pcscf.cfg”,
“scscf.cfg”,
“icscf.cfg”:
sono
i
file
di
configurazione
rispettivamente del P-CSCF, dell’S-CSCF e dell’I-CSCF. In questi file sono
definiti i moduli da caricare all’avvio delle entità. Inoltre si posso settare i
parametri di configurazione, quali l’autenticazione richiesta, l’abilitazione
dello scambio di messaggi IPSec o TLS, etc.
“pcscf.xml”, “scscf.xml”, “icscf.xml”: sono i file di configurazione dei canali di
comunicazione Diameter. Come nel caso del file DiameterPeerHSS.xml, i
parametri modificabili sono: FQDN, Realm, Acceptor Port e Authorized
Identifier.
La configurazione di default dei file precedentemente descritti è presente in
appendice B.
Ricordiamo che nel paragrafo 2.5 del capitolo 2, abbiamo copiato file “pcscf.cfg”,
“icscf.cfg”, “icscf.xml”,“scscf.cfg”, e “scscf.xml” nella cartella “/opt/OpenIMSCore”.
Successivamente verranno descritte le seguenti operazioni:
Configurazione della macchina virtuale P-CSCF;
Configurazione della macchina virtuale I-CSCF;
Configurazione della macchina virtuale S-CSCF;
3.2.1 Configurazione della macchina virtuale P-CSCF
Nella configurazione della macchina virtuale P-CSCF, all’interno del file “pcscf.cfg”
sono state apportate le modifiche, indicate in grassetto, presenti in appendice B.
Nelle modifiche apportate al file “pcscf.cfg” abbiamo utilizzato le seguenti
informazioni:
Indirizzo IP P-CSCF: 192.168.10.92
Realm: snodo
Nel file “pcscf.xml” apportiamo le seguenti modifiche, indicate in grassetto:
86
<?xml version="1.0" encoding="UTF-8"?>
<DiameterPeer
FQDN="pcscf.snodo"
Realm="snodo"
Vendor_Id="10415"
Product_Name="CDiameterPeer"
AcceptUnknownPeers="1"
DropUnknownOnDisconnect="1"
Tc="30"
Workers="4"
QueueLength="8"
>
<Peer FQDN="clf.snodo" Realm="snodo" port="3868"/>
<Acceptor port="3867" bind="192.168.10.92"/>
<Auth id="16777231" vendor="13019"/><!-- ETSI e2 -->
<DefaultRoute FQDN="clf.snodo" metric="10"/>
<!-- Realm Routing configuration - Uncomment and Edit!
<Realm name="snodo">
<Route FQDN="clf1.snodo" metric="10"/>
<Route FQDN="clf2.snodo" metric="20"/>
</Realm>
<Realm name="another.snodo">
<Route FQDN="clf3.snodo" metric="10"/>
<Route FQDN="clf2.snodo" metric="20"/>
</Realm>
<DefaultRoute FQDN="clf.snodo" metric="10"/>
<DefaultRoute FQDN="clf4.snodo" metric="20"/>
-->
</DiameterPeer>
Contrariamente dalla configurazione del file “DiameterPeerHSS.xml”, in questo caso
abbiamo impostato che la macchina virtuale P-CSCF, il cui indirizzo IP è
192.168.10.92, riceve le richieste Diameter dal clf.snodo attraverso la porta TCP
3867 e invia le richieste Diameter alla porta TCP 3868 del clf.snodo.
Il CLF è una funzione componente del sistema NASS (Network Attachment SubSystem) che si occupa dell’attachment dell’utente alla rete tramite:
Fornitura dinamica dell’indirizzo IP e di altri parametri di configurazione degli
apparati in sede di utente;
Autenticazione dell’utente, prima o durante la fase di allocazione
dell’indirizzo IP;
Autorizzazione dell’accesso alla rete su base profilo utente;
87
Configurazione della rete di accesso, su base profilo utente;
Location management (ad esempio, per gestire le chiamate di emergenza).
3.2.2 Configurazione della macchina virtuale I-CSCF
Nella configurazione della macchina virtuale I-CSCF, all’interno del file “icscf.cfg”
sono state apportate le modifiche, indicate in grassetto, presenti in appendice B.
Nelle modifiche apportate al file “icscf.cfg” abbiamo utilizzato le seguenti
informazioni:
Indirizzo IP I-CSCF: 192.168.10.91
Realm: snodo
Nel file “icscf.xml” apportiamo le seguenti modifiche, indicate in grassetto:
<?xml version="1.0" encoding="UTF-8"?>
<DiameterPeer
FQDN="icscf.snodo"
Realm="snodo"
Vendor_Id="10415"
Product_Name="CDiameterPeer"
AcceptUnknownPeers="1"
DropUnknownOnDisconnect="1"
Tc="30"
Workers="4"
QueueLength="8"
>
<Peer FQDN="hss.snodo" Realm="snodo" port="3868"/>
<Acceptor port="3869" bind="192.168.10.91"/>
<Auth id="16777216" vendor="10415"/><!-- 3GPP Cx -->
<Auth id="16777216" vendor="4491"/><!-- CableLabs Cx -->
<Auth id="16777216" vendor="13019"/><!-- ETSI/TISPAN Cx -->
<DefaultRoute FQDN="hss.snodo" metric="10"/>
<!-- Realm Routing configuration - Uncomment and Edit!
<Realm name="snodo">
<Route FQDN="hss.snodo" metric="10"/>
<Route FQDN="hss2.snodo" metric="20"/>
</Realm>
<Realm name="another.open-ims.test">
<Route FQDN="hss3.open-ims.test" metric="10"/>
<Route FQDN="hss2.open-ims.test" metric="20"/>
</Realm>
<DefaultRoute FQDN="hss.open-ims.test" metric="10"/>
<DefaultRoute FQDN="hss4.open-ims.test" metric="20"/>
-->
</DiameterPeer>
88
La macchina virtuale I-CSCF, il cui indirizzo IP è 192.168.10.91, riceve le richieste
Diameter dal hss.snodo attraverso la porta TCP 3869 e invia le richieste Diameter
alla porta TCP 3868 del hss.snodo.
3.2.3 Configurazione della macchina virtuale S-CSCF
Nella configurazione della macchina virtuale S-CSCF, all’interno del file “scscf.cfg”
sono state apportate le modifiche, indicate in grassetto, presenti in appendice B.
Nelle modifiche apportate al file “scscf.cfg” abbiamo utilizzato le seguenti
informazioni:
Indirizzo IP S-CSCF: 192.168.10.93
Realm: snodo
Nel file “scscf.xml” apportiamo le seguenti modifiche, indicate in grassetto:
<?xml version="1.0" encoding="UTF-8"?>
<DiameterPeer
FQDN="scscf.snodo"
Realm="snodo"
Vendor_Id="10415"
Product_Name="CDiameterPeer"
AcceptUnknownPeers="1"
DropUnknownOnDisconnect="1"
Tc="30"
Workers="4"
QueueLength="8"
>
<Peer FQDN="hss.snodo" Realm="snodo" port="3868"/>
<Acceptor port="3870" bind="192.168.10.93"/>
<Auth id="16777216" vendor="10415"/><!-- 3GPP Cx -->
<Auth id="16777216" vendor="4491"/><!-- CableLabs Cx -->
<Auth id="16777216" vendor="13019"/><!-- ETSI/TISPAN Cx -->
<DefaultRoute FQDN="hss.snodo" metric="10"/>
<!-- Realm Routing configuration - Uncomment and Edit!
<Realm name="snodo">
<Route FQDN="hss1.snodo" metric="10"/>
<Route FQDN="hss2.snodo" metric="20"/>
</Realm>
<Realm name="another.snodo">
<Route FQDN="hss3.snodo" metric="10"/>
<Route FQDN="hss2.snodo" metric="20"/>
</Realm>
<DefaultRoute FQDN="hss.snodo" metric="10"/>
<DefaultRoute FQDN="hss4.snodo" metric="20"/>
-->
89
</DiameterPeer>
La macchina virtuale S-CSCF, il cui indirizzo IP è 192.168.10.93, riceve le richieste
Diameter dal hss.snodo attraverso la porta TCP 3870 e invia le richieste Diameter
alla porta TCP 3868 del hss.snodo.
3.3
Configurazione personalizzata del BIND DNS
Dobbiamo adesso configurare il server DNS BIND che è stato installato sulla
macchina virtuale FHoSS.
È stato creato un file di configurazione “snodo.dnszone” nella cartella “/etc/bind”. Il
file “snodo.dnszone” è il seguente:
$ORIGIN snodo.
$TTL 1W
@
1D IN SOA
localhost. root.localhost. (
2006101001
; serial
3H
; refresh
15M
; retry
1W
; expiry
1D )
; minimum
ns
1D IN NS
1D IN A
ns
192.168.10.91
pcscf
1D IN A
192.168.10.92
snodo.
icscf
_sip
_sip._udp
_sip._tcp
1D IN A
snodo.
snodo.
1D IN NAPTR 10 50 "s" "SIP+D2U"
1D IN NAPTR 20 50 "s" "SIP+D2T"
1D
1D
1D
1D
192.168.10.91
IN A
192.168.10.91
SRV 0 0 5060 icscf
SRV 0 0 5060 icscf
SRV 0 0 5060 icscf
""
""
scscf
1D IN A
192.168.10.93
hss
1D IN A
192.168.10.90
ue
1D IN A
127.0.0.1
presence
1D IN A
127.0.0.1
_sip._udp.snodo.
_sip._tcp.snodo.
Come si può notare, sono stati settati gli indirizzi IP delle varie entità. Al contrario,
non sono stati settati gli indirizzi dell’ue e del presence dato che i servizi di Presence
non sono attivi.
90
In appendice B è presente il file “snodo.dnszone”.
Aggiungiamo al file “/etc/bind/named.conf.local” le seguenti righe:
zone "snodo" {
type master;
file "/etc/bind/snodo.dnszone";
};
Riavviamo il server DNS con il seguente comando:
/etc/init.d/bind9 restart
Dobbiamo fare in modo che le entità OpenIMSCore, installate sulle macchine
virtuali, possano contattare il server DNS BIND. Per questo motivo editiamo il file
“/etc/resolv.conf” su ogni macchina CSCF aggiungendo le seguenti righe:
search snodo
nameserver 192.168.10.90
Infine, per attivare le varie entità dell’architettura IMS dobbiamo lanciare i comandi
“pcscf.sh”, “scscf.sh”, “icscf.sh” e “fhoss.sh” nelle rispettive macchine virtuali PCSCF, S-CSCF, I-CSCF e FHoSS.
91
