Capitolo 5 Conclusioni: vantaggi. Limitazioni e possibili miglioramenti

Vantaggi

Primo e più importante: il problema presentato è stato risolto. Il software realizzato è in grado di permettere chiamate tra endpoint attestati sia sulla stessa rete sia su reti differenti. Con la dicitura "reti differenti" intendiamo due reti private a spazi di indirizzamento diversi oppure una rete privata e l'Internet a indirizzi pubblici

Il proxy è in grado di distinguere se una chiamata ha bisogno del suo intervento, oppure se limitare il proprio funzionamento a quello di gatekeeper. Questo significa che se i due terminali sono attestati sulla stessa sottorete, il flusso RTP viene scambiato direttamente tra di loro, così da non caricare di lavoro inutile la macchina sulla quale gira il proxy

Le chiamate non si limitano all'audio ma sono delle vere e proprie conferenze multimediali, video compreso

Rispetto all'RSIP Server la soluzione realizzata non ha la limitazione di dover disporre di un numero di indirizzi IP pubblici pari al numero delle chiamate contemporanee che si vogliono permettere; l'unico indirizzo pubblico del quale abbiamo bisogno è quello dell'interfaccia "esterna" del proxy

Rispetto al modulo per il masquerading non c'è la grossissima limitazione della sola chiamata diretta: è lo stesso software realizzato che funziona anche da gatekeeper. Inoltre il funzionamento è legato al kernel Linux per la sola parte di filtraggio dei pacchetti: tanto meglio funzionerà il packet filter nelle versioni successive di Linux, tanto più efficiente sarà il funzionamento del software realizzato. Le modifiche, nel caso di cambiamenti nella sintassi dei comandi, interesserebbero poche linee di codice

Sicurezza: il proxy non apre porte indiscriminatamente. Le porte sempre aperte sono quelle TCP 1719 (registrazione) e 1720 (segnalazione di chiamata). Solo quando un endpoint registrato (e l'ammissione alla registrazione è sotto il nostro completo controllo) manda un setup vengono aperte delle porte UDP supplementari, e solo per la durata della chiamata. La politica di default delle varie catene è quella di DROP

Limitazioni

Poiché necessariamente il gatekeeper deve funzionare in modalità H.225 e H.245 routed il carico di lavoro (processing) richiesto alla macchina sulla quale gira il proxy è maggiore che nella modalità direct
Interoperabilità tra certi endpoint: in genere gli endpoint software omologhi non hanno problemi a "parlarsi", dato che usano le stesse versioni dello stack H.323. I telefoni IP si comportano molto bene in tutte le situazioni; d'altra parte sono prodotti commerciali dal costo non indifferente, e sono molto più curati di quanto non siano i vari Netmeeting, Openphone e così via. Quando ci troviamo in una situazione "mista" sorgono dei problemi: al momento, in certi casi, uno tra chiamante e chiamato non riceve il flusso RTP. Il problema risiede molto probabilmente nella differente trattazione dei messaggi H.245 da parte dei terminali; per risolverlo occorre semplicemente aggiungere delle parti di codice che tengano conto del comportamento particolare di alcuni endpoint
Il numero di chiamate contemporanee che si possono gestire dipende dall'equipaggiamento hardware della macchina sulla quale gira il proxy. Non è tanto la parte di routing dei pacchetti che è pesante dal punto di vista delle risorse, quanto l'esecuzione del codice, che prevede un gran numero di controlli, di scansioni di liste e di scritture in memoria

Miglioramenti : "to do list"

Il lavoro svolto è ben lungi dall'essere un prodotto finito: nonostante le funzionalità di base siano tutte presenti, si tratta di un work in progress, che continuerà ad essere curato fino a diventare un prodotto "reale". Riportiamo una lista di aggiunte e, in generale, di cose da fare, per "prodottizzare" l'ALG:

Aggiungere al codice delle parti che permettano l'interoperabilità a tutti i tipi di terminale

Testare il funzionamento di applicazioni quali il fax su IP o la cosiddetta "lavagna condivisa", che usano il protocollo T.120. Non dovrebbero esserci problemi, dato che la parte di codice che gestisce tale protocollo è identica a quella che gestisce audio e video, che funzionano bene (quasi sempre)
Test di carico, per quantificare il numero di chiamate contemporanee che si riescono a supportare, il numero di setup al secondo, e altri parametri di interesse
Il software realizzato partiva da uno stack H.323 proprietario, che supporta la versione 3 di H.323; poiché esiste una nuova versione di tale stack, che implementa H.323 versione 4, è auspicabile un porting del codice scritto verso la versione più recente
Il software modificato, come pure quello originale, viene configurato mediante un file di configurazione, e fatto partire da linea di comando: l'aggiunta di un'interfaccia grafica è necessaria per riunire le due funzionalità e facilitare l'uso del software
Integrazione delle funzionalità di firewall nel proxy
Aggiunta di supporto per funzionalità quali il trasferimento di chiamata, il controllo di banda, etc.
Interfacciamento con Xdsl o fibra ottica per fornire a piccole reti aziendali una soluzione unica: router, firewall e H.323 in un solo oggetto

Page hosted at

Last Update ven gen 31 18:03:32 CET 2003