di Marco Calisti, Antonio Cuomo, Rocco Mazzeo e Francesco Pacilio

Outline

Introduzione

Voice over IP Controllo delle chiamate e segnalazioni Session Initiation Protocol Messaggi SIP Architettura analizzatore Interfaccia utente Servlet Engine Parser XML Data Access Object Sipana Sviluppi futuri Demo

Introduzione

Analizzatore di protocollo di alto livello per l’analisi e testing di conversazione VOIP

Decodifica dei messaggi

Filtri sulle conversazioni e sui messaggi

Implementazione post-processing

Definizione e esecuzione di test

Analisi off-line dei risultati

Voice over IP

Voice over IP è una tecnologia che rende possibile effettuare una conversazione telefonica sfruttando una connessione internet o una qualsiasi rete dedicata che utilizza il protocollo IP

Le informazioni vocali, codificate in forma digitale, vengono formattate in pacchetti e instradati sulla rete nel momento in cui avviene la comunicazione

Voice over IP - Vantaggi

Costi ridotti

Soprattutto per chiamate su lunga distanza

La sola infrastruttura richiesta è una rete IP

Nuove funzionalità avanzate

Riduzione della banda utilizzata

I pacchetti vengono trasmesso solo in presenza di comunicazione

Portabilità del numero telefonico

Voice over IP - Svantaggi

E’ necessario garantire livelli accettabili di QoS

Comunicazione real-time

Sicurezza della comunicazione

Eredità i problemi di sicurezza delle comunicazioni su rete IP

Localizzazione geografica delle chiamate molto complessa

Difficoltà di inoltrare le chiamate alle centrali più vicine

Controllo delle chiamate e segnalazioni

Gestiscono le informazioni che coinvolgono le telefonate

Selezione del numero

Segnali di libero o occupato

Chiamate multiple

Definiscono l’interfaccia tra la rete IP con la numerazione telefonica e con la rete telefonica tradizionale

Session Initiation Protocol

Protocollo del livello applicativo per la gestione delle sessioni di comunicazione tra due o più entità (User Agent)

Assicura la creazione, la modifica e la terminazione di una sessione

Non è integrato verticalmente

E’ necessario l’utilizzo di altri protocolli per la creazione di un’architettura completa

Non fornisce servizi ma primitive per implementare servizi

Session Initiation Protocol – User Agent

Entità logica associata ad un endpoint

User Agent Client: entità che inizializza una sessione

User Agent Server: entità che risponde ad una sessione

UACUser

Agent Client

User Agent

UASUser

Agent Server

User Agent

UACUser

Agent Client

UASUser

Agent Server

Proxy Server

Register

Inizializza sessione

Risposta

Messaggi SIP

I messaggi sono di due tipi Messaggi di richiesta:

○ INVITE: invito a partecipare ad una sessione e negoziare i parametri ○ ACK: conferma che l’UAC ha ricevuto una risposta finale ad una richiesta○ BYE: indica l'abbandono della sessione da parte di un utente○ CANCEL: annulla una richiesta ○ OPTIONS: richiede informazioni sullo stato di un server○ REGISTER: registra l'indirizzo di uno User Agent all'interno di un server

Messaggi di risposta

○ PROVISIONAL: la richiesta è stata ricevuta ed è in esecuzione○ SUCCESS: la richiesta ha avuto successo○ REDIRECTION: la richiesta deve essere re diretta ad un nuovo indirizzo○ REQUEST FAILURE: la richiesta non è andata a buon fine○ SERVER FAILURE: il server non riesce a processare la richiesta○ GLOBAL FAILURE: nessun server può elaborare la richiesta

Messaggio SIP - Struttura

Struttura messaggio SIP

Start Line method URL SIP/2.0 SIP/2.0 status reason

Header Fields Via: SIP/2.0/ protocol host: portFrom: user <sip: from: user@source>To: user<sip: to: user@source>Call-ID: localid@hostCseq: seq#methodContent-Length: length of bodyContent-Type: media type of bodyHeader: parameter; par1=value ; …….

Blank line

Message Body V = 0O = origin_user timestamp timestamp IN IP4 hostC = IN IP4 media destination addressT = 0M = media type port RTP/AVP payload types

Architettura analizzatore

Interfaccia utente

Servlet

Tecnologia Java per la creazione di applicazione webVengono inizializzate alla prima richiesta

○ Ogni nuova richiesta si traduce in una chiamata a un metodo della servlet

Mantengono in modo molto semplice e efficiente le sessioni

Consentono la gestione delle eccezioni, l’utilizzo dinamico della memoria

Utilizzano i meccanismi di protezioni forniti dai web container

FSMServlet

Definisce la logica per la gestione delle FSM (Finite State Machine)Creazione nuova FSM

Creazione nuovo stato

Creazione nuova transizione

Memorizzazione FSM

Cancellazione FSM

MessageServlet

Definisce la logica per la gestione della simulazione

Selezione conversazioni

Selezioni messaggi di una conversazione

Selezione FSM

Run simulazione

Engine

Componente core del simulatore

Dato un’insieme di messaggi relativi ad una comunicazione ed una o più FSM consente di eseguire il processo di analisi della comunicazione

L’analisi della comunicazione può essere eseguita in un unico run oppure è possibile analizzare ogni messaggio, singolarmente

Engine - Run

Engine – Finite State Machine

Una Finite State Machine è un modello di comportamento composto da un numero finito di stati, transizioni tra gli stati e azioni. Una transizione può essere associata ad una condizione che ne regola l’effettuazione.

Le azioni possono essere funzione dell’input e dell’uscita, macchina di Mealy, associate all’ingresso in uno stato, macchina di Moore, all’uscita da uno stato o ad una transizione.

Engine – Finite State Machine (2)

Nel nostro formalismo:

Stati e transizioni rispecchiano le definizioni classiche

L’input è costituito dalla sequenza di messaggi selezionata

Le condizioni permettono di esprimere vincoli di transizione basati sui messaggi in ingresso

Le azioni sono associate alle transizioni

La potenza espressiva è arricchita dalla presenza di uno storage in cui è possibile salvare valori (nelle azioni) e recuperarli (nelle condizioni)

Engine – Specifica delle condizioni (1)

Per la specifica delle condizioni è stata definita una grammatica context-free di tipo LL(1) e il relativo interprete

La definizione include un insieme di condizioni elementari che consentono di esprimere vincoli sul tipo di messaggio, sul valore degli header e sul tempo

Gli operatori di confronto sono uguaglianza (==) e disuguaglianza (!=) per valori di testo e numerici

operatori <, >, <=, >= per i valori numerici

Queste tipologie elementari possono essere arbitrariamente combinate con gli operatori &&, ||, !

E’ possibile esprimere precedenza con le parentesi ()

Engine – Specifica delle condizioni (2)

Le condizioni semplici rientrano nelle seguenti tipologie:

Tipo del messaggio: messageKind <comparOp> ‘constantValue’

Valore di un header del messaggio:

messageField[“Nome del campo”] <comparOp> <valore di confronto>

oppure

messageField[“fieldName”] <comparOp> readField[“varName”]

dove varName è un campo salvato nello storage da un’azione

Tempo trascorso dal messaggio immediatamente precedente:time <comparOp> ‘constantValue’

Tempo trascorso da uno dei messaggi precedenti:

timeDiff[“varName”] <comparOp> ‘constant value’

dove varName è un valore di tempo salvato nello storage da un azione e timeDiff è la differenza tra il valore corrente e quello salvato

Engine – Specifica delle azioni

Anche per la specifica delle azioni è stata definita una grammatica context-free di tipo LL(1) e il relativo interprete

Ad ogni transizione è possibile associare una sequenza di azioni, separate da ‘;’

Attualmente esistono 2 tipologie di azione:

saveField[“fieldName”, “varName”]

○ consente di salvare nella variabile di storage varName il campo fieldName del messaggio corrente

saveTimer[“varName”]

○ consente di salvare nella variabile di storage varName il valore temporale associato al messaggio corrente

Engine – Design

Le grammatiche delle condizioni e della azioni sono state definite di tipo LL(1) per poter implementare dei semplici parser a discesa ricorsiva

Tali scelte implementative rendono l’architettura estendibile

Parser Xml

Componente del simulatore che gestisce la persistenza delle FSM in file XML

Lettura FSM

Memorizzazione FSM

FSM.xml e FSM.dtd

Data Access Object

Design pattern utilizzato per astrarre e incapsulare gli accessi alle sorgenti dati

Consente di leggere e memorizzare i dati

Sipana

Sviluppi futuri

Graphical User Interface per la definizione delle FSM e generazione automatica dell’XML

Estensione multiprotocollo

Demo

Creazione di una FSM per applicazione di un test

Selezione di una conversazione

Selezione dei messaggi di una conversazione

Selezione delle FSM da eseguire

Avvio testing

Report stato del testing