SESSSIONI IMS IN UNO SCENARIO COSTITUITO DA DUE DOMINI DI RETE DISTINT
7.4 Immediate Messaging tra due utenti appartenenti a due domini IMS distint
In questo paragrafo viene descritta la procedura di Immediate Messaging tra due utenti appartenenti a domini di rete distinti.
Durante una sessione di immediate messagging un terminale genera una richiesta di Message, con il contenuto desiderato e mette nel Request-URI l'indirizzo del terminale destinatario. La richiesta è instradata dal mittente attraverso i due domini di rete IMS in modo analogo alla richiesta di Invite già analizzata in precedenza, fino a giungere al destinatario.
Nella figura 7.32 è mostrata la procedura di immediate messaging.
Figura 7.32 Procedura di Immediate Messaging
messaggi relativi esclusivamente alla fase di Immediate Immesaging della chiamata. Per acquisire tutti i messaggi scambiati durante questa fase, data la configurazione dello scenario, si deve mandare in esecuzione Wireshark nelle due macchine contenenti le Core IMS (i PC denominati godel e planck).
Figura 7.33 Scambio di messaggi durante la procedura di Immediate Messaging filtrati da Godel
Nella figura 7.33 viene mostrato lo scambio di messaggi durante la procedura di Immediate Messaging dal sistema installato nel PC denominato Godel mentre nella figura 7.34 si mostrano i messaggi filtrati da Planck. Si nota come anche in questo caso, vi sia un pacchetto presente in entrambe le figure.
Figura 7.34 Scambio di messaggi durante la procedura di Immediate Messaging filtrati da Planck
Marco (vedi campo From) invia il messaggio “ciao” presente nel Message body a Giuliano (campo To). Successivamente viene analizzato in dettaglio il procedimento di routing della trasmissione del pacchetto di Message.
Viene mostrato nella figura 7.35 la richiesta di Message. Si nota come i due utenti appartengono a due domini di rete distinti.
Internet Protocol, Src: 10.0.0.2 (10.0.0.2), Dst: 10.0.0.1 (10.0.0.1) User Datagram Protocol, Src Port: sip (5060), Dst Port: 4060 (4060) Session Initiation Protocol
Request-Line: MESSAGE sip:giuliano@ing.test SIP/2.0 Message Header
Via: SIP/2.0/UDP 10.0.0.2:5060;rport;branch=z9hG4bK349117290 Route: <sip:pcscf.openims.test:4060;lr> Route: <sip:orig@scscf.openims.test:6060;lr> From: <sip:marco@openims.test>;tag=683759604 To: <sip:giuliano@ing.test> Call-ID: 806782088@10.0.0.2 CSeq: 20 MESSAGE Max-Forwards: 70 User-Agent: eXosip/2.2.2 P-Preferred-Identity: <sip:marco@openims.test> P-Access-Network-Info: IEEE-802.11a Content-Type: text/plain Content-Length: 4 Message body
Line-based text data: text/plain ciao
Figura 7.35 Messaggio di Message (1)
Il P-CSCF, ricevuto il messaggio di Message, rimuove il suo indirizzo dal campo Route e lo aggiunge nel campo Via; inoltre rimuove l'identificativo in P- Preferred-Identity, controlla se è valido e lo mette in P-Asserted-Identity; infine aggiunge la sezione P-Charging-Vector dove descrive le informazioni di tariffazione e instrada il Message al S-CSCF. Viene mostrato tale messaggio nella figura 7.36.
Internet Protocol, Src: 10.0.0.1 (10.0.0.1), Dst: 10.0.0.1 (10.0.0.1) User Datagram Protocol, Src Port: 4060 (4060), Dst Port: 6060 (6060) Session Initiation Protocol
Request-Line: MESSAGE sip:giuliano@ing.test SIP/2.0 Message Header
Via: SIP/2.0/UDP 10.0.0.1:4060;branch=z9hG4bK1fee.76c6bfa3.0 Via: SIP/2.0/UDP 10.0.0.2:5060;rport=5060;branch=z9hG4bK349117290 Route: <sip:orig@scscf.openims.test:6060;lr> From: <sip:marco@openims.test>;tag=683759604 To: <sip:giuliano@ing.test> Call-ID: 806782088@10.0.0.2 CSeq: 20 MESSAGE Max-Forwards: 16 User-Agent: eXosip/2.2.2 P-Access-Network-Info: IEEE-802.11a Content-Type: text/plain Content-Length: 4 P-Asserted-Identity: <sip:marco@openims.test>
P-Charging-Vector: icid-value="P-CSCFabcd467f743400000019"; icid-generated-at="10.0.0.1"; orig- ioi="openims.test"
Il S-CSCF, ricevuto il messaggio di Message, rimuove il suo indirizzo dal campo Route e lo aggiunge nel campo Via. Infine lo invia all’ I-CSCF riferito al terminale chiamato (appartenente al dominio di rete Ing.test).
Internet Protocol, Src: 10.0.0.1 (10.0.0.1), Dst: 192.168.2.1 (192.168.2.1) User Datagram Protocol, Src Port: 6060 (6060), Dst Port: sip (5060) Session Initiation Protocol
Request-Line: MESSAGE sip:giuliano@ing.test SIP/2.0 Message Header
Via: SIP/2.0/UDP 10.0.0.1:6060;branch=z9hG4bK1fee.47e3c9d7.0 Via: SIP/2.0/UDP 10.0.0.1:4060;branch=z9hG4bK1fee.76c6bfa3.0 Via: SIP/2.0/UDP 10.0.0.2:5060;rport=5060;branch=z9hG4bK349117290 From: <sip:marco@openims.test>;tag=683759604
To: <sip:giuliano@ing.test> Call-ID: 806782088@10.0.0.2 CSeq: 20 MESSAGE
…
Figura 7.37 Messaggio di Message (3)
L’I-CSCF, determina l’indirizzo del S-CSCF attraverso una richiesta DNS e lo mette in Route; poi aggiunge in Via il proprio indirizzo. Infine instrada la richiesta di Message al S-CSCF (appartenente sempre al dominio di rete Ing.Test). Viene mostrato tale messaggio nella figura 7.38.
Internet Protocol, Src: 192.168.2.1 (192.168.2.1), Dst: 192.168.2.1 (192.168.2.1) User Datagram Protocol, Src Port: sip (5060), Dst Port: 6060 (6060)
Session Initiation Protocol
Request-Line: MESSAGE sip:giuliano@ing.test SIP/2.0 Message Header
Route: <sip:scscf.ing.test:6060>
Via: SIP/2.0/UDP 192.168.2.1;branch=z9hG4bK1fee.da3a3c53.0 Via: SIP/2.0/UDP 10.0.0.1:6060;branch=z9hG4bK1fee.47e3c9d7.0 Via: SIP/2.0/UDP 10.0.0.1:4060;branch=z9hG4bK1fee.76c6bfa3.0 Via: SIP/2.0/UDP 10.0.0.2:5060;rport=5060;branch=z9hG4bK349117290 From: <sip:marco@openims.test>;tag=683759604
To: <sip:giuliano@ing.test> Call-ID: 806782088@10.0.0.2 CSeq: 20 MESSAGE
…
Figura 7.38 Messaggio di Message (4)
Il S-CSCF, processato il messaggio di Invite, aggiunge la propria entry in Via e la elimina dal campo Route; inoltre aggiunge l’indirizzo del P-CSCF nella sezione
Route. Verifica se i FC (Filter Criteria) sono applicabili al messaggio ricevuto e instrada verso il P-CSCF. Si può notare come nel Request-Uri vi sia l’indirizzo con cui l’utente giuliano si è registrato in precedenza.
Internet Protocol, Src: 192.168.2.1 (192.168.2.1), Dst: 192.168.2.1 (192.168.2.1) User Datagram Protocol, Src Port: 6060 (6060), Dst Port: 4060 (4060)
Session Initiation Protocol
Request-Line: MESSAGE sip:giuliano@192.168.2.2:5060 SIP/2.0 Message Header
Route: <sip:term@pcscf.ing.test:4060;lr>
Via: SIP/2.0/UDP 192.168.2.1:6060;branch=z9hG4bK1fee.e8080a11.0 Via: SIP/2.0/UDP 192.168.2.1;branch=z9hG4bK1fee.da3a3c53.0 Via: SIP/2.0/UDP 10.0.0.1:6060;branch=z9hG4bK1fee.47e3c9d7.0 Via: SIP/2.0/UDP 10.0.0.1:4060;branch=z9hG4bK1fee.76c6bfa3.0 Via: SIP/2.0/UDP 10.0.0.2:5060;rport=5060;branch=z9hG4bK349117290 From: <sip:marco@openims.test>;tag=683759604
To: <sip:giuliano@ing.test> Call-ID: 806782088@10.0.0.2 CSeq: 20 MESSAGE
…
Figura 7.39 Messaggio di Message (5)
Il P-CSCF aggiunge il proprio indirizzo nel campo via come mostrato in figura 7.40. Infine il P-CSCF instrada il messaggio direttamente all’utente Giuliano.
Internet Protocol, Src: 192.168.2.1 (192.168.2.1), Dst: 192.168.2.2 (192.168.2.2) User Datagram Protocol, Src Port: 4060 (4060), Dst Port: sip (5060)
Session Initiation Protocol
Request-Line: MESSAGE sip:giuliano@192.168.2.2:5060 SIP/2.0 Message Header
Via: SIP/2.0/UDP 192.168.2.1:4060;branch=z9hG4bK1fee.a22476b.0
Via: SIP/2.0/UDP 192.168.2.1:6060;received=192.168.2.1;rport=6060;branch=z9hG4bK1fee.e8080a11.0 Via: SIP/2.0/UDP 192.168.2.1;branch=z9hG4bK1fee.da3a3c53.0
Via: SIP/2.0/UDP 10.0.0.1:6060;branch=z9hG4bK1fee.47e3c9d7.0 Via: SIP/2.0/UDP 10.0.0.1:4060;branch=z9hG4bK1fee.76c6bfa3.0 Via: SIP/2.0/UDP 10.0.0.2:5060;rport=5060;branch=z9hG4bK349117290 From: <sip:marco@openims.test>;tag=683759604
To: <sip:giuliano@ing.test> Call-ID: 806782088@10.0.0.2 CSeq: 20 MESSAGE
…
Figura 7.40 Messaggio di Message (6)
Giuliano riscontra il messaggio ricevuto da Marco, inviandogli una risposta 200 OK mostrata nella figura 7.41. Questa risposta utilizzando gli indirizzi memorizzati
nella sezione Via effettuerà il percorso inverso.
Internet Protocol, Src: 192.168.2.2 (192.168.2.2), Dst: 192.168.2.1 (192.168.2.1) User Datagram Protocol, Src Port: sip (5060), Dst Port: 4060 (4060)
Session Initiation Protocol Status-Line: SIP/2.0 200 OK Message Header
Via: SIP/2.0/UDP 192.168.2.1:4060;branch=z9hG4bK1fee.a22476b.0
Via: SIP/2.0/UDP 192.168.2.1:6060;received=192.168.2.1;rport=6060;branch=z9hG4bK1fee.e8080a11.0 Via: SIP/2.0/UDP 192.168.2.1;branch=z9hG4bK1fee.da3a3c53.0
Via: SIP/2.0/UDP 10.0.0.1:6060;branch=z9hG4bK1fee.47e3c9d7.0 Via: SIP/2.0/UDP 10.0.0.1:4060;branch=z9hG4bK1fee.76c6bfa3.0 Via: SIP/2.0/UDP 10.0.0.2:5060;rport=5060;branch=z9hG4bK349117290 From: <sip:marco@openims.test>;tag=683759604 To: <sip:giuliano@ing.test>;tag=610179955 Call-ID: 806782088@10.0.0.2 CSeq: 20 MESSAGE User-Agent: eXosip/2.2.2 Content-Length: 0 Figura 7.41 Messaggio di 200 Ok (7)
CONCLUSIONI
L’IMS (IP Multimedia SubSystem) rappresenta non solo il futuro della telefonia mobile in quanto porterà l’integrazione tra le reti mobili e quelle Internet, ma anche la modalità con cui si otterrà una piena convergenza multimediale che porterà alla creazione e sviluppo di nuovi servizi.
L’obiettivo del presente lavoro di tesi è stato quello di fornire una base teorica e una piattaforma implementativa relativa all’architettura IMS, al fine di dare un risultato pratico che sia utile in prospettiva di ulteriori sviluppi.
Il progetto si è focalizzato sulla descrizione dettagliata delle procedure implementate: come scenario generale è stata considerata una struttura costituita da due domini di rete IMS, uno fisso e l’altro mobile, attraverso i quali abbiamo eseguito sessioni di video-chiamata e Immediate Messaging. Infine grazie all’installazione di un Presence Server Open Source è stato implementato il servizio di presenza all’interno della struttura IMS.
APPENDICE A
Strumenti Usati
A.1 OpenSER Presence Server
Di seguito viene riportato il file di configurazione del Presence Server, openser_presence.cfg, opportunamente modificato per il nostro scenario.
#
# $Id: openser_presence.cfg 30-05-2007 #
# Simple quick-start config script for the openser to act as a presence server # To be used with the Open Source IMS Core http://www.openimscore.org
# and the UCTIMSClient http://www.uctimsclient.berlios.de
# Please refer to the Core CookBook at http://www.openser.org/dokuwiki/doku.php # for a explanation of possible statements, functions and parameters.
#
# --- global configuration parameters --- debug=3
log_stderror=yes fork=yes
#log_stderror=no # (cmd line: -E) children=4
# Uncomment these lines to enter debugging mode #fork=no
#log_stderror=yes
listen=127.0.0.1 port=5065
# uncomment the following lines for TLS support #disable_tls = 0 #listen = tls:your_IP:5061 #tls_verify_server = 1 #tls_verify_client = 1 #tls_require_client_certificate = 0 #tls_method = TLSv1 #tls_certificate = "/etc/openser/tls/user/user-cert.pem"
#tls_private_key = "/etc/openser/tls/user/user-privkey.pem" #tls_ca_list = "/etc/openser/tls/user/user-calist.pem"
# --- module loading --- #set module path
mpath="/usr/lib/openser/modules/"
# Uncomment this if you want to use SQL database loadmodule "mysql.so" loadmodule "sl.so" loadmodule "tm.so" loadmodule "rr.so" loadmodule "presence.so" loadmodule "maxfwd.so" loadmodule "usrloc.so" loadmodule "registrar.so" loadmodule "textops.so" loadmodule "mi_fifo.so"
# Uncomment this if you want digest authentication # mysql.so must be loaded !
#loadmodule "auth.so" #loadmodule "auth_db.so"
# --- setting module-specific parameters --- # -- mi_fifo params --
modparam("mi_fifo", "fifo_name", "/tmp/openser_fifo") # -- usrloc params --
modparam("usrloc", "db_mode", 0)
# Uncomment this if you want to use SQL database # for persistent storage and comment the previous line #modparam("usrloc", "db_mode", 2)
# -- auth params --
# Uncomment if you are using auth module #
#modparam("auth_db", "calculate_ha1", yes) #
# If you set "calculate_ha1" parameter to yes (which true in this config), # uncomment also the following parameter)
#
#modparam("auth_db", "password_column", "password") # -- rr params --
# add value to ;lr param to make some broken UAs happy modparam("rr", "enable_full_lr", 1)
# -- presence params --
modparam("presence", "db_url", "mysql://openser:openserrw@localhost/openser") modparam("presence", "presentity_table", "presentity")
modparam("presence", "xcap_table", "xcaps") modparam("presence", "clean_period", 100) modparam("presence", "to_tag_pref", 'a') modparam("presence", "lock_set_size", 8) modparam("presence", "expires_offset", 10) modparam("presence", "force_active", 1) modparam("presence", "max_expires", 3600)
modparam("presence", "server_address", "sip:localhost:5065")
# --- 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 the request is for other domain use UsrLoc
# (in case, it does not work, use the following command # with proper names and addresses in it)
# presence handling if(method=="PUBLISH"){ route(2); } if(method=="SUBSCRIBE"){ route(2); } route(1); } route[1] {
# send it out now; use stateful forwarding as it works reliably # even for UDP2TCP
if (!t_relay()) {
sl_reply_error(); };
exit; }
# presence handling route route[2] { # absorb retransmissions 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; }
Bibliografia
[IMS] Mikka Poikselka, Georg Mayer, Hisham Khartabil
and Aki Niemi, Wiley and Sons, “The Ims Ip Multimedia Concepts And Services In The Mobile Domain (2004) Ddu”
[3GPP TS 22.141] 3GPP TS 22.141 V7.3.0 (2006-12). 3rd Generation
Partnership Project Technical Specification Group Core Network and Terminals “Presence service using the IP Multimedia (IM)”, Core Network (CN)
subsystem; Stage 3(Release 7)
[3GPP TR 23.841] 3GPP TR 23.841 V1.1.0 3rd Generation Partnership
Project, Technical Specification Group Services and System Aspects; “Presence Service; Architecture and Functional Description”. Release 6
[3GPP TS 29.328] 3GPP TS 29.329 "Sh Interface based on the Diameter
protocol; protocol details"
[3GPP TS 23.218] 3GPP TS 23.218: 3rd Generation Partnership Project;
Technical Specification Group Services and System Aspects "IP Multimedia (IM) session handling; IM call model; Stage 2".
[3GPP TS 23.228] 3GPP TS 23.228 3rd Generation Partnership Project; Technical Specification Group Services and System Aspects "IP Multimedia Subsystem (IMS); Stage 2
[3GPP TS 24.228] 3GPP TS 24.228 Release 5: "Signalling flows for the
IP multimedia call control based on Session Initiation Protocol (SIP) and Session Description Protocol (SDP); Stage 3".
[3GPP TS 29.228] 3GPP TS 29.228: "IP Multimedia (IM) Subsystem Cx
and Dx Interfaces; Signalling flows and message contents".
[RFC 3863] IETF RFC 3856 (August 2004): "A Presence Event
Package for the Session Initiation Protocol (SIP)".
[RFC 3863] IETF RFC 3863 (August 2004): "Presence
Information Data Format (PIDF)".
[RFC 2543] Request for Comment 2543, “Sip: Session Initiator
Protocol”; http://www.ietf.org/rfc.html
[RFC 2778] Request for Comment 2778, "A Model for Presence
and Instant Messaging"; http://www.ietf.org/rfc.html
[RFC 2779] Request for Comment 2779, ”Instant
Messaging/Presence Protocol Requirement";
[ RFC 3588] IETF RFC 3588 "Diameter Base Protocol”
[ RFC 3589] IETF RFC 3589 "Diameter Command Codes for
Third Generation Partnership Project (3GPP) Release 5"
[RFC 3325] IETF RFC 3325: "Private Extensions to the Session
Initiation Protocol (SIP) for Network Asserted Identity within Trusted Networks".
[RFC 3310] IETF RFC 3310: "Hypertext Transfer Protocol
(HTTP) Digest Authentication Using Authentication and Key Agreement (AKA)".