UNIVERSITA’ DEGLI STUDI DI PALERMO FACOLTA’ DI INGEGNERIAfasciana/patch/SIGoverIP-overview.pdf · 2007-06-18 · M2PA è utilizzato quando il Signalling Gateway è sede anche

UNIVERSITA’ DEGLI STUDI DI PALERMO

FACOLTA’ DI INGEGNERIA

Dipartimento di Ingegneria Elettrica

La segnalazione telefonica e VoIP

(Overview)

Michele Luca Fasciana

Prof. Luigi Alcuri


2


Introduzione

L’integrazione Dati/Voce/Video (DVV) è ormai nelle cose. Diversi gestori di telefonia

sono in procinto di adottare infrastrutture a pacchetto per gestire e trasferire il traffico d’utente

nelle dorsali di rete (backbone).

Un discorso a parte deve essere fatto per ciò che concerne la gestione della segnalazione.

La mancanza di standard certi, la notoria inaffidabilità delle reti IP, motivi di sicurezza hanno

scoraggiato la realizzazione di sistemi basati sul criterio noto come all over IP. La figura seguente

rappresenta, schematicamente, lo stato dell’arte.

1 2 34 5 67 8 9

* 8 #

1 2 34 5 67 8 9

* 8 #

1 2 34 5 67 8 9

* 8 #

1 2 34 5 67 8 9

* 8 #

1 2 34 5 67 8 9

* 8 #

1 2 34 5 67 8 9

* 8 #

Figura 1

Come si osserva la segnalazione giunge ai Signalling Gateway dai nodi STP della rete SS7,

viene inviata al Media Gateway Controller locale e giunge al Media Gateway Controller remoto

viaggiando su canali dedicati, separata, logicamente e fisicamente, dal traffico d’utente. Lo

scenario presenta lati positivi (elevati livelli di sicurezza, affidabilità, etc.) che non è corretto

trascurare; ciononostante questa soluzione non è certamente definitiva per diversi motivi di

ordine economico e logistico.

Mantenere in piedi due sistemi, uno dedicato ai dati, l’altro alla segnalazione, comporta

alti costi; questo potrebbe rendere nulli i vantaggi economici dei sistemi VoIP.

Il secondo motivo, non meno importante, è di natura strettamente tecnica: oggi è

3


possibile utilizzare strumenti, quali i protocolli SCTP e SIP, che consentono di utilizzare

l’infrastruttura di rete IP anche per il trasferimento della segnalazione associata alle chiamate.

Inoltre, si vedrà in seguito come sia possibile continuare ad usufruire di servizi e funzionalità oggi

disponibili grazie ad SS7 (accesso a database remoti, numeri verdi, avviso di chiamata, etc.).

1 2 3

4 5 67 8 9

* 8 #

1 2 34 5 67 8 9

* 8 #

1 2 34 5 67 8 9

* 8 #

1 2 34 5 67 8 9

* 8 #

1 2 34 5 67 8 9

* 8 #

1 2 34 5 67 8 9

* 8 #

Figura 2 - All over IP

Come precedentemente accennato, le principali dorsali (backbone) delle reti pubbliche

tradizionali stanno per cedere il passo alla tecnologia VoIP. In pratica, le centrali diverranno dei

veri e propri Soft Switch chiamati a gestire un insieme di elementi. In particolare una centrale sarà

costituita da:

un Media Gateway Controller;

uno o più Signalling Gateway;

uno o più Media Gateway.

Media Gateway Controller (MGC) Costituisce l’intelligenza di call control; riceve la segnalazione SS7, opportunamente

mappata su IP dal Signalling Gateway, la inoltra ad altri MGC tramite un protocollo di

segnalazione, SIP, ISUP/TCP o H.323, la elabora e, in base a questa, pilota il Media Gateway

tramite il protocollo MGCP.

Signalling Gateway (SG) E’ l’entità che realmente si interfaccia con la rete SS7; riceve la segnalazione dagli switch

4


telefonici, la rimappa tramite il protocollo SIGTRAN e la invia al Media Gateway Controller.

Media Gateway (MG) E’ l’entità che converte i media (esclusa la segnalazione) provenienti da PSTN nel formato

richiesto per la rete IP, in base ai comandi ricevuti da MGC, utilizzando MGCP.

1 2 3

4 5 67 8 9

* 8 #

1 2 3

4 5 67 8 9

* 8 #

1 2 3

4 5 67 8 9

* 8 #

Figura 3 -Soft Switch-

In uno scenario che vede VoIP intervenire solo sulla dorsale, costituendo di fatto un ponte

(bridge) tra le centrali, il percorso seguito dalla segnalazione può essere individuato come segue:

1. il messaggio ISUP giunge al signalling gateway da un nodo STP della rete SS7;

2. il signalling gateway invia il messaggio al Media Gateway Controller;

3. il Media Gateway Controller locale scambia queste informazioni col Media

Gateway Controller remoto;

4. il Media Gateway Controller remoto invia il messaggio al Signalling Gateway

controllato;

5. il Signalling Gateway remoto fa giungere verso il corretto nodo SS7 (STP, SCP o

SSP).

5


Figura 4

Ognuno dei passaggi sopraccitati si svolge seguendo regole precise ed utilizzando

meccanismi opportuni che costituiranno l’oggetto dei prossimi paragrafi.

1. SG-MGC: l’architettura SIGTRAN

Il dialogo tra Signalling Gateway e Media Gateway Controller si svolge secondo le regole

definite dall’architettura nota come SIGTRAN (Signalling Transport) descritta nella RFC 2719.

Figura 5

Nel documento si definisce il protocollo di trasporto SCTP e diversi livelli di adattamento

(User Adaptation Layer). SCTP è stato sviluppato per rispettare i vincoli stringenti che le reti di

segnalazione telefonica devono rispettare. I livelli di adattamento consentono a diferenti

protocolli di segnalazione di utilizzare SCTP.

Nella seguente figura si mostra lo stack di protocolli di trasporto per il trasferimento della

segnalazione telefonica su reti IP.

6


Figura 6

I principali protocolli di segnalazione, considerati in ambito SIGTRAN, e trasportati

mediante i livelli di adattamento sono i seguenti:

ISDN Q.921 Users -> Q.931;

SS7 MTP3 Users -> SCCP, ISUP, TUP

SS7 MTP2 Users -> MTP3;

SS7 SCCP Users -> TCAP, RANAP, BSSAP…

Figura 7 - SigTran

7


ISDN Q.931 over IP: IUA In questo scenario si utilizza uno strato di adattamento chiamato IUA (ISDN Q.921 User

Adaptation). 9900 è il numero di porta SCTP (ma anche UDP/TCP) assegnata ad IUA.

Figura 8 - ISDN User Adaptation

MTP 3- SS7 over IP: M2UA/M2PA

In questo scenario sono previsti due possibili livelli di adattamento definiti:

M2UA (SS7 MTP2 User Adaptation)

M2PA (SS7 MTP2 User Peer-to-Peer Adaptation)

Figura 9 - M2UA

8


M2UA è il protocollo utilizzato principalmente tra Signalling Gateway e Media Gateway

Controller quando il primo si interfaccia con il livello MTP 2 di SS7 come mostrato in figura (e

non è sede, quindi delle funzionalità MTP 3, presenti, invece nel Media Gateway Controller).

Il numero di porta SCTP (ma anche UDP/TCP) assegnata ad M2UA è 2904, mentre il

valore del campo Payload Protocol Identifier dei Chunk SCTP è pari a 2.

Figura 10 - M2PA

M2PA è utilizzato quando il Signalling Gateway è sede anche del livello SS7 MTP3 o

livelli superiori, come descritto in figura. Il numero di porta SCTP (ma anche UDP/TCP)

assegnata ad M2PA è TBD, mentre il valore del campo Payload Protocol Identifier dei Chunk

SCTP è pari a TBD.

ISUP over IP: M3UA Il protocollo MTP3 User Adaptation (M3UA) supporta il trasporto del protocollo di

segnalazione ISUP (ISDN User Part), nonché TUP ed SCCP, su IP utilizzando il servizio offerto

da SCTP.

9


Figura 11 - M3UA

2. Stream Control Trasmission Protocol (SCTP)

SCTP è un protocollo di trasporto affidabile operante su reti che offrono un servizio

privo di connessione e, quindi, potenzialmente inaffidabili come le reti IP. Il protocollo consente

il trasferimento di datagram, denominati messaggi, in maniera sicura, evitando errori e/o

duplicazioni, mediante un meccanismo di ritrasmissione selettiva.

SCTP nasce nel 2000 grazie al lavoro di SIGTRAN, un workgroup, che si dedica a

risolvere le problematiche inerenti la trasmissione dei messaggi di segnalazione (ISUP, Q.931,

etc.) su reti commutate a pacchetto.

Figura 12 - SCTP

10


2.1. Caratteristiche principali

Il servizio di trasporto offerto da SCTP può essere decomposto in un numero di funzioni,

come mostrato nella seguente figura.

Figura 13 - SCTP function

Un’associazione è stabilita utilizzando un four-way handshake, secondo la sequenza

mostrata in figura nella quale i messaggi COOKIE ECHOE e COOKIE ACK possono

contenere anche dati dell’applicazione utente.

Figura 14 - four way handshake

11


Durante l’handshake gli utenti si scambiano uno o più indirizzi IP o host name, uno solo

dei quali sarà contrassegnato come primario, gli altri saranno utilizzati solo se questo diverrà

indisponibile durante la connessione. Questa caratteristica è nota come multihoming (indirizzi IP

multipli associati alla stessa connessione).

SCTP possiede pure capacità di multiplexing/demultiplexing all’interno di una

associazione. Una singola associazione può contenere diversi stream, ognuno dei quali viene

identificato mediante uno stream ID. Durante l’instaurazione vengono negoziati tra l’altro il

numero di tali stream.

Un’associazione può contenere differenti tipologie di stream in base al servizio richiesto;

il documento di specifica del protocollo ne individua due:

1. reliable ordered delivery (consegna affidabile ed in ordine);

2. reliable unordered delivery (consegna affidabile ma non in ordine).

È possibile altresì richiedere anche servizi non affidabili. È interessante osservare come i

servizi sono del tipo stream-based, quindi sulla stessa associazione si possono trasferire

contemporaneamente stream per cui si richiede il servizio di tipo ordered ed altri per i quali il

servizio è unordered.

Formato dei pacchetti SCTP Come si osserva in figura un pacchetto è costituito da un’intestazione comune e da vari

Chunk. Ogni Chunk può contenere sia informazioni di controllo del protocollo che dati d’utente.

Figura 15 - SCTP Packet

12


Figura 16 - SCTP Common Header

Figura 17 - SCTP Chunk format

Figura 18 - SCTP Data Chunk

Figura 19 - SCTP In Chunk it

13


SCTP SACK Gli Ack riportano tutti i numeri TSN (Trasmission Sequenze Number) relativi ai pacchetti

ricevuti correttamente. In particolare il valore del parametro Cumulative TSN ACK individua tutti

i dati riassemblati con successo in ricezione.

Mediante il cosiddetto Gap Block, il cui valore è individuato sottraendo al TSN più recente

il valore relativo all’intera sequenza ordinata e corretta, il ricevitore può indicare alla sorgente che

sono stati presumibilmente persi alcuni chunk. In tal modo la sorgente può ritrasmettere in

maniera veloce (fast retransmit) i pacchetti senza attendere lo scadere degli usuali timer di

trasmissione.

Controllo di flusso e meccanismi per evitare la congestione I meccanismi per controllare il flusso di traffico ed evitare la congestione sono abbastanza

simili a quelli previsti, tra l’altro, nel protocollo TCP. Essi sono del tipo window–based e

coinvolgono sia la sorgente che il ricevitore:

• il ricevitore controlla la velocità alla quale la sorgente invia i dati specificando il valore

nel parametro Receiver Window contenuto in ogni SACK (selective Ack), tale valore è legato

alle dimensioni dei buffer in ricezione; in questo modo si evita il fenomeno noto come

flooding;

• la sorgente mantiene una variabile nota come Congestion Window (CWND) che individua

il numero massimo di byte che possono essere inviati senza attendere la ricezione di

eventuali Ack. In tal modo è possibile inviare pacchetti SCTP nel periodo (circa 200

msec) tra la ricezione di un Chunk e la trasmissione del pacchetto Ack relativo.

L’associazione di figura 20 rappresenta due stream ordinati (stream id = 0 e stream id =

1). SCTP inserisce un numero di sequenza generale (TSN) ed un numero di sequenza per il

singolo stream (Stream seq). TSN è utilizzato per il controllo di flusso ed il recupero di pacchetti

persi, mentre Stream seq consente di consegnare stream individuali (demultiplex). Quando il

messaggio con TSN = 3 arriva al ricevitore, questi riconosce la perdita del pacchetto

contrassegnato con TSN = 2 è andato perso. D’altronde il ricevitore è in grado di accorgersi che

il pacchetto con TSN = 3 contiene lo stream successivo (Stream id =0) a quello correttamente

ricevuto e contrassegnato con TSN = 1 (infatti Stream seq =1). Quindi, è possibile consegnare il

pacchetto alla applicazione senza aspettare di ricevere TSN = 2. Nel messaggio SACK il

ricevitore informerà la sorgente che TSN = 2 è andato perso. Si osservi come la perdita di un

singolo stream non introduce ritardi su gli altri.

14


Figura 20 - Esemp o i

3. MGC-MGC

Se l’architettura SIGTRAN è ormai divenuta uno standard de facto per ciò che concerne

il dialogo tra Signalling Gateway e Media Gateway Controller, le regole, le problematiche legate al

dialogo tra i Controller sono, ad oggi, ancora aperte.

Figura 21

Le soluzioni possibili sono al momento due:

E-ISUP over IP

SIP

15


3.1. E-SUP

Col termine E-ISUP si indica una particolare implementazione di ISDN User Part, cche si

caratterizza per il limitato numero di messaggi e per le modifiche apportate che le consentono di

inserire all’interno degli stessi i descrittori di sessione secondo le regole dettate dal protocollo

SDP.

Figura 22

3.2. Session Initiation Protocol (SIP)

Session Initiation Protocol, definito nel documento RFC 2543, è un protocollo di

segnalazione e controllo operante al livello delle applicazioni, utilizzato per attivare, gestire e

chiudere le sessioni multimediali. Il protocollo è in grado di operare in combinazione con altri

protocolli di segnalazione come H.323 ed è indipendente dalla piattaforma sottostante (protocolli

di trasporto e di rete). SIP è, quindi, attivabile anche su reti Frame Relay, ATM AAL 5 o X.25.

SIP utilizza Session Description Protocol (SDP) per specificare i parametri della sessione.

Tra le funzionalità attivabili tramite SIP rientrano le autenticazioni per accedere alle conferenze

multimediali, la mobilità dell’utente, le conferenze multicast, la negoziazione delle capacità

terminali.

Figura 23 - Modello operazionale SIP

16


In estrema sintesi, il modello operativo, descritto in figura, assume che il cliente

chiamante invii un messaggio di invito al chiamato che, in caso di accettazione, ritorna un

messaggio di acknowledgement; questo è seguito da un messaggio di “OK”.

La rete definita SIP-enabled è una rete IP che include componenti usuali come router e

server DNS insieme ai server SIP. La principale funzione dei server SIP è quella di supportare le

telefonate che utilizzano Session Initiation Protocol per la segnalazione, fornendo un unico punto

di accesso ai client, effettuando il mapping tra nomi ed indirizzi IP ed operando la deviazione

delle richieste verso il corretto server SIP.

Due sono i componenti chiave di un sistema SIP:

• User Agent (UA);

• Network Server (NS).

User Agent (UA) Gli agenti utente sono applicazioni client operanti sul sistema terminale che contengono

un UAC (User Agent Client) ed un UAS (User Agent Server), chiamati rispettivamente client e

server. Il client inizia le richieste SIP ed opera come agente di chiamata dell’utente. Il server riceve

le richieste e restituisce le risposte da parte dell’utente; opera come agente per l’utente chiamato.

Network Server (NS) Vi sono due tipi di server SIP: proxy e redirect. Il protocollo agisce in maniera differente a

secondo del tipo di server coinvolto.

Il server SIP-proxy è solamente il punto di contatto a disposizione dei client per i

messaggi di segnalazione, contiene le funzioni di un client e di un server. Un server proxy

interpreta e può riscrivere le intestazioni delle richieste prima di passarle ad altri server.

Il server SIP-redirect accetta le richieste SIP ed invia al client una risposta di deviazione

contenente l’indirizzo del server successivo. Il server SIP-redirect non viene coinvolto nelle

successive fasi di segnalazione.

3.2.1. Indirizzamento SIP

Gli indirizzi SIP sono identificati attraverso un URL (Universal Resource Locator) SIP.

L’aspetto è praticamente identico al formato degli indirizzi e-mail, quindi del tipo: [email protected]

parte utente dell’indirizzo (user) può contenere il nome di un utente o un numero di telefono. La

parte host contiene il nome di un dominio, un CNAME o l’indirizzo numerico di rete. Esempi di

17


indirizzi URL SIP validi sono:

sip:[email protected]



Ma come può un utente effettuare una chiamata verso un client SIP se l’indirizzo URL

SIP non è conosciuto? È facile ipotizzare una procedura che utilizzi un motore di ricerca WWW

insieme ad un servizio di risoluzione dei nomi.

Si ipotizzi di voler contattare, ad esempio, il governatore di Lilliput.

Attraverso un motore di ricerca si otterrà il nome di persona “Mario Rossi”.

Un servizio di directory risolverà il nome fornendo un indirizzo URL (per esempio,

[email protected]).

Un server SIP risolverà l’indirizzo URL in un indirizzo URL SIP come

“sip:[email protected]”.

Un server DNS risolverà l’indirizzo ULR SIP ritornando un indirizzo IP.

3.2.2. Individuazione dei server SIP

Un client può inviare una richiesta SIP in maniera diretta, indirizzandola verso un server

proxy configurato localmente, oppure all’indirizzo IP e numero di porta corrispondenti

all’indirizzo URL SIP. Nel primo caso la procedura è abbastanza semplice in quanto

l’applicazione utilizzata conosce il server. La seconda può risultare problematica. infatti possono

verificarsi i seguenti casi:

• il client deve individuare l’indirizzo IP e numero di porta del server al quale è

destinata la richiesta;

• il numero di porta può risultare assente nell’indirizzo URL SIP di destinazione: in

questo caso si utilizza la porta standard 5060;

• se nella richiesta URL SIP non è specificato il tipo di protocollo di trasporto, il client

deve innanzitutto tentare di connettersi utilizzando UDP per poi eventualmente

provare con TCP;

• il client interroga il server DNS per ottenere l’indirizzo IP dell’host. Se il server DNS

non fornisce alcuna indicazione non vi sarà alcuna possibilità di inviare richieste SIP.

18


Figura 24 - SIP su infrastruttura TCP/IP

3.2.3. Richieste e Risposte: le transazioni SIP

Una volta risolto l’indirizzo il client invia una o più richieste SIP ricevendo le relative

risposte dal server specificato. La coppia richiesta/risposta viene considerata come unico

elemento di una transazione SIP. Per questo motivo gli ideatori del protocollo hanno scelto un

formato dell’intestazione identico per entrambe.

Le transazioni possono essere trasmesse utilizzando sia UDP che TCP. In quest’ultimo

caso tutti i messaggi e risposte relative alla stessa transazione SIP viaggiano su un’unica

connessione TCP. Nel caso di utilizzo di UDP la risposta sarà inviata all’indirizzo identificato

nell’intestazione. In questo caso diventa essenziale poter inserire l’intero messaggio SIP all’interno

di un unico datagram, in quanto la probabilità di perdita dell’intero messaggio aumenta col

numero di frammenti.

In figura è rappresentato lo stack di protocolli all’interno del quale è inserito SIP,

nell’ipotesi di utilizzo su un’infrastruttura TCP/UDP. Si osservi la presenza di SDP, per la

descrizione dei parametri di sessione, inseriti all’interno dei messaggi SIP.

3.2.4. I messaggi SIP

SIP definisce due tipi di messaggi: le richieste attivate dai client e le risposte restituite dai

server. I messaggi di richiesta sono utilizzati per iniziare, confermare, modificare e terminare le

19


chiamate; quelli di risposta per fornire informazioni su eventi in divenire (p.es. ringing SIP response)

o informazioni finali (p.es. busy SIP response).

Ogni messaggio contiene un’intestazione che descrive i parametri della comunicazione.

SIP è un protocollo basato su testo la cui sintassi e i cui campi di intestazione coincidono con

quelli del protocollo http (HyperTextTransferProtocol).

Intestazione L’intestazione consente di specificare il chiamante, il chiamato, il percorso nonché il tipo

di messaggio. Il protocollo individua, per i messaggi, 37 tipi di intestazioni organizzati in quattro

gruppi.

Intestazione generale: si applica alle richieste ed alle risposte.

Intestazione di entità: definisce informazioni relative al tipo ed alla lunghezza del

messaggio.

Intestazioni di richiesta: consente al client di includere informazioni di richiesta

aggiuntive.

Intestazioni di risposta: consente al server di includere informazioni di risposta

aggiuntive.

La seguente tabella elenca i gruppi principali ed i tipi di intestazione corrispondenti.

Messaggi di richiesta Il protocollo SIP introduce sei differenti tipi di messaggi di richiesta, definiti anche

metodi (Request method), di seguito descritti.

INVITE: il messaggio indica che l’utente o il servizio è invitato a partecipare alla

sessione. Include la descrizione della sessione e, per le chiamate bidirezionali, il

chiamante ed il tipo di informazioni.

ACK: viene utilizzato per terminare la transazione iniziata con il comando INVITE.

BYE: utilizzato dal chiamante e dal chiamato per il rilascio della chiamata.

CANCEL: annulla una qualsiasi richiesta in corso.

OPTIONS: per interrogare e ricevere informazioni sulle caratteristiche e funzionalità

degli agenti utente e dei server di rete. Il metodo è assente nella procedura di

attivazione delle sessioni.

REGISTER: utilizzato dai client per registrare le informazioni di localizzazione dei

server SIP.

20


Tabella 1 - Intestazioni SIP

Intestazioni

generali

Intestazioni

di entità

Intestazioni

di richiesta

Intestazioni

di risposta

Accept Content-Encoding Authorization Allow

Accept-Encoding Content-Lenght Contact Proxy-Authenticate

accept_Language Content-Type Hide Retry-After

Call-ID Max-Forwards Server

Contact Organization Unsupported

CSeq Priorità Warning

Date Proxy-Authorization WWW-Authenticate

Encryption Proxy-Require

Expires Route

From Requie

Record-Route Response-Key

Timestamp Subject

To User-Agent

Via

Tabella 2 - Parametri obbligatori nel messaggio SIP INVITE

Parametro Descrizione

Call-ID identifica univocamente un

determinato invito

CSeq numero di sequenza crescente

From identifica l’iniziatore della

richiesta

To identifica il destinatario della

richiesta

Via indica il percorso seguito dalla

richiesta

21


Messaggi di risposta I messaggi di risposta SIP, correlati alle relative richieste, vengono utilizzati per indicare il

successo o il fallimento della chiamata. Possono fornire informazioni di call progress o finali. I

messaggi di risposta contengono due campi caratteristici:

o Status-Code: intero di tre cifre che indica il risultato della richiesta;

o Reason-Prhase: fornisce una descrizione testuale comprensibile.

SIP individua sei classi di risposte, i relativi codici di stato, e la descrizione testuale.

3.2.5. Flussi di chiamata SIP

Nella forma più semplice, le chiamate SIP coinvolgono due client ed un server SIP. Vi

sono due distinti modelli di chiamata SIP: il modello proxy e il modello di chiamata redirect. Il

client chiamante invia il messaggio SIP INVITE al chiamato direttamente o mediante il server

proxy. I client individuano il server SIP attraverso un parametro di configurazione al parametro

proxy-server dei browser operanti in Internet.

Modello proxy Il modello assume la presenza di un server SIP proxy che gioca il ruolo molto simile a

quello del server proxy HTTP nel sistema omonimo. Questi server instradano i messaggi di

segnalazione tra le due parti. I pacchetti audio o video RTP sono inviati direttamente tra i client

dopo l’instaurazione della chiamata. La figura presenta una tipica procedura di segnalazione,

eseguita utilizzando il server proxy.

Modello redirect In questa modalità interviene un server SIP di tipo redirect che, ricevuto il messaggio di

richiesta (SIP INVITE) comunica al cliente chiamante l’indirizzo URL SIP del chiamato. La

procedura prosegue con lo scambio diretto tra le parti (chiamante e chiamato) dei messaggi di

segnalazione. Come mostrato in figura, il server informa il chiamante del momentaneo

spostamento del chiamato che è raggiungibile all’indirizzo comunicato nella risposta.

22


Figura 25 - flusso di chiamata SIP con server proxy

23


Figura 26 - Flusso di chiamata SIP con server redirect

24


Tabella 3 - Codici di risposta SIP

Status-Code Categoria Esempi di informazioni

1XX Informational trying, ringing, queued, etc.

2XX Success OK

3XX Redirection Moved permanently/temporarily, etc.

4XX Client Error Bad Request, unauthorization, not

found…

5XX Server Error server error, bad gateway, etc.

6XX Global failure Busy everywhere,etc.

3.3. SIP ed i protocolli di trasporto

SIP è un protocollo che può girare su diverse piattaforme di trasporto (TCP, UDP o

SCTP). Nei prossimi paragrafi si descrivono vantaggi e svantaggi riscontrati in base al particolare

protocollo di trasporto scelto per SIP.

3.3.1. SIP over TCP

La scelta più ovvia per trasportare un protocollo di segnalazione i cui messaggi devono

essere consegnati in maniera affidabile a destinazione è certamente l’utilizzo di un protocollo di

trasporto altrettanto affidabile.

TCP fu progettato per consentire il trasferimento di elevate quantità di dati tra due end-

point. Una volta stabilita la connessione, il protocollo è in grado di implementare meccanismi di

controllo di flusso e correzione dell’errore basate sulle caratteristiche del traffico end-to-end.

D’altronde il traffico di segnalazione non consiste di elevate quantità di informazioni.

fast retransmit algorithm. Quando grandi quantità di dati sono state trasmesse da TCP, il ricevitore invia

continuamente messaggi di Ack indicando la corretta ricezione degli stessi. Quasti invia duplicati

degli Ack nell’eventualità di ricezione fuori ordine di segmenti. Quindi l’arrivo di ack duplicati

indica che un dato segmento è andato perduto. In tal modo la sorgente ritrasmette senza

aspettare il timeout. Questo meccanismo è noto come fast retransmit ed è utilizzato in TCP

insieme all’algoritmo noto come fast recovery.

25


SENDER RECEIVER

1:257

ACK 257

257:513 x513:769

ACK 257

257:513

Figura 27 - Esemp oi

Come si osserva in figura, la sorgente ritrasmette il segmento alla ricezione di un

messaggio di Ack duplicato. Si osservi come il flusso dell’esempio di figura è semplificato, nel

senzo che le implementazioni effettive prevedono la ritrasmissione dei segmenti solo quando il

numero di duplicati è pari ad un N prefissato (in genere, N=3).

Con questo meccanismo è possibile immaginare uno scenario in cui le ritrasmissioni

avvengono per via della ricezione di duplicati piuttosto che per lo scadere di eventuali timer. Per

questa ragione i timeout TCP sono relativamente alti e pari, in genere ad 1,5 sec.

Figura 28 - TCP timeout

26


Si osservi come i messaggi SIP siano abbastanza piccoli (> 1000 byte) e tali, quindi, da

poter essere contenuti all’interno di un unico segmento TCP. Quindi, se un segmento che

contiene un intero messaggio SIP, dovesse andare perduto, non sarebbe possibile con TCP

ricevere gli ack duplicati, se non si dovessero inviare altri messaggi e si dovrebbe attendere la fine

del timeout per rilevare la perdita e procedere alla ritrasmissione (vedi figura).

Instaurazione Della Connessione Tcp. Prima che i dati d’utente possano essere inviati TCP utilizza una modalità del tipo three-

way handshake tra sorgente e destinazione. In tal modo il tempo di instaurazione della sessione

TCP può divenire elevato. Se questo non è un problema per le connessioni ad elevata durata

(trasferimento di file per esempio), può esserlo quando l’applicazione che utilizza TCP genera

traffico fortemente sensibile ai ritardi. Questo è il caso di SIP.

Come si osserva in figura il ricevitore non passerà alcun dato d’utente all’applicazione se

non si sarà conclusa la fase di instaurazione della sessione TCP. Questo provoca un overhead del

tutto inaccettabile nel caso in cui l’utente, ad esempio, sta aspettando un messaggio di risposta ad

un messaggio INVITE.

Figura 29 - three way handshake

TCP implementa un timer speciale per lo stabilirsi della connessione. Quando un

messaggio SYN va perso, un implementazione tipica lo ritrasmette dopo 6 secondi. Quindi la

perdita di un solo pacchetto incrementa in maniera enorme il ritardo di instaurazione della

connessione.

Multiple Sip Session

27


Una possibilità per ovviare ai problemi esposti precedentemente è quella di inviare diverse

sessioni SIP su un'unica connessione TCP. Con un elevato numero di sessioni SIP , TCP si

troverebbe nella condizione a lui più consona, dovendo occuparsi di una sessione caratterizzata

da un elevato e continuo scambio di dati che renderebbero efficaci gli strumenti di controllo di

traffico e congestione prima esposti.

Un ulteriore vantaggio è certamente quello per il quale “multiplare” diverse sessioni SIP

su unica connessione TCP annulla il ritardo di instaurazione della connessione: i messaggi

INVITE possono essere inviati immediatamente in quanto vengono trasferiri su connessioni

TCP preesistenti.

Byte Stream Service Un importante limitazione di TCP riguarda le modalità di consegna dei messaggi ricevuti

all’applicazione (nel nostro caso SIP). TCP non riconosce messaggi ma assicura una consegna

ordinata di stream di byte.

Quando il protocollo è utilizzato per trasmettere i messaggi egli preserva l’ordine con cui

tali messaggi sono stati inviati dalla sorgente. Questa proprietà può causare problemi di

interazione tra differenti sessioni SIP trasferiti su una singola connessione TCP.

Si osservi, a tal proposito il flusso descritto nella seguente figura. La sorgente invia

messaggi INVITE relative a differenti sessioni SIP sulla stessa connessione TCP. Il segmento che

trasporta il primo messaggio (1:513) viene perso, mentre l’altro (513:1025) arriva correttamente al

ricevitore. Dovendo consegnare in maniera ordinata la sequenza di byte, TCP non farà giungere

all’applicazione il secondo INVITE sinchè non avrà a disposizione il primo. Quindi il secondo

INVITE subirà un ritardo pari al tempo di ritrasmissione del primo. La conseguenza è che una

sessione SIP potrebbe subire ritardi ingiustificati senza, cioè, aver subito perdite in trasmissione.

28


Figura 30 - Esemp o i

3.3.2. SIP over UDP

Trasportare SIP utilizzando User Datagram Protocol è un’altra possibilità, grazie anche

alla struttura di SIP che è un protocollo del tutto autonomo e, quindi, non dipendente

dall’infrastruttura sottostante (livello di trasporto). In questo scenario un particolare messaggio

INVITE, per esempio, viene incapsulato all’interno di un pacchetto UDP senza introdurre alcun

ritardo dovuto all’instaurazione di una qualche connessione. Poiché UDP è un protocollo di tipo

connectionless, l’affidabilità del trasferimento dei messaggi viene demandata al livello applicativo

attraverso particolari meccanismi di ritrasmissione basati essenzialmente su timer. SIP prevede

tempi di ritrasmissione molto più brevi di TCP (dell’ordine di 0,5 sec). Questo comporta una

politica di ritrasmissione più aggressiva che potrebbe comportare una forte degradazione del

traffico. Si osservi, però, come SIP si caratterizzi per la piccola dimensione dei messaggi

scambiati, giustificando un dimensionamento dei timer così stringenti senza, per questo, mandare

necessariamente in congestione la rete.

Concludendo la scelta di UDP per SIP non è del tutto arbitraria, specie se si devono

gestire poche sessioni. D’altronde, l’impossibilità di conoscere l’effettivo stato della rete, non

essendo previsto alcun meccanismo di controllo, ne scoraggia fortemente l’utilizzo quando

bisogna gestire elevati volumi di traffico di segnalazione.

29


Figura 31 - UDP timeout

3.3.3. SIP over SCTP

Per le caratteristiche precedentemente descritte, SCTP sembra la scelta migliore per

consentire il trasferimento dei messaggi SIP. Se ciascuna sessione SIP è inviata su uno stream

ordinato, i messaggi possono avvantaggiarsi dei meccanismi di controllo di flusso senza subire

ritardi nel caso si verificassero perdite in altre sessioni.

Può accadere, però, che alcuni messaggi subiscano dei ritardi nell’ambito della stessa

sessione. Nell’esempio di figura si descrive come la perdita di una risposta provvisoria (SIP 100

Trying) possa provocare il ritardo della consegna della risposta finale (SIP 180 Ringing) che era

stata ricevuta in maniera corretta.

Come si osserva tutte le risposte SIP sono inviate su uno stream STCP in maniera

ordinata (Stream id = 0). Poiché la risposta provvisoria (180 Ringing) è andata persa, SCTP non

può consegnare la risposta finale (200 OK) all’applicazione. Il protocollo aspetterà sino a quando

non arriva lo stream con TSN = 2.

Servizio Unordered per le risposte finali Per ovviare questo problema è possibile richiedere ad SCTP un servizio di trasporto in

modalità unordered. Il protocollo invierà i messaggi senza un ordine preciso, all’interno di stream

comunque ordinati. Quindi, tutti i messaggi SIP relativi ad una stessa sessione sono inviati

utilizzando lo stesso stream (stesso Strea id), ma i messaggi che contengono risposte finali sono

inviati settando il parametro SCTP unordered flag.

Un’ulteriore caratteristica di SCTP è quella di consentire il demultiplexig in base al

parametro SIP Call-ID e non in base al valore Stream id.

30


Figura 32 - Esempio

Servizio unerdered generico È possibile, infine, richiedere il servizio in modalità unordered per tutti i messaggi SIP

relativi alla medesima sessione; in tal modo il ricevitore consegnerà tutti i messaggi in arrivo

immediatamente, indipendentemente da quale valore assuma Stream id e/o Stream Seq. Quindi le

entità SIP possono utilizzare il medesimo stream per inviare messaggi relativi a differenti sessioni.

Questa modalità sembra la migliore quando è necessario mantenere continuamente aperte

sessioni SCTP a causa, per esempio, dell’elevato volume di messaggi di segnalazione scambiato.

3.4. SIP-T

Come è noto Session Initiation Protocol consente di instaurare, gestire ed abbattere le

sessioni voce e dati. Per le sue caratteristiche il protocollo gioca un ruolo chiave per implementare

efficacemente Voice over IP.

Con SIP-T (SIP for Telephones) si indica una classe di documenti redatti per definire un

unico standard per la comunicazione tra Media Gateway Controller secondo lo scenario descritto

nella figura seguente.

31


Figura 33 - Voice over IP

I Media Gateway sono connessi alla rete pubblica tradizionale mediate i circuiti trunk SS7,

i circuiti trunk Q.931 ed i circuiti trunk CAS. I Media Gateway Controller si interfacciano,

mediante i Signalling Gateway direttamente con la rete SS7. E’ possibile individuare alcune

caratteristiche chiave che devono essere presenti in una rete di segnalazione VoIP:

• Trasparency

• Routability

• Mid-call information

Tabella 4 - SIP-T

Esigenza Funzione SIP-T

Trasparency

Routability

Mid-call information

SIP Encapsulation

SIP Traslation

SIP INFO-Method

Trasparency

32


Un importante caratteristica delle reti VoIP SIP è quella della trasparenza rispetto alle

PSTN. I tradizionali servizi disponibili grazie ad SS7, quali la chiamata in attesa (call waiting), i

numeri verdi, etc., devono continuare ad essere offerti ai clienti. È essenziale, quindi, che le

informazioni SS7 nella loro interezza siano disponibili nei punti di interconnessione PSTN/VoIP,

anche quando vi sia un diretta corrispondenza con SIP. Session Initiation Protocol consente di

trasferire all’interno dei messaggi (SIP Encapsulation Function), informazioni ISUP, che

attraversano in maniera trasparente la rete garantendo l’accesso a servizi che risiedono al di fuori

della rete VoIP.

Routability Un messaggio SIP deve contenere informazioni sufficienti per essere indirizzato verso la

corretta destinazione (corretto MGC di uscita). Diventa essenziale la funzione di traslazione degli

indirizzi (SIP Translation Function) operata dai server proxy SIP.

Mid-call information Le specifiche che definiscono SIP non prevedono alcun meccanismo per trasferire

informazioni di segnalazione, scambiate durate la sessione, che non coinvolgono direttamente

cambiamenti nel protocollo. Il metodo SIP INFO definito nella draft omonima risolve il

problema.

3.4.1. Encapsulation: ISUP/Q.931 MIME Type

Come mostrato in figura, un messaggio SIP consta di un intestazione e di un body. La

parte body, utilizzando il formato MIME (Multipurpose Internet Mail Extensions), in genere

contiene le informazioni necessarie per instaurare le sessioni multimediali secondo quando

prescritto da Session Description Protocol (SDP).

33


Figura 34 - Header/Body

E’ possibile inserire all’interno del messaggio altre informazioni, quali i messaggi ISUP

e/o Q.931, utilizzando i formati MIME ISUP e MIME QSIG definiti nella RFC 3204. In tal

modo la segnalazione può viaggiare lungo la rete in maniera del tutto trasparente. Di seguito si

mostrano due esempi di messaggio SIP INVITE contenenti nel “body” un messaggio ISUP e

Q.SIG rispettivamente.

E’ opportuno osservare che, in realtà, sia ISUP che QSIG utilizzano una codifica binaria e

non esadecimale come sembrerebbe dai precedenti esempi. La scelta della rappresentazione

esadecimale è dovuta solo a motivi di leggibilità, quindi il valore hex 34 ( 52 decimale) è da

intendersi come 00110100.

34


Figura 35 - Messagg o SIP ISUP (es.) i

Figura 36 - Messaggio SIP QSIG(es.)

35


3.4.2. Traslation

Nello scenario che vede la rete SIP-enabled far da “ponte” (bridging) tra centrali PSTN, i

Media Gateway Controller giocano il ruolo di convertitori tra ISUP e SIP o QSIG e SIP.

Generalmente, due sono le operazioni che vengono eseguite dai Media Gateway

Controller:

ISUP (QSIG) SIP message mapping;

ISUP (QSIG) SIP header mapping.

In base alla prima operazione il Controller genera un messaggio SIP per ogni messaggio

ISUP (QSIG) che giunge sull’interfaccia con il Signalling Gateway e viceversa. Diversi documenti

specificano, mediante esempi di flussi di chiamate o mediante macchine di stato, le modalità

secondo le quali ciò avviene (p.es. ad un messaggio ISUP IAM corrisponde un SIP INVITE, ad

ISUP REL un messaggio SIP BYE, etc.).

La seconda operazione (ISUP SIP header function) è una consequenziale alla prima. I

messaggi generati devono contenere informazioni sufficienti per essere correttamente indirizzati

lungo la rete SIP; quindi è necessario che gran parte delle informazioni contenute nei messaggi

ISUP (QSIG) siano presenti nelle intestazioni dei relativi messaggi SIP. Anche in questo caso

sono state definite regole ben precise (p.es. il valore di Called Party Number, CPN, del messaggio

ISUP IAM deve essere mappato nel campo “To” dell’intestazione del relativo SIP INVITE, etc.).

Figura 37 - SIP Bridge

3.4.3. SIP INFO Method

Le specifiche originarie di SIP (note come “pure SIP”) non forniscono alcun meccanismo

per trasferire informazioni di controllo durante una connessione già attiva (middle-call

information). Praticamente il protocollo è in grado di attivare ed abbattere le sessioni ma non

36


prevede scambi di informazioni durante il periodo di vita delle stesse. Invero, ISUP e Q.931 si

caratterizzano per scambi informativi sullo stato e/o di gestione delle chiamate durante lo

svolgimento delle stesse.

Per risolvere questa incompatibilità è stato definito nel documento RFC 2976 un nuovo

messaggio (Metodo) SIP: INFO method.

SIP INFO non modifica le caratteristiche della chiamata e/o i parametri della sessione

SIP, ma trasferisce informazioni opzionali scambiate tra le applicazioni che stanno utilizzando il

protocollo. In pratica contiene nel body i messaggi ISUP (QSIG) incapsulati secondo le modalità

precedentemente descritte (formato MIME).

3.4.4. Flussi di chiamata

Caso I: scenario ISUP-SIP-ISUP

Figura 38 - Call flow ISUP-SIP-SIP

37


(1) IAM Switch A -> Ingress Soft Switch IAM CgPN=314-555-1111,NPI=E.164,NOA=National CdPN=918-555-3333,NPI=E.164,NOA=National

(2) INVITE Ingress Soft Switch -> Proxy INVITE sip:[email protected];user=phone SIP/2.0 Via: SIP/2.0/SCTP iss.atlanta.com:5060;branch=z9hG4bKlueha2 Max-Forwards: 70 From:<sip:[email protected];user=phone>;tag=7643kal To: <sip:[email protected];user=phone> Call-ID: [email protected] CSeq: 1 INVITE Contact: <sip:[email protected];user=phone> Content-Type: application/sdp Content-Length: 141 v=0 o=GW 2890844526 2890844526 IN IP4 gw1.atlanta.com s=- c=IN IP4 192.168.255.101 t=0 0 m=audio 49172 RTP/AVP 0 a=rtpmap:0 PCMU/8000

/* Proxy consulta un Location Service e traduce il numero digitato in un numero privato nel campo SIP Request-URI*/ (3) INVITE Proxy -> Egress Softswitch

INVITE sip:[email protected] SIP/2.0 Via: SIP/2.0/SCTP proxy.atlanta.com:5060;branch=z9hG4bK2d4790.1 Via: SIP/2.0/SCTP iss.atlanta.com:5060;branch=z9hG4bKwqwee65 ;received=192.168.255.101 Max-Forwards: 69 Record-Route: <sip:proxy.atlanta.com;lr> From:<sip:[email protected];user=phone>;tag=7643kal To: <sip:[email protected];user=phone> Call-ID: [email protected] CSeq: 1 INVITE Contact: <sip:[email protected];user=phone> Content-Type: application/sdp Content-Length: 141 v=0 o=GW 2890844526 2890844526 IN IP4 iss.atlanta.com s=- c=IN IP4 192.168.255.101 t=0 0 m=audio 49172 RTP/AVP 0 a=rtpmap:0 PCMU/8000

38


(4) IAM Egress Softswitch-> Switch

IAM CgPN=314-555-1111,NPI=E.164,NOA=National CdPN=444-3333,NPI=Private,NOA=Subscriber

(5) ACM Switch -> GW 2 /* Ricevuto il messsaggio di ACM il Softswitch ritorna una risposta SIP 183. */ (6) 183 Session Progress ESS -> Proxy SIP/2.0 183 Session Progress Via: SIP/2.0/SCTP proxy.atlanta.com:5060;branch=z9hG4bK2d4790.1 ;received=192.168.255.111 Via: SIP/2.0/SCTP iss.atlanta.com:5060;branch=z9hG4bKlueha2 ;received=192.168.255.101 Record-Route: <sip:proxy.atlanta.com;lr> From: <sip:[email protected];user=phone>;tag=7643kal To: <sip:[email protected];user=phone>;tag=314159 Call-ID: [email protected] CSeq: 1 INVITE Contact: <sip:[email protected]> Content-Type: application/sdp Content-Length: 149 v=0 o=GW 987654321 987654321 IN IP4 ess.atlanta.com s=- c=IN IP4 192.168.255.202 t=0 0 m=audio 14918 RTP/AVP 0 a=rtpmap:0 PCMU/8000

(7) 183 Session Progress Proxy -> ISS SIP/2.0 183 Session Progress Via: SIP/2.0/SCTP iss.atlanta.com:5060;branch=z9hG4bKlueha2 ;received=192.168.255.101 Record-Route: <sip:proxy.atlanta.com;lr> From:<sip:[email protected];user=phone>;tag=7643kals To: <sip:[email protected];user=phone>;tag=314159 Call-ID: [email protected] CSeq: 1 INVITE Contact: <sip:[email protected]> Content-Type: application/sdp Content-Length: 149 v=0 o=GW 987654321 987654321 IN IP4 ess.atlanta.com s=- c=IN IP4 192.168.255.202

39


t=0 0 m=audio 14918 RTP/AVP 0 a=rtpmap:0 PCMU/8000

(8) ACM NGW 1 -> Switch A (9) ANM Switch -> ESS (10) 200 OK ESS -> Proxy SIP/2.0 200 OK Via: SIP/2.0/SCTP proxy.atlanta.com:5060;branch=z9hG4bK2d4790.1 ;received=192.168.255.111 Via: SIP/2.0/SCTP iss.atlanta.com:5060;branch=z9hG4bKlueha2 ;received=192.168.255.101 Record-Route: <sip:proxy.atlanta.com;lr> From:<sip:[email protected];user=phone>;tag=7643kals To: <sip:[email protected];user=phone>;tag=314159 Call-ID: [email protected] CSeq: 1 INVITE Contact: <sip:[email protected]> Content-Type: application/sdp Content-Length: 149 v=0 o=GW 987654321 987654321 IN IP4 ess.atlanta.com s=- c=IN IP4 192.168.255.202 t=0 0 m=audio 14918 RTP/AVP 0 a=rtpmap:0 PCMU/8000

(11) 200 OK Proxy -> ISS SIP/2.0 200 OK Via: SIP/2.0/SCTP iss.atlanta.com:5060;branch=z9hG4bKlueha2 ;received=192.168.255.101 Record-Route: <sip:proxy.atlanta.com;lr> From:<sip:[email protected];user=phone>;tag=7643kal To: <sip:[email protected];user=phone>;tag=314159 Call-ID: [email protected] CSeq: 1 INVITE Contact: <sip:[email protected]> Content-Type: application/sdp Content-Length: 149 v=0 o=GW 987654321 987654321 IN IP4 ess.atlanta.com s=- c=IN IP4 192.168.255.202 t=0 0 m=audio 14918 RTP/AVP 0

40


a=rtpmap:0 PCMU/8000 (12) ANM ISS -> Switch (13) ACK ISS -> Proxy ACK sip:[email protected] SIP/2.0 Via: SIP/2.0/SCTP iss.atlanta.com:5060;branch=z9hG4bKlueha2 Max-Forwards: 70 Route: <sip:proxy.atlanta.com;lr> From:<sip:[email protected];user=phone>;tag=7643kal To: <sip:[email protected];user=phone>;tag=314159 Call-ID: [email protected] CSeq: 1 ACK Content-Length: 0

(14) ACK Proxy 1 -> GW 2

ACK sip:[email protected] SIP/2.0 Via: SIP/2.0/SCTP proxy.atlanta.com:5060;branch=z9hG4bK2d4790.1 Via: SIP/2.0/SCTP iss.atlanta.com:5060;branch=z9hG4bKlueha2 ;received=192.168.255.101 Max-Forwards: 69 From:<sip:[email protected];user=phone>;tag=7643kals To: <sip:[email protected];user=phone>;tag=314159 Call-ID: [email protected] CSeq: 1 ACK Content-Length: 0

/* I flussi RTP sono stability in entrambe le direzioni tra I Media Gateway controllati dai due Softswitch */ /* Effettuata la chiamata comincia la procedura di rilascio*/ (15) REL Switch -> ESS REL CauseCode=16 Normal

(16) BYE ESS ->Proxy BYE sip:[email protected];user=phone SIP/2.0 Via: SIP/2.0/SCTP ess.atlanta.com:5060;branch=z9hG4bKtexx6 Max-Forwards: 70 Route: <sip:proxy.atlanta.com;lr> From: <sip:[email protected];user=phone>;tag=314159 To: <sip:[email protected];user=phone>;tag=7643kals Call-ID: [email protected] CSeq: 4 BYE Content-Length: 0

41


(17) RLC ESS -> Switch (18) BYE Proxy->ESS BYE sip:[email protected];user=phone SIP/2.0 Via: SIP/2.0/SCTP proxy.atlanta.com:5060;branch=z9hG4bK2d4790.1 Via: SIP/2.0/SCTP ess.atlanta.com:5060;branch=z9hG4bKtexx6 ;received=192.168.255.202 Max-Forwards: 69 From: <sip:[email protected];user=phone>;tag=314159 To: <sip:[email protected];user=phone>;tag=7643kals Call-ID: [email protected] CSeq: 4 BYE Content-Length: 0

(19) 200 OK ISS -> Proxy SIP/2.0 200 OK Via: SIP/2.0/SCTP proxy.atlanta.com:5060;branch=z9hG4bK2d4790.1 ;received=192.168.255.111 Via: SIP/2.0/SCTP ess.atlanta.com:5060;branch=z9hG4bKtexx6 ;received=192.168.255.202 From: <sip:[email protected];user=phone>;tag=314159 To: <sip:[email protected];user=phone>;tag=7643kals Call-ID: [email protected] CSeq: 4 BYE Content-Length: 0

(20) 200 OK Proxy ->ESS SIP/2.0 200 OK Via: SIP/2.0/SCTP ess.atlanta.com:5060;branch=z9hG4bKtexx6 ;received=192.168.255.202 From: <sip:[email protected];user=phone>;tag=314159 To: <sip:[email protected];user=phone>;tag=7643kals Call-ID: [email protected] CSeq: 4 BYE Content-Length: 0

(21) REL ISS ->Switch REL CauseCode=16 Normal

(22) RLC Switch ->ISS

42


Scenario 2: ISUP-SIP-Q.931

Figura 39 - Call flow ISUP-SIP-Q.931

(1) ISUP IAM Switch A -> Ingress Soft Switch IAM CgPN=314-555-1111,NPI=E.164,NOA=National CdPN=918-555-3333,NPI=E.164,NOA=National

(2) SIP INVITE Ingress Soft Switch -> Proxy INVITE sip:[email protected];user=phone SIP/2.0

43


Via: SIP/2.0/SCTP iss.atlanta.com:5060;branch=z9hG4bKlueha2 Max-Forwards: 70 From:<sip:[email protected];user=phone>;tag=7643kal To: <sip:[email protected];user=phone> Call-ID: [email protected] CSeq: 1 INVITE Contact: <sip:[email protected];user=phone> Content-Type: application/sdp Content-Length: 141 v=0 o=GW 2890844526 2890844526 IN IP4 gw1.atlanta.com s=- c=IN IP4 192.168.255.101 t=0 0 m=audio 49172 RTP/AVP 0 a=rtpmap:0 PCMU/8000

/* Proxy consulta un Location Service e traduce il numero digitato in un numero privato nel campo SIP Request-URI*/ (3) SIP INVITE Proxy -> Egress Soft Switch INVITE sip:[email protected] SIP/2.0 Via: SIP/2.0/SCTP proxy.atlanta.com:5060;branch=z9hG4bK2d4790.1 Via: SIP/2.0/SCTP iss.atlanta.com:5060;branch=z9hG4bKwqwee65 ;received=192.168.255.101 Max-Forwards: 69 Record-Route: <sip:proxy.atlanta.com;lr> From:<sip:[email protected];user=phone>;tag=7643kal To: <sip:[email protected];user=phone> Call-ID: [email protected] CSeq: 1 INVITE Contact: <sip:[email protected];user=phone> Content-Type: application/sdp Content-Length: 141 v=0 o=GW 2890844526 2890844526 IN IP4 iss.atlanta.com s=- c=IN IP4 192.168.255.101 t=0 0 m=audio 49172 RTP/AVP 0 a=rtpmap:0 PCMU/8000

(4) Q.931 SETUP ESS -> PBX Protocol discriminator=Q.931 Message type=SETUP Bearer capability: Information transfer capability=0 (Speech) or 16 (3.1 kHz audio) Channel identification=Preferred or exclusive B-channel Progress indicator=1 (Call is not end-to-end ISDN; further call progress information may be available inband)

44


Called party number: Type of number and numbering plan ID=33 (National number in ISDN numbering plan) Digits=918-555-3333

(5) ISUP CPG ISS ->Switch (6) SIP 100 Trying ESS -> Proxy SIP/2.0 100 Trying Via: SIP/2.0/SCTP proxy.atlanta.com:5060;branch=z9hG4bK2d4790.1 ;received=192.168.255.111 Via: SIP/2.0/SCTP iss.atlanta.com:5060;branch=z9hG4bKlueha2 ;received=192.168.255.101 Record-Route: <sip:proxy.atlanta.com;lr> From: <sip:[email protected];user=phone>;tag=7643kal To: <sip:[email protected];user=phone>;tag=314159 Call-ID: [email protected] CSeq: 1 INVITE Contact: <sip:[email protected]> Content-Type: application/sdp Content-Length: 149 v=0 o=GW 987654321 987654321 IN IP4 ess.atlanta.com s=- c=IN IP4 192.168.255.202 t=0 0 m=audio 14918 RTP/AVP 0 a=rtpmap:0 PCMU/8000

(7) SIP 100 Trying Proxy -> ISS SIP/2.0 100 Trying Via: SIP/2.0/SCTP iss.atlanta.com:5060;branch=z9hG4bKlueha2 ;received=192.168.255.101 Record-Route: <sip:proxy.atlanta.com;lr> From:<sip:[email protected];user=phone>;tag=7643kals To: <sip:[email protected];user=phone>;tag=314159 Call-ID: [email protected] CSeq: 1 INVITE Contact: <sip:[email protected]> Content-Type: application/sdp Content-Length: 149 v=0 o=GW 987654321 987654321 IN IP4 ess.atlanta.com s=- c=IN IP4 192.168.255.202 t=0 0 m=audio 14918 RTP/AVP 0 a=rtpmap:0 PCMU/8000

45


(8) Q.931 CALL PROC PBX ->ESS (9) Q.931 ALERT PBX ->ESS (10) SIP 180 Ringing ESS -> Proxy SIP/2.0 180 Ringing Via: SIP/2.0/SCTP proxy.atlanta.com:5060;branch=z9hG4bK2d4790.2 ;received=192.168.255.111 Via: SIP/2.0/SCTP gw1.atlanta.com:5060;branch=z9hG4bKwqwee65 ;received=192.168.255.201 Record-Route: <sip:proxy.atlanta.com;lr> From: <sip:[email protected]>;tag=63412s To: <sip:[email protected]>;tag=123456789 Call-ID: [email protected] CSeq: 1 INVITE Contact: <sip:[email protected];user=phone> Content-Length: 0

(11) SIP 180 Ringing Proxy ->ISS SIP/2.0 180 Ringing Via: SIP/2.0/SCTP gw1.atlanta.com:5060;branch=z9hG4bKwqwee65 ;received=192.168.255.201 Record-Route: <sip:proxy.atlanta.com;lr> From: <sip:[email protected]>;tag=63412s To: <sip:[email protected]>;tag=123456789 Call-ID: [email protected] CSeq: 1 INVITE Contact: <sip:[email protected];user=phone> Content-Length: 0

(12) ISUP ACM ISS-> Switch (13) Q.931 CONNect PBX->ESS

CONN Protocol discriminator=Q.931 Message type=CONN

(14) SIP 200 OK ESS -> Proxy SIP/2.0 200 OK Via: SIP/2.0/SCTP proxy.atlanta.com:5060;branch=z9hG4bK2d4790.1 ;received=192.168.255.111 Via: SIP/2.0/SCTP iss.atlanta.com:5060;branch=z9hG4bKlueha2 ;received=192.168.255.101 Record-Route: <sip:proxy.atlanta.com;lr> From: <sip:[email protected];user=phone>;tag=7643kals

46


To: <sip:[email protected];user=phone>;tag=314159 Call-ID: [email protected] CSeq: 1 INVITE Contact: <sip:[email protected]> Content-Type: application/sdp Content-Length: 149 v=0 o=GW 987654321 987654321 IN IP4 ess.atlanta.com s=- c=IN IP4 192.168.255.202 t=0 0 m=audio 14918 RTP/AVP 0 a=rtpmap:0 PCMU/8000

(15) SIP 200 OK Proxy 1 -> ISS SIP/2.0 200 OK Via: SIP/2.0/SCTP iss.atlanta.com:5060;branch=z9hG4bKlueha2 ;received=192.168.255.101 Record-Route: <sip:proxy.atlanta.com;lr> From: <sip:[email protected];user=phone>;tag=7643kals To: <sip:[email protected];user=phone>;tag=314159 Call-ID: [email protected] CSeq: 1 INVITE Contact: <sip:[email protected]> Content-Type: application/sdp Content-Length: 149 v=0 o=GW 987654321 987654321 IN IP4 ess.atlanta.com s=- c=IN IP4 192.168.255.202 t=0 0 m=audio 14918 RTP/AVP 0 a=rtpmap:0 PCMU/8000

(16) ISUP ANM ISS -> Switch (17) SIP ACK ISS -> Proxy ACK sip:[email protected] SIP/2.0 Via: SIP/2.0/SCTP iss.atlanta.com:5060;branch=z9hG4bKlueha2 Max-Forwards: 70 Route: <sip:proxy.atlanta.com;lr> From: <sip:[email protected];user=phone>;tag=7643kals To: <sip:[email protected];user=phone>;tag=314159 Call-ID: [email protected] CSeq: 1 ACK Content-Length: 0

47


(18) SIP ACK Proxy ->ESS ACK sip:[email protected] SIP/2.0 Via: SIP/2.0/SCTP proxy.atlanta.com:5060;branch=z9hG4bK2d4790.1 Via: SIP/2.0/SCTP iss.atlanta.com:5060;branch=z9hG4bKlueha2 ;received=192.168.255.101 Max-Forwards: 69 From: <sip:[email protected];user=phone>;tag=7643kals To: <sip:[email protected];user=phone>;tag=314159 Call-ID: [email protected] CSeq: 1 ACK Content-Length: 0

(19) Q.931 CONNect ACK ESS -> PBX Protocol discriminator=Q.931 Message type=CONN ACK

(20) Q.931 DISC PBX->ESS Protocol discriminator=Q.931 Message type=DISC

(21) SIP BYE ESS -> Proxy BYE sip:[email protected];user=phone SIP/2.0 Via: SIP/2.0/SCTP ess.atlanta.com:5060;branch=z9hG4bKtexx6 Max-Forwards: 70 Route: <sip:proxy.atlanta.com;lr> From: <sip:[email protected];user=phone>;tag=314159 To: <sip:[email protected];user=phone>;tag=7643kals Call-ID: [email protected] CSeq: 4 BYE Content-Length: 0

(22) SIP BYE Proxy ->ISS BYE sip:[email protected];user=phone SIP/2.0 Via: SIP/2.0/SCTP proxy.atlanta.com:5060;branch=z9hG4bK2d4790.1 Via: SIP/2.0/SCTP ess.atlanta.com:5060;branch=z9hG4bKtexx6 ;received=192.168.255.202 Max-Forwards: 69 From: <sip:[email protected];user=phone>;tag=314159 To: <sip:[email protected];user=phone>;tag=7643kals Call-ID: [email protected] CSeq: 4 BYE Content-Length: 0

(23) Q.931 REL ESS ->PBX

48


REL CauseCode=16 Normal

(24) ISUP REL ISS ->Switch (25) SIP 200 OK ISS-> Proxy SIP/2.0 200 OK Via: SIP/2.0/SCTP proxy.atlanta.com:5060;branch=z9hG4bK2d4790.1 ;received=192.168.255.111 Via: SIP/2.0/SCTP ess.atlanta.com:5060;branch=z9hG4bKtexx6 ;received=192.168.255.202 From: <sip:[email protected];user=phone>;tag=314159 To: <sip:[email protected];user=phone>;tag=7643kals Call-ID: [email protected] CSeq: 4 BYE Content-Length: 0

(26) SIP 200 OK Proxy ->ESS SIP/2.0 200 OK Via: SIP/2.0/SCTP ess.atlanta.com:5060;branch=z9hG4bKtexx6 ;received=192.168.255.202 From: <sip:[email protected];user=phone>;tag=314159 To: <sip:[email protected];user=phone>;tag=7643kals Call-ID: [email protected] CSeq: 4 BYE Content-Length: 0

(27) RLC Switch->ISS (28) Q.931 REL COM PBX ->ESS Protocol discriminator=Q.931 Message type=REL COM

49


Appendice A

Segnalazione nelle reti PSTN

SS7

Q.931

50


A.1 Il sistema di segnalazione SS7

Il sistema di segnalazione SS7 (Signalling System 7) è uno standard di segnalazione a canale

comune sviluppato alla fine degli anni ’70 dal settore standardizzazione della ITU-T, un tempo

chiamato CCITT (Consultative committee for International Telegraph and Telephone). SS7 deriva da SS6

che ha rappresentato la prima generazione di segnalazione a canale comune.

Originariamente, l’obbiettivo di SS7 fu quello di divenire l’unico standard mondiale per le

segnalazioni sulle reti telefoniche. Questo non è accaduto e sono state sviluppate molte varianti

fra le quali gli standard ANSI (American National Standards Imstitute) e Bellcore (Bell Communication

Research), utilizzati in Nord America, e lo standard ETSI (European Telecommunication Standards

Institute), adottato in Europa.

A.1.1 Architettura della rete SS7

La rete SS7 viene utilizzata per lo scambio di messaggi informativi di instaurazione,

gestione e rilascio delle chiamate e per gestire la rete di segnalazione. SS7 è una rete di

segnalazione a canale comune, quindi, tutte le informazioni di segnalazione viaggiano lungo un

piattaforma distinta, logicamente, da quella contenente i circuiti vocali.

Si possono individuare tre elementi fondamentali (nodi) che caratterizzano la rete SS7:

o SSP (Service Switching Point);

o STP (Service Transer Point);

o SCP (Service Control Point).

Service Switching Point Sono centrali telefoniche terminali o intermedie, dotate di funzionalità SS7, che

connettono i circuiti vocali e svolgono le funzioni di segnalazione necessarie per gestire le

chiamate. La centrale SSP terminale instaura e rilascia le chiamate e le centrali principali della rete

forniscono il transito per le chiamate. Si connettono direttamente agli utenti tramite la relativa

interfaccia dell’abbonato. I protocolli utilizzati possono essere analogici o digitali e possono

essere basati su un’interfaccia ISDN PRI o CAS.

Service Transfer Point I nodi STP sono parte fondamentale dell’architettura SS7 in quanto garantiscono l’accesso

alla rete. Essi indirizzano tutti i messaggi di segnalazione della rete sulla base delle informazioni di

instradamento e dell’indirizzo di destinazione contenuto nel messaggio.

51


STP fornisce la connettività logica tra nodi SSP senza richiederne una diretta. Sono

configurati a coppie per garantire la ridondanza necessaria ed aumentarne la disponibilità. Ogni

coppia di nodi STP è considerata come un’unica entità da tutti gli altri nodi direttamente

connessi.

I messaggi creati nei nodi STP, inizialmente basati su circuito, vengono trasformati in

pacchetti SS7 ed inviati dal nodo SSP per poi giungere al nodo SCP di destinazione.

I nodi STP svolgono pure funzioni di misura del livello di traffico e del livello di utilizzo

delle risorse.

È possibile impiegare ed installare le funzionalità STP su dispositivi dedicati distinti

oppure incorporarle con le altre funzioni SSP in un’unica centrale telefonica locale o intermedia.

Questa integrazione è molto comune in Europa ed in Australia. È questo il motivo per cui in tali

aree sono prevalenti le reti SS7, denominata anche CCS7 ( versione SS7 dell’ITU-T). Una

caratteristica di CCS7 è certamente il fatto di essere una rete ad associazione completa; nel senso che

lo stesso canale trasmissivo trasporta sia dati bearer che informazioni di segnalazione.

Figura 40 - Architettura di una rete SS7

Service Control Point Il nodo SCP rappresenta l’interfaccia con i database dove vengono memorizzate

informazioni di instradamento aggiuntive per i messaggi non basati su circuiti. È importante

sottolineare che i nodi SCP non ospitano alcuna informazione, ma forniscono l’interfaccia con il

database di sistema. L’interfaccia, generalmente, si basa su un protocollo standard, normalmente

X. 25. Quindi, SCP fornisce la conversione tra il protocollo SS7 e quello adottato per dialogare

con il database.

52


Il database memorizza le informazioni relative all’applicazione che è chiamato a svolgere,

ed è indirizzato in base al numero di sottosistema cui appartiene. Tale numero è denominato

livello SSP ; questo identificatore è presente nella richiesta che ha avuto origine dalla PSTN.

Nella rete SS7 sono disponibili diversi database, i più comuni dei quali sono:

Database 800

Fornisce le informazioni di instradamento per i numeri speciali.

Database LIDB (Line Information DataBase)

Fornisce agli abbonati o agli utenti varie informazioni nonché servizi a pagamento

tramite carta di credito e servizi di autenticazione.

Database LNPDB (Local Number Portability DataBase)

Fornisce il cosìdetto LRN (Location Routing Number), numero di 10 cifre della

centrale che serve il numero composto dall’utente.

Database HLR (Home Location Register)

Utilizzato nelle reti per telefonia cellulare, HLR memorizza diversi dati quali la

posizione corrente dell’utente e le informazioni necessarie ad effettuare fatturazioni o

per identificare gli abbonati.

Database VLR (Visitor Location Register)

Utilizzato nei sistemi di telefonia mobile per memorizzare la posizione corrente di un

abbonato quando questi vengano a trovarsi all’esterno della rete di appartenenza

(roaming).

A.1.2 Modalità di segnalazione

SS7 prevede tre possibili modalità di segnalazione.

o Segnalazione associata

È la forma di segnalazione più semplice in quanto i percorsi dei segnali e della voce

sono direttamente connessi tra i due punti terminali.

o Segnalazione non associata

In questa modalità voce e segnalazione seguono percorsi differenti. La segnalazione

non associata è la forma più comune di una rete SS7.

53


o Segnalazione quasi associata

Usa per i segnali un percorso logico distinto ottenuto, però, cercando di minimizzare

il numero di nodi STP attraversati. Uno dei vantaggi della segnalazione quasi associata

è legato al fatto che il ritardo della rete viene minimizzato grazie alla scelta del minor

numero di punti di trasferimento fra l’origine e la destinazione.

Figura 41 - Modalità di segnalazione in SS7

A.1.3 Collegamenti di segnalazione

Come mostrato in figura 40, i nodi della rete SS7 (detti anche punti di segnalazione) sono

connessi tramite collegamenti (link) di segnalazione. Questi collegamenti, full-duplex, ricevono e

trasmettono i messaggi SS7.

I collegamenti di segnalazione sono in genere a 56 Kbps o a 64 Kbps e possono trovarsi

su linee indipendenti o utilizzare i canali nei collegamenti strutturati E1.

La rete SS7 distingue i collegamenti in base alla tipologia di punti terminali che connette.

Di seguito se ne fornisce l’elenco accompagnato da una breve descrizione.

54


A-Link: connettono nodi terminali di segnalazione (SCP o SSP) e nodi STP.

B-Link (Bridge-Link): connettono coppie di nodi STP.

C-Link (Cross-Link): connettono un nodo STP con l’altro nodo STP cui è accoppiato.

I C-Link vengono utilizzati solo in caso di errore o in presenza di congestione; in

condizioni normali trasportano messaggi di gestione interna della rete.

D-Link (Diagonal-Link): utilizzati per interconnettere coppie di nodi STP di un livello

gerarchico a coppie analoghe poste ad un livello gerarchico superiore.

E-Link (Extented Link): connettono nodi SSP ad un nodo STP alternativo;

consentono, di fatto, al nodo SSP di avere a disposizione una connessione di riserva

rispetto al collegamento A-Link, aumentando l’affidabilità della rete. Si evince come

l’utilizzo di tale collegamento, se presente, sia utilizzato solo in caso di errori o

congestione nei nodi STP principali.

F-LInk: utilizzati per connettere direttamente nodi terminali di segnalazione. Gli F-

Link consentono la modalità di segnalazione associata.

A.1.4 La stack SS7

Il sistema SS7 è strutturato in strati, in maniera analoga al modello di riferimento OSI

(Open System Interconnection), ma, a differenza di questo, presenta solo quattro livelli; ciascun livello

offre un set di servizi ai livelli superiori. In figura 42 si mostra l’architettura del sistema SS7.

I primi tre livelli compongono la parte MTP (Message Transfer Part) e rappresentano i

protocolli di trasporto per tutti gli altri protocolli SS7. La funzionalità MTP include le

specifiche dell’interfaccia di rete, di trasferimento affidabile delle informazioni e di

gestione e indirizzamento dei messaggi.

SCCP (Signal Connection Part) fornisce l’indirizzamento punto-punto e l’instradamento

per i protocolli L4 ( ad esempio per la parte TCAP).

TUP (Telephone User Part) è, fondamentalmente, un sistema di segnalazione utilizzato

per connettere gli apparecchi telefonici o le chiamate vocali come ad esempio le

trasmissioni di fax.

ISUP (ISDN User Part) è un protocollo basato su circuiti impiegato per instaurare e

gestire le connessioni per le chiamate vocali e dati.

55


TCAP (Transaction Capabilities Application Part ) fornisce l’accesso ai database remoti

per le informazioni di indirizzamento e attiva le funzionalità delle entità remote della

rete.

Figura 42 - Architettura SS7

A.1.4.1 La parte MTP

MTP fornisce l’infrastruttura comune ai protolli di livello più elevato. È costituito da tre

livelli (1, 2 e 3 dello stack SS7):

Livello 1: Signalling Data Link;

Livello 2: Signalling Link Functions;

Livello 3: Signalling Network Functions

Il livello fisico: Signalling Data Link È il livello più basso dello stack ; definisce le caratteristiche fisiche ed elettriche del

collegamento di segnalazione tra due elementi di rete. Coincide col livello fisico (physical layer) del

modello OSI e, come questo, non specifica alcuna particolare interfaccia. SS7 ammette

collegamenti digitali e/o analogici.

Tra le interfaccie di rete più comuni vi sono:

T1: standard per la trasmissione digitale della voce, dei dati e delle immagini. I segnali

T1, detti anche DS1) vengono trasmessi lungo due coppie di fili con una capacità di

1.544 Mbps. T1 offre 24 canali full-duplex o canali DS-0 (Digital Signal Livel 0)

ognuno dei quali occupa 64 Kbps.

56


DS-0: è la velocità standard per la digitalizzazione di una conversazione vocale in

modulazione PCM (Pulse Code Modulation), notoriamente pari a 64 Kbps.

E1: è lo standard per la trasmissione digitale, alternativo a T1. I segnali E1 vengono

trasmessi su due coppie di fili con la capacità di 2.048 Mbps. Il collegamento E1

contiene 30 canali (più 2 di servizio) full-duplex, ognuno dei quali occupa 64 Kbps

(DS-0).

56/64 Kbps: sono canali di tipo DS-0; questi livelli sono i più utilizzati nelle

interfacce fisiche della rete SS7.

V.35: è lo standard ITU per l’interfaccia fisica tra un’unità DSU (Digital Service Unit)

e un dispositivo a pacchetti/dati.

Il livello di collegamento dati: Signalling Link Le funzionalità presenti nel livello 2 della rete SS7 consentono di creare collegamenti

affidabili e sicuri tra due punti terminali della rete, assicurandone il controllo durante l’invio o la

ricezione dei messaggi. MTP 2 utilizza diversi meccanismi di seguito elencati.

Rilevamento e correzioni degli errori, ottenuto tramite il sistema CRC-16 (Ciclic

Redundancy Check-16).

Sequenze dei pacchetti, grazie alle quali ci si può rendere conto di eventuali perdite

e/o errori richiedendone la ritrasmissione.

Indicatori dello stato dei collegamenti, utilizzati per gestire e monitorare lo stato delle

connessioni.

MTP2 trasmette i messaggi SS7 utilizzando pacchetti chiamati SU (Signal Unit), in

particolare, tre sono i tipi di unità di segnalazione:

MSU (Message Signal Unit): trasportano informazioni relative alla segnalazione;

LSSU Link (Status Signal Unit): utilizzati per effettuare inizializzazioni e allineamenti

all’interno della rete;

FISU (Fill In band Signal Unit): utilizzati per monitorare i collegamenti.

57


Figura 43 - Formato delle unità di segnalazione (SU)

I tipi di pacchetto si possono distinguere grazie all’indicatore di lunghezza presente

nell’intestazione (header), come mostrato in figura 44.

Il livello di rete: Signalling Network Functions Il protocollo MTP3 in SS7 è del tutto analogo al livello 3 del modello di riferimento OSI

(Network layer). MTP3 indirizza i messaggi SS7 e si affida a MTP2 per l’invio degli stessi. Le

funzioni principali si dividono in due categorie:

• SMH (Signal Message Handling): indirizza I messaggi SS7 durante le normali condizioni;

• SNM (Signal Network Message): indirizza il traffico di collegamento durante le

condizioni di errore, se presenti in rete.

I messaggi MTP3 sono costituiti da due campi: SIO (Signalling Information Octet) e

SIF(Signalling Information Field). Il primo identifica l’utilizzatore o il tipo di protocollo (SCCP,

58


TUP, ISUP o TCAP) e la versione del protocollo SS7 (nazionale o internazionale). Il campo SIF

è suddiviso, a sua volta, in due parti: l’etichetta di instradamento ed il messaggio dell’utilizzatore o

del protocollo del livello L4. In figura 40 si riporta la struttura del messaggio.

Figura 44 - Formato del messaggio SS7

A.1.4.2 Signalling Connection Control Part (SCCP)

MTP fu originariamente disegnato per effettuare il controllo delle chiamate, fornendo la

segnalazione per la gestione delle connessioni. Talvolta però, è necessario inviare segnali che non

sono necessariamente collegati a connessioni da controllare; si pensi, per esempio,

all’interrogazione dei database presenti nella rete SS7: è proprio SCCP che rende disponibile,

collaborando con MTP, tali funzionalità ai protocolli che risiedono nella parte alta del livello 4

(L4) di SS7, TUP e ISUP. La combinazione dei due livelli, MTP3 e SCCP, è chiamata NSP

(Network Service Part).

SCCP fornisce due modalità di servizio: orientata alla connessione e non orientata alla

connessione. È opportuno sottolineare che, ad oggi, SCCP è utilizzato solamente per usufruire

dei servizi non orientati alla connessione (interrogazione di database, transazioni telematiche,

servizi prepagati, autenticazioni).

A.1.4.3 Telephone User Part (TUP)

TUP, protocollo di livello 4 della rete SS7, rende disponibile le funzionalità di

59


segnalazione per le chiamate vocali. Esiste una versione internazionale del protocollo, ma diversi

paesi hanno sviluppato varianti con caratteristiche specifiche.

TUP supporta le connessioni su circuito fisico ma non è in grado di gestire i circuiti bearer,

attualmente utilizzati nelle reti digitali.

A.1.4.4 Transaction Capabilities Application Part (TCAP)

TCAP fornisce le funzionalità di transazione svolte dai messaggi utilizzati per accedere ai

database remoti e per richiamare funzionalità remote degli elementi di rete. Originariamente fu

pensato per gestire le chiamate ai numeri verdi, oggi è indispensabile per usufruire dei servizi

avanzati se la rete presenta funzionalità di Intelligent Network (IN)1.

TCAP fornisce un servizio end-to-end di tipo connectionless e può utilizzare sia MTP che

SCCP.

A.1.4.5 ISDN User Part (ISUP)

La parte ISUP connette, gestisce e rilascia tutte le chiamate voce e dati presenti nella rete

PSTN. ISUP apre e chiude i circuiti utilizzati per connettere gli utenti PSTN, fra i quali vi sono

gli abbonati ISDN e non ISDN. ISUP è utilizzato anche per la gestione dei circuiti di

collegamento di reti mobili.

Le informazioni ISUP vengono trasferite medianti messaggi MTP3, simili a quelli degli

altri protocolli residenti nel livello L4 di SS7.

Due sono le tipologie di servizio offerte da ISUP:

Sevizio base: per la gestione della chiamata semplice;

Servizio supplementare: per la gestione di servizi aggiuntivi, se disponibili.

Le primitive utilizzate da ISUP per usufruire dei servizi MTP3 sono quattro:

MTP-Tranfer;

MTP-Pause;

MTP-Resume;

MTP-Status.

Un messaggio ISUP consiste di un set di parametri. Ciascun parametro contiene degli

1 IN: Insieme di servizi aggiuntivi (chiamata a tre, identificatore del chiamante, etc.) disponibili in una rete di segnalazione.

60


indicatori, e questi indicatori contengono le informazioni del messaggio. I parametri contenuti nel

messaggio sono raggruppati in tre parti:

o Mandatory fixed part;

o Mandatory variable part;

o Optional part.

Ciascun messaggio contiene, inoltre, un Message Type Code (MTC) che identifica, in maniera

univoca, il tipo di messaggio. In figura 45 è descritta la struttura generale del messaggio ISUP,

mentre la tabella 2 fornisce un elenco dei principali messaggi ISUP e dei parametri più

significativi.

Figura 45 - Struttura del messaggio ISUP

A.1.5 Esempi di operazioni di segnalazione

Vi sono due tipologie di sequenze di segnalazione denominate, rispettivamente: en bloc ed

overlap. Nella segnalazione en bloc il numero di destinazione è contenuto nel messaggio IAM in

quella overlap sono inviati diversi messaggi SAM contenenti il citato numero.

Quando la centrale locale riceve il messaggio IAM con il numero di destinazione invia

indietro un messaggio ACM. Quando l’utente chiamato solleva la cornetta la stessa centrale invia

un messaggio ANM e la connessione è così stabilita. Per rilasciare la connessione viene inviato un

messaggio REL cui la centrale remota risponde con un messaggio RLC. La figura 46 descrive il

flusso di chiamata corrispondente.

61


Nella modalità overlap il messaggio ACM non è inviato se prima non sono stati ricevuti

tutti i messaggi SAM contenenti il numero di destinazione, come mostrato in figura 47.

Figura 46 - Sequenza di segnalazione en bloc

Figura 47 - Sequenza di segnalazione boverlap

62


Tabella 5 - I protocolli SS7

NOME CODICE NOME CODICE

Introduction to CCITT SSN.7 Q.700 Data Yser Oart (DUP) Q.740-Q.749

Message Transfer Part (MTO) Q701-Q.709 SS7 Management Q.750-Q.759

Simplified Message

Trasfer Part Q.710 ISDN User Part (ISUP) Q.760-Q.769

Signalling Connection

Control Part

Q.711-Q.719 Transaction Capabilities

Application Part (TCAP) Q.770-Q.779

Telephone User Part (TUP) Q.720-Q.729 Intelligent Network Q.1100-Q.1999

Tabella 6 - Messaggi ISUP

Messaggio Code Dir Funzione

Address Complete

Message ACM d->o

Indica il ricevimento di tutte le indicazioni per

l’instaurazione della chiamata

Answer Message ANM d->o Indica che la chiamata ha ricevuto risposta

Blocking Message BLO d->o

o->d

Provoca una condizione di blocco nel circuito per

eseguire operazioni di manutenzione

Blocking ACK Message BLA d->o

o->dRisposta al messaggio BLO

Call Progress

Message CPG

d->o

Indica il verificarsi di un evento da comunicare al

chiamante durante la fase di instaurazione della

chiamata

Circuit Group

Blocking Message CGB

d->o

o->dProvoca il blocco di un insieme di circuiti

Circuit Group

Blocking ACK Message CGBA

d->o

o->dRisposta positive al messaggio CBG

63


Circuit Group Reset

Message GRS

d->o

o->d

Libera un insieme di circuiti quando, causa errori,

non se ne conosce lo stato

Circuit Group Reset

ACK Message GRA

d->o

o->dRisposta positive al messaggio GRS

Connect Message CON d->o Indica che la chiamata ha avuto risposta

Continuity Message COT o->d Indica la presenza di continuità sul/sui circuito/i

Forward Transfer

Message FOT o->d

Utilizzato tra centrali internazionali per richiedere

l’intervento di un operatore

Initial Address

Message IAM o->d

Prenota il circuito per una chiamata in partenza.

IAM contiene l’indirizzo ed altre informazioni

utili per l’instradamento

Circuit Group

Unblocking Message CGU

d->o

o->d

Elimina la condizione di blocco su circuiti

determinate da messaggi BLO o CGB

Circuit Group

Unblocking ACK

Message

CGUA d->o

o->dRisposta positive ad un messaggio CGU

Continuity Check

Request Message CCR

d->o

o->dUsato tra centrali per richiedere test di continuità

Releise Message REL d->o

o->dIndica che un circuito è stato rilasciato

Releise Complete

Message RLC

d->o

o->d

Risposta ad un messaggio REL RSC ad indicare

che un circuito è libero

Reset Circuit

Message RSC

d->o

o->d

Libera un circuito quando, causa errori, non se

conosce lo stato

Resume Message RES d->o

o->dIndica che l’utente posto in attesa è stato collegato

Subsequent Address

Message SAM o->d

Raccoglie le informazioni aggiuntive ad un

indirizzo dopo il messaggio IAM

Suspend Message SUS d->o

o->d

Indica che un utente è stato momentaneamente

posto in stato di attesa

Unblocking Message UBL d->o

o->d

Elimina la condizione di blocco di un circuito

originate da un messaggio BLO o CGB

Unblocking ACK

Message UBA

d->o

o->dRisposta positive al messaggio UBL

64


A.2 Il protocollo di segnalazione Q.931

Le specifiche di interfacciamento ISDN L2 e L3 sono denominate DSS1 (Digital Subscriver

Signalling System 1). L’interfaccia L2 fornisce connessioni sicure ed esenti da errori fra due punti

terminali in una configurazione di riferimento ISDN. L3 fornisce il meccanismo per

l’instaurazione delle chiamate, il controllo e l’accesso ai servizi. Il protocollo L2 per ISDN è

Q.920/921 ed il protocollo L3 è Q.930/931. Il protocollo Q.932 attiva le procedure generali per

l’accesso ed il controllo dei sevizi supplementari.

1 2 3

4 5 67 8 9

* 8 #

1 2 3

4 5 67 8 9

* 8 #

Figura 48 - Protocolli di segnalazione ISDN

Le specifiche per L3 definiscono i messaggi che si scambiano la centrale locale ed il

dispositivo TE. Questi messaggi vengono utilizzati per l’instaurazione, supervisione e rilascio

della chiamata e per i vari servizi supplementari. In tabella 3 vengono elencati i messaggi con i

rispettivi codici, inseriti nel campo Message Type Value, all’ interno del formato generale del

messaggio Q.931.

Figura 49 - Formato dei messaggi Q.931

65


Tra le centrali ISDN, la segnalazione viene effettuata utilizzando il servizio SS7, che

stabilisce ogni connessione in base alle caratteristiche richieste. Quindi, PSTN ed ISDN

utilizzano, generalmente, un identico sistema per il trasferimento dei messaggi di gestione

all’interno delle rispettive reti. Quello che cambia è il protocollo di livello 4 dello stack SS7

utilizzato: TUP (Telephone Users Part) per PSTN, ISUP (ISDN User Part) per ISDN. ISUP e TUP

non possono essere direttamente collegati. Per interconnettere le due reti è necessaria la presenza

di elementi in grado di supportare la conversione dei due protocolli.

1 2 3

4 5 67 8 9

* 8 #

1 2 3

4 5 67 8 9

* 8 #

Figura 50 - Lo svolgimento di una chiamata ISDN

66


Tabella 7 .- Messaggi e codici Q.931 ( fonte: ITU-T Q.931 3/93)

Tipo di messaggio Q.931 MESSAGE TYPE VALUE

Setup message (SETUP) 00000101

Setup acknowledgement

message (SETACK) 00001101

Call proceeding message (CALPRC) 00000010

Progress message (PROG) 00001111

Alerting Message (ALERT) 00000011

Connect Message (CONN) 00000101

Connect acknowledgement

message (CONACK) 00000111

Disconnect message (DISC) 01000101

Releise message (RLSE) 01001101

Releise complete message (RLCOM) 01011010

Information message (INFO) 01111011

67


Appendice B

Le reti IP

&

Voice over IP

68


B.1 Le reti IP

Verso la fine degli anni ’60, la Defence Advanced Research Project Agency (DARPA) si

rivolse all'Università di Stanford ed alla BBN (Bolt, Beranek and Newman) affinché sviluppassero

un insieme di protocolli in grado di garantire la comunicazione tra calcolatori eterogenei. Dopo

qualche anno si giunse al completamento dell'Internet Protocol Suite, di cui i due protocolli più noti

sono Transmission Control Protocol (TCP) ed Internet Protocol (IP), e nacque la rete militare ARPAnet.

Proprio per le origini militari il sistema presentava due caratteristiche principali: robustezza ed

adattabilità. La robustezza consente alla rete di continuare a funzionare correttamente anche in

presenza di interruzioni o guasti nei nodi interni; l’adattabilità permette il collegamento tra coppie

di sistemi del tutto incompatibili ( per esempio, connessione tra apparecchiature via cavo da un

lato e satellitari dall’altro).

Successivamente i militari consentirono l’utilizzo della rete anche in ambito civile per

scopi di ricerca scientifica, in maniera totalmente gratuita: ARPAnet divenne Internet, la rete

telematica a commutazione di pacchetto più famosa ed utilizzata al mondo. Il nome più accurato

per l'architettura di rete rimane quello di Internet Protocol Suite, anche se comunemente si fa

riferimento ad essa con la sigla TCP/IP o IP/TCP. I protocolli appartenenti a questa architettura

sono specificati tramite standard che si chiamano RFC (Request For Comments) facilmente reperibili

sulla rete Internet. Famoso è lo RFC 791 Internet Protocol, datato 1981, che specifica appunto il

protocollo IP.

Negli anni 1990, gli anni della maturità dell'ISO/OSI, l'unica architettura di rete che

sembra interessare il mercato è quasi paradossalmente TCP/IP. Anche gli enti di

standardizzazione nazionali e internazionali hanno dovuto arrendersi davanti alla massiccia

diffusione di TCP/IP e dargli la stessa dignità di ISO/OSI.

È interessante sottolineare le profonde differenze tra i due modelli, OSI e TCP/IP. OSI è

un modello di riferimento stratificato del tutto generale che si occupa di descrivere

dettagliatamente le proprietà e funzionalità che devono risiedere nei vari livelli, senza specificare

particolari protocolli. Per contro, il modello TCP/IP può applicarsi esclusivamente alle reti che

scelgono di adottare specifici protocolli, quelli progettati per soddisfare i requisiti del Department of

Defence (DOD), ammettendo eventuali violazioni all’architettura, anch’essa stratificata.

Nei prossimi paragrafi si presentano i due modelli e si descrivono le caratteristiche

principali dei protocolli utilizzati nelle reti strutturate secondo l’architettura TCP/IP.

69


B.2 Generalità sulIe architetture di rete: il modello OSI2

Nella comunicazione tra computer i protocolli giocano un ruolo fondamentale. In

sostanza, un protocollo (di comunicazione) è l’insieme di convenzioni che regola il dialogo tra gli

elementi di rete coinvolti in una comunicazione descrivendo, ad esempio, il formato dei messaggi

scambiati, le azioni da intraprendere in seguito ad una loro ricezione e le modalità per evitare e/o

correggere eventuali errori.

Strettamente legato al concetto di protocollo è quello di architettura stratificata delle reti di

telecomunicazione. Il modello stratificato organizza il problema della comunicazione tra

macchine suddividendolo in livelli: ciascun livello, o strato, offre specifiche funzionalità che

possono essere utilizzate dal livello posizionato immediatamente sopra.

Figura 51 - Esempio di architettura stratificata

Per rendere possibile la comunicazione tra due host, questi devono essere connessi

attraverso un qualche mezzo fisico. Tutti i dati saranno inviati attraverso questo mezzo, ma solo il

livello più basso potrà accedervi direttamente. Livelli analoghi residenti in macchine differenti

possono dialogare direttamente utilizzando proprio i protocolli. Quando un livello vuole

trasmettere un qualche dato al corrispondente livello posizionato nella macchina remota utilizza

le funzionalità offerte dal livello sottostante. Questo aggiunge alcune informazioni di controllo ai

dati, usualmente sotto forma di intestazione, e richiede in modo analogo i servizi del livello

sottostante. Il processo si ripete finché non si raggiunge il mezzo fisico attraverso cui i dati sono

effettivamente trasmessi. Una volta raggiunta la destinazione il livello più basso processa le

2 OSI: Open System Interconnection.

70


informazioni di controllo e passa il carico al livello superiore effettuando, all’inverso, la procedura

descritta. È opportuno osservare come un qualunque livello possa subire miglioramenti e

modiche, più o meno sostanziali, senza necessariamente coinvolgere gli altri livelli.

Il comitato di standardizzazione ISO (International Organization Standardization) ha

sviluppato il modello di riferimento OSI (Open Systems Interconnection) all’inizio degli anni ’80;

questo è, ad oggi, lo standard per lo sviluppo di protocolli di comunicazione tra computer. Anche

se non tutti i protocolli seguono il modello, molto spesso viene impiegato con finalità didattiche

o come termine di paragone tra differenti architetture di rete esistenti o in fase di progettazione.

OSI suddivide il problema delle comunicazioni tra macchine in sette livelli. Ogni livello

comunica con il livello corrispondente della macchina remota e solo con questo, senza

preoccuparsi del mezzo fisico impiegato.

Ogni livello OSI fornisce dei servizi al livello sovrastante (il livello 5 al livello 6, il livello 6

al livello 7 e così via) e richiede determinati servizi al livello sottostante (il livello 5 al livello 4, il

livello 4 al livello 3 etc.)

L’approccio ora descritto consente di gestire con un determinato livello un insieme

ridotto di informazioni, di apportare ai dati le modifiche necessarie e di aggiungere le funzioni

necessarie per tale livello prima di passare i dati al livello sottostante.

I dati, man mano che scendono verso i livelli più bassi, divengono sempre meno

comprensibili all’uomo e più orientati alla macchina fino a raggiungere i valori 1 e 0 (impulsi

elettrici) del livello fisico. Di seguito si riporta una breve descrizione dei singoli livelli.

Figura 52 - Modello di riferimento OSI

71


Livello Fisico Il livello fisico si occupa di ricreare le sequenze di cifre 1 e 0 sul mezzo fisico tramite

impulsi elettrici costituiti da variazioni di tensione. È l’unico ad avere accesso direttamente al

mezzo fisico condiviso con l’analogo livello del sistema cui è destinata l’informazione trasmessa.

Livello di collegamento dati Il livello offre un meccanismo di trasporto affidabile su un collegamento fisico; rende

possibili l’invio di blocchi di dati, denominati trame, e presenta un proprio schema di

indirizzamento basato sulla connettività fisica dei sistemi.

Livello di rete Il livello fornisce diversi, importanti, servizi.

o Indirizzamento: consente a due sistemi in reti logiche distinte di poter creare un percorso

di comunicazione.

o Instradamento: il servizio consente di scegliere un percorso tra i tanti possibili tra due

sistemi comunque connessi (tramite la creazione e gestione delle tabelle di

instradamento).

o Controllo del traffico: fornisce meccanismi per evitare il fenomeno della congestione.

Livello di trasporto È il primo dei livelli end-to-end; è responsabile dell’affidabilità del trasporto

dell’informazione sulla rete. L’affidabilità è ottenuta grazie al controllo di flusso, al controllo degli

errori (tramite checksum), ai messaggi di acknowledgement, alla gestione ed eventuale

ritrasmissione di sequenze dati.

Livello di sessione Il livello consente di instaurare, mantenere ed abbattere sessioni tra due host. Le sessioni

sono dialoghi tra due o più entità di presentazione (che usufruiscono dei servizi offerti dalle entità

residenti nel livello di sessione). Il livello di sessione sincronizza il dialogo, gestisce lo scambio dei

dati, la classe di servizio e si occupa di rilevare eventuali situazioni d’errore.

72


Livello di presentazione Il livello garantisce che l’informazione, inviata dal sovrastante livello delle applicazioni del

sistema sorgente, risulti leggibile all’analogo livello residente nel sistema remoto. Se necessario, le

entità di presentazione possono contrattare la scelta di un formato comune per l’informazione da

inviare e/o ricevere.

Livello delle applicazioni È il più alto livello nel modello di riferimento OSI. In esso risiede la maggior parte delle

applicazioni d’utente. Tra le applicazioni più note si ricordano: la posta elettronica, la navigazione

web, l’elaborazione dei testi.

B.3 Il modello di riferimento TCP/IP

La figura mostra la struttura del modello paragonandola al corrispondente modello di

riferimento OSI. Come può facilmente osservarsi i due modelli presentano grosse differenze nella

struttura, che, per entrambi, è, comunque, stratificata.

TCP/IP si struttura su quattro livelli:

o Host-to-Network layer

o Internet layer

o Transport layer

o Application layer

Figura 53 - Confronto tra i modelli OSI e TCP/IP

73


Host-to-Network layer È il livello più basso del modello TCP/IP. Talvolta è denominato livello di collegamento

(link layer) o livello di interfaccia di rete (network interface layer). Non sono specificati particolari

protocolli per questo livello; ai protocolli si richiede solo di essere abili a trasmettere e/o ricevere

datagram IP dai livelli superiori.

Per le funzionalità che presenta il livello host-to network è assimilabile all’unione del

livello fisico e data link del modello OSI.

Internet layer Il livello corrisponde al livello di rete nel modello di riferimento OSI. Il suo compito è

quello di trasferire i pacchetti dalla sorgente al destinatario, attraverso differenti tipi di rete, se

necessario. Il servizio offerto rientra nella classe Best Effort: non è previsto alcun meccanismo che

rilevi la eventuale perdita di pacchetti, non viene fornita alcuna garanzia sulla consegna ordinata

degli stessi ed il trasferimento avviene senza che venga instaurata alcuna connessione.

L’unità informativa è il datagramm IP o pacchetto IP, il protocollo utilizzato prende il

nome di Internet Protocol (IP) e verrà descritto nei prossimi paragrafi. Il pacchetto IP consiste di

un’intestazione (header) e dei dati d’utente (payload).

Transport layer Il livello di trasporto fornisce funzionalità aggiuntive al livello di rete. In particolare,

consente di differenziare trasmissioni multiple riconducibili allo stesso host, in base al tipo di

applicazione coinvolta, utilizzando il numero di porta (port number). Questo livello ha molto in

comune con l’analogo del modello OSI. Transport layer è il primo livello end-to-end.

Il modello TCP/IP prevede la possibilità di utilizzare due differenti protocolli. Uno di

questi è il Transport Control Protocol (TCP), protocollo orientato alla connessione che ha dato il

nome, insieme ad IP, al modello in esame. L’altro protocollo è User Datagram Protocol (UDP),

utilizzabile da tutte quelle applicazioni che non necessitano del servizio offerto da TCP ma

preferiscono utilizzare un protocollo più snello che renda più veloce la trasmissione, anche a

costo di dover sopportare eventuali perdite ed errori nei pacchetti. Anche UDP prevede l’utilizzo

di numeri di porta.

74


Application layer Come nel modello OSI il livello contiene i protocolli delle applicazioni di rete. Tra questi

rientrano TELNET, File Transfer Protocol (FTP), Simple Mail Transfer Protocol (SMTP).

B.3.1 Internet Protocol (IP)

IP è un protocollo di livello 3 (livello di rete) senza connessione, quindi non prevede

alcun meccanismo di garanzia sull’affidabilità, controllo di flusso, controllo delle sequenze o

acknowledgement. Queste funzionalità, se necessarie, possono essere aggiunte da altri protocolli

residenti nei livelli superiori (come TCP). Una peculiarità del protocollo è quella di consentire la

frammentazione dei datagram quando necessario.

Il protocollo Internet, essendo un protocollo di rete, non deve preoccuparsi degli

elementi di collegamento quali ATM, Frame Relay, Ethernet o degli elementi fisici (SONET su

fibra o rame).

Per l’importanza assunta nell’ambito dei sistemi VoIP, parte fondamentale del presente

lavoro, si offre, di seguito, una dettagliata descrizione delle principali caratteristiche del

protocollo.

B.3.1.1 Formato dei pacchetti IP

Come accennato in precedenza, il pacchetto IP consta di un intestazione (IP-header) cui

seguono i dati d’utente (payload). Il formato dell’intestazione è mostrato in figura.

Di seguito si fornisce una breve descrizione dei diversi campi.

Version: il campo contiene un numero pari alla versione del protocollo IP che si sta

utilizzando; attualmente dovrebbe essere pari a 4 (da cui il nome IPv4).

IHL (Internet Header Lenght): il campo specifica la lunghezza dell’intestazione in parole

da 32-bit.

Type of Service (ToS): il campo fu inserito per fornire un minimo meccanismo di qualità

del servizio secondo le modalità mostrate in figura 55.

Total lenght: specifica la lunghezza dell’intero pacchetto che può raggiungere il valore

massimo di 65.535 byte.

Identification: identifica tutti i pacchetti riconducibili allo stesso datagram, se questo è

stato frammentato.

Flag: campo di tre bit utilizzato per richiedere ai router di non frammentare

75


ulteriormente il pacchetto.

Fragment offset: il campo è utilizzato se il pacchetto contiene frammenti di datagram.

Time to live (TTL): il campo è utilizzato per limitare il tempo di permanenza dei

pacchetti nella rete; il funzionamento del meccanismo è abbastanza semplice: il

valore, che rappresenta il tempo (in secondi) di esistenza del pacchetto, viene

decrementato da ogni router attraversato in base al tempo di permanenza in coda

(maggiore è l’attesa in coda, maggiore è il decremento); se il campo segna zero il

router è autorizzato a scartare il pacchetto in questione.

Protocol: il campo specifica il tipo di protocollo di trasporto cui è indirizzato il

pacchetto.

Source IP address e destination IP address: i due campi contengono gli indirizzi della

sorgente e quello di destinazione il cui formato è descritto nel prossimo paragrafo. I

due valori devono essere presenti in ogni pacchetto: è questa una delle conseguenze

del servizio senza connessione offerto da IP.

Option: il campo, se presente, può essere utilizzato come record del percorso seguito

dal pacchetto per giungere a destinazione.

Figura 54 - Intestazione IP

76


Figura 55 - Il campo ToS

B.3.1.2 Indirizzamento IP

Ogni host che intende utilizzare il protocollo IP dovrebbe essere dotato di un indirizzo (a

livello di rete) unico. I router inoltrano il traffico in base a questo indirizzo.

Nel formato IPv4 al campo indirizzo sono riservati 32 bit: una parte del campo identifica

la rete, la rimanente parte identifica il sistema host, sorgente o destinatario del pacchetto. Lo

spazio degli indirizzi IP (totalità dei valori ammissibili per il campo) è diviso in cinque classi,

secondo la modalità descritta in figura 56.

Figura 56 - Classi degli indirizzi IP

In particolare:

• gli indirizzi di classe A dedicano 7 bit per identificare la rete e 24 bit per il sistema;

77


• gli indirizzi di classe B allocano 14 bit per l’indirizzo della rete e 16 per l’indirizzo del

sistema;

• gli indirizzi di classe C allocano 21 bit per la rete e solo 8 bit per il sistema;

• gli indirizzi di classe D sono riservati per i gruppi multicast ,come formalmente

descritto nel documento RFC 1112;

• gli indirizzi di classe E sono riservati per usi futuri.

Gli indirizzi IP vengono trascritti nel formato decimale a punti. Ad esempio 121.12.3.116

B.3.1.3 Il formato IPv6

L’enorme sviluppo della rete Internet, ha messo in evidenza i limiti del protocollo IP. I

problemi principali riscontrati sono:

la limitata capacità di indirizzamento, dovuta ai pochi bit dedicati allo scopo;

la scarsa propensione a supportare meccanismi di qualità del servizio o di sicurezza.

Per queste ragioni è stato messo a punto un nuovo formato per l’intestazione IP,

denominato IPv6. Il formato, costituito da 40 byte, è descritto in figura.

Figura 57 - Intestazione IPv6

Molte sono le modifiche apportate, in particolare:

o 128 bit sono dedicati all’indirizzamento;

o il campo ToS è stato sostituito con Traffic Class;

78


o il formato è più semplice (8 campi contro i 12 del formato precedente);

o è stato introdotto il campo flow label che consente di utilizzare meccanismi di

differenziazione del traffico tali da garantire trattamenti particolari ad interi flussi di

dati.

B.3.1.4 Instradamento

Come più volte affermato, il protocollo IP si occupa di organizzare il trasferimento dei

pacchetti attraverso reti interconnesse ma non si occupa dell’instradamento che è invece

demandato ad altri protocolli. Praticamente IP consulta ma non aggiorna le tabelle di

instradamento all’interno dei router.

Attualmente le reti IP usano due tipi di protocolli di instradamento:

a vettore di distanza: in cui si considerano il numero di router che vengono attraversati;

a stato di collegamento: in base al quale la scelta del percorso dipende dallo stato delle

interfacce sul router corrente ( stato attivo/inattivo).

B.4 I protocolli di trasporto

Il modello TCP/IP consente l’utilizzo di differenti protocolli a livello di trasporto. È

possibile, infatti, usufruire di due modalità di servizio: orientato alla connessione (mediante TCP),

non orientato alla connessione (utilizzando UDP).

Transport Control Protocol (TCP) Insieme ad IP, è il protocollo più utilizzato nella rete Internet. TCP fornisce un servizio

full-duplex, con acknowledgement e a flusso controllato. TCP può supportare più conversazioni

simultanee per il livello superiore, identificate tramite il numero di porta dell’intestazione. Molte

delle porte TCP sono riservate per applicazioni quali FTP, World Wide Web (WWW), Telnet,

etc.

I campi dell’intestazione TCP sono di seguito descritti.

o Source Port Number e Destination Port Number. Identificano i punti di accesso al servizio

per i processi di origine e destinazione.

o Sequence Number : specifica il numero assegnato al primo byte dei dati del messaggio

corrente.

o Acknowledgement Number: contiene il numero di sequenza del byte successivo nei dati

79


che il mittente del pacchetto si attende di ricevere.

o Offset: indica il numero di parole (32 bit) che compongono l’intestazione TCP.

o Reserved: campo riservato per usi futuri.

o Flag: campo contenete informazioni di controllo.

o Window: specifica la dimensione del buffer disponibile per i dati in arrivo.

o Checksum: rileva eventuali errori nell’intestazione o nei dati trasmessi.

o Pointer: puntatore al primo byte di dati urgenti (se presenti).

o Option: specifica diverse opzioni TCP.

Il protocollo TCP prevede una fase iniziale per instaurare la connessione e produce un

overhead3 eccessivo che lo rendono inadatto per tutte quelle applicazioni, come quelle VoIP, che

necessitano di un servizio veloce anche se non totalmente affidabile. Questa esigenza è

soddisfatta dal protocollo UDP descritto di seguito.

Figura 58 - Intestazione TCP

User Datagram Protocol (UDP) In maniera molto più semplice di TCP, User Datagram Protocol offre un servizio di

trasporto senza connessione aggiungendo al carico utile un’intestazione di soli otto byte,

costituita da quattro campi, come descritto in figura 59. Per le sue peculiarità UDP viene

utilizzato dalle applicazioni VoIP per il trasporto del traffico vocale. Per questo tipo di

applicazioni (real time applications) è più importante controllare la latenza piuttosto che garantire il

trasferimento affidabile di ogni singolo pacchetto.

3 Overhead: numero di byte di intestazione che si aggiungono al carico utile.

80


Figura 59 - Intestazione UDP

Reliable User Datagram Protocol (RUDP)

RUDP è un protocollo progettato per ottenere un più alto grado di affidabilità del

servizio di trasporto nell’ambito dei protocolli senza connessione. Il protocollo utilizza un

meccanismo di tipo FEC (Forward Error Correction). RUDP invia più copie dello stesso

pacchetto alla stazione ricevente, la quale è in grado di eliminare i pacchetti ridondanti. È

immediato osservare come ciò aumenti la probabilità di ricezione dei pacchetti.

RUDP, così come altri meccanismi FEC, è caratterizzato da un elevato consumo

dell’ampiezza di banda (doppia o tripla rispetto a UDP). È questo il principale motivo per cui

sono poche le implementazioni disponibili del protocollo.

B.5 Descrittori di sessione: Session Description Protocol (SDP)

Session Description Protocol, oggetto del documento RFC 2327, è utilizzato per

descrivere sessioni multimediali. In effetti, non rappresenta un vero e proprio protocollo,

piuttosto si può parlare di una convenzione, comunemente adottata dalle applicazioni che

utilizzano il formato SDP per scambiarsi informazioni necessarie all’attivazione di sessioni

multimediali. In generale, SDP consente di definire:

o il tipo di media stream (video, audio,applicazioni condivise);

o il protocollo di trasporto utilizzato (tipicamente RTP/UDP/IP, ma potrebbe

benissimo essere un circuito virtuale ATM);

o il formato (ad esempio, MPEG video e G.723.1 audio), con la corrispondente

mappatura tra i nomi di codifica ed i tipi di payload RTP;

o informazioni di sicurezza, come le chiavi di decodifica per le sessioni multimediali;

o indirizzo IP e numero di porta;

o informazioni sull’ampiezza di banda da utilizzare durante la conferenza multimediale;

o informazioni per contattare colui il quale gestisce la sessione, per comunicargli

eventuali problemi riscontrati.

81


Un messaggio SDP consiste di un set di parametri globali che forniscono le caratteristiche

dell’intera sessione, seguite da un altro gruppo di parametri che descrivono il tipo di media

stream. Ciascuna linea è costituita dal nome del parametro (un singolo carattere) seguito da un

insieme di valori. Uno dei pregi del protocollo risiede nella semplicità del formato e nella facile

estensibilità.

Nell’esempio di figura 60 si mostra un tipico messaggio SDP. Il messaggio descrive tre

media stream: uno audio (payload di tipo 0) e due video ( H.231 ed MPEG con payload di tipo

31 e 32 rispettivamente)

.

v=0

O=- 289084456 2890842807 IN IP4

192.16.24.202

C= IN IP4 host.anywhere.com

m= audio 49170 RTP/AVP 0

a=rtpmap:0 PCMU/8000

m=video 51372 RTP/AVP 31

a=rtpmap: 31 H261/90000

m=video 53000 RTP/AVP 32

a=rtpmap:32 MPV/90000

Figura 60- Messaggio SDP (esempio)

B.6 Voice Over IP

Da decenni, l’obbiettivo principale che il mondo delle telecomunicazioni cerca di

perseguire è l’integrazione VVD (Video/Voice/Data)4. È questo il motivo per cui la

commutazione di circuito comincia a cedere il passo a tecniche alternative in grado di offrire il

servizio telefonico utilizzando infrastrutture, originariamente progettate per il trasferimento dati.

A queste tecniche si da usualmente il nome di Voice Over Packet. Tre sono attualmente le

soluzioni proposte: Voice Over Frame Relay (VoFR), Voice Over ATM5, Voice Over IP (VoIP).

Il sistema VoIP è quello che, certamente, sta trovando i consensi maggiori per la grande

flessibilità del modello TCP/IP e per gli indiscutibili vantaggi che può apportare ai gestori, in

grado di sfruttare le risorse di rete in modo efficiente e con costi di gestione relativamente bassi,

4 ISDN e ADSL sono solo degli esempi indicatori di questa tendenza. 5 Nota anche come VTOA (Voice and Telephony Over ATM) in accordo con il forum ATM.

82


ed agli utenti che possono usufruire di una vastità di servizi, assolutamente impensabili sino ad

oggi.

B.6.1 Architettura di Voice Over IP

È possibile immaginare, anche per Voice Over IP, un modello stratificato, così come accade

per la maggior parte dei sistemi di telecomunicazione. Non esiste, in effetti, uno standard di

riferimento ma quello rappresentato in figura 61 meglio si presta a descrivere il sistema, offrendo

un modello utilizzabile anche per le altre architetture Voice Over Packet. Come si osserva, sono

presenti tre livelli che comunicano tra loro tramite opportune interfacce:

Livello standard dell’infrastruttura a commutazione di pacchetto;

Livello aperto di controllo della chiamata;

Livello aperto di servizio e delle applicazioni.

Livello standard dell’infrastruttura a commutazione di pacchetto È l’infrastruttura che sostituisce quella a commutazione di circuito. In VoIP è

rappresentata dal protocollo IP. Come è noto IP è un protocollo aperto che trasporta pacchetti

dalla sorgente alla destinazione, senza preoccuparsi della tipologia dei dati trasferiti. Per rendere

quanto più celeri i tempi di consegna dei pacchetti voce, si utilizza IP insieme al protocollo UDP,

preferito al più affidabile ma anche più lento ed oneroso TCP. I pacchetti UDP/IP sono

accompagnati dal protocollo RTP, dedicato al trasporto del traffico in tempo reale su questo tipo

di reti. Tutti i sistemi VoIP, attualmente, adottano per la trasmissione del traffico voce i pacchetti

RTP/UDP/IP.

Livello aperto di controllo della chiamata Si occupa di indirizzare e definire la modalità di svolgimento delle chiamate. Nella PSTN

questo servizio è svolto dai Service Control Point (SCP) SS7. Attualmente i principali protocolli di

controllo della chiamata sono:

• H.323 (ITU-T);

• SIP (IETF);

• MGCP;

• Megaco/H.248.

83


Livello aperto di servizio e delle applicazioni In questo livello risiedono tutte le applicazioni che consentono agli utenti di usufruire di

un vasto numero di servizi disponibili sulla rete (applicazioni con carta telefonica prepagata,

chiamata in attesa via Internet, servizio “click to talk” nelle pagine Web, etc.).

Figura 61 - Architettura VoIP

B.6.2 Protocolli di segnalazione VoIP

In maniera del tutto analoga al servizio tradizionale, ogni chiamata VoIP è accompagnata

da un insieme di operazioni che si svolgono prima, durante e dopo la chiamata stessa. Al

momento della richiesta del servizio, il chiamato ed il chiamante debbono poter stabilire in modo

univoco diversi parametri, ad esempio:

o il meccanismo di codifica per i dati (audio e/o video) che costituiranno il payload;

o gli indirizzi di trasporto da utilizzare durante il trasferimento dati (indirizzi IP,

protocollo di trasporto e corrispondente numero di porta);

o requisiti di banda;

o opportune autorizzazioni per iniziare ed accettare la chiamata.

Una volta attivata la sessione è necessario monitorarla per modificarne, eventualmente,

alcuni parametri. Ad esempio, in base alle condizioni di traffico in rete, si può rendere necessario

84


diminuire la velocità di trasmissione dei pacchetti, o modificare lo schema di codifica adottato.

Terminata la sessione si attiveranno le procedure per comunicare alle entità di rete

coinvolte che i due (o più) utenti sono nuovamente disponibili ad effettuare e/o ricevere nuove

chiamate.

I protocolli di segnalazione nascono proprio per questi scopi. In aggiunta, essi forniscono

le interfacce necessarie per “connettere” gli utenti di preesistenti sistemi telefonici agli utenti

VoIP.

Allo stato attuale, due sono i principali protocolli di segnalazione adottati in VoIP: SIP e

H.3236. Session Initiation Protocol, definito nel documento RFC 2543, è un protocollo di

segnalazione e controllo operante al livello delle applicazioni, utilizzato per attivare, gestire e

chiudere le sessioni multimediali. Il protocollo è in grado di operare in combinazione con altri

protocolli di segnalazione come H.323 ed è indipendente dalla piattaforma sottostante (protocolli

di trasporto e di rete). H.323 è il risultato dello Study Group 16 del ITU-Telecommunication

Styandardizzation Sector che nel giugno del 1996 presentò la prima versione dello standard per le

videoconferenze in tempo reale su LAN prive di ogni garanzia QoS.

6 In effetti H.323 è una suite di protolli.

85


Indice delle figure7

Figura 1......................................................................................................................................3 Figura 2 - All over IP ................................................................................................................4 Figura 3 -Soft Switch- ...............................................................................................................5 Figura 4......................................................................................................................................6 Figura 5......................................................................................................................................6 Figura 6......................................................................................................................................7 Figura 7 - SigTran.....................................................................................................................7 Figura 8 - ISDN User Adaptation ...........................................................................................8 Figura 9 - M2UA .......................................................................................................................8 Figura 10 - M2PA......................................................................................................................9 Figura 11 - M3UA ...................................................................................................................10 Figura 12 - SCTP ....................................................................................................................10 Figura 13 - SCTP funct oni

.....................................................................................................11 Figura 14 - four way handshake ............................................................................................11 Figura 15 - SCTP Packet........................................................................................................12 Figura 16 - SCTP Common Header......................................................................................13 Figura 17 - SCTP Chunk format............................................................................................13 Figura 18 - SCTP Data Chunk...............................................................................................13 Figura 19 - SCTP Init Chunk.................................................................................................13 Figura 20 - Esempio ...............................................................................................................15 Figura 21..................................................................................................................................15 Figura 22..................................................................................................................................16 Figura 23 - Modello operazionale SIP...................................................................................16 Figura 24 - SIP su infrastruttura TCP/IP .............................................................................19 Figura 25 - flusso di chiamata SIP con server proxy...........................................................23 Figura 26 - Flusso di chiamata SIP con server redirect......................................................24 Figura 27 - Esempio ...............................................................................................................26 Figura 28 - TCP timeout ........................................................................................................26 Figura 29 - three way handshake...........................................................................................27 Figura 30 - Esempio ...............................................................................................................29 Figura 31 - UDP timeout .......................................................................................................30 Figura 32 - Esempio ...............................................................................................................31 Figura 33 - Voice over IP .......................................................................................................32 Figura 34 - Header/Body .....................................................................................................34 Figura 35 - Messaggio SIP ISUP (es.) ..................................................................................35 Figura 36 - Messaggio SIP QSIG(es.)...................................................................................35 Figura 37 - SIP Bridge............................................................................................................36 Figura 38 - Call flow ISUP-SIP-SIP......................................................................................37 Figura 39 - Call flow ISUP-SIP-Q.931..................................................................................43 Figura 40 - Architettura di una rete SS7 ................................................................................52 Figura 41 - Modalità di segnalazione in SS7 ........................................................................54 Figura 42 - Architettura SS7 ...................................................................................................56 Figura 43 - Formato delle unità di segnalazione (SU).........................................................58 Figura 44 - Formato del messaggio SS7................................................................................59

7 Tutte le immagini sono state eseguite utilizzando il programma Microsoft Visio Drawing 2002®

86


Figura 45 - Struttura del messaggio ISUP ............................................................................61 Figura 46 - Sequenza di segnalazione en bloc .....................................................................62 Figura 47 - Sequenza di segnalazione boverlap ....................................................................62 Figura 48 - Protocolli di segnalazione ISDN ........................................................................65 Figura 49 - Formato dei messaggi Q.931 ..............................................................................65 Figura 50 - Lo svolgimento di una chiamata ISDN .............................................................66 Figura 51 - Esempio di architettura stratificata ..................................................................70 Figura 52 - Modello di riferimento OSI ................................................................................71 Figura 53 - Confronto tra i modelli OSI e TCP/IP..............................................................73 Figura 54 - Intestazione IP ....................................................................................................76 Figura 55 - Il campo ToS .......................................................................................................77 Figura 56 - Classi degli indirizzi IP.......................................................................................77 Figura 57 - Intestazione IPv6.................................................................................................78 Figura 58 - Intestazione TCP ................................................................................................80 Figura 59 - Intestazione UDP................................................................................................81 Figura 60- Messaggio SDP (esempio) ..................................................................................82 Figura 61 - Architettura VoIP ................................................................................................84

Indice delle tabelle

Tabella 1 - Intestazioni SIP....................................................................................................21 Tabella 2 - Parametri obbligatori nel messaggio SIP INVITE...........................................21 Tabella 3 - Codici di risposta SIP ..........................................................................................25 Tabella 4 - SIP-T.....................................................................................................................32 Tabella 5 - I protocolli SS7 .....................................................................................................63 Tabella 6 - Messaggi ISUP .....................................................................................................63 Tabella 7 .- Messaggi e codici Q.931 ( fonte: ITU-T Q.931 3/93) .......................................67

87


Indice generale

Introduzione ..............................................................................................................................3 1. SG-MGC: l’architettura SIGTRAN..................................................................................6 2. Stream Control Trasmission Protocol (SCTP)..............................................................10

2.1. Caratteristiche principali ........................................................................................11 3. MGC-MGC ......................................................................................................................15

3.1. E-SUP ......................................................................................................................16 3.2. Session Initiation Protocol (SIP) ...........................................................................16

3.2.1. Indirizzamento SIP .........................................................................................17 3.2.2. Individuazione dei server SIP ........................................................................18 3.2.3. Richieste e Risposte: le transazioni SIP ........................................................19 3.2.4. I messaggi SIP.................................................................................................19 3.2.5. Flussi di chiamata SIP ....................................................................................22

3.3. SIP ed i protocolli di trasporto ...............................................................................25 3.3.1. SIP over TCP ...................................................................................................25 3.3.2. SIP over UDP ..................................................................................................29 3.3.3. SIP over SCTP .................................................................................................30

3.4. SIP-T ........................................................................................................................31 3.4.1. Encapsulation: ISUP/Q.931 MIME Type ....................................................33 3.4.2. Traslation.........................................................................................................36 3.4.3. SIP INFO Method ..........................................................................................36 3.4.4. Flussi di chiamata ...........................................................................................37

Appendice A ............................................................................................................................50

A.1 Il sistema di segnalazione SS7 .....................................................................................51 A.1.1 Architettura della rete SS7......................................................................................51 A.1.2 Modalità di segnalazione ......................................................................................53 A.1.3 Collegamenti di segnalazione ...............................................................................54 A.1.4 La stack SS7...........................................................................................................55

A.1.4.1 La parte MTP ..................................................................................................56 A.1.4.2 Signalling Connection Control Part (SCCP) .................................................59 A.1.4.3 Telephone User Part (TUP) ...........................................................................59 A.1.4.4 Transaction Capabilities Application Part (TCAP) .....................................60 A.1.4.5 ISDN User Part (ISUP) ..................................................................................60

A.1.5 Esempi di operazioni di segnalazione .................................................................61 A.2 Il protocollo di segnalazione Q.931 .............................................................................65

Appendice B ............................................................................................................................68

B.1 Le reti IP........................................................................................................................69 B.2 Generalità sulIe architetture di rete: il modello OSI..................................................70 B.3 Il modello di riferimento TCP/IP...............................................................................73

B.3.1 Internet Protocol (IP) ............................................................................................75 B.3.1.1 Formato dei pacchetti IP ................................................................................75 B.3.1.2 Indirizzamento IP ...........................................................................................77 B.3.1.3 Il formato IPv6 ................................................................................................78 B.3.1.4 Instradamento .................................................................................................79

B.4 I protocolli di trasporto ................................................................................................79

88


B.5 Descrittori di sessione: Session Description Protocol (SDP)....................................81 B.6 Voice Over IP................................................................................................................82

B.6.1 Architettura di Voice Over IP ...............................................................................83 B.6.2 Protocolli di segnalazione VoIP ...........................................................................84

Indice delle figure ...................................................................................................................86 Indice delle tabelle ..................................................................................................................87 Indice generale ........................................................................................................................88 La segnalazione telefonica e VoIP................................ Errore. Il segnalibro non è definito.

89

Documents

UNIVERSITA’ DEGLI STUDI DI PALERMO FACOLTA’ DI INGEGNERIAfasciana/patch/SIGoverIP-overview.pdf · 2007-06-18 · M2PA è utilizzato quando il Signalling Gateway è sede anche