UNIVERSITA DEGLI STUDI DI PALERMO FACOLTA DI INGEGNERIA

Transcript

1 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 2 La segnalazione telefonica e VoIP

3 * 8 # * 8 # * 8 # * 8 # * 8 # * 8 # La segnalazione telefonica e VoIP 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. 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

4 * 8 # * 8 # * 8 # * 8 # * 8 # * 8 # La segnalazione telefonica e VoIP 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.). 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

5 * 8 # * 8 # * 8 # La segnalazione telefonica e VoIP 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. 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

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

7 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

8 ISDN Q.931 over IP: IUA In questo scenario si utilizza uno strato di adattamento chiamato IUA (ISDN Q.921 User Adaptation) è 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

9 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

10 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

11 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

12 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

13 Figura 16 - SCTP Common Header Figura 17 - SCTP Chunk format Figura 18 - SCTP Data Chunk Figura 19 - SCTP In it Chunk 13

14 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

15 Figura 20 - Esempio 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

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

17 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 Indirizzamento SIP Gli indirizzi SIP sono identificati attraverso un URL (Universal Resource Locator) SIP. L aspetto è praticamente identico al formato degli indirizzi , quindi del tipo: user@host.la 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

18 indirizzi URL SIP validi sono: 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, mario.rossi@lilliput.gov). Un server SIP risolverà l indirizzo URL in un indirizzo URL SIP come sip:mrossi@segreteria.lilliput.gov. Un server DNS risolverà l indirizzo ULR SIP ritornando un indirizzo IP 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

19 Figura 24 - SIP su infrastruttura TCP/IP 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 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

20 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

21 Intestazioni generali Tabella 1 - Intestazioni SIP Intestazioni Intestazioni di entità 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 Expires From Record-Route Timestamp To Proxy-Require Route Requie Response-Key Subject User-Agent Via Tabella 2 - Parametri obbligatori nel messaggio SIP INVITE Parametro Call-ID CSeq From To Via Descrizione identifica univocamente un determinato invito numero di sequenza crescente identifica l iniziatore della richiesta identifica il destinatario della richiesta indica il percorso seguito dalla richiesta 21

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

23 Figura 25 - flusso di chiamata SIP con server proxy 23

24 Figura 26 - Flusso di chiamata SIP con server redirect 24

25 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 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 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 endpoint. 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

26 SENDER RECEIVER 1:257 ACK :513 x 513:769 ACK :513 Figura 27 - Esempi o 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

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

28 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

29 SIP over UDP Figura 30 - Esempio 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

30 Figura 31 - UDP timeout 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

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

32 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 Trasparency Routability Mid-call information Funzione SIP-T SIP Encapsulation SIP Traslation SIP INFO-Method Trasparency 32

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

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

35 Figura 35 - Messaggio SIP ISUP (es.) Figura 36 - Messaggio SIP QSIG(es.) 35

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

37 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) Flussi di chiamata Caso I: scenario ISUP-SIP-ISUP Figura 38 - Call flow ISUP-SIP-SIP 37

38 (1) IAM Switch A -> Ingress Soft Switch IAM CgPN= ,NPI=E.164,NOA=National CdPN= ,NPI=E.164,NOA=National (2) INVITE Ingress Soft Switch -> Proxy INVITE sip: @proxy.atlanta.com;user=phone SIP/2.0 Via: SIP/2.0/SCTP iss.atlanta.com:5060;branch=z9hg4bklueha2 Max-Forwards: 70 From:<sip: @iss.atlanta.com;user=phone>;tag=7643kal To: <sip: @proxy.atlanta.com;user=phone> Call-ID: 2xTb9vxSit55XU7p8@iss.atlanta.com CSeq: 1 INVITE Contact: <sip: @iss.atlanta.com;user=phone> Content-Type: application/sdp Content-Length: 141 v=0 o=gw IN IP4 gw1.atlanta.com s=c=in IP t=0 0 m=audio 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: @ess.atlanta.com SIP/2.0 Via: SIP/2.0/SCTP proxy.atlanta.com:5060;branch=z9hg4bk2d Via: SIP/2.0/SCTP iss.atlanta.com:5060;branch=z9hg4bkwqwee65 ;received= Max-Forwards: 69 Record-Route: <sip:proxy.atlanta.com;lr> From:<sip: @iss.atlanta.com;user=phone>;tag=7643kal To: <sip: @proxy.atlanta.com;user=phone> Call-ID: 2xTb9vxSit55XU7p8@iss.atlanta.com CSeq: 1 INVITE Contact: <sip: @iss.atlanta.com;user=phone> Content-Type: application/sdp Content-Length: 141 v=0 o=gw IN IP4 iss.atlanta.com s=c=in IP t=0 0 m=audio RTP/AVP 0 a=rtpmap:0 PCMU/

39 (4) IAM Egress Softswitch-> Switch IAM CgPN= ,NPI=E.164,NOA=National CdPN= ,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/ Session Progress Via: SIP/2.0/SCTP proxy.atlanta.com:5060;branch=z9hg4bk2d ;received= Via: SIP/2.0/SCTP iss.atlanta.com:5060;branch=z9hg4bklueha2 ;received= Record-Route: <sip:proxy.atlanta.com;lr> From: <sip: @iss.atlanta.com;user=phone>;tag=7643kal To: <sip: @proxy.atlanta.com;user=phone>;tag= Call-ID: 2xTb9vxSit55XU7p8@iss.atlanta.com CSeq: 1 INVITE Contact: <sip: @ess.atlanta.com> Content-Type: application/sdp Content-Length: 149 v=0 o=gw IN IP4 ess.atlanta.com s=c=in IP t=0 0 m=audio RTP/AVP 0 a=rtpmap:0 PCMU/8000 (7) 183 Session Progress Proxy -> ISS SIP/ Session Progress Via: SIP/2.0/SCTP iss.atlanta.com:5060;branch=z9hg4bklueha2 ;received= Record-Route: <sip:proxy.atlanta.com;lr> From:<sip: @iss.atlanta.com;user=phone>;tag=7643kals To: <sip: @proxy.atlanta.com;user=phone>;tag= Call-ID: 2xTb9vxSit55XU7p8@iss.atlanta.com CSeq: 1 INVITE Contact: <sip: @ess.atlanta.com> Content-Type: application/sdp Content-Length: 149 v=0 o=gw IN IP4 ess.atlanta.com s=c=in IP

40 t=0 0 m=audio RTP/AVP 0 a=rtpmap:0 PCMU/8000 (8) ACM NGW 1 -> Switch A (9) ANM Switch -> ESS (10) 200 OK ESS -> Proxy SIP/ OK Via: SIP/2.0/SCTP proxy.atlanta.com:5060;branch=z9hg4bk2d ;received= Via: SIP/2.0/SCTP iss.atlanta.com:5060;branch=z9hg4bklueha2 ;received= Record-Route: <sip:proxy.atlanta.com;lr> From:<sip: @iss.atlanta.com;user=phone>;tag=7643kals To: <sip: @proxy.atlanta.com;user=phone>;tag= Call-ID: 2xTb9vxSit55XU7p8@iss.atlanta.com CSeq: 1 INVITE Contact: <sip: @ess.atlanta.com> Content-Type: application/sdp Content-Length: 149 v=0 o=gw IN IP4 ess.atlanta.com s=c=in IP t=0 0 m=audio RTP/AVP 0 a=rtpmap:0 PCMU/8000 (11) 200 OK Proxy -> ISS SIP/ OK Via: SIP/2.0/SCTP iss.atlanta.com:5060;branch=z9hg4bklueha2 ;received= Record-Route: <sip:proxy.atlanta.com;lr> From:<sip: @iss.atlanta.com;user=phone>;tag=7643kal To: <sip: @proxy.atlanta.com;user=phone>;tag= Call-ID: 2xTb9vxSit55XU7p8@iss.atlanta.com CSeq: 1 INVITE Contact: <sip: @ess.atlanta.com> Content-Type: application/sdp Content-Length: 149 v=0 o=gw IN IP4 ess.atlanta.com s=c=in IP t=0 0 m=audio RTP/AVP 0 40

41 a=rtpmap:0 PCMU/8000 (12) ANM ISS -> Switch (13) ACK ISS -> Proxy ACK SIP/2.0 Via: SIP/2.0/SCTP iss.atlanta.com:5060;branch=z9hg4bklueha2 Max-Forwards: 70 Route: <sip:proxy.atlanta.com;lr> To: Call-ID: CSeq: 1 ACK Content-Length: 0 (14) ACK Proxy 1 -> GW 2 ACK sip: @ess.atlanta.com SIP/2.0 Via: SIP/2.0/SCTP proxy.atlanta.com:5060;branch=z9hg4bk2d Via: SIP/2.0/SCTP iss.atlanta.com:5060;branch=z9hg4bklueha2 ;received= Max-Forwards: 69 From:<sip: @iss.atlanta.com;user=phone>;tag=7643kals To: <sip: @proxy.atlanta.com;user=phone>;tag= Call-ID: 2xTb9vxSit55XU7p8@iss.atlanta.com 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: @iss.atlanta.com;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: @proxy.atlanta.com;user=phone>;tag= To: <sip: @iss.atlanta.com;user=phone>;tag=7643kals Call-ID: 2xTb9vxSit55XU7p8@iss.atlanta.com CSeq: 4 BYE Content-Length: 0 41

42 (17) RLC ESS -> Switch (18) BYE Proxy->ESS BYE SIP/2.0 Via: SIP/2.0/SCTP proxy.atlanta.com:5060;branch=z9hg4bk2d Via: SIP/2.0/SCTP ess.atlanta.com:5060;branch=z9hg4bktexx6 ;received= Max-Forwards: 69 From: To: Call-ID: CSeq: 4 BYE Content-Length: 0 (19) 200 OK ISS -> Proxy SIP/ OK Via: SIP/2.0/SCTP proxy.atlanta.com:5060;branch=z9hg4bk2d ;received= Via: SIP/2.0/SCTP ess.atlanta.com:5060;branch=z9hg4bktexx6 ;received= From: <sip: @proxy.atlanta.com;user=phone>;tag= To: <sip: @iss.atlanta.com;user=phone>;tag=7643kals Call-ID: 2xTb9vxSit55XU7p8@iss.atlanta.com CSeq: 4 BYE Content-Length: 0 (20) 200 OK Proxy ->ESS SIP/ OK Via: SIP/2.0/SCTP ess.atlanta.com:5060;branch=z9hg4bktexx6 ;received= From: <sip: @proxy.atlanta.com;user=phone>;tag= To: <sip: @iss.atlanta.com;user=phone>;tag=7643kals Call-ID: 2xTb9vxSit55XU7p8@iss.atlanta.com CSeq: 4 BYE Content-Length: 0 (21) REL ISS ->Switch REL CauseCode=16 Normal (22) RLC Switch ->ISS 42

43 Scenario 2: ISUP-SIP-Q.931 Figura 39 - Call flow ISUP-SIP-Q.931 (1) ISUP IAM Switch A -> Ingress Soft Switch IAM CgPN= ,NPI=E.164,NOA=National CdPN= ,NPI=E.164,NOA=National (2) SIP INVITE Ingress Soft Switch -> Proxy INVITE sip: @proxy.atlanta.com;user=phone SIP/2.0 43

44 Via: SIP/2.0/SCTP iss.atlanta.com:5060;branch=z9hg4bklueha2 Max-Forwards: 70 To: Call-ID: CSeq: 1 INVITE Contact: <sip: @iss.atlanta.com;user=phone> Content-Type: application/sdp Content-Length: 141 v=0 o=gw IN IP4 gw1.atlanta.com s=c=in IP t=0 0 m=audio 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: @ess.atlanta.com SIP/2.0 Via: SIP/2.0/SCTP proxy.atlanta.com:5060;branch=z9hg4bk2d Via: SIP/2.0/SCTP iss.atlanta.com:5060;branch=z9hg4bkwqwee65 ;received= Max-Forwards: 69 Record-Route: <sip:proxy.atlanta.com;lr> From:<sip: @iss.atlanta.com;user=phone>;tag=7643kal To: <sip: @proxy.atlanta.com;user=phone> Call-ID: 2xTb9vxSit55XU7p8@iss.atlanta.com CSeq: 1 INVITE Contact: <sip: @iss.atlanta.com;user=phone> Content-Type: application/sdp Content-Length: 141 v=0 o=gw IN IP4 iss.atlanta.com s=c=in IP t=0 0 m=audio 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

45 Called party number: Type of number and numbering plan ID=33 (National number in ISDN numbering plan) Digits= (5) ISUP CPG ISS ->Switch (6) SIP 100 Trying ESS -> Proxy SIP/ Trying Via: SIP/2.0/SCTP proxy.atlanta.com:5060;branch=z9hg4bk2d ;received= Via: SIP/2.0/SCTP iss.atlanta.com:5060;branch=z9hg4bklueha2 ;received= Record-Route: <sip:proxy.atlanta.com;lr> From: To: Call-ID: CSeq: 1 INVITE Contact: <sip: @ess.atlanta.com> Content-Type: application/sdp Content-Length: 149 v=0 o=gw IN IP4 ess.atlanta.com s=c=in IP t=0 0 m=audio RTP/AVP 0 a=rtpmap:0 PCMU/8000 (7) SIP 100 Trying Proxy -> ISS SIP/ Trying Via: SIP/2.0/SCTP iss.atlanta.com:5060;branch=z9hg4bklueha2 ;received= Record-Route: <sip:proxy.atlanta.com;lr> From:<sip: @iss.atlanta.com;user=phone>;tag=7643kals To: <sip: @proxy.atlanta.com;user=phone>;tag= Call-ID: 2xTb9vxSit55XU7p8@iss.atlanta.com CSeq: 1 INVITE Contact: <sip: @ess.atlanta.com> Content-Type: application/sdp Content-Length: 149 v=0 o=gw IN IP4 ess.atlanta.com s=c=in IP t=0 0 m=audio RTP/AVP 0 a=rtpmap:0 PCMU/

46 (8) Q.931 CALL PROC PBX ->ESS (9) Q.931 ALERT PBX ->ESS (10) SIP 180 Ringing ESS -> Proxy SIP/ Ringing Via: SIP/2.0/SCTP proxy.atlanta.com:5060;branch=z9hg4bk2d ;received= Via: SIP/2.0/SCTP gw1.atlanta.com:5060;branch=z9hg4bkwqwee65 ;received= Record-Route: <sip:proxy.atlanta.com;lr> From: To: Call-ID: CSeq: 1 INVITE Contact: <sip: @gw3.atlanta.com;user=phone> Content-Length: 0 (11) SIP 180 Ringing Proxy ->ISS SIP/ Ringing Via: SIP/2.0/SCTP gw1.atlanta.com:5060;branch=z9hg4bkwqwee65 ;received= Record-Route: <sip:proxy.atlanta.com;lr> From: <sip:551313@gw1.atlanta.com>;tag=63412s To: <sip: @proxy.atlanta.com>;tag= Call-ID: 2xTb9vxSit55XU7p8@gw1.atlanta.com CSeq: 1 INVITE Contact: <sip: @gw3.atlanta.com;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/ OK Via: SIP/2.0/SCTP proxy.atlanta.com:5060;branch=z9hg4bk2d ;received= Via: SIP/2.0/SCTP iss.atlanta.com:5060;branch=z9hg4bklueha2 ;received= Record-Route: <sip:proxy.atlanta.com;lr> From: <sip: @iss.atlanta.com;user=phone>;tag=7643kals 46