Università degli Studi di Roma "La Sapienza"

Facoltà di Ingegneria

Tesi

Ruolo di SIP nell'IMS di 3GPP: interoperabilità con le specifiche IETF

Roma, 03/06/2003

1 Stato dell'arte

1.1 Breve storia della telefonia mobile

A partire dai primi anni '80, con l'introduzione delle prime reti di telefonia cellulare (conosciute come reti di "prima generazione"), il bisogno di mobilità nelle comunicazioni ha spinto in avanti lo sviluppo di nuove tecnologie, volte a soddisfare la sempre crescente richiesta di servizi che andassero al di là della semplice fonia tradizionale, così come offerto dalle reti di prima generazione. Di conseguenza, nel breve (in senso tecnologico) spazio di due decenni, la telefonia mobile si è evoluta di ben tre generazioni.

Della prima generazione (1G) si è già detto: si trattava di reti come la rete TACS. (Total Access Communication System), sviluppate su tecnologie telefoniche tutto sommato tradizionali, come la commutazione di circuito; i servizi offerti agli abbonati erano, come già accennato, altrettanto tradizionali: soltanto fonia e nessun tipo di servizio dati.

La seconda generazione (2G), nata nei primi anni '90, pur rimanendo legata alla tecnologia a commutazione di circuito ha iniziato ad offrire servizi diversi, oltre alla fonia: messaggistica (il noto servizio SMS, ossia Short Message Service), e dati a bassa velocità (comprese tra 14.4 kbps e 28.8 kbps). Di questa generazione è anche la rete GSM (Global System Mobile communication), dominatrice del mercato mondiale wireless, con una quota di oltre il 60% del totale.

Tuttavia, anche le reti GSM, progettate secondo la tecnologia a commutazione di circuito, si prestavano male per soddisfare la crescente richiesta di servizi a commutazione di pacchetto, come ad esempio l'accesso ad Internet da terminale mobile; ciò a causa dei bassi "data rates" raggiungibili con un'architettura del genere, e già quantificati in precedenza. Per porre rimedio a questa situazione, alla rete GSM è stata affiancata un'altra rete nata per il supporto di servizi a commutazione di pacchetto: la rete GPRS (General Packet Radio Services). Questo ha portato a definire l'insieme delle reti GSM/GPRS come reti di generazione 2.5 (2.5G): reti in grado di offrire efficiente supporto a servizi a commutazione di pacchetto, oltre che ai tradizionali servizi a commutazione di circuito.

Nonostante il notevole salto in avanti compiuto con le reti GSM/GPRS, restavano irrisolte almeno due questioni. Primo, il "data rate" offerto agli utenti si aggirava intorno a 64 kbps: un valore buono ma non sufficiente per molti servizi. Secondo, e forse più grave nell'ottica della fornitura di servizi Internet e multimediali, non c'era supporto per i servizi a commutazione di pacchetto in tempo reale. Questo, per esempio, impediva la fornitura di servizi di videoconferenza, di streaming audio/video, e più in generale di tutti quei servizi che necessitano uno scambio di pacchetti sincronizzato e affidabile, con ritardi di trasmissione non eccessivi. La necessità di risolvere questi problemi ha portato allo sviluppo delle reti di telefonia mobile di terza generazione (3G) note con il nome di reti UMTS (Universal Mobile Telecommunication System). Le reti UMTS possono essere considerate l'evoluzione naturale delle reti GSM/GPRS; con tali reti si è in grado di offrire agli abbonati connettività fino a 2 Mbps, servizi di streaming (risolvendo in tal modo i problemi cui si è accennato in precedenza), ed anche servizi correlati al luogo da cui l'utente è connesso.

La definizione formale della rete UMTS è curata dal 3GPP (3^rd Generation Partnership Project), un'unione di vari organismi che si occupano di standards nelle telecomunicazioni: fra gli altri si ricordano l'ETSI (European Telecommunication Standards Institute) e l'ARIB (Association of Radio Industry Business).

Lo sviluppo della rete UMTS è passato finora attraverso tre fasi. La prima fase ha condotto alla standardizzazione di una architettura di rete, derivata direttamente dalla rete GSM/GPRS, nota come Release 1999 (dal nome del relativo gruppo di specifiche). La Release 1999 verrà illustrata nel paragrafo 1.2; quello che si può dire sin da ora è che si tratta di una architettura nata per favorire la transizione degli utenti dalle generazioni precedenti (2G e 2.5G) verso la rete UMTS. La fase successiva ha portato alla standardizzazione di un'architettura di rete tramite un gruppo di specifiche note come Release 4, che sarà brevemente illustrata nel paragrafo 1.3. La Release 4 può essere definita come una operazione di transizione verso la Release 5: c'è l'introduzione di nuove idee di progettazione (che poi si ritroveranno nella Release 5) ma, a parte i cambiamenti dovuti a questo, l'architettura resta quella della Release 1999. La fase che segue, e che è recentemente terminata, ha portato alla standardizzazione di un'architettura di rete denominata (come il gruppo di specifiche relativo) Release 5, decisamente innovativa rispetto alle precedenti; la Release 5 sarà illustrata nel paragrafo 1.4 e, per quello che riguarda l'IMS (IP MultimediaSubsystem) che ne è l'aspetto più interessante, nel capitolo 2. Va citato anche il fatto che attualmente il 3GPP sta iniziando il lavoro sulla successiva architettura (e sul relativo gruppo di specifiche), che porterà il nome di Release 6; tale lavoro è tuttora in corso.

1.1.1 Third Generation Partnership Project (3GPP)

Come anticipato, Il "3^rd Generation Partnership Project" (3GPP) è un progetto di collaborazione tra alcuni enti di standardizzazione, quali ETSI (European Telecommunication Standard Institute), ARIB (Association of Radio Industries and Business), TTA (Telecommunication Technology Association), CWTS (China Wireless Telecommunication Standard Group) e TTC (Telecommunication Technology Committee).

L'obiettivo principale del 3GPP è di sviluppare le specifiche tecniche (Technical Specification) e i report (Technical Report) per il sistema radiomobile di terza generazione UMTS.

Il progetto è organizzato in maniera gerarchica. Al vertice si trova il Project Coordination Group (PCG), costituito da cinque Technical Specification Group (TSG), ognuno dei quali è internamente composto da vari Working Group (WG):

• Services and System Aspects (SA).

• Core Network (CN).

• Terminals (T).

• GSM EDGE Radio Access Network (GERAN).

• Radio Access Network (RAN).

La realizzazione delle specifiche 3GPP prevede tre fasi:

• Stage 1: descrizione del servizio dal punto di vista dell'utente.

• Stage 2: descrizione dell'architettura di rete che realizza il servizio.

• Stage 3: descrizione dettagliata di modi e protocolli per la realizzazione del servizio.

La standardizzazione del sottosistema IMS (IP Multimedia Subsystem) è curata principalmente da:

• TSG SA WG1 (in breve SA1): cura gli aspetti legati alla definizione dei servizi di terza generazione (Stage 1).

• TGS SA WG2 (in breve SA2): definisce gli aspetti di architettura del servizio definito da SA1 (Stage 2).

• 
  TSG CN WG1 (in breve CN1): si occupa della definizione dei protocolli utilizzati nella Core Network per il servizio (Stage 3).

L'organizzazione dei gruppi del 3GPP è illustrata in figura 1.1.

Figura 1.1 - Organizzazione gerarchica del 3GPP

1.2 Architettura della Release 1999

La "Release 1999", come già affermato, è stata pensata con l'intento di permettere una transizione "indolore" dalla rete GSM/GPRS verso l'UMTS.

Figura 1.2 - Schema di principio dell'architettura della Release 1999

1. UTRAN: UMTS Terrestrial Radio Access Network. Se ne parlerà nel sottoparagrafo 1.2.1.

2. CS-CN: Circuit Switched Core Network. Se ne parlerà nel sottoparagrafo 1.2.2.

3. PS-CN: Packet Switched CoreNetwork. Se ne parlerà nel sottoparagrafo 1.2.3.

Va precisato che, soprattutto per quel che riguarda il Core Network, la suddivisione presentata è logica più che fisica. Nella rete UMTS è effettivamente presente un solo Core Network, il quale può suddividersi logicamente nei domini CS e PS che, come si vedrà in seguito, sono parzialmente sovrapposti.

1.2.1 - UTRAN (UMTS Terrestrial Radio Access Network)

Figura 1.3 - Schema a blocchi dell'UTRAN

È l'interfaccia radio del sistema UMTS. Nella figura 1.3 ne è presentato uno schema a blocchi funzionali, che verranno di seguito descritti.

1. Nodo B: è grossolanamente equivalente alla BTS (Base Transceiver Station) della rete GSM. Gestisce quindi il collegamento delle celle radio verso la rete.

2. RNC (Radio Network Controller): può dirsi equivalente al BSC (Base Station Controller) della rete GSM. Si occupa quindi di un certo numero di nodi "Nodo B", per ciò che riguarda la gestione delle risorse radio ad essi assegnate; inoltre, negozia canali di comunicazione e qualità del servizio con il Core Network.

All'UTRAN sono interamente demandate le funzionalità di accesso radio al sistema. A tal fine il 3GPP ha standardizzato l'interfaccia tra l'UTRAN ed i Core Networks componenti la rete: tale interfaccia è detta interfaccia Iu. A seconda del tipo di Core Network, si parla di interfaccia Iu-PS (verso la PS-CN) e di interfaccia Iu-CS (verso la CS-CN). Così facendo è possibile svincolare completamente la modalità di funzionamento delle Core Networks componenti la rete dalla modalità di accesso radio alla rete stessa: basta che il comportamento dell'oggetto che garantisce l'accesso radio (sia esso l'UTRAN come in questo caso, sia un altro tipo di interfaccia, come ad esempio una Wireless LAN) sia conforme a quanto stabilito dai documenti che definiscono l'interfaccia Iu. Oltre all'interfaccia Iu, in figura 1.3 sono indicate anche le rimanenti interfacce definite per l'UTRAN; fatta eccezione per l'ultima, tutte le altre (ossia tutte le interfacce Iu) utilizzano l'ATM (Asynchronous Transfer Mode) come trasporto di rete.

1. Interfaccia Iub: è l'interfaccia tra Nodo B ed RNC.

2. Interfaccia Iur: è l'interfaccia tra diversi RNC.

3. Interfaccia Uu: è l'interfaccia tra unità mobile (UE, ovvero User Equipment) e Nodo B; di seguito se ne parla diffusamente.

Dal lato dell'unità mobile (interfaccia Uu), l'UTRAN adotta come sistema di comunicazione il cosiddetto W-CDMA, ossia Wideband Code Division Multiple Access, una tecnologia di derivazione militare. In breve, si tratta di un sistema in cui la condivisione del canale trasmissivo tra i vari flussi di comunicazione avviene non per intervalli di tempo o di frequenza (come nei sistemi di multiplazione tradizionali TDM o FDM) ma si realizza tramite opportuni codici associati in modo biunivoco ai flussi di comunicazione; si suppone ovviamente che i codici siano noti per altre vie alle parti in comunicazione. I vari segnali vengono intercorrelati con opportune funzioni dei codici ad essi associati prima di essere immessi nel canale trasmissivo. Quest'operazione ha due effetti: "marcare" il segnale con il codice corrispondente (in modo da renderlo riconoscibile), ed "allargarne l'occupazione di banda (il grafico dello spettro di densità di potenza si schiaccia" sull'asse delle frequenze). Dopo tale operazione, i vari segnali viaggiano nel canale trasmissivo sovrapponendosi in tempo ed in frequenza, con potenza proporzionale alla distanza tra i punti in comunicazione. Il segnale risultante sarà caotico e inintelligibile per un osservatore esterno. In ricezione, il segnale viene intercorrelato con la stessa funzione del codice associato usata in trasmissione. In questo modo, il segnale associato al codice viene esaltato dall'intercorrelazione, ed è quindi distinguibile dal resto; inoltre, l'intercorrelazione ricostruisce lo spettro di densità di potenza del segnale, dalla forma "allargata" e "schiacciata" necessaria per la trasmissione, alla forma originaria (operazione nota con il termine inglese di despreading, ossia "restringimento"). Il fatto che la potenza sia controllata in base alla distanza di comunicazione è fondamentale per il funzionamento del sistema. Infatti, se non ci fosse un controllo, il segnale proveniente da un punto vicino coprirebbe quelli da punti lontani anche dopo il despreading, rendendone impossibile la ricezione. Lo sviluppo di adeguati sistemi di controllo di potenza in tempo reale è ciò che ha effettivamente reso possibile l'adozione del W-CDMA. Un altro aspetto fondamentale per il funzionamento del W-CDMA è quello relativo alla scelta dei codici, che devono essere ortogonali, ossia: un codice qualsiasi A intercorrelato con un altro B dà risultato nullo a meno che A non coincida con B. Il W-CDMA presenta due vantaggi fondamentali rispetto ai metodi di multiplazione tradizionali" in tempo e/o frequenza. In primo luogo, non c'è necessità di precauzioni nel riutilizzo delle frequenze fra celle adiacenti: non è la frequenza portante diversa a discriminare i diversi segnali, e quindi non c'è rischio d'interferenza tra flussi informativi sulla stessa portante. È anzi necessario per quanto possibile che le frequenze utilizzate in celle adiacenti siano le stesse, al fine di evitare temporanee disconnessioni durante gli hand-offs, intollerabili soprattutto per la trasmissione dati ad alta velocità. Il secondo vantaggio è quello di poter sfruttare a profitto della comunicazione un fenomeno normalmente considerato un disturbo nella trasmissione tradizionale: il multipath. La presenza di percorsi multipli (e quindi di diverse componenti additive ricevute con fasi diverse) non pregiudica la ricezione: il ricevitore è in grado di isolare comunque il messaggio ricevuto, utilizzando il codice associato; la presenza di varie "versioni" del segnale può essere utilizzata, ad esempio, scegliendo la migliore di esse (non necessariamente corrispondente all'onda diretta); oppure ricomponendo dette versioni (portando in conto gli opportuni ritardi dovuti ai differenti percorsi seguiti), a formare un segnale più forte. Un simile uso dei percorsi multipli è noto come Multipath Diversity; un ricevitore in grado di combinare i segnali ricevuti è noto come "Rake Receiver".

1.2.2 - CS-CN (Circuit Switched Core Network)

Figura 1.4 - La Rete CS-CN

Questa entità funzionale della rete UMTS si occupa della fornitura dei servizi "tradizionali" a commutazione di circuito (fonia, fax) e di alcuni servizi "moderni" come SMS, e dati su rete commutata. Per fornire questi servizi, la CS-CN supporta connettività verso le reti PSTN (Public Switched Telephone Network) e ISDN (Integrated Services Digital Network) come mostrato in figura 1.4. Il protocollo di segnalazione utilizzato è quindi quello tradizionale delle reti commutate, ossia il protocollo SS7.

I più importanti componenti funzionali della CS-CN, riassunti in figura 1.4 sono i seguenti.

1. MSC (Mobile SwitchingCenter): si occupa dell'interfacciamento della rete con le reti PSTN e ISDN; in particolare, instrada le comunicazioni dalle reti suddette verso i terminali mobili e viceversa. Inoltre, l'MSC si occupa della gestione della mobilità del terminale: ossia, provvede a garantire un collegamento stabile e con buona qualità indipendentemente dalla posizione e dall'eventuale velocità di spostamento del mobile.

2. G-MSC (Gateway Mobile Switching Center): è un particolare tipo di MSC, deputato dall'operatore di rete a fare da intermediario tra una rete esterna alla PLMN (Public Land Mobile Network) che deve instradare una chiamata verso un terminale mobile e l'HLR (la cui definizione è data di seguito); questo avviene se, per qualche motivo, l'operatore di rete restringa l'accesso all'HLR. Nel dettaglio, il G-MSC interroga l'HLR per ricavare la zona ove si trova l'utente cui la chiamata è diretta; ottenuta tale informazione, il G-MSC smista la chiamata verso l'MSC di competenza per tale area territoriale. Un MSC può agire anche contemporaneamente da G-MSC; è l'operatore che decide quanti e quali MSC possano farlo.

3. VLR (Visitor Location Register): quest'entità contiene le informazioni che indicano lo stato puntuale dell'abbonato. Tali informazioni vengono scaricate dall'HLR al momento della registrazione di un abbonato presso il particolare VLR. In particolare il VLR contiene i profili di abbonati temporaneamente appoggiati alla rete (nel profilo dell'abbonato sono contenute informazioni come i servizi attivi, quelli sbarrati, e parametri relativi alla sicurezza), e le posizioni correnti dei terminali mobili. L'MSC si serve di quest'entità, ad esempio, per stabilire dove instradare le chiamate da o per un certo abbonato presente nell'area geografica gestita dall'MSC stesso. Ogni VLR è univocamente identificato da un numero, detto "VLR number", che consente ad un HLR (entità definita di seguito nel sottoparagrafo) di individuare presso quale VLR è temporaneamente registrato un certo abbonato.

4. AC (Authentication Center, anche detto AuC): quest'entità di rete si occupa di conservare e gestire i dati necessari ad autenticare l'abbonato che richiede l'accesso alla rete, fornendo quindi (assieme ad HLR, VLR, MSC ed SGSN) il supporto funzionale a varie metodologie di autenticazione.

5. HLR (Home Location Register): quest'entità contiene, analogamente al VLR ma in modo permanente, i profili degli abbonati alla rete; tra le altre cose, nell'HLR è contenuto l'IMSI (International Mobile Subscriber Identity) di ogni abbonato, ossia il "numero seriale" che lo identifica univocamente e che è una delle chiavi di ordinamento dei profili. L'HLR contiene anche tutti i parametri relativi al dominio PS. I dati vengono forniti su richiesta ad altre entità di rete (come l'MSC od il G-MSC). Ciò avviene ad esempio, per stabilire se un certo abbonato ha diritto o meno di usufruire di un certo servizio; o anche per motivi di instradamento, operazione in cui l'HLR ha il ruolo fondamentale di fornire l'indirizzo del VLR di competenza per il terminale da raggiungere.

Va precisato che le ultime due entità, ovvero HLR ed AC, forniscono il loro servizio sia per la CS-CN che per la PS-CN, e quindi sono entità comuni ad ambedue i Core Networks.

1.2.3 - PS-CN (Packet SwitchedCore Network)

Figura 1.5 - Schema di principio della PS-CN

Questa entità funzionale della rete UMTS si occupa della fornitura dei servizi a commutazione di pacchetto: accesso ad Internet, VPN (VirtualPrivateNetworks), SMS, trasmissione dati. Per fornire tali servizi, la PS-CN deve garantire la connettività a reti a commutazione di pacchetto come Internet ed interfacciarsi verso di esse come una "normale" sottorete a pacchetto. Nella figura 1.5 è mostrato uno schema di principio della PS-CN, in cui sono visibili i componenti funzionali fondamentali del PS-CN, che sono di seguito descritti.

1. 3G-SGSN (3G Serving GPRS Support Node). Essendo connesso all'UTRAN (tramite l'interfaccia IuPS, con connettività UDP/IP su ATM) il 3G-SGSN è il nodo di riferimento del terminale mobile, e svolge funzionalità analoghe a quelle dell'MSC per la CS-CN. Infatti, il 3G-SGSN effettua la localizzazione e l'autenticazione del terminale in fase di aggancio alla rete, ed è interlocutore "alla pari" con il terminale stesso per l'instaurazione delle sessioni ed il trasferimento dei dati. Il 3G-SGSN dialoga con i database già visti per il dominio CS, ossia HLR-AuC ed MSC/VLR, per l'eventuale gestione di funzioni di mobilità CS/PS combinate ed altre funzionalità che prevedono la collaborazione dei due domini.

2. GGSN (Gateway GPRS Support Node). Costituisce il punto d'accesso della PS-CN da e verso le reti a pacchetto esterne, dette genericamente PDN (Packet Data Network). L'interfaccia GGSN-PDN, (detta interfaccia Gi) è un'interfaccia dati standard, come IP o PPP (Point to Point Protocol); in questo modo la CS-CN appare all'esterno come una sottorete del protocollo utilizzato su tale interfaccia. Essendo un punto d'accesso, il GGSN deve poter instradare i dati e proteggere la CS-CN da eventuali intrusioni e usi non autorizzati: per questo, implementa anche funzionalità di routing e di firewalling. Insieme al 3G-SGSN, il GGSN di occupa anche della preparazione dei dati grezzi relativi alla fatturazione del traffico a pacchetto.

3. Private IP Network. È la rete interna alla CS-CN che connette 3G-SGSN e GGSN. Benché non ne sia specificato il sottostante strato di trasporto, si tratta di una rete IP: questo perciò richiede che i Support Node che essa mette in comunicazione implementino funzioni di routing IP. Negli standard tale rete è anche detta Intra-PLMN BB (Intra-PLMN BackBone), per distinguerla dalla rete che collega due PLMN distinte, detta Inter-PLMN BB.

1.3 Architettura della Release 4

Come anticipato nell'introduzione, la Release 4 è essenzialmente una evoluzione della Release 1999 nel percorso di transizione verso la Release 5 e le successive. Nella Release 4 il principio architetturale della separazione del controllo di rete dal trasporto di rete viene applicato al dominio CS della Release 1999, anticipando ciò che poi verrà più estesamente applicato alla Release 5.

Il layout del dominio CS rappresenta quindi la principale novità della Release 4. In particolare, la novità maggiore è la separazione dell'MSC in due entità di rete distinte: MSC server e MGW (Media GateWay). Tale separazione è il risultato dell'applicazione del principio di separazione di cui si parlava poco sopra. Infatti, riassumendo grossolanamente le funzionalità delle due entità, si può dire che:

• l'MSC server è la "mente": si occupa del controllo di rete, ossia controllo di chiamata, gestione della mobilità, gestione della segnalazione da rete a mobile e viceversa, integrando inoltre funzionalità da VLR;

• l'MGW è il "braccio": si occupa di vari aspetti del trasporto di rete, ossia gestione delle risorse trasmissive, manipolazione dei dati in transito (transcoding, generazione di toni DTMF, etc.).

Dal momento che uno è la "mente" e l'altro è il "braccio", è stata anche definita un'interfaccia di comunicazione tra MSC server e MGW: l'interfaccia Mc. È comunque lasciata una certa libertà di scelta riguardo alla implementazione dei due nodi in maniera fisicamente distinta: si può anche scegliere di integrarli (rispettando comunque i requisiti di servizio imposti dalle specifiche), eliminando in tal modo l'interfaccia Mc.

1.4 Architettura della Release 5

Come visto in precedenza nel paragrafo 1.2, nell'architettura della Release 1999 si ha una rete d'accesso, l'UTRAN, dalla quale si accede a due domini distinti ed in un certo senso paralleli: il dominio CS (CS-CN) ed il dominio PS (PS-CN). Il dominio CS, di derivazione diretta dall'esperienza GSM, si presta al supporto di traffico vocale, che ha necessità di servizio in tempo reale; il dominio PS, di derivazione diretta dai nodi GPRS, è invece più adatto al supporto del traffico dati, che generalmente non ha requisiti di servizio in tempo reale.

Di contro, con la Release 5 si è cercato di superare il principio architetturale delle due reti separate e parallele. Uno dei concetti di progetto fondamentali è quello della convergenza: non due reti separate e specializzate, ma l'integrazione di ogni tipo di traffico, in tempo reale o meno, su di un'unica piattaforma a commutazione di pacchetto, di fatto mantenendo le strutture di rete a commutazione di circuito soltanto per ragioni di compatibilità all'indietro. Nel paragrafo 1.4.1 si analizzeranno le motivazioni di questa scelta.

Figura 1.6 - Architettura della Release 5

Quindi, la principale innovazione della Release 5 rispetto alle precedenti è l'introduzione dell'IMS (IP Multimedia SubSystem): un insieme di server e media gateway controller dedicati al controllo delle sessioni IP multimediali d'utente¹. Il trasporto delle suddette sessioni è a carico del dominio a commutazione di pacchetto (PS), alle cui capacità tradizionali sono state aggiunte quelle per il trasporto di dati in tempo reale e per la gestione della qualità del servizio (QoS, ovvero Quality of Service). Sulla struttura interna del dominio IMS si tornerà diffusamente nel capitolo 2.

La figura 1.6 fornisce una schematizzazione dell'architettura dove si evidenziano i domini componenti; in particolare, sono ben visibili i due domini IMS e PS. Dalla distinzione tra di essi si nota come, nella progettazione dell'architettura della Release 5, sia stato applicato il principio della separazione del controllo di rete (dominio IMS) dal trasporto (dominio PS), già presente nella Release 1999, e che può generalizzarsi come principio di stratificazione delle funzionalità. A tale proposito va notato anche che, in base a tale principio, la modalità d'accesso all'IMS, tramite UTRAN e dominio PS, non è che un'implementazione particolare per fornire connettività IP tra un terminale mobile ed un server del dominio IMS. Questo significa che, nel futuro, potrebbero essere impiegate anche altre tecnologie per l'accesso all'IMS, a condizione che l'accesso fornito sia basato su IP. Va infine notato come nella figura 1.6 sia evidenziata la presenza del dominio CS, mantenuto per esigenze di compatibilità con i terminali della Release 1999. L'eliminazione totale del dominio CS è uno dei possibili obiettivi della futura Release 6.

Un altro punto innovativo della Release 5 rispetto al passato è la scelta di non specificare in modo dettagliato l'offerta dei servizi supplementari; ciò che invece è stato dettagliato e definito sono le capacità di base necessarie per la creazione di servizi più complessi. È stata anche definita una API (Application Program Interface), che permette l'accesso e l'utilizzo di tali capacità di base da parte dei cosiddetti AS (Application Server); tali AS si trovano nella Service Platform, all'esterno del Dominio IMS e talvolta anche all'esterno della rete cui l'IMS appartiene. In questo modo si semplifica la definizione e realizzazione di servizi complessi, anche a cura di terze parti; di conseguenza, c'è un aumento dell'offerta di tali servizi da parte dei gestori, sia in termini di quantità che in termini di qualità e personalizzabilità. Questo concetto è brevemente riassunto con l'acronimo OSA, che sta per Open Service Architecture.

Ultima, ma non meno importante, innovazione della Release 5 è l'estesa adozione di protocolli pubblici (derivanti dal mondo Internet) per la comunicazione tra le varie entità di rete. In particolare, 3GPP ha scelto il protocollo SIP (Session InitiationProtocol), per la comunicazione a livello applicazione tra i terminali utente (UE, User Equipment) e le entità del dominio IMS, ed anche tra alcune delle entità stesse. Come si vedrà meglio nel capitolo 3, SIP è a tutti gli effetti un protocollo derivato dal mondo Internet, la cui standardizzazione è stata curata dall'organismo che si occupa della definizione di tali protocolli: l'IETF (Internet Engineering Task Force), sotto l'egida della "Internet Society". SIP è definito nella specifica IETF [3]. Inoltre, date le caratteristiche peculiari della rete IMS, IETF ha definito una serie di estensioni a SIP, che sono utilizzate in ambito 3GPP.

1.4.1 Le ragioni di una scelta convergente

Si cercherà ora di spiegare brevemente i motivi della scelta di convergenza verso la commutazione di pacchetto.

Una prima motivazione è quella del minor costo delle infrastrutture: riducendo l'importanza della rete a commutazione di circuito (rete CS d'ora in poi nel paragrafo), il cui ruolo è, ove possibile, ricoperto dalla rete a commutazione di pacchetto (rete PS d'ora in poi nel paragrafo), si riducono anche le relative spese di costruzione e di gestione. Inoltre, le modifiche necessarie alla rete PS per l'implementazione delle funzionalità della rete CS prevedono l'introduzione di componenti comunque basati su tecnologia a commutazione di pacchetto; tali componenti sono generalmente più economici dei componenti telefonici tradizionali, per via di una maggiore competizione di mercato tra i produttori e, come già accennato, per l'adozione di standard pubblici e non proprietari. Infine, vi è la possibilità di eliminare alcune parti ridondanti nelle due reti: per esempio, non è necessario progettare e costruire due piattaforme separate di network management per la rete CS e quella PS, ne basta una (ovviamente quella PS) per tutta la rete; in tal modo i costi delle infrastrutture sono ulteriormente ridotti.

Un'altra motivazione risiede nei ridotti costi di gestione di una rete "convergente". Ancora una volta, l'adozione di standard pubblici facilita lo sviluppo di piattaforme di gestione di rete PS a loro volta a standard aperto; di conseguenza, la gestione di rete viene semplificata, così che lo staff necessario alle operazioni si riduce, ed il costo di gestione si abbassa. In più, anche i costi di formazione del personale si abbassano, poiché è richiesta conoscenza per lo più nel campo delle tecnologie a commutazione di pacchetto (e non anche in quello della commutazione di circuito).

La possibilità di offrire servizi multimediali arricchiti, in combinazione con i servizi di telefonia tradizionale, utilizzando le infrastrutture e le tecnologie IP, proprie della rete Internet, è un'altra causa che ha orientato verso la scelta progettuale convergente. Le potenzialità in termini di servizi offerti e di guadagni possibili per i gestori telefonici sono alte, data l'ampia diffusione di Internet e la sua continua espansione in tutto il mondo.

Un altro vantaggio della scelta "convergente" è la facilità di introduzione e di implementazione di nuovi servizi: con una rete convergente, basata su di un singolo standard, lo sforzo di configurazione e coordinamento necessario all'introduzione di nuove caratteristiche si riduce, potendo contare su di una gestione di rete più semplice.

2 Il dominio IMS (IP Multimedia SubSystem)

Nella figura 2.1 è rappresentato il dominio IMS, o IMS-CN

Figura 2.1 - Architettura dell'IMS-CN

Le entità più importanti dell'IMS sono il Call SessionControl Function (CSCF) e l'Home Subscriber Server (HSS). Sono inoltre presenti le entità necessarie per l'interfacciamento con le reti a commutazione di circuito (Media e Signalling Gateways).

2.1 Call Session Control Function (CSCF)

Il CSCF è l'elemento più importante della Core Network IMS, il cui ruolo principale è di elaborare i messaggi di segnalazione SIP. È approssimativamente l'equivalente del SIP Proxy Server (in realtà non è proprio così: anzi, questa pretesa equivalenza è proprio uno degli argomenti in discussione nel resto della trattazione). Le funzionalità principali del CSCF sono:

• controllo della sessione multimediale;

• traduzione di indirizzi e instradamento della segnalazione SIP;

• negoziazione dei parametri dei media coinvolti nella sessione;

• gestione del profilo d'utente.

Il CSCF può caratterizzarsi in tre ruoli distinti: Proxy CSCF (P-CSCF), Interrogating CSCF (I-CSCF) e Serving CSCF (S-CSCF), illustrati ciascuno in uno dei paragrafi seguenti.

2.1.1 Proxy CSCF

Il Proxy CSCF rappresenta il primo punto di contatto con la Core Network IMS; può trovarsi nella "Visited Network", quando l'utente è localizzato in una rete diversa da quella dell'operatore di appartenenza (quest'ultima è detta invece: HN, ossia Home Network). Il Proxy CSCF accetta richieste SIP, svolge funzionalità interne e inoltra la segnalazione SIP al prossimo nodo di rete coinvolto nell'instradamento.

Le funzionalità svolte dal P-CSCF sono:

• inoltrare le richieste di registrazione ricevute dallo UE verso l'Interrogating CSCF, il cui indirizzo è determinato, in base al dominio di appartenenza dell'utente, con un'interrogazione al DNS;

• inoltrare i messaggi SIP al S-CSCF che ha in gestione l'utente, il cui indirizzo è determinato durante la registrazione;

• inoltrare le richieste e le risposte allo User Equipment.

Nel P-CSCF è inclusa un'entità particolare: il PCF (Policy ControlFunction). Lo scopo di tale entità è la gestione delle risorse di rete per le trasmissioni dei flussi di dati utente; tramite il PCF vengono erogate le autorizzazioni all'uso delle risorse da parte degli UE che fanno riferimento al P-CSCF.

2.1.2 Interrogating CSCF

L'Interrogating CSCF è il punto di contatto con la Home Network, permette di nascondere la topologia interna della rete dell'operatore (anche su quest'affermazione si tornerà ampiamente sul seguito della trattazione) e di selezionare il Serving CSCF assegnato alla gestione dell'utente.

Le funzionalità svolte dall'I-CSCF sono:

• nella fase di registrazione,

  • determina l'S-CSCF presso cui l'utente si registra;

• durante l'instaurazione della sessione,

  • determina l'indirizzo del Serving CSCF interrogando l'HSS;

  • inoltra la segnalazione SIP verso il Serving CSCF.

2.1.3 Serving CSCF

Il Serving CSCF, oltre alle funzionalità di instradamento della segnalazione, gestisce il controllo della sessione per conto dell'utente sottoscritto. Il Serving CSCF determina se è necessario contattare uno o più Application Server per l'esecuzione di applicazioni. La decisione è presa in base al profilo di sottoscrizione, relativo all'utente servito, ricevuto dall'HSS durante la registrazione.

Le funzionalità svolte dall'S-CSCF sono:

• nella fase di registrazione,

  • svolgere il ruolo di SIP Registrar e accettare le registrazioni;

• durante l'instaurazione della sessione,

  • gestire il controllo della sessione;

  • svolgere il ruolo di SIP Proxy ed elaborare internamente la segnalazione, prima di inoltrarla verso la destinazione;

  • interagire con la Service Platform per la fornitura dei servizi;

  • inoltrare i messaggi SIP alle opportune entità di rete, per l'instradamento verso PSTN/PLMN o verso il Dominio CS.

Non è importante se l'utente si trovi nella propria rete di appartenenza (Home Network) o in una rete diversa (sia cioè in roaming presso una Visited Network): l'S-CSCF che ne gestirà il controllo di sessione è sempre quello della sua Home Network, mentre le risorse utilizzate saranno quelle della rete presso cui l'utente è fisicamente attestato. Questa filosofia di progettazione prende il nome di "Home Control Of Services" ed è una caratteristica propria del dominio IMS.

2.2 Home Subscriber Server

L'Home Subscriber Server è l'evoluzione dell'Home Location Register e dell'Authentication Center; rappresenta il database che contiene le informazioni di sottoscrizione degli utenti, per coadiuvare le entità di rete nella gestione della chiamata/sessione.

L'HSS è responsabile di mantenere i seguenti dati;

• identificativi dell'utente;

• informazioni per l'Autenticazione e l'Autorizzazione;

• informazioni di localizzazione;

• informazioni relative al profilo di servizio dell'utente.

Figura 2.2 - Schema logico delle funzionalità dell'HSS

L'HSS supporta le procedure di sicurezza (cioè: autenticazione, controllo di integrità, codifica) ed è responsabile di identificare le risorse di rete necessarie per il controllo di sessione. In figura 2.2 sono riassunte le funzionalità dell'HSS e le interfacce di comunicazione verso i domini CS, PS e IMS.

2.3 Application Server

Un Application Server (AS), che può essere un SIP Application Server (SIP-AS), un OSA Application Server (OSA-AS) o un CAMEL IP Multimedia Service Switching Function (IM-SSF), permette la creazione e la fornitura di servizi multimediali. Il Serving CSCF è l'entità del dominio IMS che interagisce con gli Application Server utilizzando SIP come protocollo di segnalazione all'interfaccia IP Multimedia Service Control (ISC).

2.4 Breakout Gateway Control Function

Il Breakout Gateway Control Function (BGCF) seleziona la rete PSTN/PLMN o il Dominio CS, verso cui inoltrare la segnalazione relativa alla sessione. Se l'interfacciamento avviene all'interno della rete dello stesso operatore, la segnalazione è instradata verso il Media Gateway Control Function (MGCF), altrimenti è contattato un altro BGCF.

2.5 Media Gateway Control Function

Il Media Gateway Control Function (MGCF) si occupa dell'interfacciamento tra la segnalazione SIP nel dominio IMS e la segnalazione ISUP/BICC (ISDN Signalling UserPart/Bearer Independent Call Control) nelle reti GeneralSwitching Telephone Network (GSTN). II MGCF è inoltre responsabile del controllo del Media Gateway (IM-MGW), che si occupa dell'interfacciamento per il piano di utente, ad esempio determinando la conversione tra AMR (Adaptive Multi Rate coding) e la voce codificata in PCM.

2.6 Multimedia Resource Function

Il Multimedia Resource Function (MRF) è logicamente diviso in due entità:

• Media Resource Function Controller (MRFC), che controlla le risorse per i flussi multimediali nel MRFP e interpreta le informazioni che provengono dal S-CSCF o dall'Application Server per il trattamento dei media.

• Media Resource Function Processor (MRFP), che controlla il trasporto all'interfaccia Mb, determina il mixing degli stream multimediali ricevuti e, successivamente, applica l'elaborazione richiesta, come ad esempio la transcodifica o l'analisi dei media.

2.7 Interfacce tra le entità del dominio IMS

Nella figura 2.1 sono anche illustrate le interfacce interne tra gli elementi di rete IMS e le interfacce verso le entità dei domini CS e PS.

2.7.1 Interfaccia HSS- CSCF (Cx Reference Point)

L'interfaccia Cx si basa sul protocollo Diameter, che è un'evoluzione del protocollo Radius, concepito per le funzionalità di "AAA" (Authentication, Authorization and Accounting). Tale interfaccia supporta il trasferimento di informazioni tra l'HSS e i CSCF per:

• procedure per l'assegnazione del S-CSCF;

• procedure relative alle informazioni di instradamento;

• procedure relative alla fornitura dei servizi multimediali.

2.7.2 Interfaccia HSS- SIP AS (Sh Reference Point)

Un SIP Application Server può comunicare con l'HSS per ricevere informazioni relative al profilo dell'utente per la fornitura del servizio. L'interfaccia Sh è stata definita per fornire questa funzionalità e usa il protocollo Diameter.

2.7.3 Interfaccia CSCF- UE (Gm Reference Point)

L'interfaccia Gm permette allo User Equipment di comunicare con i vari CSCF per le procedure relative a:

• registrazione presso un S-CSCF;

• autenticazione per la fornitura di applicazioni e servizi;

• inizio e termine di chiamate/sessioni;

• controllo di servizi supplementari.

L'interfaccia Gm utilizza il protocollo SIP.

2.7.4 Interfaccia CSCF- AS (ISC Reference Point)

L'interfaccia IP multimedia Service Control (ISC), tra il S-CSCF e gli Application Server è usata per lo scambio della segnalazione relativa alla fornitura di servizi multimediali. L'interfaccia ISC utilizza il protocollo SIP, così come definito nella relativa specifica di IETF [3].

2.7.5 Interfaccia CSCF- MRFC (Mr Reference Point)

Questa interfaccia permette l'interazione tra il S-CSCF e il MRFC; il protocollo usato per la segnalazione all'interfaccia Mr è SIP.

2.7.6 Interfaccia CSCF- CSCF (Mw Reference Point)

Questa interfaccia permette le interazioni tra le diverse tipologie di CSCF per svolgere procedure come ad esempio l'instradamento della segnalazione relativa all'instaurazione di una sessione. Il protocollo usato per la segnalazione all'interfaccia Mw è SIP.

2.7.7 Interfaccia GGSN- PCF (Go Reference Point)

L'interfaccia permette al Policy Control Function (PCF), che è l'entità logica all'interno del P-CSCF per supportare la QoS, di applicare una politica di gestione del bearer nel GGSN.

2.7.8 Interfaccia CSCF- BGCF (Mi Reference Point)

L'interfaccia permette ai CSCF di inoltrare la segnalazione al Border Gateway Control Function (BGCF) per l'interworking con le reti PSTN. L'interfaccia si basa sul protocollo SIP.

2.7.9 Interfaccia BGCF- MGCF (Mj Reference Point)

L'interfaccia permette al Border Gateway Control Function (BGCF) di inoltrare la segnalazione al Media Gateway Control Function (MGCF) per l'interworking con le reti PSTN. L'interfaccia Mj si basa sul protocollo SIP.

2.7.10 Interfaccia BGCF- BGCF (Mk Reference Point)

L'interfaccia permette a un Breakout Gateway Control Function (BGCF) di inoltrare la segnalazione di sessione ad un altro Breakout Gateway Control Function.(BGCF) Il protocollo usato all'interfaccia Mk è SIP.

2.8 Principali procedure nel dominio IMS

Dopo aver introdotto l'architettura di base, analizziamo le operazioni fondamentali definite nel dominio IMS per stabilire le sessioni multimediali.

Una sessione multimediale implica il controllo delle risorse di rete che sono dinamicamente impiegate per lo scambio di informazioni (voce, video. dati o una combinazione di questi) tra i nodi funzionali coinvolti (terminali e server).

Le procedure necessarie per la fornitura di servizi nel dominio IMS prevedono l'instaurazione del "Data Bearer", la registrazione presso un appropriato server, l'inizio, la gestione ed il termine di sessioni multimediali. Analizziamo come il protocollo SIP è usato per la creazione e fornitura del servizio nell'IP Multimedia Subsystem. Un terminale deve svolgere una serie di passi, illustrati in figura 2.3, per ottenere l'accesso al dominio IMS ed essere abilitato alla fornitura dei servizi multimediali sottoscritti.

Figura 2.3 - Procedure di accesso ai servizi SIP

1. System Acquisition
   II primo passo rappresenta l'attivazione dello User Equipment all'interno del sistema UMTS; dopo aver selezionato l'appropriata cella, il terminale dell'utente è pronto a scambiare i messaggi di segnalazione necessari ad instaurare una sessione multimediale.

2. Data Connection Set-up
   Il passo successivo è rappresentato dallo stabilire la connessione per il trasporto dei dati verso il dominio IMS. Lo UE non conosce l'indirizzo IP del P-CSCF per effettuare direttamente la procedura di registrazione; occorre quindi definire la connessione attraverso due fasi, rappresentate dalle procedure di "Attach" e di "Packet DataProtocol" (PDP) Context Activation".

   1. "Attach": rappresenta la registrazione per servizi a pacchetto e coinvolge il Serving GPRS Support Node (SGSN). L'SGSN stabilisce un'associazione logica con l'UE per gestire la mobilità all'interno della rete UMTS.

   2. "PDP Context Activation": prima di poter inviare traffico a pacchetto, l'UE deve attivare il suo indirizzo PDP (nel nostro caso, un indirizzo IP) per stabilire la connessione tra l'SGSN, che ha in uso l'utente, e il GGSN che fornisce connettività verso le reti a pacchetto. L'SGSN e il GGSN creano speciali "path" o "tunnel" per trasferire pacchetti da e verso l'UE; una volta che il path è stato stabilito, il GGSN fornisce all'UE l'indirizzo IP relativo al P-CSCF, necessario per continuare le procedure previste per la realizzazione di servizi SIP.

Figura 2.4 - Creazione del "tunnel" dall'UE all'IMS.

3.             Service Registration

   Prima di stabilire una sessione, l'UE deve registrarsi nel dominio IMS, per far conoscere alla rete la sua localizzazione ed abilitare i servizi sottoscritti. L'UE agisce da SIP client e invia il messaggio di registrazione alla sua Home Network attraverso il Proxy-CSCF.

4.             Session Setup

   Dopo aver attivato il PDP Context e concluso il processo di registrazione, l'utente è in grado di stabilire la sessione, con l'invio degli opportuni messaggi previsti dal protocollo SIP.

2.8.1 Registrazione

Prima di poter attivare una sessione multimediale, lo User Equipment deve effettuare la registrazione presso il dominio IMS. La procedura prevede le seguenti azioni nelle entità di rete coinvolte:

• l'utente deve essere attestato presso un S-CSCF, che è selezionato durante la fase di registrazione nella propria Home Network. Il S-CSCF assegnato all'utente riceve dall'HSS il profilo di sottoscrizione ai servizi;

• per completare positivamente la procedura, sono svolte le procedure di Autorizzazione e Autenticazione, per verificare se l'utente è abilitato a registrarsi nella rete;

• Al termine della registrazione, la localizzazione corrente relativa all'utente viene notificata all'HSS, che ne aggiorna il profilo.

Si descrive ora il flusso dei messaggi di segnalazione ("Call Flow") per la registrazione, illustrato in figura 2.5. Per tale figura valgono le seguenti ipotesi:

• l'utente è localizzato in una Visited Network ed ha completato la procedura di PDP Context Activation per disporre della connettività IP;

• l'I-CSCF rappresenta il punto d'accesso alla Home Network;

• si omettono le procedure di autenticazione ed autorizzazione.

Figura 2.5 - Procedura di Registrazione

1. Dopo aver ottenuto il canale di segnalazione dalla rete di accesso, lo UE può iniziare la procedura di registrazione. Per fare questo, invia al P-CSCF il messaggio SIP REGISTER, che contiene l'identità dell'utente, da cui ricavare il nome del dominio della Home Network, e l'indirizzo IP dello UE.

2. Alla ricezione del messaggio di registrazione, il P-CSCF esamina il nome del dominio di rete e determina, interrogando il DNS, l'entry point nella Home Network (cioè l'I-CSCF). Il P-CSCF aggiunge l'identificativo della Visited Network attraversata e inoltra il messaggio all'I-CSCF.

3. L'I-CSCF interroga l'HSS per verificare se l'utente è già registrato nel dominio IMS;

4. l'HSS determina se l'utente è abilitato a registrarsi, in base al profilo di sottoscrizione e alle specifiche restrizioni dell'operatore e comunica la risposta all'I-CSCF.

5. L'I-CSCF richiede all'HSS le informazioni relative alla lista di S-CSCF tra cui selezionare quello che avrà in gestione l'utente;

6. l'HSS fornisce la lista comprensiva delle caratteristiche dei vari S-CSCF inclusi.

7. L'I-CSCF determina l'indirizzo del S-CSCF cui inoltrare la segnalazione SIP per la registrazione e gli inoltra la richiesta REGISTER.

8. L'S-CSCF, alla ricezione del messaggio, informa l'HSS dell'attestazione dell'utente;

9. l'HSS risponde riscontrando il messaggio.

10. II S-CSCF può ora richiedere all'HSS il profilo dell'utente e memorizzare le informazioni di instradamento (cioè l'indirizzo del P-CSCF) da usare in caso di chiamate terminate verso l'utente.

11. L'HSS risponde all'S-CSCF inoltrando il profilo relativo all'utente registrato, che comprende la lista dei Filter Criteria per il contatto con gli eventuali AS da coinvolgere nella registrazione.

12. In base ai Filter Criteria, il S-CSCF può notificare la registrazione alla piattaforma di servizio e svolgere le procedure di controllo appropriate.

13. Il S-CSCF genera il messaggio di risposta "200 OK", per l'avvenuta registrazione dell'utente e lo inoltra a ritroso attraverso tutti gli elementi di rete IMS coinvolti, fino a raggiungere l'UE.

2.8.2 Instaurazione della sessione multimediale.

Nella figura 2.6 sono schematizzate le fasi fondamentali dell'instaurazione di una generica sessione multimediale avente origine da e termine in una coppia di UE.

Figura 2.6 - Schematizzazione dell'instaurazione di sessione

Si suppone che il chiamante ed il chiamato abbiano completato le procedure di PDP context activation, conoscano l'indirizzo del P-CSCF cui afferire e siano registrati presso i rispettivi S-CSCF.

La procedura di instaurazione della sessione può essere scomposta in 12 fasi elementari, alcune delle quali fondamentali ed altre opzionali. Le fasi opzionali, evidenziate in figura con il tratteggio, possono avere luogo o meno a seconda del tipo di terminale e a seconda di come questo è stato preconfigurato dall'utente.

• Fase 1: l'utente A invita alla sessione l'utente B (tramite una richiesta SIP INVITE), corredando l'INVITE con un corpo SDP che descrive codec e/o flussi multimediali da utilizzare nella sessione.

• Fasi 2, 3, 4: nella fase opzionale di pre-alerting, il mobile B stabilisce un'interazione con l'utente chiamato, per lasciargli impostare alcune preferenze sulle caratteristiche della sessione proposte dal chiamante. Questo è importante affinché il chiamato possa scegliere, per esempio, il flusso dati (voce, video, ...) e la qualità del servizio, prima di riservare ed impegnare pesantemente risorse preziose come quelle radio. Nel frattempo, l'utente chiamante potrà ricevere un'indicazione del pre-alerting in atto.

• Fase 5: il mobile B genera un nuovo descrittore di sessione sulla base delle interazioni avvenute nelle fasi precedenti, o semplicemente sulla base di configurazioni preimpostate dall'utente.

• Fase 6: il descrittore di sessione è propagato indietro verso il chiamante, come payload di un messaggio SIP che risponde in maniera provvisoria all'invito della Fase 1.

• Fase 7: in questa fase viene creato il trasporto necessario al supporto della sessione, sulla base delle caratteristiche negoziate (ad. Esempio, vengono attivati i secondary PDP context per lo scambio dei flussi scelti, dal lato del chiamato e da quello del chiamante).

• Fasi 8, 9, 10: completata l'assegnazione delle risorse da entrambe le parti, il mobile B può accettare la sessione senza consultare l'utente oppure può decidere di segnalargli la sessione in arrivo aspettando indicazioni su come procedere. In quest'ultimo caso, l'utente chiamante potrà ricevere un'indicazione di alerting in atto.

• Fase 11: in questa fase opzionale, i due terminali possono modificare le caratteristiche del trasporto in base ad eventuali indicazioni emesse dall'utente B e non conformi all'allocazione di risorse compiuta in precedenza (per esempio, possono essere modificati i secondary PDP context).

• Fase 12: l'utente chiamato risponde ed il terminale B ne invia conferma al terminale A. La sessione è attiva e può avere inizio la trasmissione dei flussi scelti tra le due parti.

2.8.3 Rilascio della sessione multimediale

Figura 2.7 - Procedura per il rilascio della sessione multimediale

1. Uno degli utenti coinvolti chiude la comunicazione; ciò genera un messaggio (SIP BYE) dallo UE verso il P-CSCF.

2. I passi 2 e 3 possono avvenire prima o dopo il passo 1 ed in parallelo con il passo 4. Lo UE inizia il rilascio del PDP context dedicato ai dati d'utente. Anche il sottosistema GPRS procede per parte sua a tale rilascio. Le risorse di rete IP allocate per la ricezione dei dati di questa sessione verso il terminale vengono rilasciate, a cura del GGSN.

3. Il sottosistema GPRS risponde allo UE riguardo al rilascio delle risorse di rete.

4. Il P-CSCF/PCF revoca l'autorizzazione concessa allo UE per l'uso delle risorse impiegate nella sessione Questa revoca comporterà anche un'indicazione di conferma del rilascio verso il sottosistema GPRS.

5. Il P-CSCF inoltra il BYE verso l'S-CSCF del terminale che sta chiudendo la comunicazione.

6. L'S-CSCF esegue, se necessario in base al profilo dell'utente servito, le dovute procedure di controllo dei servizi, contattando per esempio degli AS.

7. L'S-CSCF dell'utente che chiude la sessione inoltra il BYE verso l'S-CSCF dell'altro utente.

8. L'S-CSCF esegue, se necessario in base al profilo dell'utente servito, le dovute procedure di controllo dei servizi, contattando per esempio degli AS.

9. L'S-CSCF inoltra il BYE verso il P-CSCF di competenza per l'utente cui deve essere comunicato la chiusura di sessione.

10. Il P-CSCF/PCF revoca l'autorizzazione concessa allo UE per l'uso delle risorse impiegate nella sessione Questa revoca comporterà anche un'indicazione di conferma del rilascio verso il sottosistema GPRS.

11. Il P-CSCF inoltra il BYE verso lo UE.

12. Lo UE riconosce il BYE ed invia un messaggio di risposta SIP del tipo 200 OK verso il P-CSCF di competenza.

13. I passi 13 e 14 possono avvenire in parallelo con il passo 12. Lo UE inizia il rilascio del PDP context dedicato ai dati d'utente.

14. Il sottosistema GPRS rilascia per parte sua il PDP context. Le risorse di rete IP allocate per la ricezione dei dati di questa sessione verso il terminale vengono rilasciate, a cura del GGSN.

15. Il messaggio SIP OK è inviato all'S-CSCF.

16. L'S-CSCF dell'utente cui è stata notificata la chiusura di sessione inoltra la risposta 200 OK verso l'S-CSCF dell'utente che ha chiuso.

17. La risposta 200 OK procede dall'S-CSCF al P-CSCF dell'utente che ha chiuso.

18. Il P-CSCF inoltra la risposta 200 OK verso lo UE.

3 Il protocollo SIP

3.1 Introduzione

Molte applicazioni che coinvolgono la rete Internet richiedono la creazione e la gestione di una sessione, dove per sessione si intende uno scambio di dati all'interno di un'associazione di partecipanti. L'implementazione di queste applicazioni prevede la possibilità per gli utenti di spostarsi tra punti terminali, essere indirizzati attraverso molteplici identificativi e comunicare, anche simultaneamente, con diversi media, come video, audio e testo.

Il Session Initiation Protocol è un protocollo di controllo di strato applicativo, per creare, modificare e terminare sessioni multimediali, indipendente dallo strato di trasporto e dal tipo dei media impiegati nella sessione. Sia i messaggi SIP che i flussi multimediali coinvolti usano IP come infrastruttura di trasporto, tuttavia possono seguire un diverso percorso in rete, in termini di elementi attraversati.

SIP offre la possibilità di raggiungere la completa integrazione di voce e dati permettendo la comunicazione in tempo reale, in modo indipendente dalla tipologia di dispositivo usato, come telefoni fissi, mobili, Personal Computer, Personal Digital Assistant (PDA) o qualsiasi altro dispositivo basato su IP.

SIP è un protocollo testuale, basato sul modello "client-server", è parte del processo di standardizzazione IETF, ed è stato definito in [3]; è stato progettato seguendo i principi di semplicità, estensibilità, flessibilità, tipici del paradigma Internet. In termini di modello di servizio e architettura del protocollo, SIP è molto più simile a HTTP e SMTP, piuttosto che alla segnalazione SS7 delle reti telefoniche tradizionali.

Uno dei concetti più potenti di Internet è la possibilità di far elaborare le applicazioni tra un server e un browser; lo stesso vale per i servizi SIP, dove un server e un client SIP hanno il completo controllo della sessione. Questo aspetto è in completo contrasto con il modello di controllo del servizio nel tradizionale mondo a circuito, dove i punti terminali mancano di intelligenza e il controllo è centralizzato in rete. SIP fornisce completa integrazione con gli open standard del mondo Internet: permette di usare URI (Uniform Resource Indicators), DNS (Domain Name System) e MIME (Multipurpose Internet Mail Extension), in modo da favorire la compatibilità con altre applicazioni.

3.2 Funzionalità del protocollo SIP

II protocollo SIP supporta cinque funzionalità fondamentali per stabilire e terminare comunicazioni multimediali:

1. User Location: determinazione del sistema terminale da usare per la comunicazione multimediale.

2. User Availability: determinazione della volontà di una parte di essere coinvolta nella comunicazione.

3. User Capabilities: determinazione della tipologia dei media coinvolti nella comunicazione e dei parametri descrittivi.

4. Session Set Up: instaurazione della sessione sia nel lato originante che terminante.

5. Session Management: gestione della sessione, che prevede la modifica dei parametri per una sessione in corso, invocazione di servizi per conto dell'utente e terminazione della sessione.

SIP è progettato in modo tale da garantire l'indipendenza dallo strato di trasporto utilizzato, permettendo il supporto di UDP, TCP e SCTP²; tuttavia quando la dimensione del messaggio SIP supera i 1500 byte è preferibile l'uso di TCP.

SIP è basato su un modello transazionale "richiesta/risposta": ogni transazione consiste di una richiesta e una o più risposte, provvisorie e finali, associate. SIP è strutturato come un protocollo "stratificato": le funzionalità sono realizzate come stadi di elaborazione indipendenti, con un debole accoppiamento tra gli stadi; non tutte le entità SIP contengono la totalità degli strati.

3.3 Architettura del protocollo SIP

Gli elementi che costituiscono l'architettura del protocollo SIP sono:

1. User Agent (UA): rappresenta l'end-system che agisce per conto dell'utente; lo User Agent include due funzionalità distinte:

   1. User Agent Client (UAC): applicazione chiamante che crea la richiesta ed usa la macchina degli stati della Client Transaction per inviarla in rete. Il ruolo dello UAC è associato alla durata della transazione; quando si riceve una richiesta, lo UAC assume il ruolo di UAS e svolge l'elaborazione prevista per la Server Transaction.

   2. User Agent Server (UAS): entità logica che genera una risposta per una richiesta SIP che può essere accettata, reindirizzata o rifiutata. Analogamente allo UAC, il ruolo dello UAS permane solo per la durata della transazione.

2. SIP Terminal: supporta comunicazioni bidirezionali, in modalità real time con altri terminali dotati dello stack protocollare SIP ed include sia le funzionalità di UAC che di UAS.

3. Redirect Server: accetta le richieste SIP e restituisce allo UAC la lista di indirizzi, in forma di SIP URI, con cui l'utente di destinazione vuole essere contattato; il Redirect Server non può iniziare nuove richieste.

4. Registrar: rappresenta il server che accetta le richieste di registrazione (REGISTER); il Registrar tiene traccia della lista dei contatti relativi all'utente registrato, detta "Address of Record", che identifica i diversi dispositivi in cui l'utente può essere raggiunto da sessioni SIP).

5. Proxy Server: rappresenta un'entità che agisce sia da client che da server per l'elaborazione della segnalazione SIP verso la destinazione. Un Proxy Server svolge principalmente la funzionalità di instradamento, che consiste nell'inviare la richiesta al nodo successivo previsto (sia esso UA/Proxy/Redirect). I Proxy Server sono particolarmente utili per applicare criteri di controllo del servizio end-to-end, per interpretare e, se necessario, riscrivere parte del messaggio prima di inoltrarlo. Esistono due tipologie di Proxy Server:

   1. Stateful Proxy: entità logica che mantiene traccia delle transazioni client e server, per la durata dell'elaborazione di una richiesta. Non viene mantenuto lo stato della sessione, in quanto in base alle specifiche del protocollo, la procedura di abbattimento della sessione, può seguire un percorso che coinvolge nodi diversi rispetto alla fase di instaurazione.

   2. Stateless Proxy: entità logica che non mantiene memoria della transazione ed effettua solo funzionalità di rilancio e instradamento della segnalazione SIP.

6. Back to Back User Agent (B2BUA): entità logica "bifronte" formata dall'accoppiamento di due UA in modalità "back-to-back", ossia "spalla a spalla". Nel B2BUA, i messaggi SIP in arrivo verso uno dei due UA rilanciano messaggi SIP in uscita dall'altro UA. Il senso di questa operazione è quello di mantenere separati i dialoghi da un lato e dall'altro dell'interfaccia costituita dal B2BUA stesso, ad esempio per implementare servizi di chiamata anonima, oppure per modificare parti del messaggio SIP che non dovrebbero essere modificabili se non dagli estremi in comunicazione. La figura 3.1 illustra schematicamente un B2BUA ed il suo funzionamento.

Figura 3.1 - Schematizzazione di un B2BUA

3.4 Messaggi SIP

SIP è un protocollo testuale, che ricalca il modello Request/Response tipico di altri protocolli sviluppati in ambiente Internet, come HTTP e SMTP. Un messaggio SIP può essere una richiesta (Request), inviata dal client verso il server, o una risposta (Response), che transita dal server al client. La sintassi del protocollo è specificata attraverso la grammatica "Augmented Backus-NaurForm" (A-BNF). I messaggi di richiesta e di risposta hanno la stessa struttura base, che prevede:

• Start-line, che discrimina il tipo di messaggio e contiene la versione del protocollo SIP;

• Header, di cui alcuni obbligatori per il corretto trattamento del messaggio;

• Message Body, facoltativo, che fornisce alla parte chiamata informazioni sufficienti per l'instaurazione della sessione; generalmente il message body contiene un messaggio SDP (Session Description Protocol).

3.4.1 SIP Request

Il messaggio "SIP Request", la cui struttura è schematizza in figura 3.2, si distingue per avere la Start-Line costituita dalla Request-Line, che contiene il nome del metodo, la Request-URI e la versione del protocollo SIP utilizzata. SIP definisce in [3] un insieme di metodi, che sono di seguito elencati:

• REGISTER, per associare una SIP URI ad una SIP URI temporanea, che riflette la locazione di rete corrente dell'utente.

• INVITE, per instaurare la sessione e fornire le informazioni relative ai media che si vogliono utilizzare.

• ACK, per confermare l'instaurazione della sessione.

• OPTION, per interrogare un server sulle sue capacità.

• CANCEL, per cancellare una sessione "pending", ovvero non confermata da una risposta definitiva.

• BYE, per terminare una sessione.

Bisogna tener presente che quest'insieme costituisce il nucleo base dei metodi SIP; data l'estensibilità del protocollo, IETF ha definito anche altri metodi, concepiti come, per l'appunto, "estensioni" al protocollo originario.

La Request-URI è una SIP URI (Uniform Resource Indicator) che indica l'utente o il servizio cui la richiesta è indirizzata. Le entità SIP possono supportare schemi alternativi alle SIP URI, come le Tel URI, che sono, ad esempio, della forma "+1234567890@operator.doc".

Figura 3.2 - Formato delle SIP Request.

3.4.2 SIP Response

I messaggi "SIP Response" si distinguono dalle SIP Request per avere, come inizio la Status Line, formata della versione del protocollo, un codice numerico (Status Code) e una frase testuale (Reason Phrase).

Lo Status Code è formato da tre cifre intere e indica il risultato del tentativo di comprensione ed elaborazione della richiesta.

La Reason Phrase ha lo scopo di fornire una breve descrizione testuale della risposta, è indirizzata alla comprensione dell'utente e non all'elaborazione da parte dello Stack SIP.

La prima cifra dello Status Code definisce la classe della risposta; nella versione SIP/2.0 ne sono definiti sei possibili tipi:

• 1xx: "Provisional", indica la ricezione della richiesta e la continuazione dell'elaborazione della stessa;

• 2xx: "Success", indica che la richiesta è stata ricevuta, compresa ed elaborata con successo;

• 3xx: "Redirection", indica che ulteriori azioni devono essere compiute per completare l'elaborazione della richiesta;

• 4xx: "Client Error", la richiesta contiene errori di sintassi o non può essere elaborata dal server;

• 5xx: "Server Error", il server ha fallito nell'elaborazione di una richiesta apparentemente valida;

• 6xx: "Global Failure", la richiesta non può essere processata da nessun server.

In figura 3.3 è fornito uno schema del formato delle SIP Response.

Figura 3.3 - Formato delle SIP Response

3.4.3 SIP Header

Una richiesta SIP valida deve contenere, obbligatoriamente, un insieme minimo di header (detti anche "campi"), formato da: To, From,Cseq, Call-ID, Max-Forward e Via, che ne definiscono le funzionalità base. Congiuntamente questi sei header determinano infatti la modalità di instradamento delle richieste, l'indirizzamento del destinatario e l'instradamento automatico delle risposte, limitano la propagazione in rete dei messaggi, ordinano la sequenza dei messaggi scambiati e identificano in maniera univoca la transazione.

• From: l'header From indica l'identità logica dell'iniziatore della richiesta e contiene un valore univoco per il parametro "tag", che facilita l'identificazione del dialogo. Identifica l'utente per cui svolgere le funzionalità di servizio per la fase "Mobile originating".

• To: l'header To specifica il destinatario "logico" della richiesta o l'Address of Record dell'utente o della risorsa a cui è indirizzata la richiesta. Identifica l'utente per cui svolgere le procedure per la fase "Mobile Terminating".

• Call-ID: l'headerCall-ID rappresenta un identificativo per raggruppare insieme una serie di messaggi; deve avere lo stesso valore per tutte le richieste e le risposte generate da entrambi gli User Agent coinvolti in un dialogo. Il Call-ID deve essere lo stesso per ogni messaggio di registrazione inviato da uno User Agent. In caso di generazione di richieste che iniziano un nuovo dialogo o che sono transazioni a sé stanti, il valore del Call-ID deve essere selezionato dallo UAC in modo da essere globalmente unico.

• Cseq: l'header CSeq è usato per identificare e ordinare le transazioni; consiste di un numero di sequenza e del metodo che deve coincidere con quello del messaggio. Il Cseq è incrementato di uno per ogni nuova richiesta generata da uno UAC.

• Max-Forward: l'header Max-Forward serve a limitare il numero di nodi attraverso cui una richiesta può transitare; il campo consiste di un numero intero, posto inizialmente a 70, che è decrementato di uno ad ogni nodo attraversato. Se il valore di Max-Forward arriva a zero prima di raggiungere la destinazione, la richiesta è rifiutata ed è generata la risposta di errore "483-Too Many Hops".

• Via: l'header Via indica il percorso, in termini di entità SIP attraversate, seguito da una richiesta e determina la strada da seguire a ritroso per le risposte. Uno User Agent Client che genera una richiesta memorizza il proprio indirizzo nel campo Via; ogni Proxy Server coinvolto nell'instradamento della richiesta aggiunge il proprio indirizzo in cima alla lista degli header. Il campo indica inoltre il protocollo di trasporto usato per inviare il messaggio, l'indirizzo di rete dell'host associato al client e il numero di porta in cui ricevere la risposta.

• Contact: l'header Contact fornisce una SIP URI che può essere usata per contattare la specifica istanza dello User Agent per le successive richieste. Il campo Contact, nel caso di richieste INVITE, contiene l'URI verso cui lo UA vuole ricevere risposte e successive richieste, anche al di fuori di dialoghi già precedentemente stabiliti.

3.4.3.1 SIP header relativi al Message Body

I messaggi SIP possono contenere un body, la cui interpretazione dipende dal metodo della richiesta; per il trattamento del message body sono definite degli header "ad-hoc", descritti di seguito.

• Content-Length: La lunghezza, espressa in byte, del message body è contenuta nell'header Content-Length, che è obbligatorio nel caso si usi TCP come protocollo di trasporto, per la corretta ricezione di tutti i byte del messaggio.

• Content-Type: l'header Content-Type indica al ricevente la tipologia di media contenuto nel message body; il campo deve essere necessariamente presente se è presente il message body.

• Content-Disposition: l'header Content-Disposition descrive come il message body debba essere interpretato dallo UAC o dallo UAS.
  Sono definiti vari tipi di Content-Disposition:

  • "session": il body contiene i parametri descrittivi della sessione

  • "render": il body deve essere visualizzato nel display;

  • "icon": il body contiene un'immagine da usare come icona

  • "alert": il body contiene informazioni come audio clip che devono essere usati dallo User Agent per notificare l'utente dell'arrivo di una chiamata.

3.4.3.2 SIP Header relative all'instradamento

• Route: l'header Route è usato per forzare l'instradamento di una richiesta attraverso una serie di SIP Proxy; le richieste possono avere una lista, definita in fase di registrazione, di entità di rete SIP da attraversare.

• Record-Route: l'header Record-Route è incluso nella richiesta iniziale dai SIP Proxy che vogliono essere contattati per i successivi messaggi di segnalazione all'interno della stessa sessione; ogni elemento di rete SIP aggiunge l'header Record-Route contenente il proprio indirizzo, in forma di SIP URI.

3.4.4 SIP Tag

Il parametro "tag" è usato nei campi To e From dei messaggi SIP come parte dell'identificativo del dialogo, che è formato dal Call-ID e due tag, uno per ogni partecipante al dialogo. Quando uno User Agent invia una richiesta al di fuori di un dialogo, viene incluso solo il tag per l'header From. II dialogo è completato da una o più risposte, ciascuna delle quali include il tag per il campo To. Ogni tag deve essere globalmente unico e prevede l'utilizzo di almeno 32 bit generati in maniera casuale.

3.5 Il Dialogo SIP

II dialogo rappresenta una relazione "peer-to-peer " tra due User Agent, che persiste per un intervallo di tempo. Il concetto di dialogo è utile per:

• identificare tutte le transazioni relative ad una sessione;

• facilitare il sequenziamento dei messaggi tra due User Agent;

• distinguere tra il caso di re-INVITE, per una nuova negoziazione dei parametri di una sessione già in corso, e il caso di nuove richieste di INVITE.

3.5.1 Dialog-ID

Il dialogo è identificato ad ogni User Agent da un Dialog-ID, che è formato da tre elementi: "Call-ID ", "Local Tag" e "Remote Tag".

Il Dialog-ID non è lo stesso per entrambe le parti coinvolte nella comunicazione, in particolare il local tag di uno UA è uguale al remote tag dell'altro UA, dove per tag si intende un "opaque token" che facilita la generazione di identificativi univoci.

In caso di UAC, il local tag corrisponde al tag presente nel campo From, per lo UAS il local tag corrisponde al tag presente nell'header To.

3.5.2 Stato del Dialogo SIP

Ad ogni dialogo è associato uno stato, mantenuto per tutta la durata della sessione, necessario per il corretto sequenziamento di messaggi. Gli elementi che formano lo stato del dialogo sono:

• Dialog-ID: identificativo del dialogo;

• Local Sequence Number, per ordinare i messaggi inviati al peer;

• Remote Sequence Number, per ordinare le richieste ricevute;

• Local URI, per indicare l'iniziatore del dialogo;

• Remote URI, per indicare la parte chiamata (peer);

• Contact URI del peer;

• Secure Flag, che assume il valore "vero" se la richiesta è ricevuta attraverso TLS;

• Route Set, che identifica la lista di server SIP da attraversare per inviare la richiesta al peer.

Un dialogo può trovarsi nello stato "early", che è creato alla ricezione di una risposta provvisoria, per poi passare nello stato "confirmed" quando è ricevuta una risposta finale del tipo 2xx.

3.5.3 Creazione del Dialogo SIP

Il dialogo è creato con la ricezione di risposte appartenenti alle classi 101-199 o 2xx, che contengono un tag nel campo To. Non tutti i tipi di messaggi SIP determinano la creazione del dialogo: INVITE genera un dialogo, le richieste REGISTER e OPTION non instaurano il dialogo e sono indicate come transazioni a sé stanti o "stand-alone transactions".

3.5.4 Terminazione del Dialogo SIP

Il dialogo SIP, nello stato "confirmed", è terminato con l'invio del messaggio BYE. Per i dialoghi nello stato "early", che non hanno ricevuto una risposta definitiva, è usato il metodo CANCEL.

3.6 La stratificazione del protocollo SIP

SIP può essere descritto come un protocollo stratificato. Tuttavia non tutti gli strati sono presenti in ogni entità SIP ed è inoltre possibile che uno strato superiore interagisca direttamente con uno inferiore "evitando" di attraversare il livello intermedio. Gli stati definiti per il protocollo SIP sono il Transaction User (TU), il Transaction e il Transport.

3.6.1 Transaction User (TU)

Ogni entità SIP, ad eccezione dei Proxy Stateless, è considerata una "Transaction User" (TU). Quando una TU vuole inviare una richiesta SIP, crea un'istanza della client transaction, le passa la richiesta, insieme all'indirizzo IP, la porta e il protocollo di trasporto da utilizzare. La Transaction User è responsabile di cancellare le transazioni non appena è ricevuta la risposta relativa. Le entità SIP, ovvero gli User Agent Client (UAC), gli User Agent Server (UAS), i Proxy Stateless, i Proxy Stateful e i Registrar contengono un "core" che distingue ciascuno dagli altri ed è responsabile della gestione della segnalazione SIP. Il core, tranne che per i Proxy Stateless, è rappresentato dal Transaction User.

3.6.2 Transaction

Il processamento della segnalazione SIP è basato sul concetto di transazione: una transazione consiste di una singola richiesta e di tutte le risposte ad essa relative, che includono nessuna o più risposte provvisorie e una o più risposte definitive.

Lo strato "Transaction" gestisce la ritrasmissione dei messaggi SIP, valuta la corrispondenza tra richieste e risposte e tiene traccia del valore dei timer per le ritrasmissioni. Le transazioni hanno un lato client (Client Transaction) e un lato server (Server Transaction): la Client Transaction è responsabile dell'invio delle richieste, la Server Transaction gestisce l'elaborazione della richiesta e l'invio delle risposte relative.

Sia la Client Transaction che la Server Transaction sono presenti negli User Agent e nei Proxy Stateful, mentre i Proxy in modalità Stateless non tengono traccia delle transazioni. L'elaborazione delle transazioni è descritto attraverso una macchina degli stati, che si differenzia nel caso di Client Transaction e Server Transaction.

3.6.3 Transport

Lo strato di Trasporto (Transport Layer) definisce la modalità, per un client, di inviare richieste e ricevere risposte e, parallelamente, per un server, di ricevere richieste e inviare risposte in rete. Quando è inviato un messaggio, lo strato di trasporto sceglie il protocollo di rete da utilizzare, UDP o TCP secondo la dimensione del messaggio (oltre 1500 byte si preferisce usare TCP per evitare la frammentazione); se è usato TCP, il Transport Layer è responsabile della gestione delle connessioni. Lo strato gestisce inoltre la corrispondenza del messaggio con la relativa transazione: se è trovato il matching, il messaggio è passato alla transazione, altrimenti è inoltrato direttamente al core dell'entità SIP.

3.7 Esempi di Procedure SIP

Una sessione SIP è un insieme di flussi multimediali che scorrono da un insieme di mittenti ad un insieme di relativi riceventi. SIP supporta la segnalazione per iniziare, terminare e rinegoziare i parametri di una sessione, permettendo l'aggiunta, la modifica o anche la rimozione di media per una sessione già in corso. Si riassumono di seguito le procedure più comuni per la gestione di una sessione SIP.

3.7.1 Registrazione

Per iniziare una sessione, le entità SIP devono conoscere l'host corrente attraverso cui è raggiungibile l'utente di destinazione. Gli elementi di rete SIP, per "trovare" l'utente, consultano un servizio astratto di localizzazione ("Location Service"), responsabile del binding degli indirizzi relativi ad un particolare dominio. Il processo di Registrazione prevede l'interazione con il Location Service di un dominio, per creare la mappatura tra la SIP URI registrata e un insieme di "Contact Address" definiti dall'utente. La procedura consiste nell'invio della richiesta REGISTER ad un particolare UAS, detto "Registrar", che agisce da "front-end" per le registrazioni relative ad un dominio. Il Registrar è poi consultato dal Proxy Server responsabile per l'instradamento nel particolare dominio. Occorre sottolineare che il Registrar e il SIP Proxy rappresentano entità logiche che, fisicamente, possono coesistere in un solo elemento di rete.

La richiesta REGISTER può aggiungere, rimuovere o richiedere il binding degli indirizzi. La registrazione di un utente può essere realizzata da una terza parte autorizzata: si parla in questo caso di "Third Party Registration". REGISTER non instaura un dialogo; ogni messaggio di registrazione deve contenere necessariamente i seguenti header:

Request-URI: indica il dominio del location service, ovvero del Registrar responsabile della registrazione.

To: contiene l'indirizzo per cui la registrazione è creata o modificata; il To e la Request URI in questo caso differiscono.

From: contiene l'indirizzo della persona responsabile della registrazione; il valore è lo stesso dell'header To a meno che la richiesta rappresenti una "Third Party Registration".

Call-ID: tutte le registrazioni da parte di un client devono contenere lo stesso valore per il campo Call-ID.

Cseq: lo UA deve incrementare il valore di Cseq per tutte le registrazioni.

Contact: una registrazione può contenere il campo Contact con uno o più valori per il binding degli indirizzi.

Figura 3.4 - Esempio di registrazione SIP

Il messaggio REGISTER può contenere l'header opzionale Expire, che indica la durata in secondi della registrazione. Un esempio di registrazione è illustrato in figura 3.4, dove per brevità sono stati omessi alcuni dei campi citati in precedenza come obbligatori; inoltre, per avere da tale figura un esempio di Third Party Registration, basta sostituire il contenuto del campo To con quello della terza parte per conto della quale si esegue la registrazione.

3.7.2 Instaurazione della sessione ("Session Set-up")

Le sessioni SIP sono instaurate attraverso una procedura che si basa sul modello "Three-way-handshaking".

Quando l'utente A vuole instaurare una sessione con l'utente B, lo User Agent A invia una richiesta INVITE allo User Agent B, che contiene nel message body i parametri descrittivi della sessione che vuole creare. Il Proxy SIP, coinvolto nell'instradamento della chiamata, invia la risposta provvisoria "100 Trying", che serve ad inibire la ritrasmissione delle richieste da parte della Client Transaction associata allo UA mittente, e consulta il Location Service per stabilire quale sia il contatto associato all'address-of-record per lo User Agent B; ricevuta tale informazione, il Proxy inoltra la richiesta verso lo User Agent B. Lo User Agent B invia dapprima la risposta provvisoria "100 Trying" al proxy, e successivamente la risposta provvisoria "180 Ringing" all'utente A, a conferma della ricezione del messaggio INVITE ed ad indicazione che l'utente B è stato notificato dell'arrivo della sessione.

Quando la chiamata/sessione è accettata, lo User Agent B invia la risposta definitiva "200 OK", che permette di negoziare i parametri di sessione e scambiare informazioni per la ricezione dei media, come la porta e la tipologia di codec da utilizzare.

Figura 3.5 - Instaurazione di una Sessione SIP

La procedura "Three-way-Handshaking" si conclude quando l'utente A invia il messaggio "ACK" (Acknowledgement) all'utente B, che conferma la ricezione della risposta. La sessione multimediale ha quindi inizio: il trasporto dei flusso multimediali avviene attraverso un altro protocollo di rete, tipicamente RTP. Lo scambio di messaggi descritto è illustrato in figura .

Nell'esempio precedente, lo scenario prevede l'interazione con un Proxy Server. La destinazione della richiesta è identificata dalla Request-URI e ogni Proxy interessato nell'elaborazione della segnalazione deve risolvere la localizzazione dell'utente e inviare correttamente la richiesta. I Proxy possono modificare i campi del messaggio SIP ad eccezione degli header necessari ad identificare il dialogo. In genere, solo la richiesta che instaura il dialogo attraversa tutta la catena di SIP Proxy, mentre le richieste successive sono scambiate direttamente tra i due User Agent. Alternativamente, un SIP Proxy che vuole rimanere nel percorso della segnalazione successiva all'interno del dialogo, introduce l'header Record-Route contenente la sua SIP URI.

Va sottolineato che non è necessario avere un SIP Proxy per instaurare una sessione multimediale tra due entità che dispongono dello Stack protocollare SIP (SIP enabled): due punti terminali SIP-enabled, a conoscenza del reciproco indirizzo IP, possono scambiarsi messaggi SIP per attivare una sessione multimediale.

3.7.3 Abbattimento della sessione ("Session Tear-down")

Figura 3.6 - Procedura di Session Tear-down.

Dopo aver instaurato una sessione SIP, sia l'utente A che l'utente B possono terminare la sessione emettendo una richiesta SIP BYE. La struttura del protocollo SIP prevede, infatti, che uno User Agent possa svolgere il ruolo di client e server durante la sessione. La richiesta BYE deve essere invita all'interno di un dialogo già stabilito, quindi il messaggio deve contenere i corretti campi ("To tag", "From tag" e "Call-ID") che permettono di identificare il dialogo. La risposta di conferma prevista per il BYE è il 200 OK come illustrato in figura 3.6.

3.7.4 Modifica di una sessione esistente

SIP permette il controllo dinamico dei media della sessione, come aggiungere o rimuovere un media o cambiare i codec. La funzionalità viene realizzata attraverso l'invio di un nuovo messaggio di INVITE all'interno dello stesso dialogo, indicato usualmente come re-INVITE, con un body SDP differente.

3.8 Estensioni al protocollo SIP

Come già accennato nell'introduzione, il protocollo SIP è un protocollo estensibile, nel senso che è possibile da parte di IETF definire in maniera relativamente facile delle estensioni al protocollo base, così come definito in [3]. Tali estensioni possono essere di vari tipi:

• nuovi metodi, che definiscono quindi nuove classi di richiesta;

• nuove risposte, inteso come allocazione di nuovi Status-Code compresi nelle classi possibili di risposta;

• nuove intestazioni (header), che trovano collocazione in alcuni messaggi SIP.

IETF ha definito molte estensioni al protocollo SIP, con l'intento di facilitarne l'uso anche in ambienti con esigenze particolari che non sono soddisfatte dal protocollo di base. Si presentano di seguito alcuni esempi:

• Presence: notifica di eventi ad un'entità SIP che ne faccia richiesta tramite i metodi SUBSCRIBE e NOTIFY.

• Instant messaging, tramite il metodo SIP MESSAGE.

• Trasporto di informazioni aggiuntive durante una sessione SIP senza modificare lo stato della sessione stessa e seguendo il percorso di segnalazione iniziale, tramite il metodo INFO.

Per quanto riguarda le intestazioni definite come estensioni, si presentano di seguito alcuni esempi.

Intestazione Path: questa estensione è applicabile alle richieste REGISTER ed alle risposte relative. Lo scopo di questa estensione al protocollo è quello di permettere ai proxies coinvolti in un'operazione di registrazione di restare nel percorso di segnalazione per le successive transazioni, aggiungendosi all'intestazione Path quando la richiesta li attraversa; all'arrivo al registrar, l'intestazione Path viene copiata nella risposta 200 OK da inviare verso lo UA. Dal punto di vista dello UA invece, l'intestazione Path, ricevuta in una risposta ad una registrazione, permette di verificare per quali proxies la registrazione sia effettivamente transitata. Il meccanismo di funzionamento è simile a quello dell'intestazione Record-Route, che tuttavia non è applicabile al metodo REGISTER. Maggiori informazioni al riguardo sono reperibili in [6]

Intestazione Service Route: questa estensione è applicabile alle risposte 200 OK a richieste di tipo REGISTER, da parte del registrar che invia la risposta. In tale campo il registrar include un percorso di rete che vuole comunicare allo UA, comprendente certe entità di rete che possono fornire dei servizi allo UA stesso. Lo UA che riceve tale intestazione nella risposta alla registrazione la memorizza, associandola al particolare address-of-record per il quale si è richiesta la registrazione; successivamente, può utilizzare il valore memorizzato per inserire una campo Route in una richiesta, forzandone quindi l'instradamento e il servizio secondo quanto prescritto dal registrar. Maggiori informazioni al riguardo sono reperibili in [1].

3.9 L'uso della codifica S/MIME nel protocollo SIP

La specifica SIP prevede la possibilità per gli UA di inviare message bodies codificati tramite codifica S/MIME, per proteggerli da eventuali modifiche non autorizzate. Inoltre, esiste anche la possibilità di includere un intero messaggio SIP nel message body di un altro, codificandolo tramite S/MIME; le intestazioni del messaggio che è stato incapsulato vengono replicate nel messaggio che funge da "involucro". Questo incapsulamento fornisce una certa protezione a tali intestazioni, perché una modifica delle intestazioni esterne potrebbe essere rivelata per confronto con quelle interne decodificate. Per ulteriori dettagli, si rimanda a [3].

4 Il dibattito tra IETF e 3GPP

4.1 Liaison Statement da IETF a 3GPP

Nel Settembre 2002, IETF, nella persona di uno dei direttori del SIP Working Group e per mezzo di una e-mail indirizzata al suo omologo del gruppo di lavoro TSG-CN di 3GPP, ha sollevato degli interrogativi sull'interoperabilità tra gli stack SIP di IETF e di 3GPP.

Il documento (definito, in ambito 3GPP ed IETF, Liaison Statement (LS)) contenente l'opinione di IETF si articola in diversi punti, alcuni di carattere generale, altri più specifici che riguardano problemi concreti: vi sono entità dell'IMS il cui comportamento (secondo le specifiche 3GPP) non è conforme a quanto stabilito dallo standard SIP elaborato da IETF. Nel seguito del paragrafo vedremo in dettaglio le questioni introdotte.

4.1.1 Motivazioni generali

Una linea guida fondamentale per IETF è quella di progettare i protocolli in modo che abbiano la più larga applicabilità possibile, per quel che riguarda reti pubbliche o private, interconnesse o meno, che decidano di utilizzare tali protocolli. Sulla scorta di ciò, IETF considera pericoloso lo sviluppo di alternative agli standard che definiscono i protocolli, siano esse eccezioni agli standard o sottoinsiemi di essi (questo anche se le reti per cui i "profili" sono progettati non sono interconnesse). Il rischio di tali alternative è quello di generare incompatibilità tra i vari "profili" dello stesso protocollo che si verrebbero a creare, con il risultato di rendere difficile, se non impossibile, una futura interconnessione tra reti conformi a "profili" diversi. Dal momento che la tendenza nel mondo delle telecomunicazioni è quella della progressiva integrazione di sistemi differenti, l'interoperabilità tra di essi rimane un problema critico, anche se non produce alcun effetto visibile finché i sistemi non sono interconnessi.

Posto questo, IETF ricorda che il requisito fondamentale perché un'implementazione (come l'IMS) si possa definire conforme al protocollo secondo cui è stata progettata (come SIP), è la sua possibilità di interoperare, anche con un'opportuna configurazione, in ambienti non appositamente progettati per questo (come per l'appunto è Internet per l'IMS). Se non c'è interoperabilità l'implementazione, nonostante sia per altri aspetti conforme allo standard, è di fatto un'altra cosa e non può essere assimilata ad un'implementazione totalmente conforme.

4.1.2 Linee guida per l'interoperabilità

Con questa premessa, 3GPP viene invitata a considerare due criteri per stabilire se la specifica IMS induce problemi di interoperabilità:

1. La specifica IMS non dovrebbe di per sé limitare in alcun modo la possibilità per i propri utenti di utilizzare servizi SIP erogati su Internet, o di instaurare sessioni con altri utenti su Internet (in entrambi i casi, si tratta di azioni che richiedono contatti con un dominio esterno a quello dell'operatore IMS). Eventualmente, questa possibilità dovrebbe essere limitata con altri mezzi, per esempio attraverso la configurazione di criteri locali di protezione della rete IMS. Un utente dell'IMS dovrebbe (almeno potenzialmente) disporre di questa possibilità; e questo senza l'interposizione di un gateway a livello applicazione che modifichi i protocolli IMS. Quindi, l'utente dell'IMS dovrebbe poter accedere ad applicazioni residenti su Internet anche senza esplicito supporto da parte dell'IMS stessa. Ciò implica che l'utente IMS abbia a disposizione un implementazione di SIP completa anche e soprattutto per ciò che riguarda le capacità di sicurezza offerte da SIP.

2. Dal momento che la specifica IETF di SIP, assieme alle altre specifiche correlate, consente la realizzazione di applicazioni Internet robuste e sicure, un gestore IMS dovrebbe essere in grado di utilizzare un qualsiasi sistema SIP commerciale che implementi le specifiche suddette (oltre al supporto per le capacità proprie dell'IMS), così come esso viene fornito, al più servendosi delle opzioni di configurazione previste per definire i criteri di sicurezza locali. Con tali opzioni si dovrebbero definire tutti quegli aspetti interni non ampiamente implementati nel dominio esterno all'IMS (ad esempio autenticazione locale, AAA, reporting). D'altra parte, chi costruisce un'implementazione SIP non dovrebbe prevederne due diverse a seconda che si tratti di SIP in Internet o di SIP in IMS. Il punto focale resta quello di contenere le differenze tra le due implementazioni (IMS e non-IMS) a diverse scelte di configurazione, mantenendo la conformità alle specifiche IETF.

4.1.3 Problemi specifici

Nel documento IETF identifica tre classi di problemi cui le questioni specifiche possono essere ricondotte.

1. I nodi CSCF di IMS mandano messaggi SIP che secondo IETF sono riservati agli User Agent, senza implementare tutte le funzionalità di questi ultimi. La giustificazione proposta da 3GPP a questo comportamento, ossia il considerare il CSCF come un "back to back UA" (B2BUA) a contatto con l'UA finale, non è fondata: per funzionare in questo modo, il CSCF dovrebbe implementare a tutti gli effetti un UA.

2. I nodi CSCF di IMS modificano l'intestazione dei messaggi SIP in un modo esplicitamente vietato ai proxy da IETF, senza implementare le funzionalità di User Agent che consentirebbero ciò.

3. I nodi CSCF di IMS modificano il corpo dei messaggi SIP in un modo esplicitamente vietato ai proxy da IETF, ancora una volta senza implementare le funzionalità di User Agent che consentirebbero ciò.

Nel seguito del paragrafo si vedranno uno per uno i problemi reali di interoperabilità, così come esposti nel documento.

4.1.3.1 Invio di BYE da parte del P-CSCF

Il P-CSCF può inviare, per conto dell'UA coinvolto in una sessione, un BYE destinato a chiudere la sessione stessa. Questo ad esempio avviene quando al P-CSCF è notificata per altri mezzi (e cioè dallo strato radio del protocollo) la perdita di contatto da parte dello UA cui il P-CSCF si sostituisce.

Naturalmente, non implementando le funzionalità di UA, il P-CSCF non dispone delle credenziali per autenticare questa richiesta presso lo UA cui è diretta: di conseguenza, UA conformi alla specifica SIP e dotati di supporto per l'autenticazione dei messaggi, considereranno tali BYE come messaggi falsi, ignorandoli. Inoltre, questo rende possibili attacchi di tipo DOS (Denial Of Service) verso gli UA di 3GPP con BYE falsi, sfruttando la vulnerabilità data dal dover accettare questo tipo di messaggi senza autenticarli.

4.1.3.2 Cancellazione delle intestazioni per l'instradamento

Prima di passare i messaggi SIP all'UA, il P-CSCF cancella le parti dell'intestazione relative all'instradamento del messaggio stesso, e cioè i campi Route, Record-Route, Via, Path,Service-Route; tali parti verranno reintrodotte dallo stesso P-CSCF nei messaggi in direzione opposta (ricevuti dall'UA ed inoltrati verso la destinazione), potendo anche sostituire un eventuale campo Route introdotto dall'UA.

Questo comportamento produce degli effetti collaterali che di seguito elenchiamo.

1. Innanzitutto, la modifica del contenuto del messaggio rende inefficace la protezione da estremo ad estremo messa in atto dagli UA con la codifica S/MIME dei messaggi: se il contenuto è modificato, la signature calcolata sul messaggio prima della modifica non è più valida.

2. Dal punto di vista dell'instradamento, la cancellazione del campo Route introdotto dall'UA impedisce all'UA stesso l'accesso a servizi esterni all'IMS utilizzando le metodologie di "loose routing".

3. Infine, la cancellazione effettuata sul messaggio inbound dell'intestazione Path impedisce all'UA di conoscere quali proxy siano stati informati tramite tale campo della sua registrazione: ciò espone gli utenti 3GPP al rischio di registrazione presso server esterni soggetti ad attacchi del tipo "Man-In-The-Middle" (MITM) sui messaggi REGISTER, senza alcuna possibilità di rivelare tali attacchi.

4.1.3.3 Le modifiche al corpo SDP del messaggio SIP

Il CSCF può modificare i contenuti SDP di un messaggio SIP diretto all'UA, e contenente l'offerta o la controfferta per i media da impiegare nella sessione. Specificatamente i CSCF dotati di questa prerogativa sono il P-CSCF e l'S-CSCF; lo scopo è quello di selezionare, fra quelli presenti nel messaggio SDP, i codec più vantaggiosi per il gestore del servizio, eliminando gli altri. Gli effetti collaterali di questo comportamento sono:

1. la perdita di efficacia della protezione da estremo ad estremo del messaggio SDP, posta in essere dagli UA tramite la codifica S/MIME del messaggio stesso, per i motivi già detti in precedenza;

2. l'impossibilità da parte di un UA di 3GPP di interoperare con un UA esterno, quando tutti i codec in comune ai due UA non siano vantaggiosi per il gestore: in tal caso, benché i due UA possano potenzialmente comunicare utilizzando i codec in comune, il P-CSCF preclude l'uso di essi all'UA, cancellandoli dai messaggi SDP in transito.

4.1.3.4 Manipolazione delle intestazioni From e To

Il S-CSCF potrebbe (IETF crede che l'argomento sia ancora dibattuto all'interno di 3GPP: da qui il condizionale) alterare le intestazioni From: e To: dei messaggi SIP, per motivi di tutela della privacy imposti dalle normative vigenti, soprattutto in Europa. Oltre alla già citata perdita di efficacia per la protezione da estremo ad estremo tramite la codifica S/MIME del messaggio, questo comportamento impedisce il funzionamento dei servizi esterni che utilizzino le informazioni contenute nei campi delle intestazioni suddette: e cioè la maggior parte degli attuali servizi di identificazione del chiamante implementati in entità SIP.

4.1.3.5 Filtro delle identità sconosciute al P-CSCF

Il P-CSCF opera una selezione dei messaggi provenienti dall'UA in base all'identità contenuta nell'intestazione dei messaggi stessi, nel campo P-Asserted-Identity: se tale campo manca o contiene un'identità non nota al P-CSCF (perché non associata ad un'identità pubblica dell'utente) l'identità dell'utente che ha generato il messaggio viene modificata utilizzando il valore di default previsto dal profilo dell'utente stesso. In conseguenza di ciò, l'utente 3GPP non potrà utilizzare un'identità diversa da quella fornita dall'operatore di rete; questo potrebbe portare all'impossibilità di usufruire di servizi di terze parti che forniscano altre identità a meno che tale funzione sia implementata tramite un B2BUA che garantisca in ogni caso l'utilizzo dell'identità appropriata nei messaggi scambiati con il P-CSCF, fornendo invece un'identità alternativa negli altri messaggi.

4.1.3.6 Codifica delle intestazioni per l'instradamento

L'I-CSCF può, in determinate circostanze, codificare parti d'intestazione dei messaggi SIP uscenti: in particolare, quelle necessarie all'instradamento del messaggio stesso attraverso la rete di cui l'I-CSCF è il punto d'accesso (il primo per i messaggi inbound, l'ultimo per i messaggi outbound). Questo accade quando all'I-CSCF venga richiesto di comportarsi nella modalità cosiddetta THIG (Topology Hiding Internetwork Gateway), allo scopo di mantenere riservate quelle informazioni che possano rivelare la struttura interna della rete 3GPP all'esterno della rete stessa.

Questo comportamento, tollerato nelle prime specifiche di SIP, è stato esplicitamente scoraggiato nelle versioni più recenti delle specifiche stesse. Per questo motivo IETF ritiene possa costituire un problema, sebbene l'impatto sull'interoperabilità non ne sia stato ancora esattamente valutato.

4.1.3.7 Manipolazione del corpo dei messaggi

Alcuni elementi della rete 3GPP, come i CSCF e gli AS, possono manipolare il corpo dei messaggi SIP che transitano in essi. La specifica SIP vieta la manipolazione del corpo dei messaggi ad opera di entità di rete che non implementano le funzionalità di UA: questo perché tale modifica del corpo del messaggio rende inservibile la protezione da estremo ad estremo, tramite codifica S/MIME operata dagli UA sul messaggio stesso. Ciò avviene esattamente per le stesse ragioni già viste a proposito della modifica delle intestazioni del messaggio SIP: la firma digitale, calcolata sul messaggio iniziale, non è più valida per quello modificato.

Quindi, la manipolazione dei messaggi da parte di AS e/o CSCF è in contrasto con la specifica SIP, dal momento che questi elementi di rete non implementano quella parte di specifiche relative all'UA che consentirebbe loro di salvaguardare la protezione da estremo ad estremo.

4.2 Soluzioni proposte

4.2.1 Linee guida per la stesura delle soluzioni

Dal momento che il documento è stato reso noto in primo luogo al direttore del gruppo di lavoro TSG-CN di 3GPP, le prime reazioni sono arrivate da questo gruppo, dopo il 17° meeting, tenutosi a pochi giorni dalla comunicazione di IETF. La risposta del CN WG non è direttamente rivolta a IETF (anche perché non contiene proposte concrete, difficili da pensare e realizzare nel breve lasso di tempo intercorso dalla notifica), ma al gruppo di lavoro TSG-SA. Ciò che rende interessante il documento è la presenza di indicazioni da seguire per le linee di comportamento dei gruppi di lavoro di 3GPP, cosa che permette di chiarire quali sono le premesse di fondo che porteranno alle soluzioni proposte. Le indicazioni vengono illustrate di seguito in dettaglio.

1. Il TSG-CN si trova d'accordo con IETF sugli obiettivi ideali per l'interoperabilità, così come riportati nel documento e riassunti nel paragrafo precedente. Tuttavia i cambiamenti strutturali per l'IMS, al fine di assicurare l'interoperabilità, vanno rapportati allo sforzo, in termini di tempo e risorse, necessario per conseguire tale fine.

2. Le questioni presentate da IETF vanno analizzate dai gruppi di lavoro che saranno coinvolti, innanzitutto al fine di quantificare lo sforzo di cui al punto precedente; poi al fine di cogliere le eventuali implicazioni in termini di variazioni dei requisiti e/o architetturali.

3. L'analisi introdotta al punto precedente consente una divisione dei problemi di interoperabilità in due classi: quelli prontamente risolvibili, (senza modifiche ai requisiti di 3GPP), e quelli che invece richiedono un impegno maggiore e/o hanno impatto sui requisiti.

4. Per la prima classe, il TSG-CN invita a trovare una soluzione entro dicembre 2002, in modo da poter includere le modifiche nella Release 5

5. Per la seconda classe, il TSG-CN invita alla collaborazione i gruppi appropriati di 3GPP ed IETF (magari anche con un workshop in comune), per formulare soluzioni da aggiungere eventualmente alla futura Release 6 dell'architettura. In quest'ambito, TSG-CN rimarca l'importanza di mantenere la compatibilità tra le due Release, anche e soprattutto per quello che riguarda le funzionalità IMS implementate negli UA rispondenti alle specifiche 3GPP.

Infine, TSG-CN detta alcune direttive per il TSG-SA. Accertato l'accordo sulle direttive per l'elaborazione delle soluzioni, TSG-CN chiede che:

1. i WG di SA rivedano i propri requisiti, architetturali e di sicurezza, tenendo conto dei problemi posti in evidenza da IETF, e collaborino con gli appropriati WG di CN per la stesura delle possibili soluzioni;

2. il TSG-SA risponda ad IETF, per comunicare quanto stabilito, e assicurandosi di porre in risalto l'importanza della compatibilità fra le release presente e futura dell'IMS; tale risposta andrà inoltrata anche ai WG di SA e CN coinvolti, affinché la posizione di 3GPP sia resa nota anche a loro.

4.2.2 L'analisi del 26° meeting del WG CN1

La prima analisi proposta nel dibattito nell'ambito di 3GPP arriva al termine del 26° meeting del CN1 WG (fine Settembre 2002). Si tratta di un Liaison Statement, indirizzato ai gruppi di lavoro SA1, SA2, SA3, (nella qualità di WG coinvolti nell'analisi, come si vedrà meglio in seguito e come previsto dalle linee guida di cui al paragrafo precedente) ed ai TSG CN ed SA. In questo documento il WG CN1 analizza punto per punto le questioni sollevate da IETF nella propria relazione: nei sottoparagrafi seguenti verranno esposti i risultati raggiunti, integrandoli, dove opportuno, con ulteriori informazioni.

4.2.2.1 Invio di BYE da parte del P-CSCF

CN1 sostiene che il problema del possibile attacco di tipo DOS verso uno UA 3GPP-compliant (basato sull'uso di BYE contraffatti da parte dell'attaccante), è già stato affrontato e parzialmente risolto. La soluzione per quel che riguarda attacchi provenienti da altri UA 3GPP-compliant, consiste nel verificare, da parte del P-CSCF, la provenienza dei BYE, accertandosi che essi provengano tutti dallo stesso terminale che ha iniziato il dialogo: nel caso in cui questa condizione non si verifichi, il P-CSCF considererà come contraffatti i BYE, e non li inoltrerà verso lo UA di destinazione. La situazione è diversa per ciò che riguarda gli attacchi dall'esterno della rete IMS, come ad esempio da parte di uno UA SIP-compliant operante in Internet: se fossero carpiti i parametri di stato di un dialogo, l'attacco a tale dialogo sarebbe possibile, perché non ci sarebbe modo di distinguere BYE autentici da BYE contraffatti. Questa parte di problema, secondo CN1, solleva questioni di interoperabilità con Internet e resta per ora irrisolta; sempre nell'opinione di CN1, andrà risolta nel corso dell'elaborazione della Release 6.

CN1 identifica la fonte del problema descritto da IETF in un requisito architetturale posto dal WG SA2 nel documento tecnico che illustra le specifiche di stage 2 per l'IMS [10], e che viene di seguito descritto. La figura 4.1 illustra quel che accade al momento di una chiusura di sessione per perdita di copertura radio. È contemplato il caso di UA appartenenti a differenti Home Network e residenti in due distinte Visited Network; va inoltre notato che 3GPP utilizza il termine UE (User Equipment) come sinonimo di UA.

Figura 4.1 - Schema della chiusura di sessione da parte del P-CSCF

I passi da 1 a 3 permettono al P-CSCF/PCF di ricevere notifica della perdita di copertura radio da parte dello UA (UA1) cui si sostituirà e di eliminare l'autorizzazione all'uso delle risorse di rete concessa all'attivazione del dialogo. Dal passo 4 in poi è possibile osservare che il P-CSCF/PCF emette un messaggio che pur essendo genericamente chiamato "Hangup" è di fatto un BYE, nel caso di utilizzo del protocollo SIP. Questo BYE viene girato all'S-CSCF della Home Network cui appartiene lo UA1 (per brevità sono stati omessi elementi delle Home Network diversi dagli S-CSCF), che provvede alle procedure di controllo di servizio necessarie per la chiusura della sessione (passo 5). Il BYE viene poi inoltrato all'S-CSCF della Home Network dell'altro UA (UA2) impegnato nella sessione (passo 6), il quale a sua volta esegue le procedure di controllo del servizio per la chiusura della sessione (passo 7). Il BYE è poi trasmesso al P-CSCF/PCF della Visited Network in cui risiede lo UA2 (passo 8), che procede all'eliminazione delle autorizzazioni per le risorse di rete relative al dialogo (passo 9), ed alla consegna del BYE allo UA2 (passo 10). Lo UA2 risponde con un messaggio SIP 200 OK (passo 11) e contemporaneamente procede al rilascio delle risorse di trasporto a livello GPRS (passi 12, 13). Infine, il BYE viaggia a ritroso lungo il percorso di segnalazione verso il P-CSCF che lo ha emesso (passi 14,15,16).

In definitiva, CN1 sostiene che l'implementazione corrente (cioè: al momento dell'analisi) di questo aspetto costituisce la migliore interpretazione possibile della specifica SIP di IETF, compatibilmente con i requisiti richiesti da 3GPP ed appena illustrati; non c'è possibilità di risolvere il problema sollevato da IETF nella Release 5, a meno di un cambiamento di tali requisiti.

4.2.2.2 Cancellazione delle intestazioni per l'instradamento

CN1 sostiene che la cancellazione delle intestazioni è mirata essenzialmente ad impedire che gli UA 3GPP-compliant possano, per errore o per dolo, evitare il passaggio per alcuni elementi fondamentali del percorso di segnalazione (come l'S-CSCF, per esempio), aggirando così alcune tappe altrettanto fondamentali della segnalazione (come la fatturazione). Sostituendo le intestazioni necessarie all'instradamento, la rete IMS assicura che gli UA 3GPP-compliant non possano omettere o manipolare, nei campi intestazione Route o Via dei messaggi SIP in uscita, indirizzi di elementi di rete che sono stati ricevuti nei campi intestazione Record-Route, Via, o Service-Route dei messaggi SIP entranti e appartenenti allo stesso dialogo. Salvaguardando il corretto instradamento della segnalazione attraverso la rete IMS (in particolare attraverso l'S-CSCF), si protegge anche l'elaborazione di essa ai fini della fatturazione.

Secondo CN1, il problema delle registrazioni a server soggetti ad attacchi di tipo MITM non deve essere preso in considerazione in ambito 3GPP, dal momento che tra tutti i nodi dell'IMS sono adottate misure di sicurezza a livello di dominio di rete (utilizzo dei meccanismi di protezione dell'integrità di messaggio forniti dal protocollo IPSec [2] per le connessioni passo-passo tra nodi dell'IMS).

CN1 è dell'opinione che l'eliminazione delle intestazioni non produca effetti negativi sulla compatibilità degli UA 3GPP-compliant con le procedure di instradamento previste da IETF. In ogni caso, le intestazioni Path e Service-Route (che sono citate da IETF come intestazioni eliminate in modo improprio dal P-CSCF) derivano da estensioni al protocollo SIP (cfr. [6] e [1]) e perciò non devono essere necessariamente implementate negli UA suddetti.

A tale riguardo, una proposta per l'implementazione nello UA di queste estensioni (volta ad ottenere completa compatibilità con le specifiche IETF) è stata discussa nel corso del meeting ed è stata temporaneamente respinta dal CN1, in attesa di altre analisi sui suoi effetti sull'IMS. Comunque, questo non avrebbe risolto il problema, perché il comportamento del P-CSCF sarebbe rimasto invariato; ciò in base alla convinzione di alcune compagnie di telecomunicazione, che non vedono in questo comportamento un ostacolo allo sviluppo di soluzioni future da adottare per la Release 6, anzi, sostengono che il suo permanere offre migliori possibilità di soluzioni future.

Per quello che riguarda la registrazione degli UA presso "registrar" esterni alla rete IMS, CN1 afferma che l'operazione è possibile, sempre che questo servizio sia fornito tramite un regolare dominio PS, piuttosto che dall'IMS. Quanto al loose routing, CN1 considererà la possibilità di permettere agli UA 3GPP-compliant di usare questa modalità di instradamento. A questo scopo, gli UA 3GPP-compliant potrebbero inserire dei campi intestazione Route nelle richieste iniziali del dialogo; tali campi poi verrebbero utilizzati dall'S-CSCF per instradare le richieste in modo opportuno. CN1 deve però ancora determinare se questa modifica potrà essere introdotta nella Release 5 o nella Release 6.

Oltre a quanto già prospettato da IETF, CN1 ha identificato altri possibili problemi futuri, in relazione al supporto di eventuali nuovi meccanismi SIP che diano origine a dialoghi SIP complessi e non comprensibili per il P-CSCF; tali meccanismi potrebbero ostacolare la creazione di nuovi servizi. La portata delle difficoltà è ancora in discussione, soprattutto per quanto riguarda l'utilizzo congiunto di CSCF appartenenti a release e/o a reti diverse.

Secondo il parere di CN1, l'attuale comportamento del P-CSCF è dettato anche dall'esigenza di non rivelare topologia ed indirizzi di nodi della rete IMS ad entità non autorizzate, e dalla necessità di minimizzare la quantità di dati di segnalazione scambiati via radio.

Sempre secondo CN1, l'implementazione adottata per quest'aspetto del P-CSCF deriva dai due requisiti elencati di seguito.

1. Requisito posto dal WG SA1 in [8]: dovrebbe essere possibile limitare la visibilità della topologia della rete IMS alle sole entità autorizzate.

2. Requisito architetturale posto dal WG SA2 in [10]: il P-CSCF dovrebbe rimuovere le intestazioni Record-Route e Via generate dalla rete nelle richieste SIP prima di inoltrarle verso lo UA; questo al fine di aumentare la sicurezza e di ridurre le dimensioni dei messaggi SIP, diminuendo così anche il ritardo di trasmissione attraverso l'interfaccia radio.

Alla luce di questi requisiti, CN1 considera quella attuale (cioè: al momento dell'analisi) la migliore implementazione possibile basata sui requisiti appena esposti; i problemi relativi ad essa non potranno essere risolti nell'ambito della Release 5 a meno di un cambiamento dei requisiti stessi.

4.2.2.3 Le modifiche al corpo SDP del messaggio SIP

Per CN1, l'operatore dei servizi 3G richiede espressamente la capacità di controllo sui media e/o i codec scelti dall'utente per l'utilizzo durante la sessione. In particolare, il controllo deve essere esercitato tanto nella Home Network (HN) quanto nella Visited Network (VN), per verificare che l'uso dei mezzi negoziati dall'utente sia

• (nella HN): conforme al profilo dell'utente stesso e consentito in base ai criteri di gestione delle risorse di rete (fissati dall'operatore della HN);

• (nella VN): consentito in base ai criteri di gestione delle risorse di rete (fissati dall'operatore della VN).

La negoziazione dei codec nella rete IMS è basata completamente sul modello offerta/controfferta di SIP/SDP. La negoziazione avviene fondamentalmente da estremo ad estremo, dal momento che è condizionata dalle preferenze dell'utente finale e dalle capacità del terminale con cui l'utente stesso si collega.

Se le modifiche al corpo SDP del messaggio dovessero essere eseguite secondo la specifica SIP, si dovrebbe impiegare un B2BUA. Però, l'utilizzo di un B2BUA provoca alcuni degli effetti collaterali individuati da IETF; inoltre un B2BUA è meno efficiente, in termini di prestazioni, rispetto ad un vero proxy SIP; infine, un B2BUA può compromettere la trasparenza della segnalazione³. Secondo CN1, l'utilizzo da parte di 3GPP di un modus operandi diverso da quello di IETF non comporta problemi immediati di interoperabilità; esiste però la possibilità di problemi futuri, a fronte di un'eventuale estensione del protocollo SDP da parte di IETF.

CN1 ha identificato la fonte di questo problema nei requisiti che sono descritti qui di seguito.

1. Requisiti formulati dal WG SA1 in [8]:

   1. un operatore di rete dovrebbe avere la possibilità di implementare dei criteri di controllo per le applicazioni multimediali su IP;

   2. la negoziazione dei media dovrebbe tenere conto delle preferenze dell'abbonato per le applicazioni multimediali su IP, attraverso le informazioni reperite nel profilo utente associato all'abbonato stesso, in ogni caso in cui ciò sia possibile e utile.

2. Requisito architetturale formulato dal WG SA2 in [10]: cfr. figura 4.2 e, di seguito, descrizione del flusso dei messaggi durante la negoziazione iniziale di codec e caratteristiche dei media.

Figura 4.2 - Schema del flusso dei messaggi per la scelta dei codec

Nella figura 4.2 sono rappresentati soltanto gli elementi di rete direttamente coinvolti nella negoziazione, per le reti di appartenenza di ciascun UE. Si suppone inoltre che gli UE risiedano nelle rispettive Home Network. Segue la descrizione dettagliata passo per passo.

1. Lo UE#1 costruisce un messaggio di tipo SDP che contiene i codec e flussi che si vogliono usare per la sessione in corso di preparazione; i dati inseriti dovrebbero riflettere le capacità del terminale e le preferenze dell'utente.

2. Il messaggio SDP viene inserito come payload della richiesta iniziale di INVITE e passato al P-CSCF#1, residente nella stessa rete in cui risiede lo UE#1.

3. Il P-CSCF#1, ricevuto l'INVITE, ne esamina il payload SDP e rimuove flussi e codec non permessi sulla rete #1 in base ai criteri locali dell'operatore.

4. Il P-CSCF#1 inoltra l'INVITE così modificato verso l'S-CSCF#1.

5. L'S-CSCF#1 esamina a sua volta il payload SDP, rimuovendo flussi e codec per i quali l'utente dello UE#1 non dispone dell'abilitazione all'uso, in base ai dati del suo profilo d'abbonamento. Dal momento che nell'elaborazione della sessione da parte dell'S-CSCF può essere coinvolto anche un "Application Server" (AS), qualora ciò accadesse, il payload sarà esaminato anche dall'AS, con modalità e finalità simili a quanto visto per l'S-CSCF.

6. L'S-CSCF#1 inoltra l'INVITE verso l'S-CSCF#2, residente nella rete in cui risiede lo UE#2.

7. Analogamente a quanto visto per l'S-CSCF#1, l'S-CSCF#2 esamina il payload SDP eliminando flussi e codec per i quali l'utente dello UE#2 non dispone dell'autorizzazione all'uso, in base al suo profilo.

8. L'S-CSCF#2 inoltra l'INVITE verso il P-CSCF#2.

9. Il P-CSCF#2 esamina il payload SDP dell'INVITE, ed elimina i flussi ed i codec non ammessi sulla rete #2 in base ai criteri locali dell'operatore. Il PCF associato al P-CSCF costruisce l'Authorization-Token, ossia il token di autorizzazione all'uso delle risorse.

10. Il token di cui al punto precedente viene incluso nell'intestazione dell'INVITE, che viene inoltrato allo UE#2.

11. Lo UE#2 costruisce un messaggio SDP contenente la propria controfferta all'offerta ricevuta. Tale messaggio dovrebbe contenere l'intersezione tra l'insieme di flussi e codec ricevuto nell'INVITE e l'insieme di flussi e codec che è supportato dal terminale, tenuto conto anche delle preferenze dell'utente.

12. Il messaggio SDP viene inoltrato verso il P-CSCF#2.

13. Il P-CSCF#2 provvede all'autorizzazione d'uso delle risorse QoS per il sottoinsieme di flussi e codec rimasto nel messaggio SDP.

14. Il messaggio SDP viene inoltrato dal P-CSCF#2 verso l'S-CSCF #2.

15. Il messaggio SDP viene inoltrato dall'S-CSCF#2 verso l'S-CSCF #1.

16. Il messaggio SDP viene inoltrato dall'S-CSCF #1 verso il P-CSCF #1.

17. Il P-CSCF#1 provvede all'autorizzazione d'uso delle risorse QoS per il sottoinsieme di flussi e codec rimasto nel messaggio SDP. Il PCF associato al P-CSCF#1 costruisce l'Authorization-Token, ossia il token di autorizzazione all'uso delle risorse.

18. Il token di cui al punto precedente viene incluso nel messaggio SDP, che viene inoltrato allo UE#1.

19. Il messaggio SDP viene ricevuto dallo UE#1 che, in base al contenuto, decide quali flussi e quali codec utilizzare per la sessione che si sta instaurando.

20. Nel caso in cui per un flusso fosse possibile l'uso di più codec, o fossero descritti più flussi nel messaggio SDP, sarà necessaria una nuova offerta SDP da parte dello UE#1 per eliminare l'ambiguità; il tragitto di questa nuova offerta, lungo il percorso di segnalazione stabilito dalla prima, è descritto in questo punto e nei seguenti di figura 4.2.

Va notato che, sebbene non esplicitamente affermato da CN1, una situazione analoga si presenta quando, durante una sessione già instaurata, si debba procedere ad una nuova negoziazione di flussi e/o codec (per cambiarli od aggiungerne altri) che preveda l'utilizzo di risorse di rete che non siano già state allocate durante la prima negoziazione. In tale situazione il comportamento dei CSCF è perfettamente analogo a quello appena visto, e di conseguenza il problema si ripresenta.

Tornando all'analisi del WG, CN1 afferma che le soluzioni alternative proposte da IETF non hanno progredito e questo pregiudica la possibilità di poterle inserire nelle specifiche della Release 5. Inoltre tali soluzioni presuppongono tutte una modifica del requisito architetturale appena esposto, che è molto rigido sull'implementazione da attuare da parte di CN1.

In definitiva, CN1 considera quella attuale (cioè: al momento dell'analisi) la migliore implementazione possibile basata sui requisiti appena esposti; i problemi relativi ad essa non potranno essere risolti nell'ambito della Release 5 a meno di un cambiamento dei requisiti stessi.

4.2.2.4 Manipolazione delle intestazioni From e To

CN1 sostiene che al momento dell'analisi, la possibilità di nascondere le intestazioni Frome To è soltanto un'eventuale opzione di configurazione, basata sui criteri locali dell'operatore. CN1 si sta adoperando affinché questa opzione venga completamente rimossa nella Release 5, e venga chiaramente affermato che qualora l'utente richieda la protezione dell'identità, l'intestazione From non dovrebbe contenere informazioni che possano violare la riservatezza.

4.2.2.5 Filtro delle identità sconosciute al P-CSCF

Secondo CN1, la procedura con cui la rete IMS convalida ed asserisce le identità dei propri utenti è conforme alle specifiche IETF [4] e [5] riguardanti definizione, uso e manipolazione di identità asserite all'interno di un dominio di fiducia.

In base a tali specifiche, si definisce "dominio di fiducia" (Trust Domain) una rete i cui nodi hanno reciproche garanzie di appartenenza al dominio stesso, e possono comunicare tramite un canale sicuro⁴, come nel caso della rete IMS. Quando la garanzia di appartenenza al dominio di fiducia non sia reciproca, si dice che il nodo non appartenente al dominio "si fida" dell'altro (ma non viceversa); questa è per esempio la relazione intercorrente tra uno UE e gli elementi della rete IMS ad esso connessi tramite un canale sicuro. Se non sussiste la sicurezza del canale di comunicazione, non c'è relazione di fiducia, indipendentemente dall'appartenenza o meno al dominio. Un nodo può appartenere ad un certo dominio di fiducia F se soddisfa un certo insieme di specifiche Spec(F), riguardanti le caratteristiche di sicurezza del canale di comunicazione; questo garantisce di un trattamento dei dati secondo specifiche cui tutti i nodi devono rispondere. In questo contesto, si definisce una nuova intestazione, detta P-Asserted-Identity, dove "P" sta per Private. Questa intestazione contiene l'identificatore univoco di un utente (ad esempio uno URI di tipo SIP, ed un eventuale nome da visualizzare), che viene costruito dal nodo del dominio di fiducia dopo che, alla registrazione, ha autenticato in modo sicuro⁵ l'utente stesso. Quest'intestazione può essere inserita dal nodo che l'ha creata nei messaggi SIP uscenti dal nodo stesso, e fornita ad altre entità di rete che il nodo considera fidate (o anche non fidate se sono verificate opportune condizioni). Nodi di rete che ricevono messaggi contenenti quest'intestazione da entità considerate fidate, possono ritenere valide le informazioni d'identità contenute nell'intestazione stessa, senza dover ricorrere ad alcuna autenticazione supplementare.

Tornando all'analisi del problema, secondo CN1 l'allineamento delle procedure di autenticazione alle specifiche IETF le rende pienamente compatibili con il protocollo SIP secondo IETF. Sempre secondo CN1, questo modo di procedere soddisfa un requisito proveniente dal WG SA1, secondo il quale ogni identità utilizzata nelle richieste SIP deve essere nota all'operatore della rete IMS.

CN1 fa poi osservare che ciò che è autenticato (o meglio generato tramite autenticazione), e che quindi viene filtrato dal P-CSCF, è l'intestazione P-Asserted-Identity. Se uno UA SIP intendesse utilizzare servizi di terze parti attraverso l'IMS, potrebbe fornire per tali servizi un'identità alternativa tramite l'intestazione From, che non necessita di autenticazione. In questo modo, il campo From fornirebbe un'identità conforme alla specifica SIP di IETF; mentre il campo P-Asserted-Identity fornirebbe le credenziali necessarie a raggiungere il fornitore del servizio in questione tramite l'IMS.

Infine, CN1 identifica i requisiti che hanno portato a questa soluzione, e che sono elencati di seguito.

1. Requisiti formulati dal WG SA1 in [8].

   1. Le identità pubbliche degli utenti saranno amministrate dall'operatore di rete e non saranno modificabili dagli utenti stessi. L'operatore di rete dovrà essere in grado di garantire al chiamato l'autenticità dell'identità pubblica presentata dal chiamante, quando la chiamata sia interamente all'interno della rete⁶ gestita dall'operatore stesso.

   2. Il sottosistema IM CN dovrà essere in grado di poter verificare in qualsiasi momento, l'autorizzazione data all'utente per l'uso delle proprie risorse.

2. Requisiti formulati dal WG SA3 in [13] a proposito dell'architettura di sicurezza della rete IMS, che prescrivono l'autenticazione della richiesta iniziale di REGISTER da parte dello UE 3GPP compliant.

La conclusione di CN1, sulla scorta delle considerazioni precedenti, è che il filtro delle identità sconosciute al P-CSCF non è un problema; pertanto non sono previsti cambiamenti di nessun genere, a patto che non cambino i requisiti di sicurezza.

4.2.2.6 Codifica delle intestazioni per l'instradamento

Secondo CN1, l'eventuale possibilità di nascondere la topologia della rete IMS all'esterno della rete stessa è un requisito posto dall'operatore, ed è presente nelle specifiche di stage 1 e stage 2 di 3GPP. È vero che il meccanismo adottato a tale scopo da CN1 non trova corrispondenza nelle specifiche SIP di IETF; ma è anche vero che CN1 non ha identificato finora nessun problema di interoperabilità.

I requisiti 3GPP che sono all'origine del problema vengono identificati da CN1 nel dettaglio seguente.

1. Requisito posto dal WG SA1 in [8]: dovrebbe essere possibile limitare la visibilità della topologia della rete IMS alle sole entità autorizzate. Questo requisito è già stato citato nel paragrafo 4.2.2.2 a proposito della cancellazione delle intestazioni per l'instradamento.

2. Diversi requisiti architetturali posti dal WG SA2 in [10]; di seguito si elencano i più significativi.

   1. Per svolgere i compiti assegnati all'I-CSCF, il gestore di rete si può avvalere di una funzionalità di Topology Hiding Inter-network Gateway (THIG) integrata nell'I-CSCF stesso (in questo caso si parlerà di I-CSCF(THIG)), o realizzata mediante altre tecniche, al fine di nascondere topologia, capacità e configurazione della rete IMS all'esterno di essa. Nel caso in cui, per soddisfare tale requisito, si sia scelta la prima implementazione, allora l'I-CSCF(THIG) potrà inoltrare i messaggi SIP inerenti sessioni tra domini di operatori diversi (siano essi richieste o risposte) verso un altro I-CSCF(THIG), consentendo così agli operatori coinvolti di mantenere la reciproca riservatezza delle configurazioni.

   2. In [10] (più precisamente, in un allegato al testo) sono elencate le necessità più importanti che conducono al requisito di riservatezza delle configurazioni di rete; necessità che sono elencate di seguito.

      1. Necessità dettate dalla gestione di rete. Se, per esempio, gli indirizzi degli S-CSCF fossero visibili all'esterno della rete, ogni eventuale loro riconfigurazione (temporanea o permanente) dovrebbe essere resa pubblica anche a tutti gli elementi interessati e residenti in reti esterne.

      2. Necessità dettate dalla scalabilità di rete. Lo stabilire delle relazioni di sicurezza (security association) per ogni coppia di S-CSCF residenti in due reti diverse è un processo non scalabile. Le relazioni di sicurezza dovrebbero essere indipendenti dal numero degli elementi di rete.

      3. Necessità dettate dalla competitività tra operatori. I dettagli funzionali di una rete di comunicazione sono considerati come informazioni riservate dal punto di vista economico; informazioni che gli operatori di rete non vorrebbero condividere con dei potenziali concorrenti. Mentre accordi di collaborazione tra operatori potrebbero anche consentire tale condivisione, deve comunque essere disponibile un modo per evitare che ciò accada.

      4. Necessità dettate dalla sicurezza di rete. L'occultamento della topologia di rete potrebbe essere d'aiuto nel ridurre la vulnerabilità ad attacchi provenienti dall'esterno (come per esempio gli attacchi di tipo Denial Of Service (DOS) ).

La conclusione di CN1 riguardo al problema sollevato da IETF è che l'implementazione corrente (al momento della discussione) è considerata la migliore possibile, dati i requisiti elencati. Restando tali i requisiti, il problema non sarà risolvibile.

4.2.2.7 Manipolazione del corpo dei messaggi

Secondo CN1, l'idea di inserire informazioni intra-sistema IMS, in linguaggio XML, in una parte del corpo del messaggio SIP è stata soppiantata dall'introduzione delle estensioni private al linguaggio SIP (SIP P-Headers; cfr. [7]); tutte le P-Headers di 3GPP sono raccolte sotto un unico ID di IETF. A parte questa differenza, il problema sollevato è simile a quanto già visto nel paragrafo 4.2.2.3 a proposito della modifica del corpo SDP del messaggio SIP.

L'S-CSCF può introdurre nel corpo del messaggio SIP anche altre parti in linguaggio XML, contenenti le cosiddette Service-Info. Con riferimento alla specifica [12] di 3GPP, questo comportamento è di fatto consentito soltanto per richieste SIP di tipo REGISTER per conto di terze parti e dirette verso AS (dal momento che le Service-Info sono necessarie alla gestione e alla fornitura dei servizi aggiuntivi da parte degli AS). In questo caso, l'S-CSCF si comporta come uno UA e quindi non viola la specifica SIP di IETF. Tuttavia, la specifica [9] di 3GPP non sancisce questa restrizione in modo esplicito, sebbene non ci sia motivo di consentire il comportamento visto in richieste diverse dalla REGISTER.

In conclusione, la soluzione al problema proposta ed in corso di valutazione (al momento dell'analisi) da parte di CN1 consiste nell'applicare la restrizione presente nella specifica [12] anche nella specifica [9]. Secondo CN1, questo può avvenire nei tempi necessari all'inserimento della modifica nelle specifiche della Release 5.

4.2.3 25° meeting del WG SA3: analisi e proposte

Procedendo in ordine cronologico, la seconda analisi della relazione di IETF arriva dal 25° meeting del WG SA3 (all'inizio di Ottobre 2002). In effetti, avendo già come input (oltre alla relazione suddetta) il documento d'analisi prodotto dal WG CN1 di cui al paragrafo 4.2.2, il WG SA3 pubblica un altro Liaison Statement, indirizzato ai gruppi più direttamente interessati (CN1, SA1, SA2, SA, CN), in cui si limita essenzialmente a concordare con l'analisi e con le conclusioni raggiunte nel documento citato. Tuttavia, SA3 integra anche alcune considerazioni che vale la pena di esporre.

4.2.3.1 Considerazioni sull'uso della codifica S/MIME

L'eventuale uso della codifica S/MIME tra gli UA, come mezzo di protezione da estremo a estremo, cui IETF ha accennato a proposito dei problemi trattati nei paragrafi 4.1.3.3 (Modifiche al corpo SDP del messaggio SIP) e 4.1.3.7 (Manipolazione del corpo dei messaggi SIP) non è compatibile con i requisiti posti da 3GPP al riguardo e che sono stati citati nell'analisi di CN1 (cfr. paragrafi 4.2.2.3 e 4.2.2.7). Inoltre, l'incapsulamento dei messaggi SIP tramite S/MIME renderebbe incompatibili anche i requisiti 3GPP esposti da CN1 nel paragrafo 4.2.2.2 a proposito della cancellazione delle intestazioni per l'instradamento.

Una possibilità che secondo SA3 andrebbe eventualmente esplorata, è quella dell'impiego della codifica S/MIME limitatamente al caso di collegamento tra un'entità dell'IMS e uno UA IETF-compliant allocato all'esterno dell'IMS stessa. Tuttavia, SA3 aggiunge che, dati i requisiti stringenti di tempo, lo studio non potrebbe essere pronto per la Release 5.

4.2.3.2 Scenario alternativo per l'autenticazione dei BYE

Nell'ambito della discussione sul problema dei BYE inviati dal P-CSCF per conto degli UE (trattato nel paragrafo 4.1.3.1), SA3 dà il suo contributo identificando un altro scenario⁷ in cui sarebbe richiesta un'autenticazione di tali BYE. Tale scenario è quello in cui lo UA esterno all'IMS non è quello di un possibile attaccante, ma un legittimo UA SIP-compliant: in questo caso, il BYE proveniente dal P-CSCF sarebbe considerato dall'UA come un messaggio falso, in mancanza di una sua autenticazione.

In ogni caso, SA3 condivide appieno l'analisi di CN1; anche e soprattutto per quanto concerne l'identificazione come problema (per adesso insoluto) delle possibilità di attacchi esterni verso l'IMS, tramite BYE contraffatti.

4.2.3.3 Considerazioni sul filtro delle identità

Per quel che concerne il problema della selezione delle sole identità note da parte del P-CSCF, sollevato da IETF (cfr. par. 4.1.3.5) ed analizzato da CN1, SA3 conferma di non voler cambiare i propri requisiti di sicurezza (citati da CN1 nel paragrafo 4.2.2.5) al riguardo. In particolare, è considerata irrinunciabile la possibilità, da parte dell'operatore di rete IMS, di verificare in ogni momento l'associazione tra l'identità pubblica presentata da uno UE e l'identificatore privato dell'abbonato cui deve essere fatturato l'utilizzo delle risorse della rete; l'associazione, inoltre, deve essere stabilita prima dell'utilizzo delle risorse stesse. SA3, infine, concorda con quanto già esposto da CN1 riguardo al mantenimento di questi requisiti: non c'è alcuna limitazione alla fruizione di servizi esterni forniti da terze parti, accessibili con un'identità alternativa contenuta nel campo intestazione From, mentre l'identità autenticata trasportata dal campo intestazione P-Asserted-Identity serve come credenziale per l'utilizzo della rete IMS.

4.2.4 27° meeting del WG SA2: analisi e proposte

Nel corso del 27° meeting del WG SA2, tenutosi intorno alla metà di Ottobre del 2002, la liaison sollevata da IETF e la relativa analisi compiuta dal WG CN1 sono stati oggetto di ulteriori approfondimenti. In particolare, l'analisi di CN1 è stata interpretata da DynamicSoft (una delle società di telecomunicazioni i cui progettisti partecipano al WG) allo scopo di valutarne le implicazioni sui requisiti architetturali posti da SA2.

Inoltre, sono state formulate le prime proposte concrete di soluzioni possibili, a proposito della manipolazione del corpo SDP del messaggio SIP e dell'occultamento della topologia di rete.

Nel seguito del paragrafo saranno esposti nel dettaglio i risultati ottenuti nel corso del meeting.

4.2.4.1 L'analisi di DynamicSoft ed il relativo dibattito

Il documento presentato da DynamicSoft prende spunto dalle affermazioni contenute nella Liaison Statement pubblicata da CN1, propone un'analisi dal punto di vista del WG SA2, identifica le azioni che lo stesso WG dovrebbe intraprendere. Va inoltre notato che DynamicSoft ha fornito un'analisi del tutto simile anche al 18° meeting del WG SA1. La cosa ha rilevanza dal momento che tale analisi è stata utilizzata in un sottogruppo di lavoro tra i WG SA1 ed SA2 (tenutisi contemporaneamente), descritto in un paragrafo successivo.

DynamicSoft innanzitutto identifica una ragione di fondo per la liaison di IETF in alcuni requisiti di servizio generali per l'interoperabilità con Internet, posti nella già citata specifica di fase 1 per l'IMS [8]; in particolare, si tratta dei requisiti seguenti.

1. Dovrebbe essere possibile (per l'IMS) fornire supporto ad applicazioni Internet associate alle sessioni multimediali e sviluppate all'esterno della comunità 3GPP.

2. È importante che le applicazioni multimediali su IP disponibili sul mercato possano essere supportate (dall'IMS). In generale, la compatibilità dell'IMS con tali applicazioni dovrebbe essere preferita allo sviluppo di soluzioni specifiche per 3GPP.

3. Negli standard 3GPP per la fornitura di servizi tramite IMS dovrebbero essere disponibili le opzioni seguenti:

   1. dovrebbe essere creato uno scheletro architetturale in grado di garantire la massima flessibilità sia per i terminali utente che per i server di rete, secondo concetti simili a quelli adottati in Internet;

   2. questo scheletro dovrebbe rendere disponibili all'operatore di servizi 3G applicazioni multimediali su IP in maniera "network-agnostic" (ovvero senza alcuna conoscenza particolare della struttura di rete sottostante) ed efficiente, senza dover attendere, da parte di 3GPP, la standardizzazione di tali applicazioni, o di tecnologie supplementari per il loro supporto.

Secondo DynamicSoft ed alla luce di questi requisiti, la questione sollevata da IETF è un utile contributo per l'analisi della effettiva rispondenza delle specifiche della Release 5 ai requisiti stessi, ed è anche uno spunto per capire quanto ancora resta da fare nelle Release successive.

Per quello che riguarda le questioni concrete, DynamicSoft compie una disamina punto per punto dei problemi presentati da IETF ed analizzati da CN1; i risultati sono presentati nei sottoparagrafi seguenti, assieme alla discussione nell'ambito di SA2.

4.2.4.1.1 Invio di BYE da parte del P-CSCF

DynamicSoft concorda con CN1 nell'individuare la fonte del problema nel requisito architetturale posto da SA2 in [10], già citato nel paragrafo 4.2.2.1, e riguardante il rilascio di sessione da parte del P-CSCF in caso di perdita della copertura radio da parte del mobile.

Entrambi gli scenari già individuati prima da IETF (cfr. 4.1.3.1) e poi da CN1 (possibilità di attacchi di tipo DOS con BYE contraffatti, provenienti dall'esterno dell'IMS, cfr. 4.2.2.1) ed SA3 (possibilità di una mancata disconnessione quando il terminale destinatario del BYE lo consideri falso in mancanza di autenticazione, cfr. 4.2.3.2) vengono catalogati come possibile fonte di futuri problemi.

Secondo DynamicSoft, la soluzione al problema va studiata in modo congiunto dai WG CN1, SA2, SA3, per essere adottata non prima dell'uscita della Release 6. Un'alternativa possibile è quella di consentire la generazione dei BYE non al P-CSCF, ma all'S-CSCF che ha in carico, presso la Home Network, il terminale che deve ricevere il BYE; oppure a un Application Server, sempre presso la HN. Dal momento che la HN (l'S-CSCF in particolare) possiede le credenziali necessarie, il BYE così generato potrebbe essere autenticato presso il terminale, consentendo così la discriminazione delle richieste autentiche e di quelle false anche per gli UE 3GPP-compliant. Al P-CSCF rimarrebbe comunque il ruolo di raccolta dell'informazione della perdita di copertura radio e di notifica di tale condizione all'opportuna entità di rete (S-CSCF o AS) presso la HN. Tale informazione potrebbe essere trasmessa per mezzo di un meccanismo del tipo "subscribe/notify", in cui l'S-CSCF, una volta sottoscritto il servizio di notifica tramite la richiesta di SUBSCRIBE, riceverebbe alla variazione di stato del terminale (per perdita di copertura radio) un NOTIFY da parte del P-CSCF, innescando così la generazione del BYE verso il terminale rimasto "appeso".

La sola cosa degna di nota che è emersa nel corso del dibattito a proposito di questo punto, è una non completa concordia sui tempi di questa soluzione: per alcuni gestori, sarebbe potuta essere pronta anche per la release 5, mentre DynamicSoft ha comunque fatto osservare che i cambiamenti implicati sono troppo importanti per affrettarne l'introduzione.

4.2.4.1.2 Cancellazione delle intestazioni per l'instradamento

Riguardo a questo punto, DynamicSoft concorda con CN1 nell'identificazione delle cause del problema: si tratta dei requisiti posti da SA1 ed SA2 rispettivamente in [8] ed in [10], e citati nel paragrafo 4.2.2.2.

Le motivazioni date da CN1 per questo comportamento del P-CSCF, ovvero la necessità di prevenire l'aggiramento di alcuni elementi di rete da parte degli UE, possono essere interpretate secondo DynamicSoft con la necessità di soddisfare un altro requisito posto da SA1 in [8]: le applicazioni multimediali su IP dovrebbero essere fornite senza alcuna riduzione in riservatezza, sicurezza ed autenticazione rispetto ai corrispondenti servizi offerti tramite le reti GPRS e/o a commutazione di circuito. Questo indica che la possibilità di evitare elementi di rete che svolgono funzioni vitali come la fatturazione, è considerata da CN1 e da DynamicSoft come una riduzione di sicurezza del servizio, rispetto ai casi switched o GPRS.

Come CN1, anche DynamicSoft riconosce la possibilità di futuri problemi, legati all'evoluzione di SIP verso nuovi meccanismi che possano creare dialoghi SIP complessi, non interpretabili correttamente dall'attuale implementazione del P-CSCF (per via delle "particolarità" d'uso di SIP in ambito 3GPP), con una conseguente difficoltà per la creazione di nuovi servizi. Secondo DynamicSoft, il considerare questa possibilità dimostra la non totale rispondenza dell'implementazione attuale ai requisiti di servizio generali elencati all'inizio di quest'analisi. In particolare, non sarebbe soddisfatto il requisito riguardante la disponibilità (da parte dell'operatore 3G) di applicazioni multimediali su IP in modo "network-agnostic", senza lo sviluppo di componenti e/o tecnologie aggiuntive. Infatti, se si verificasse la possibilità paventata da CN1 e DynamicSoft, le future nuove applicazioni potrebbero essere inutilizzabili senza lo sviluppo di nuove componenti di rete; in particolare, di un nuovo P-CSCF in grado di interpretare i nuovi dialoghi SIP introdotti con l'evoluzione del protocollo: per questo, le nuove applicazioni multimediali su IP non sarebbero impiegate in modo "network agnostic". Trattandosi poi di sviluppare un nuovo P-CSCF, bisogna anche considerare che quest'entità potrebbe risiedere in una rete diversa da quella di appartenenza dell'abbonato: nel caso di roaming, per esempio, il P-CSCF appartiene alla rete che ospita l'abbonato e, in base al principio dell'esercizio del controllo dei servizi presso la Home Network, deve poter dialogare con l'S-CSCF, residente nella HN dell'abbonato. Dal momento che esistono più di 400 gestori di servizi di telecomunicazione, ognuno dei quali potrebbe avere una versione diversa del P-CSCF (in base alle esigenze dettate dalle nuove applicazioni), l'esempio del roaming rende evidente il problema di come mantenere il controllo dei servizi nella HN tramite l'S-CSCF, dovendo quest'ultimo potenzialmente "parlare" 400 "dialetti" diversi.

Per quanto riguarda le azioni richieste al WG SA2, DynamicSoft propone che:

1. SA2 stimoli il WG CN1 a collaborare con IETF per preparare, per la Release 6, una soluzione migliore di quella attuale, che realizzi il pieno rispetto dei requisiti di servizio citati all'inizio dell'analisi;

2. SA2 stimoli il WG CN1 a portare avanti la proposta per il completo allineamento degli UE di Release 5 con le specifiche IETF riguardanti l'instradamento IMS, in modo che la soluzione di cui al punto precedente, basata anche e soprattutto sul lavoro di IETF, possa più facilmente mantenere compatibilità all'indietro verso tali terminali.

4.2.4.1.3 Le modifiche al corpo SDP del messaggio SIP

L'analisi riguardo questo punto è, con i dovuti cambiamenti, simile a quella fatta nel punto precedente. DynamicSoft concorda con CN1 nell'individuare i requisiti costituenti la fonte del problema in quelli già citati nell'analisi di CN1 (cfr. paragrafo 4.2.2.3) e provenienti da SA1 ed SA2. DynamicSoft concorda con CN1 anche riguardo i possibili problemi di interoperabilità nel caso di un'estensione di SDP da parte di IETF (al riguardo DynamicSoft afferma che IETF sta per iniziare lo sviluppo di un SDP di nuova concezione denominato SDP Next Generation, basato su XML (eXtension Markup Language) e non compatibile con l'attuale SDP). Sempre secondo DynamicSoft, il considerare possibili tali problemi rivela la mancata rispondenza dell'implementazione corrente agli stessi requisiti di servizio generici già citati all'inizio dell'analisi (cfr. paragrafo 4.2.4.1); questo per motivazioni simili a quelle già viste nel paragrafo 4.2.2.3: impossibilità ad utilizzare i nuovi servizi in maniera "network-agnostic"; conseguente necessità di riprogettare componenti di rete in nuove forme (in particolare il P-CSCF); conseguente potenziale presenza di varie centinaia di versioni differenti di P-CSCF (teoricamente una per ogni gestore); necessità per l'S-CSCF di dover "parlare" centinaia di "dialetti" diversi; impossibilità a mantenere il controllo dei servizi nella HN.

DynamicSoft conclude l'analisi affermando che è possibile introdurre i cambiamenti necessari in modo progressivo già a partire dalla Release 5, per risolvere definitivamente il problema nella Release 6 grazie al lavoro da compiere assieme ad IETF. Fra le possibili soluzioni adottabili nella Release 5, DynamicSoft ne cita una per la quale si vedranno ulteriori dettagli nel resto del capitolo: a fronte di una richiesta di INVITE con un corpo messaggio SDP descrivente media e/o codec non permessi (a prescindere dalle motivazioni), il CSCF o l'AS che riscontra l'anomalia invia una risposta di tipo 4xx (denotante un errore nella richiesta cui la risposta stessa si riferisce). In alternativa, se la modifica del corpo SDP del messaggio SIP è ritenuta indispensabile, può essere sempre compiuta instradando la sessione SIP attraverso un AS che ricopra il ruolo di B2BUA secondo la specifica SIP di IETF, e che sarà quindi abilitato a compiere modifiche al corpo del messaggio.

Ci sono alcune osservazioni, emerse nella discussione di questo punto, che vale la pena di riportare. Innanzitutto, riguardo la formulazione del problema introdotta da IETF, si è fatto osservare che sarebbe più appropriato parlare di "codec sconosciuti" ai CSCF piuttosto che di "codec non supportati". Riguardo alle motivazioni per modificare il corpo SDP dei messaggi, Orange sostiene che il problema di codec e media non supportati è uno degli aspetti che rendono conveniente modificare la descrizione SDP; tuttavia, ci sono anche altri aspetti, come la gestione delle sessioni attraverso i firewall, per i quali è richiesta tale capacità di modifica. Infine, DynamicSoft fa notare che il cambiamento introdotto nei CSCF per risolvere questo problema è abbastanza radicale e potrebbe richiedere un notevole impegno economico.

4.2.4.1.4 Manipolazione delle intestazioni From e To

Riguardo questo problema, DynamicSoft si limita ad affermare che non c'è nulla che possa essere fatto da SA2 per facilitarne la soluzione.

4.2.4.1.5 Filtro delle identità sconosciute al P-CSCF

DynamicSoft si associa alle conclusioni tratte da CN1, per quanto concerne i requisiti di servizio di 3GPP su cui l'implementazione attuale si basa e ritenuti quindi cause del problema. Detti requisiti, provenienti da SA1 ed SA2, sono stati descritti nel paragrafo 4.2.2.5. Secondo DynamicSoft, la segnalazione fatta da IETF si potrebbe riferire al mancato soddisfacimento del requisito di servizio generico, citato nel paragrafo 4.2.4.1, riguardante il supporto da parte dell'IMS di applicazioni Internet collegate alle sessioni SIP e sviluppate da parti esterne alla comunità 3GPP. Tuttavia, DynamicSoft appoggia l'analisi fatta da CN1, e la soluzione proposta; perciò ritiene che il problema sia risolto, e non prescrive alcuna azione al riguardo da parte di SA2.

4.2.4.1.6 Codifica delle intestazioni per l'instradamento

Ancora una volta DynamicSoft concorda con l'analisi fatta da CN1, riguardo ai requisiti di servizio di 3GPP alla fonte del problema: si tratta della necessità di nascondere la topologia della rete all'esterno della rete stessa, espressa in [8] e riportata al paragrafo 4.2.2.6 nell'esposizione dell'analisi di CN1.

Per quanto non si vedano problemi immediati di interoperabilità, DynamicSoft fa notare che questo comportamento è una deviazione rispetto alla specifica SIP di IETF, e rappresenta comunque un'anomalia.

Riguardo alle possibili azioni da intraprendere da parte di SA2, nel caso in cui i requisiti posti da SA1 non cambino, DynamicSoft suggerisce la possibilità di operare a livello di rete (ossia ad un livello gerarchicamente inferiore a quello di applicazione, cui il protocollo SIP appartiene), per ottenere l'occultamento della topologia; ad esempio con il mascheramento dell'indirizzo IP tramite firewall a livello IP.

4.2.4.1.7 Manipolazione del corpo dei messaggi

Riguardo questo problema, DynamicSoft si collega all'analisi fatta da CN1, per fornire alcune precisazioni (rivolte sempre a CN1) circa il caso di comunicazione dell'S-CSCF con i vari AS per la trasmissione delle Service-Info (parti di corpo messaggio SIP in linguaggio XML, necessarie alla gestione dei servizi aggiuntivi forniti dagli AS con i quali è in atto la comunicazione; cfr. paragrafo 4.2.2.7). Le precisazioni riguardano i requisiti, posti da SA2 in [10], sull'interfaccia ISC (IP Multimedia SubSystem Service Control Interface) tra S-CSCF ed AS, sulla quale transitano i messaggi SIP contenenti le Service-Info: secondo tali requisiti, il linguaggio da usare per l'interfaccia ISC dovrebbe essere SIP puro, senza alcuna delle estensioni adottate per altre interfacce (Mw, Mg, Mm, per esempio) nell'IMS. Anche se non esplicitamente vietato, l'utilizzo di estensioni di SIP su quest'interfaccia è quindi sconsigliato; questo in special modo nel caso segnalato da CN1, in cui tale difformità potrebbe generare problemi di interoperabilità.

4.2.4.2 Proposta riguardante la manipolazione del corpo SDP

Come anticipato, in questo paragrafo si descrive la proposta presentata durante il meeting per rimuovere il problema di interoperabilità sollevato dalla manipolazione del corpo SDP nei CSCF.

Tale proposta, presentata a nome di Nokia ed Ericsson, analizza i requisiti che portano al problema (così come essi sono stati individuati da CN1), giungendo alla formulazione dei requisiti architetturali seguenti per la soluzione:

1. l'S-CSCF deve poter impedire l'instaurazione di sessioni contenenti componenti multimediali di un tipo non permesso all'abbonato in virtù del suo profilo d'abbonamento;

2. il P-CSCF/PCF deve poter impedire l'instaurazione di sessioni contenenti componenti multimediali di un tipo non permesso dai criteri di utilizzo delle risorse trasmissive, fissati dal gestore della rete cui il P-CSCF appartiene.

Considerando la natura da estremo ad estremo della negoziazione di media e codec, è anche importante che la soluzione prevista consenta un feedback verso l'utente finale quando la rete (a prescindere da come lo faccia) interferisce con la negoziazione (come nel caso attuale). Il feedback dovrebbe contenere informazioni relative all'interferenza, e dovrebbe consentire all'utente di capire il perché dell'interferenza. Dal momento che SIP dispone di molteplici strumenti per la segnalazione d'errore (le risposte SIP con campo intestazione Status-Code pari a 4xx, ed in esse: campo intestazione Reason-Phrase, possibilità di integrare il messaggio con parti che precisano come ovviare alla condizione d'errore, etc.), la soluzione proposta per l'S-CSCF prevede l'uso da parte dello stesso S-CSCF di tali capacità, per notificare all'utente l'errore dovuto all'uso di codec e/o media non consentiti. Uno schema di principio di tale soluzione è riportato in figura 4.3.

Figura 4.3 - Invio di risposte 4xx da parte dell'S-CSCF.

In questo schema si suppone che l'INVITE ricevuto al passo 1 dall'S-CSCF contenga codec e/o media che l'utente non è autorizzato ad utilizzare. Anziché correggere il corpo SDP del messaggio, eliminando le voci non consentite, l'S-CSCF replica all'INVITE con una risposta avente Status-Code di tipo 4xx⁸ (passo 2). Naturalmente, tale risposta conterrà indicazioni dettagliate sul motivo dell'errore, fornendo così all'utente il feedback di cui si parlava prima. Sulla base di tale feedback l'utente sarà in grado (tramite il proprio client) di riproporre un nuovo INVITE (passo 3) correggendo il corpo SDP in maniera opportuna. A questo punto, se non ci sono difficoltà di altro genere, la negoziazione procede come di consueto fino alla risposta di conferma (200 OK) da parte dell'S-CSCF, al passo 4.

Per quanto concerne il P-CSCF, si può adottare una soluzione simile, dove il criterio in base al quale viene emessa la risposta di tipo 4xx è legato ai criteri di utilizzo delle risorse trasmissive adottati dal gestore nella rete IMS cui il P-CSCF appartiene. In questo modo, la soluzione per il P-CSCF è efficace, anche se non elegante. In effetti, l'entità di rete più appropriata per la notifica di violazioni dei criteri di utilizzo suddetti sarebbe il GGSN, che è preposto alla loro applicazione tramite le primitive PDP, come visibile in figura 4.4.

Figura 4.4 - Ruolo del GGSN nella negoziazione di codec e/o media.

Purtroppo, i protocolli di segnalazione utilizzati dal GGSN⁹ prevedono soltanto un modo per segnalare una violazione dei criteri a livello dell'insieme dei componenti del flusso multimediale, e non per il singolo componente. Questo perciò impedisce di fornire all'utente il feedback necessariamente dettagliato.

Secondo Nokia ed Ericsson, questa soluzione è adottabile già a partire dalla Release 5.

4.2.4.3 Proposta riguardante l'occultamento della topologia di rete

Come anticipato, in questo paragrafo si descrive la proposta presentata da Siemens durante il meeting per rimuovere il problema di interoperabilità sollevato dall'occultamento della topologia di rete.

Secondo Siemens, l'implementazione studiata da CN1, che prevede la codifica delle intestazioni per l'instradamento e che è l'oggetto delle osservazioni di IETF, è la migliore soluzione possibile, dati i requisiti forniti da SA1 in [8] e le specifiche architetturali fornite da SA2 in [10]. Siemens inoltre aggiunge che un'altra qualsiasi soluzione comunque violerebbe il principio della trasparenza di rete propugnato da IETF. Sulla base di queste considerazioni, Siemens condivide le conclusioni di CN1: quello che va eventualmente rivisto è il requisito, e non il modo in cui il requisito stesso è soddisfatto; cosa che tra l'altro spetterebbe a chi lo ha elaborato, ossia al WG SA1.

Siemens invita SA2 a considerare che né IETF né CN1 hanno individuato problemi di interoperabilità collegati alla soluzione implementata da CN1. Questo da un lato può significare che il problema è di importanza secondaria; da un altro lato può significare che il problema può essere visto come un fatto locale, legato ai criteri adottati in materia di offuscamento della topologia di rete da parte dei singoli operatori, senza implicazioni macroscopiche per l'interoperabilità fra le reti. Secondo Siemens e considerando questo fatto dal punto di vista di SA2 (vale a dire quello architetturale), non c'è alcun impedimento dovuto ai requisiti di SA2 per l'implementazione di criteri di offuscamento della topologia di rete da parte dei singoli gestori.

Sulla base di queste considerazioni, e permanendo i requisiti imposti da SA1, Siemens ritiene possibile e conveniente lo spostamento di tutte le parti della specifica [10] (ed anche della relative specifiche a cura di CN1) relative al problema in un allegato informativo alla specifica stessa. Questa operazione avrebbe lo scopo di:

1. soddisfare i requisiti di SA1;

2. costituire un'indicazione chiara della volontà di 3GPP di aspirare a soluzioni in armonia con le specifiche IETF;

3. fornire a costruttori e gestori di rete una soluzione possibile per l'implementazione dell'offuscamento della topologia di rete.

Siemens osserva inoltre che, in questo modo, la deviazione dagli standard di IETF sarebbe imputabile ai gestori di rete e non a 3GPP.

Nel dibattito sollevato dalla proposta sono emerse posizioni abbastanza discordanti.

DynamicSoft ha apprezzato l'idea di Siemens, valutando lo spostamento richiesto come un segno di buona volontà verso IETF, in grado di irrobustire l'accordo di collaborazione tra le parti.

Alcuni gestori (AWS e Orange) hanno bocciato la proposta, motivando la bocciatura con le argomentazioni seguenti. Secondo AWS, non ha senso spostare l'implementazione della funzionalità in un allegato: o la si sostiene attraverso una completa definizione, oppure non la si definisce affatto. Orange, pur non sostenendo una bocciatura esplicita, ha rimarcato come lo spostamento delle parti interessate sia problematico anche soltanto dal punto di vista editoriale, essendo tali parti disposte in "ordine sparso" nel documento. Secondo Siemens tuttavia, lo spostamento può essere complicato per SA2, ma non per CN1, nelle cui specifiche le parti da spostare sono individuabili abbastanza chiaramente; inoltre per favorire il lavoro di SA2, Siemens propone come punto di partenza un documento, elaborato da Nokia e presentato nello stesso meeting, contenente la stima delle modifiche da apportare alla specifica [10].

Non è comunque il caso di approfondire ulteriormente l'argomento, poiché la discussione non ha portato a nulla di concreto: quella di Siemens è rimasta una proposta, e nessuna decisione è stata presa in merito, rimandando tutto ai successivi meeting del WG.

4.2.5 18° meeting del WG SA1: sessione congiunta con il WG SA2

Poiché il 18° meeting del WG SA1 ed il già citato 27° meeting del WG SA2 si sono tenuti contemporaneamente e nello stesso luogo, è stato istituito un sottogruppo di lavoro congiunto, allo scopo di valutare, dal punto di vista dei requisiti posti dal WG SA1, l'impatto del liaison statement di IETF. Il dibattito si è basato sull'analisi del WG CN1 (cfr. paragrafo 4.2.2) e sull'analisi di DynamicSoft (simile a quella proposta per SA2, cfr. paragrafo 4.2.4.1), e viene di seguito brevemente illustrato.

Per quanto concerne l'invio di BYE da parte del P-CSCF, non c'è stata alcuna proposta concreta: si è soltanto convenuto che la soluzione andrà studiata congiuntamente dai WG SA1, SA2 e CN1 e potrà essere inserita nelle specifiche della Release 6, ma non prima.

Per ciò che riguarda la codifica delle intestazioni per l'instradamento e l'offuscamento della topologia di rete, assodata la discendenza dei problemi dal requisito di SA1 più volte citato, il dibattito ha visto gli interventi di costruttori e gestori di rete. Secondo KPN e Orange, il requisito suddetto non deve essere cancellato (questo era prevedibile, anche in base al comportamento di Orange descritto nel paragrafo 4.2.4.3). Secondo Vodafone, il THIG non è essenziale, dal momento che la topologia di rete può essere scoperta in altri modi. In modo analogo, Nokia sostiene che la complessità del THIG è troppo elevata, se confrontata con i benefici che offre. Orange ha inoltre aggiunto che, dato lo stadio finale della Release, l'introduzione di un nuovo meccanismo per l'implementazione di questa funzionalità sarebbe fuori tempo e richiederebbe un carico di lavoro eccessivo. Siemens, in accordo con quanto illustrato nel paragrafo 4.2.4.3, è dell'opinione che l'offuscamento della topologia di rete è completamente trasparente all'esterno della rete stessa, così che può essere applicata ad una particolare rete, senza che ciò influenzi le altre. Nella discussione è stato anche posto il problema di quanto della topologia di rete sia rivelato dai nomi scelti per le entità; questo ovviamente dipende da come i gestori di rete scelgono tali nomi: dovrebbero essere tali da non rivelare più del dovuto sulle collocazioni delle entità stesse.

La decisione conclusiva del SWG riguardo questo punto è stata di lasciare inalterati i requisiti, in attesa di eventuali nuove idee da proporre al WG SA1.

A proposito della manipolazione del corpo SDP ai fini di controllo dei codec e/o dei flussi multimediali, DynamicSoft ha invitato a non confondere requisito e soluzione: mentre l'esigenza di controllare i media che gli utenti intendono utilizzare è pienamente legittima, la manipolazione del corpo SDP del messaggio SIP da parte dei CSCF può portare a diversi inconvenienti. Il requisito posto da SA1 perciò dovrebbe rimanere inalterato, ma l'implementazione va rivista, e quindi si dovrebbero considerare nuove soluzioni.

Riguardo alla manipolazione delle intestazioni From e To ed al filtraggio delle identità sconosciute al P-CSCF, il SWG ha concluso che non ci sono legami con i requisiti posti da SA1.

Per l'offuscamento della topologia di rete si rimanda alla discussione esposta a proposito della codifica delle intestazioni per l'instradamento: i due problemi discendono dallo stesso requisito di SA1.

Riguardo alla manipolazione del corpo dei messaggi da parte dell'S-CSCF (nella comunicazione con un AS), il SWG ha concluso che non ci sono legami con i requisiti posti da SA1.

La conclusione globale del SWG è quindi che i requisiti di servizio posti da SA1 in [8] e coinvolti nei problemi denunciati da IETF restano inalterati. Ciò vale anche per i requisiti architetturali posti da SA2 in [10], almeno al momento della chiusura del SWG.

4.2.6 28° meeting del WG SA2: analisi e proposte

Nell'ambito di questo meeting (tenutosi a Novembre 2002), l'episodio di maggior interesse, per quanto riguarda la risoluzione delle controversie con IETF di cui si sta trattando, è senz'altro la sessione congiunta con il WG CN1. Nel seguito del paragrafo verranno illustrate analisi e proposte, discusse nell'ambito di tale sessione, limitatamente alla parte riguardante il WG SA2. Infine, verrà documentato il Liaison Statement che il WG SA2 ha emesso con il resoconto del lavoro fatto nel meeting.

4.2.6.1 Proposta di Ericsson sulla cancellazione delle intestazioni per l'instradamento

Questa proposta integra quella presentata dal lato CN1 e documentata nel paragrafo 4.2.7.3, con la parte di competenza del WG SA2, ossia quella riguardante i requisiti architetturali.

Nel dettaglio, Ericsson propone di cambiare il requisito architetturale presente in [10] e citato da CN1 nella sua analisi (cfr. paragrafo 4.2.2.2), riguardante il comportamento del P-CSCF stigmatizzato da IETF. La nuova versione del requisito elimina l'obbligo di cancellazione e sostituzione, da parte del P-CSCF, delle intestazioni Via e Record-Route incluse nelle richieste provenienti dallo UE; ogni azione del P-CSCF al riguardo sarà subordinata ad un controllo di correttezza per tali intestazioni, da effettuarsi a cura del P-CSCF stesso. Nel caso di uso improprio, al P-CSCF sono lasciate due possibilità alternative: o respingere la richiesta verso lo UE originante, oppure sostituire le intestazioni con quelle memorizzate in precedenza (come prescritto dalla vecchia versione del requisito), se i criteri locali dell'operatore di rete prescrivono ciò. La scelta della strategia da seguire quindi è lasciata alle scelte dei singoli operatori.

A conclusione del dibattito relativo, e nonostante l'opposizione di Siemens e Nokia (motivata con la mancanza di tempo per l'approvazione della proposta da parte del TSG SA) la proposta è stata approvata.

4.2.6.2 Proposta sull'offuscamento della topologia di rete

Questa proposta non è altro che la revisione, richiesta da CN1, di quella descritta nel paragrafo 4.2.7.6, parlando della parte riguardante CN1 del meeting congiunto. La revisione si è limitata alla affermazione esplicita di quanto decretato all'approvazione della proposta suddetta: nella specifica [10] è stato apertamente affermato che:

1. la scelta dell'offuscamento della topologia di rete è dipendente dalle decisioni del gestore della rete stessa;

2. in caso ciò sia necessario, il THIG dovrebbe essere utilizzato a tale scopo, soddisfacendo al requisito di servizio imposto da SA1 in [8] e documentato nel paragrafo 4.2.2.6.

La proposta è stata approvata e non c'è stata la necessità di comunicazioni ulteriori a CN1 (come era stato eventualmente richiesto).

4.2.6.3 Proposta riguardante la modifica del corpo SDP dei messaggi SIP

L'intento di questa proposta, presentata da DynamicSoft, Ericsson, Nokia, Vodafone, è quello di modificare le procedure di stage 2 (contenute nella specifica [10]) per la negoziazione end-to-end di codec e media durante l'instaurazione della sessione SIP allo scopo di:

1. renderle conformi ai dettami di IETF;

2. consentire all'operatore l'esercizio dei criteri di controllo su media e/o codec impiegati;

3. fornire agli UE le informazioni necessarie all'instaurazione di una sessione nel rispetto di tali criteri.

La modifica delle procedure si ispira alle idee che DynamicSoft prima, Nokia ed Ericsson poi, hanno già espresso a proposito del problema, e che sono state documentate rispettivamente nei paragrafi 4.2.4.1.3 e 4.2.4.2.

Figura 4.5 - Flusso modificato dei messaggi per la negoziazione di codec e/o media

Rispetto alla figura 4.2, presentata nel paragrafo 4.2.2.3, il contenuto dei riquadri ai punti 3,5,7,9 (passaggi dell'INVITE iniziale per i CSCF coinvolti nella negoziazione) è stato cambiato, esprimendo ora la volontà di controllare la rispondenza dell'insieme di codec e/o flussi ai criteri dell'operatore di rete o al profilo dell'abbonato (rispettivamente per Proxy o Serving CSCF), senza rimuovere quelli inadatti. In figura 4.5 si suppone che nell'INVITE iniziale non siano utilizzati codec e/o flussi vietati; perciò esso prosegue il percorso verso lo UE#2. Va inoltre precisato che la modifica proposta elimina la possibilità di rimozione delle parti del corpo SDP del messaggio anche per gli AS eventualmente coinvolti nella negoziazione dagli S-CSCF.

Nel caso in cui invece la verifica presso uno dei CSCF (sia esso Proxy o Serving, nella rete #1 o nella rete #2) rilevasse codec e/o flussi non consentiti, sarà cura del CSCF che ha rilevato l'anomalia di respingere il tentativo di instaurazione di sessione, emettendo una risposta d'errore SIP verso lo UE#1, e fornendo con tale risposta informazioni sufficienti a permettere un nuovo tentativo, con un corpo SDP di contenuto adeguato ai criteri in vigore presso il CSCF stesso.

La soluzione appena illustrata vale anche quando, durante una sessione già instaurata, si debba procedere ad una nuova negoziazione di flussi e/o codec (per cambiarli od aggiungerne altri) che preveda l'utilizzo di risorse di rete che non siano già state allocate durante la prima negoziazione: il comportamento dei CSCF sarà perfettamente analogo a quello appena visto.

Nel dibattito seguito alla presentazione della proposta tuttavia non è stato trovato l'accordo per la sua approvazione: sono stati sollevati dei dubbi da parte di alcune compagnie, secondo cui il rapporto tra gli svantaggi ed i vantaggi introdotti non ne rende conveniente l'introduzione. La proposta è stata rimandata all'analisi ed all'eventuale approvazione da parte del successivo meeting del TSG SA.

4.2.6.4 Liaison Statement di SA2 verso i TSG CN ed SA

Con questo LS il WG SA2 ha inteso segnalare ai TSG CN ed SA i progressi fatti nella trattazione delle questioni sollevate da IETF, includendo i riferimenti alle proposte approvate nel corso della sessioni congiunte con i WG SA1 e CN1.

Per quanto riguarda la sessione con SA1, la conclusione riportata in breve è che non c'è stato motivo di modificare i requisiti di servizio posti da SA1 in [8] ed inerenti i problemi individuati da IETF; pertanto tali requisiti restano sostanzialmente invariati.

Per quanto riguarda la sessione con CN1, l'LS tratta le questioni suddette punto per punto, laddove vi siano stati delle evoluzioni significative con la partecipazione di SA2; questo è il motivo per cui alcuni punti non sono presenti nella descrizione che segue: SA2 non ha contribuito ai progressi in tali punti, o non c'è stata evoluzione.

4.2.6.4.1 Risultati per l'invio di BYE da parte del P-CSCF

Viene essenzialmente ribadito che il requisito da parte di 3GPP sulla interruzione di una sessione in corso dall'interno della rete IMS è irrinunciabile, per motivi di tariffazione e di applicazione di criteri di protezione per l'IMS stessa. Non essendo stati individuati metodi alternativi per la soddisfazione di questo requisito, la situazione resta invariata, almeno per ciò che riguarda la Release 5; questo ciononostante le questioni legittime sollevate da CN1 e da SA3 e riportate nelle rispettive analisi.

4.2.6.4.2 Risultati per la cancellazione delle intestazioni per l'instradamento

Sintetizzando il risultato raggiunto nel meeting congiunto con CN1, SA2 afferma che è stato deciso di risolvere il problema prima del rilascio della Release 5, per:

1. evitare l'introduzione di successivi problemi di compatibilità all'indietro per gli UE conformi a tale release;

2. indirizzare la soluzione in una certa direzione, riducendo o eliminando le alternative possibili.

Il modo scelto per eliminare il problema, come già ampiamente descritto, ha comportato l'eliminazione del requisito che obbligava il P-CSCF alla cancellazione delle intestazioni per l'instradamento; inoltre è stata conservata la possibilità di sostituzione, in base a scelte locali, delle intestazioni "errate".

4.2.6.4.3 Risultati per la modifica del corpo SDP dei messaggi

SA2 fa notare come, nel corso delle discussioni su questo problema, sia emersa l'opinione seguente, condivisa da molte compagnie: 3GPP dovrebbe elaborare una soluzione che permetta di modificare il corpo SDP (disciplinando così l'uso di codec e/o media) nell'ambito delle entità interne alla rete IMS (cioè senza la collaborazione dei punti terminali della comunicazione) e senza violare la filosofia della negoziazione end-to-end.

È stata proposta una soluzione (cfr. paragrafo 4.2.6.3), orientata a mantenere il requisito di controllo da parte dei gestori di rete su codec e media utilizzati cercando contemporaneamente di fornire ai terminali informazioni sufficienti per la prosecuzione della sessione secondo i criteri imposti dai gestori stessi. Nonostante ciò, SA2 afferma che non è stato possibile trovare un accordo su tale soluzione in questo meeting: secondo alcune compagnie, gli svantaggi introdotti da questa soluzione (come ad esempio l'aumento del traffico sull'interfaccia radio) sono preponderanti rispetto al vantaggio di una soluzione parziale del problema individuato da IETF; per esempio, il problema dell'uso della codifica S/MIME non è risolto, dal momento che la rete continua a non avere le credenziali per il suo utilizzo al fine di decrittare il corpo SDP eventualmente codificato. Va comunque notato che, in base all'analisi del WG SA3 (presentata nel paragrafo 4.2.3.1), il problema legato all'uso della codifica S/MIME non potrebbe essere comunque risolto nell'ambito della Release 5.

4.2.6.4.4 Risultati per l'offuscamento della topologia di rete

Riguardo questo problema, SA2 afferma che, come si è già ampiamente visto, la scelta dell'utilizzo dell'offuscamento è lasciata ai singoli gestori di rete in base alle proprie esigenze; le specifiche 3GPP si limitano al riguardo a fornire lo strumento funzionale (l'I-CSCF(THIG)) per implementare tale requisito.

4.2.7 27° meeting del WG CN1: analisi e proposte

Nell'ambito di questo meeting (tenutosi a Novembre 2002), l'episodio di maggior interesse, per quanto riguarda la risoluzione delle controversie con IETF di cui si sta trattando, è senz'altro la sessione congiunta con il WG SA2. Nel seguito del paragrafo verranno illustrate analisi e proposte, discusse nell'ambito di tale sessione, limitatamente alla parte riguardante il WG CN1. Infine, verrà documentato il Liaison Statement che il WG CN1 ha emesso verso il TSG CN, con il resoconto del lavoro fatto nel meeting.

4.2.7.1 Analisi e proposte di Lucent Technologies

Anziché rifarsi alla consueta classificazione dei problemi proposta da IETF, ossia quella in sette punti distinti rappresentanti le situazioni concrete, nella sua analisi Lucent si rifà alla divisione in tre classi di problemi, sempre proposta da IETF, rintracciabile nel paragrafo 4.1.3, e che viene qui riportata per comodità di lettura.

1. I nodi CSCF di IMS mandano messaggi SIP che secondo IETF sono riservati agli User Agent, senza implementare tutte le funzionalità di questi ultimi. La giustificazione proposta da 3GPP a questo comportamento, ossia il considerare il CSCF come un "back to back UA" (B2BUA) a contatto con l'UA finale, non è fondata: per funzionare in questo modo, il CSCF dovrebbe implementare a tutti gli effetti un UA.

2. I nodi CSCF di IMS modificano l'intestazione dei messaggi SIP in un modo esplicitamente vietato ai proxy da IETF, senza implementare le funzionalità di User Agent che consentirebbero ciò.

3. I nodi CSCF di IMS modificano il corpo dei messaggi SIP in un modo esplicitamente vietato ai proxy da IETF, ancora una volta senza implementare le funzionalità di User Agent che consentirebbero ciò.

Posto che l'S-CSCF dovrebbe essere in grado di agire in entrambi i ruoli (di proxy e di UA), ma in situazioni distinte (e con scopi distinti), Lucent ne riconosce il comportamento anomalo: in alcune situazioni l'S-CSCF si comporta da proxy e da UA nell'ambito di un medesimo dialogo SIP, mescolando funzionalità che, secondo le specifiche IETF, non dovrebbero essere usate contemporaneamente.

Secondo Lucent, esistono due tipi di approcci per la soluzione di quest'inconsistenza. Il concetto alla base di entrambi è che quando l'S-CSCF si trova in una posizione ibrida tra i due ruoli (proxy o UA), bisogna fargli assumere l'uno o l'altro di essi. Il primo approccio consiste nel rendere l'S-CSCF un proxy SIP puro in dialoghi o in transazioni SIP isolate ove l'inconsistenza si verifichi. L'altro approccio consiste nel rendere, nella stessa situazione, l'S-CSCF uno UA puro; questo può ottenersi facendo interpretare ad ambedue gli S-CSCF (quello in contatto con lo UE chiamante e quello in contatto con lo UE chiamato) il ruolo di B2BUA.

Per quanto riguarda la prima soluzione possibile, Lucent fa osservare che rendere l'S-CSCF un proxy puro non permette di soddisfare i requisiti di servizio richiesti da 3GPP: in particolare, ad un proxy SIP non è consentito modificare il corpo SDP del messaggio SIP in base al profilo dell'abbonato (Problemi di classe 3), né è consentito generare richieste di tipo BYE (Problemi di classe 1). Inoltre, allo scopo di instradare i messaggi SIP in base a dei criteri di filtro, un S-CSCF manipola le intestazioni dei messaggi stessi in un modo che va oltre le possibilità di un semplice proxy (Problemi di classe 2). In base a queste osservazioni, Lucent considera non praticabile questa soluzione. Al contrario, adottando la seconda soluzione, potrebbe essere possibile eliminare i problemi di interoperabilità appartenenti a tutte e tre le classi. Infatti, ad un B2BUA è consentito: modificare il corpo SDP dei messaggi SIP (Problemi di classe 3) sulla base del profilo dell'abbonato; generare richieste di tipo BYE per conto degli UE (Problemi di classe 1); modificare le intestazioni per l'instradamento per interagire con gli AS e per offuscare la topologia di rete (Problemi di classe 2). Infine, secondo Lucent, imporre ad un S-CSCF il ruolo di B2BUA lascia anche spazio per una futura evoluzione dell'S-CSCF stesso, di pari passo con l'evoluzione della Release 6 e oltre.

Per capire come l'adozione della seconda soluzione può risolvere tutte e tre le classi di problemi di interoperabilità, Lucent suggerisce di tenere presente che, quando un S-CSCF si comporta come un B2BUA, valgono le regole seguenti.

1. L'S-CSCF si comporta da B2BUA alla ricezione della richiesta che inizia il dialogo. L'S-CSCF associato con l'UA da cui ha origine l'INVITE iniziale riceve tale messaggio come un B2BUA; anche l'S-CSCF associato con l'UA cui è destinato l'INVITE riceve tale messaggio (da parte dell'S-CSCF corrispondente, possibilmente tramite un I-CSCF, oppure da un MGCF, nel caso che la chiamata provenga da PSTN) come un B2BUA.

2. In ogni interazione con un AS, l'S-CSCF si comporta come un B2BUA. Questo implica che, ogniqualvolta un S-CSCF contatta un AS sulla base di determinati criteri iniziali di filtraggio, sarà creato, da parte dell'S-CSCF stesso, un nuovo dialogo SIP tra le due entità.

3. L'S-CSCF si comporta da B2BUA all'invio della richiesta che inizia il dialogo verso la sua destinazione finale, dopo l'interazione con l'AS. L'S-CSCF associato con l'UA da cui ha origine l'INVITE iniziale invia tale messaggio verso l'S-CSCF corrispondente (possibilmente tramite un I-CSCF) o verso un BGCF oppure verso un MGCF, come un B2BUA; anche l'S-CSCF associato con l'UA cui è destinato l'INVITE invia tale messaggio verso l'UA di destinazione come un B2BUA.

In ognuna delle situazioni presentate, vengono generati due dialoghi distinti, a causa del comportamento da B2BUA dell'S-CSCF e questo consente di evitare i problemi di interoperabilità appena presentati. L'S-CSCF stesso sarà responsabile della gestione della correlazione tra questi due dialoghi.

Nell'interpretazione del ruolo di B2BUA, si potrebbe concedere all'S-CSCF completa libertà di scelta sull'utilizzazione di messaggi e dati provenienti da un dialogo nell'altro dialogo corrispondente. Tuttavia questa caratteristica avvicinerebbe il comportamento dell'S-CSCF a quello di un AS, e questo non è l'intento della proposta avanzata da Lucent. In ogni caso, per poter superare i problemi di interoperabilità con le specifiche IETF, all'S-CSCF deve essere garantita la libertà di alterare alcune intestazioni e il corpo del messaggio SIP.

La definizione delle procedure per l'interazione tra S-CSCF (come B2BUA) ed AS deve comprendere anche le metodologie per la manipolazione delle intestazioni nel modo che un AS si aspetta; tale manipolazione avviene sostanzialmente sulla base delle informazioni presenti nel profilo di servizio per l'abbonato, che controllano anche quali altri AS (oltre al primo) possono essere coinvolti. Naturalmente, ogni altro AS coinvolto oltre al primo non potrà fare affidamento sul passaggio in modo trasparente di tutte le informazioni, dal momento che il primo AS contattato, come B2BUA, potrebbe aver modificato le intestazioni della richiesta SIP che contenevano tali informazioni.

La regola di base per l'assunzione del ruolo di B2BUA da parte di un S-CSCF è la seguente: tutte le intestazioni e le parti del messaggio SIP ricevuto da un lato del B2BUA nell'ambito di un certo dialogo dovrebbero essere trasferite inalterate sul corrispondente messaggio SIP (appartenente al dialogo correlato al primo) uscente dall'altro lato del B2BUA. Questa regola di trasparenza include anche eventuali metodi sconosciuti all'S-CSCF, con la precisazione che un metodo sconosciuto ricevuto al di fuori di un dialogo sarà considerato come una transazione isolata. Secondo Lucent, le eccezioni a questa regola di trasparenza saranno documentate nelle opportune parti delle specifiche da modificare.

Lucent propone di seguito, a titolo di esempio, i nomi di alcune intestazioni che possono essere copiate senza problemi¹⁰ dall'S-CSCF (con funzione di B2BUA) dai messaggi del dialogo in cui sono ricevute a quelli del dialogo corrispondente dall'altro lato dell'S-CSCF. In particolare, si tratta delle intestazioni seguenti.

• Request-URI

• Require

• Subject

• Supported

• Content-Type

• Content-Length (sebbene le cose possano cambiare con la revisione dell'SDP)

• "P-headers" (sono anche consentite delle modifiche a quest'intestazione da parte dell'S-CSCF, come meglio specificato in [12])

Le intestazioni seguenti sono direttamente correlate al particolare dialogo SIP nei cui messaggi appaiono e non dovrebbero essere copiate da un dialogo all'altro, ma rigenerate:

• To

• From

• Call-ID

• Contact

• Cseq

• Record-Route

• Route

• Via

Le eccezioni alla regola di trasparenza illustrata poco fa sono elencate di seguito.

• In base ai dati del profilo utente, il corpo SDP del messaggio potrebbe essere modificato tra un dialogo ed il suo corrispondente dall'altro lato dell'S-CSCF; questo permetterebbe di risolvere i problemi di classe 3 identificati da IETF ed elencati all'inizio del paragrafo.

• L'intestazione Route potrebbe essere modificata per permettere l'inserimento dell'S-CSCF; questo permetterebbe di risolvere i problemi di classe 2 identificati da IETF ed elencati all'inizio del paragrafo.

In conclusione, Lucent propone, tramite una serie di documenti separati proposti durante il meeting, una serie di modifiche alle specifiche 3GPP [9] e [12], per riflettere il nuovo orientamento adottato per l'S-CSCF, oltre ad altre modifiche marginali riguardanti gli esempi relativi all'S-CSCF in [11]. Lucent inoltre precisa che sarebbe necessario anche del lavoro aggiuntivo da parte del WG SA2, per allineare i requisiti architetturali alla nuova situazione.

Nel dibattito seguito alla presentazione della proposta è emersa l'opinione seguente. È stato osservato che è troppo tardi per introdurre la soluzione proposta in [9] ed in [12], comprese le modifiche alle intestazioni e tutto il resto; inoltre l'idea di consentire agli S-CSCF di fungere da "estremi" del dialogo SIP (del resto un B2BUA è, in fin dei conti, l'unione di due UA correlati, e quindi di due terminali dei dialoghi SIP) non è stata accettata in modo unanime. L'adozione della soluzione di Lucent comporterebbe l'introduzione di troppe novità; posticiparne l'inserimento alla Release 6 renderebbe difficile l'interoperabilità con le strutture conformi alla Release 5, a meno di un (improbabile) aggiornamento simultaneo di tutti i nodi di rete. In definitiva, non c'è stato accordo sull'adozione di questa proposta.

4.2.7.2 Proposta riguardante la modifica del corpo SDP dei messaggi SIP

Questa proposta, presentata per conto di Dynamicsoft, Ericsson, Hutchison, Vodafone, Nokia, fornisce le modifiche opportune alla specifica di fase 3 [12]. Tali modifiche sono in correlazione con quelle presentate dagli stessi promotori a proposito dei requisiti architetturali presenti nella specifica di fase 2 [10], e documentate nel paragrafo 4.2.6.3. Scendendo nei dettagli, vengono formalizzati i comportamenti delle entità di rete UE ed x-CSCF (dove "x" sta per "P" (Proxy) o "S" (Serving)) per la negoziazione end-to-end di codec e/o media durante l'instaurazione della sessione SIP, nel caso in cui siano presenti elementi non consentiti dai criteri locali dell'operatore di rete o dal profilo dell'abbonato. La figura 4.6 descrive quel che accade presso un x-CSCF alla ricezione di un INVITE contenente un SDP non conforme ai criteri.

Figura 4.6 - Dettaglio del comportamento del CSCF

1. L'INVITE arriva all'x-CSCF; a questo punto viene effettuato il controllo sul corpo SDP del messaggio.

2. Il controllo ha esito negativo. L'x-CSCF emette una risposta SIP con Result-Code 488, e Reason-Phrase "Not Acceptable Here", a segnalare che il corpo SDP non è conforme ai criteri in vigore presso l'x-CSCF stesso. Tale risposta conterrà a sua volta un corpo SDP contenente codec e/o media ammessi dai criteri suddetti. Questo consentirà un eventuale nuovo tentativo, da parte dello UE che ha iniziato la sessione, con minori probabilità di fallimento.

3. Lo UE emette un nuovo INVITE con un corpo SDP conforme a quanto richiesto. Il nuovo INVITE arriva all'x-CSCF.

4. Questa volta il controllo ha esito positivo, e l'INVITE viene inoltrato verso la destinazione finale. L'instaurazione della sessione SIP procede normalmente fino alla ricezione della risposta affermativa 200 OK.

Nonostante in ambito CN1 fosse stato raggiunto un largo accordo per la sua approvazione, il fatto che la corrispondente proposta non sia stata approvata dal WG SA2 (cfr. paragrafo 4.2.6.3) ha impedito la immediata adozione della proposta, in attesa di decisioni dal lato TSG SA in merito.

4.2.7.3 Proposta di Ericsson sulla cancellazione delle intestazioni per l'instradamento

Questa proposta, presentata come documento di discussione nei WG SA2 e CN1 e dibattuta nella sessione congiunta di cui si sta trattando, suggerisce un metodo per soddisfare i requisiti di servizio imposti da SA1 ed SA2 al P-CSCF riguardo le intestazioni per l'instradamento (cfr. paragrafo 4.2.2.2) senza violare le specifiche IETF. In breve, si evita che il P-CSCF elimini le intestazioni per l'instradamento dai messaggi SIP che deve dirigere verso gli UE, reinserendole poi in quelli provenienti dagli UE stessi e diretti verso gli S-CSCF o gli I-CSCF.

Ericsson sostiene che il requisito di sicurezza che giustifica l'attuale modus operandi del P-CSCF, ossia evitare l'aggiramento di particolari elementi di rete (ad esempio quelli preposti alla tariffazione), non è in effetti soddisfatto da tale comportamento. Per dimostrare ciò, vanno fatte le considerazioni seguenti.

1. A livello di rete a pacchetto, tutto il traffico di segnalazione proveniente da un certo UE è instradato verso un determinato P-CSCF, senza alternative. Questo è reso possibile dall'adozione di un contesto PDP dedicato alla segnalazione IMS, ossia di un canale in cui transitano solo pacchetti provenienti dallo UE e diretti al P-CSCF (oppure ai server DHCP, o DNS), e nient'altro. Quindi, il P-CSCF non può essere escluso dal percorso di segnalazione.

2. Una volta instaurata la sessione SIP, lo UE è a conoscenza dell'indirizzo della controparte, tramite il campo intestazione Contact ricevuto nella risposta 200 OK all'INVITE; eppure non può contattarla direttamente, a livello di segnalazione SIP, se il contesto PDP dedicato di cui al punto precedente è presente ed attivo. Va comunque notato che nulla vieta che lo UE contatti la controparte, noto il suo indirizzo IP, tramite una connessione non-IMS; ad esempio attraverso la rete GPRS, che fornisce comunque connettività verso le reti a pacchetto esterne e/o Internet.

La soluzione proposta da Ericsson si basa sui princìpi di seguito elencati.

1. Il P-CSCF non dovrà in nessun caso rimuovere delle intestazioni dai messaggi SIP in transito verso lo UE, in conformità con le procedure previste per i proxies dalla specifica IETF di SIP.

2. Lo UE per parte sua elaborerà tutte le intestazioni ricevute nel messaggio SIP in conformità con le procedure previste per gli UE dalla specifica IETF di SIP.

3. Il P-CSCF dovrà controllare l'utilizzo corretto dei valori nelle intestazioni da parte dello UE. Se uno UE avrà costruito e inviato una richiesta SIP contenente intestazioni scorrette (ad esempio "dimenticando" di inserire nel percorso di instradamento l'S-CSCF deputato alla fatturazione), il P-CSCF potrà respingerla al mittente, tramite una risposta SIP contenente un codice d'errore. Se invece i criteri locali adottati dall'operatore di rete, richiedono la sostituzione delle intestazioni fornite dallo UE, allora il P-CSCF potrà farlo, utilizzando i valori opportuni memorizzati in precedenza per il dialogo cui il messaggio SIP appartiene.

Questa soluzione implica la ricezione da parte dello UE delle intestazioni per l'instradamento, cosa non prevista prima. A parte la necessità di modifiche alle capacità degli UE, sono stati sollevati degli interrogativi sull'impatto in termini di maggior utilizzo delle risorse radio, aggiungendosi ulteriore carico ai messaggi SIP. Ericsson sostiene che tale impatto è irrilevante se, come previsto, sarà adottata la compressione della segnalazione SIP sul canale radio.

Ericsson invita all'eventuale adozione della soluzione nell'ambito della Release 5: la sua adozione nella Release 6 non sarebbe possibile, dal momento che sarebbero già circolanti terminali compatibili con la Release 5 e costruiti in accordo alle specifiche che prevedono l'eliminazione delle intestazioni da parte del P-CSCF.

Nel dibattito seguito alla presentazione, sono emersi pareri discordanti, ma la proposta è stata approvata. Nel dettaglio, si è raggiunto l'accordo sui punti seguenti:

• Lo UE dovrà implementare le intestazioni Via, Route,Record-Route,Path e Service-Route.

• Il P-CSCF non rimuoverà le intestazioni Via, Route,Record-Route,Path e Service-Route nei messaggi diretti verso lo UE.

• In base ai criteri dei singoli operatori di rete, si potrà, tramite il P-CSCF, imporre l'uso corretto delle intestazioni per l'instradamento da parte degli UE tramite la sostituzione di quelle utilizzate in modo improprio.

• Allo scopo di garantire un controllo più fine da parte dell'operatore sull'uso delle intestazioni, l'applicazione delle regole di cui al punto precedente dovrà avvenire intestazione per intestazione e non su tutte le intestazioni per l'instradamento considerate come un'unica stringa.

4.2.7.4 Proposta di DynamicSoft sulla manipolazione del corpo dei messaggi SIP

La proposta verte in particolare sulla manipolazione collegata all'uso delle Service Info, le parti del corpo del messaggio SIP utilizzate nella segnalazione verso gli AS. Raccogliendo l'idea di CN1 riguardante questo tema (cfr. par. 4.2.2.7), DynamicSoft propone una modifica della specifica [9] che sancisce formalmente il divieto di utilizzare le Service Info in un contesto diverso dalla registrazione per conto di terze parti presso un AS, contesto in cui l'S-CSCF si comporta da UA (più precisamente da UA Client) e quindi non viola le specifiche IETF. La proposta è stata discussa ed approvata senza riserve.

4.2.7.5 Proposta sulla manipolazione delle intestazioni From e To

La proposta, presentata da DynamicSoft, si articola in due distinte CR (Change Request) alla specifica [12], che si riassumono di seguito.

La prima CR prescrive che la rete IMS non alteri in alcun modo il campo intestazione From,né basandosi sulla necessità di privacy asserita dall'utente, né basandosi su direttive riguardanti la privacy contenute nel profilo di rete dell'utente stesso, o nelle politiche dell'operatore di rete. Se l'utente ha bisogno di mantenere riservata la propria identità espressa nel campo intestazione From, dovrà in maniera esplicita attribuirgli il valore Anonymous. È prescritto inoltre che lo UE non attribuisca valori di default al campo intestazione From¹¹, in mancanza di esplicito consenso da parte dell'utente. Infine, per le chiamate SIP effettuate al di fuori dell'IMS, laddove a destinazione non sia implementata la specifica RFC3325 [5], l'utente dovrà sancire in modo esplicito la propria identità, attribuendo un valore diverso da Anonymous al campo intestazione From.

La seconda CR elimina completamente la possibilità che, alla ricezione di una richiesta SIP da inoltrare verso uno UE servito dall'S-CSCF, l'S-CSCF stesso alteri il campo intestazione To (impostandone il valore ad Anonymous) sulla base di criteri di configurazione locali (cioè stabiliti dall'operatore di rete) riguardanti l'offuscamento di tale campo intestazione, ed applicabili al dialogo di cui fa parte la richiesta.

Anche questa proposta è stata discussa ed approvata senza riserve.

4.2.7.6 Proposta sull'offuscamento della topologia di rete

Questa proposta, sponsorizzata da diverse parti (tra cui Ericsson, H3G, Nokia), cerca di chiarire che l'uso di un I-CSCF con funzionalità di THIG può, ma non necessariamente deve, essere implementato nell'IMS. La proposta prescrive alcuni cambiamenti alle parti della specifica [10] contenente i requisiti architetturali concernenti il THIG. Essenzialmente, i cambiamenti tolgono il carattere di indispensabilità all'esigenza di nascondere la topologia della rete all'esterno (cfr. par. 4.2.2.6); sebbene nella specifica fosse già affermato piuttosto chiaramente che l'uso del THIG non è obbligatorio, l'uso del termine "requisito" riferito all'esigenza suddetta si è prestato ad un'interpretazione ambigua, che ha condotto IETF a segnalare il possibile problema di interoperabilità. La proposta ha eliminato tale uso, facendo parziale chiarezza sulla vicenda.

Durante il dibattito relativo alla proposta, è emersa la necessità di rendere più chiaro che l'eventuale uso di un THIG dipende dalle scelte locali del gestore della rete. Per questo motivo la proposta è stata approvata, ma a condizione che SA2 ne facesse un'ulteriore revisione, dando poi comunicazione a CN1 degli eventuali cambiamenti significativi (cfr. paragrafo 4.2.6.2).

4.2.7.7 Liaison Statement di CN1 verso i TSG CN ed SA

Con questo LS il WG CN1 ha inteso segnalare ai TSG CN ed SA i progressi fatti nella trattazione delle questioni sollevate da IETF, includendo i riferimenti alle proposte approvate nel corso della sessione congiunta con il WG SA2. Dal punto di vista editoriale, il LS è un'integrazione dell'analisi presentata nel corso del 26° meeting del WG CN1 (descritta in modo dettagliato nel paragrafo 4.2.2) ed include per ogni singolo punto di contrasto le decisioni prese in proposito. Di seguito si riportano soltanto le variazioni rispetto all'analisi suddetta e le conclusioni finali.

4.2.7.7.1 Invio di BYE da parte del P-CSCF

Non ci sono stati progressi significativi a proposito di questo punto. Pertanto, restando invariati i requisiti posti da SA2 in [10], non c'è stata alcuna revisione della attuale modalità di comportamento del P-CSCF.

4.2.7.7.2 Cancellazione delle intestazioni per l'instradamento

Di concerto con le modifiche apportate dal WG SA2 ai requisiti architetturali imposti in [10], CN1 ha apportato le opportune modifiche alla specifica [12], sostituendo la rimozione delle intestazioni per l'instradamento con il controllo della loro correttezza e prescrivendo l'obbligo di interpretazione di tali intestazioni da parte dello UE (cfr. par. 4.2.7.3).

4.2.7.7.3 Le modifiche al corpo SDP del messaggio SIP

CN1 ha elaborato una Change Request per la specifica [12], con la quale si sostituisce la rimozione delle parti del corpo SDP non consentite con il loro controllo da parte dei CSCF e l'eventuale rifiuto del tentativo di instaurazione della sessione SIP (risposta "488 Not Acceptable Here"), corredato da un corpo SDP con codec e/o flussi accettabili (cfr. par. 4.2.7.2). CN1 precisa che, in mancanza dell'accordo da parte di SA2 sulle CR correlate, la soluzione proposta resta ferma, in attesa di notizie in proposito.

CN1 inoltre aggiunge che la soluzione proposta non risolve completamente le questioni poste da IETF (per esempio, la codifica S/MIME). CN1 conclude infine che, l'utilizzo di particolari soluzioni non standard per la gestione dell'attraversamento di firewall, di NAT (Network Address Translator), o di dispositivi per la transcodifica potrebbe provocare comunque delle minime modifiche al corpo SDP del messaggio SIP.

4.2.7.7.4 Manipolazione delle intestazioni From e To

CN1 comunica che la possibilità di offuscamento delle intestazioni From e To in base ai criteri dell'operatore è stata rimossa, con l'approvazione della proposta di DynamicSoft riguardante l'argomento ed illustrata nel paragrafo 4.2.7.5.

4.2.7.7.5 Manipolazione del corpo dei messaggi

CN1 comunica che,con l'approvazione della proposta di DynamicSoft al riguardo, illustrata nel paragrafo 4.2.7.4, la possibilità di manipolazione del corpo dei messaggi SIP da parte degli S-CSCF è stata opportunamente limitata ai casi in cui ciò è legittimo secondo IETF.

4.2.8 Le risposte del 18° meeting del TSG CN: LS verso il TSG SA

Al termine del 18° meeting del TSG CN è stata emesso un LS verso il TSG SA, comunicando i progressi fatti nella risoluzione delle questioni sollevate da IETF. Sono state comunicate nel dettaglio le Change Request approvate, che poi sono quelle che sono state discusse nell'ambito del meeting 27 del WG CN1 ed illustrate nel paragrafo precedente.

Il TSG CN ha in particolare sollecitato il TSG SA a decidere sulla proposta presentata nel meeting 28 del WG SA2, riguardante la modifica del corpo SDP dei messaggi SIP, e rimandata alla decisione del TSG stesso. Da tale decisione dipende infatti l'adozione della CR correlata da parte del TSG CN, che potrà essere adottata soltanto in caso di risposta affermativa da parte del TSG SA.

Il TSG CN inoltre ha proposto al TSG SA una serie di temi riguardanti la modifica del corpo SDP del messaggio SIP, nel caso in cui si decida di adottare la soluzione che prevede la risposta "488 Not Acceptable Here" da parte dei CSCF nel caso di corpo SDP non conforme ai criteri dell'operatore di rete. Tali temi sono di seguito riportati.

1. Rischio di mancanza di codec comuni tra i terminali da porre in comunicazione.
   Il TSG CN invita il TSG SA a sviluppare delle linee guida da fornire agli operatori di rete affinché vi sia un accordo di fondo sui criteri di scelta di codec e/o flussi da permettere nelle singole reti, minimizzando così la possibilità di un fallimento dell'instaurazione della sessione per mancanza di codec comuni.

2. Minimizzazione del tempo di session setup
   Il TSG CN invita il TSG SA a studiare delle soluzioni per minimizzare il ritardo nell'instaurazione della sessione dovuto allo scambio di risposte "488" ed ai susseguenti nuovi INVITE da parte dello UE. Essendo coinvolti P-CSCF ed S-CSCF sia per la VN che per la HN, tale scambio può avvenire fino ad un massimo di quattro volte, allungando i tempi per l'instaurazione della sessione.

3. Minimizzazione del tempo di session setup per le successive sessioni.
   Il TSG CN invita il TSG SA a considerare lo sviluppo di requisiti architetturali per l'implementazione di meccanismi di caching delle informazioni sui codec accettabili per l'operatore, al fine di poter sfruttare tali informazioni per l'instaurazione di sessioni multimediali successive. Questi meccanismi saranno allocati nello UE oppure nella rete IMS

4. Gestione degli errori reiterati da parte dello UE
   Il TSG CN invita il TSG SA a considerare lo sviluppo di metodologie di gestione delle situazioni in cui lo UE insiste nell'invio di una richiesta già giudicata inaccettabile.

Il TSG CN ha infine allegato all'LS una possibile bozza di risposta da spedire da parte del TSG SA verso IETF. Tale bozza si basa essenzialmente sull'ultimo LS in proposito ricevuto dal TSG CN da parte del WG CN1, e documentato nel paragrafo 4.2.7.7.

4.3 18° meeting del TSG SA: risposta finale di 3GPP ad IETF

La risposta finale da parte di 3GPP ad IETF è stata fornita al termine del meeting 18 del TSG SA. Tale risposta ricalca la bozza fornita dal TSG CN e comprende la decisione del TSG SA in merito all'approvazione della proposta sulla modifica del corpo SDP da parte dei CSCF. Il TSG SA ha approvato tale proposta, e quindi le modifiche previste sono state inserite nelle specifiche di stage 2. Il risultato è che i CSCF potranno respingere le richieste di INVITE contenenti codec e/o flussi non accettabili tramite la risposta SIP "488 Not Acceptable Here". Per comodità di lettura e per chiarezza si riporta in breve la situazione punto per punto.

1. Invio di BYE da parte del P-CSCF.
   La soluzione implementata da 3GPP prima della notifica del problema da parte di IETF è ritenuta la migliore possibile stanti i requisiti di servizio ed architetturali al riguardo.

2. Cancellazione delle intestazioni per l'instradamento.
   3GPP comunica l'approvazione di alcune CR (Change Request) che impediscono al P-CSCF la cancellazione delle intestazioni per l'instradamento dai messaggi indirizzati verso lo UE. Tali intestazioni dovranno essere ricevute e comprese dallo UE, per cui è stato anche reso obbligatorio il loro supporto nello UE stesso.

3. Modifica del corpo SDP da parte dei CSCF
   3GPP comunica che, in seguito all'approvazione delle appropriate CR, la rimozione dal corpo SDP dell'INVITE iniziale di codec e/o flussi non supportati dalla rete IMS è stata sostituita con il loro controllo, sempre da parte dei CSCF. In caso di controllo fallito, il CSCF potrà rispondere con una risposta SIP 488 "Unacceptable Here".

4. Manipolazione delle intestazioni From e To
   3GPP comunica che, con l'approvazione delle appropriate CR, è stato chiarito la rete IMS non manipolerà le intestazioni suddette. È stato anche sancito che lo UE non dovrà attribuire al campo From valori che possano violare la privacy dell'utente senza il suo esplicito consenso. Qualora l'utente volesse mantenere riservata la propria identità, dovrà farlo impostando esplicitamente il campo From al valore Anonymous.

5. Filtro delle identità da parte del P-CSCF
   L'identità filtrata dal P-CSCF è quella del campo P-Asserted-Identity, previsto dall'estensione [5] di IETF al protocollo SIP; l'utilizzo di tale intestazione avviene in conformità a quanto previsto da tale specifica. Il comportamento del P-CSCF è quindi ritenuto conforme alle specifiche SIP. Pertanto 3GPP non considera la questione sollevata come un vero problema.

6. Offuscamento della topologia di rete
   L'offuscamento della topologia di rete è una caratteristica dipendente non dalle specifiche di IETF ma dalle scelte implementative dei gestori di rete. La soluzione implementata da 3GPP prima della notifica del problema da parte di IETF è ritenuta la migliore possibile stanti i requisiti (opzionali, non obbligatori) di servizio ed architetturali al riguardo.

7. Manipolazione del corpo del messaggio SIP da parte dell'S-CSCF
   3GPP comunica che, con l'approvazione delle appropriate CR, è stato chiarito che la possibilità dell'S-CSCF di inserire informazioni nel corpo del messaggio SIP è stata limitata al caso di messaggi REGISTER per la registrazione per conto di terze parti (lo UE) presso un Application Server. In tale circostanza l'S-CSCF si comporta da UA, e non viola le specifiche SIP.

5 Conclusioni

5.1 Il punto della situazione

Figura 5.1 - Tabella riassuntiva di problemi e soluzioni per l'interoperabilità

Nella figura 5.1, presentata in un workgroup congiunto tra IETF e 3GPP tenutosi a Gennaio 2003, è riassunta la situazione riguardo i problemi di interoperabilità segnalati da IETF al termine del dibattito in sede 3GPP. Come visibile, e come ampiamente esposto nel capitolo 4, alcune questioni sono state risolte in modo efficace; altre parzialmente, con una soluzione non elegante e/o non efficiente, e necessiteranno di ulteriore lavoro da parte di 3GPP ed IETF; infine, alcune non sono state risolte.

In particolare, restano aperte le questioni riguardanti l'invio di BYE da parte del P-CSCF e l'offuscamento della topologia di rete.

Quest'ultima controversia dipende essenzialmente dai requisiti locali imposti al riguardo dagli operatori di rete, e questo è stato anche chiarito dalle CR approvate da SA nelle relative specifiche di stage 2. Come visibile dalla tabella, esiste anche la concreta possibilità che la questione sia abbandonata, se non vale la pena di risolverla.

Il primo problema è invece legato ad un requisito di servizio irrinunciabile per 3GPP; la possibilità di interrompere una sessione multimediale in atto dall'interno dell'IMS. Restano a tale proposito aperte le questioni sollevate a proposito del mancato riconoscimento del BYE da parte di UA IETF-compliant, che lo considereranno falso. Resta aperta anche la questione inerente al possibile attacco di tipo DOS verso lo UE 3GPP-compliant dall'esterno dell'IMS, qualora i parametri del dialogo cui appartiene il BYE arrivino in possesso dell'attaccante: il terminale 3GPP-compliant non potrebbe in tal caso distinguere tra BYE autentici e contraffatti, rischiando di accettare per buono quello dell'attaccante, con la conseguente impossibilità a continuare la sessione.

Per quanto riguarda la manipolazione del corpo SDP del messaggio SIP, si è alla ricerca di soluzioni migliori e di risolvere i problemi collaterali introdotti dall'adozione della soluzione illustrata, così come segnalato dal TSG CN al TSG SA nel LS documentato nel paragrafo 4.2.8.

Resta inoltre aperto il problema dell'uso della codifica S/MIME, così come previsto dalla specifica SIP di IETF. Per 3GPP, tale codifica non è accettabile all'interno dell'IMS; va studiata la possibilità di utilizzo di tale codifica nell'interazione tra UE 3GPP-compliant e UA IETF-compliant.

Quindi, per la soluzione di tali questioni rimaste aperte, 3GPP ed IETF rimandano ad ulteriori lavori da effettuarsi in preparazione al rilascio della Release 6.