• Non ci sono risultati.

CAPITOLO 2

N/A
N/A
Protected

Academic year: 2021

Condividi "CAPITOLO 2"

Copied!
9
0
0

Testo completo

(1)

CAPITOLO 2

ASTERISK

Asterisk è nato come progetto Open Source per la realizzazione di un centralino VoIP e TDM in grado di gestire le moderne comunicazioni VoIP e le interfacce per la gestione di linee PSTN (analogiche e digitali).

Asterisk è un programma applicativo scritto in linguaggio C per funzionare su Personal computer e in ambiente Linux. Esistono anche delle versioni per poter lavorare in Windows, in MacOSX, ma la comunità di sviluppo rivolge la maggiore attenzione alla versione Linux.

La prima stesura venne realizzata da Mark Spencer che attorno all’anno 2000 fondò Digium, una società di produzione elettronica, e per favorire la diffusione dei propri prodotti fece sviluppare un’applicazione in grado di attribuire ad un PC, equipaggiato di interfaccie Digium, le funzionalità tipiche di un centralino telefonico.

Il suo nome, Asterisk , proviene dal mondo Unix e Dos dove rappresenta un cosiddetto “carattere jolly” (*) cioè la possibilità di rappresentare ogni file. In modo simile, Asterisk è stato progettato per interfacciare qualsiasi tipo di apparato telefonico standard (sia hardware che software) con qualsiasi applicazione telefonica standard , in modo semplice e consistente.

Essendo Asterisk un progetto Open Source, esso è rilasciato sotto licenza GNU GPL ed è possibile per tutti accedere al suo contenuto liberamente. Questo ha favorito lo sviluppo di moltissime soluzioni e il suo continuo miglioramento grazie a centinaia di sviluppatori in tutto il mondo.

A differenza di altri prodotti commerciali è infatti possibile per chiunque applicare delle modifiche al codice sorgente e renderle pubbliche all'interno

della CVS (Concurrent Versions System). Chiaramente tali modifiche (patch) vengono valutate e testate da più sviluppatori ed inserite nella CVS solo se sono di interesse generale per la comunità del progetto.

Asterisk supporta diversi protocolli e raccomandazioni per la segnalazione delle chiamate VoIP:

§

IAX (Inter Asterisk Exchange): protocollo VoIP creato dai

programmatori di Asterisk e progettato con l’obiettivo di risolvere le problematiche emerse dagli altri protocolli per la gestione della voce su IP.

§

SIP: lo standard IETF per il VoIP

§

H323: lo standard ITU per il Voice Over IP

§

MGCP (Media Gateway Control Protocol): protocollo che gestisce

la segnalazione e il controllo di connessioni VoIP (utilizzabile con Cisco Call Manager)

§

SCCP (Skinny Cisco Control Protocol): standard proprietario

Cisco per il supporto dei servizi sui propri telefoni

Mentre alcuni di questi protocolli, come il SIP, sono implementati nativamente nel software, altri, come l’H323, hanno bisogno della presenza di altri packege e librerie. Per esempio, per l’H323 si richiede l’installazione di Openh323 e Pwlib.

Le funzioni svolte da Asterisk sono quelle tipiche dei centralini. È possibile trasferire le chiamate con o senza offerta, creare delle stanze per le conferenze, mettere in attesa con musica una chiamata, attivare la segreteria, creare IVR, parcheggiare le chiamate, connettersi ai Provider Voip e alla rete PSTN. Oltre a queste e ad altre caratteristiche, Asterisk può svolgere

(2)

anche la funzione di semplice Gateway per mettere in comunicazione fra di loro centralini Voip che utilizzano protocolli di segnalazione diversi.

2.1

Installazione, struttura e avvio di Asterisk

Il software Asterisk è possibile scaricarlo dal sito ufficiale (www.asterisk.org). Una volta decompresso il file, viene creata una cartella asterisk in /usr/src. Dopo essere entrati in questa directory(/usr/src) possiamo procedere con la compilazione del programma. Asterisk per essere compilato necessita della libreria gcc quindi dell’utilizzo del comando make. Le operazione da compiere sono il lancio dei seguenti comandi

§ make § make install § make sample

Il make sample non è obbligatorio ma risulta utile in quanto permette di salvare una configurazione di esempio.

Affinché la compilazione vada a buon fine dovranno essere installati su Linux anche i seguenti pacchetti: glibc-devel, openssl-devel e zlib-devel

La struttura di Asterisk è stata progettata per seguire l’organizzazione tradizionale di Linux; sarà quindi raggruppato in diverse cartelle.

La più importante per quanto riguarda la configurazione di Asterisk è

/etc/asterisk dove sono contenuti tutti i file di configurazione.

Fra questi file troviamo:

§ feature.conf: in questo file è possibile configurare le modalità con cui è possibile accedere, attraverso il tastierino telefonico dei vari client, ad alcuni dei servizi avanzati, come il trasferimento di

chiamata di tipo blind (senza offerta) o di tipo attend (con offerta), oppure il parking della chiamata

§ meetme.conf: in questo file devono essere dichiarate le stanze e le relative password di ingresso per poter effettuare conferenze di tipo statico.

§ voicemail.conf: in questo file devono essere definiti alcuni parametri per fare in modo che ad una determinata estensione sia associata una segreteria telefonica.

§ sip.conf: questo rappresenta uno dei file più importanti nel quale devono essere definiti gli utenti sip appartenenti ad Asterisk; sempre da questo file è possibile indicare la porta su cui Asterisk starà in ascolto per i messaggi di segnalazione Sip; in generale dal file sip.conf posso configurare tutti quei parametri afferenti al canale SIP

§ h323.conf: in maniera duale al sip.conf, in questo file sono definite tutte le proprietà (utenti, porta, gatekeeper…) relative al canale H323.

§ musicOnHold.conf: definisce la musica di attesa

§ extension.conf: in questo file viene definito il dialplan (ovvero « piano di chiamata ») che è la parte più interessante della configurazione di Asterisk. Nel dialplan si definisce cosa deve fare il PBX se una chiamata è ricevuta su uno dei canali (sip, h323, iax). Il dialplan definisce il modo di trattare ed instradare le chiamate in entrata ed in uscita. È qui che si configura il comportamento di tutte le connessioni che attraversano il PBX. Il contenuto di

extensions.conf è organizzato in sezioni che si chiamano contesti o contexts.

(3)

Per tutti i moduli che lo richiedono sono presenti degli opportuni file di configurazione. I moduli che hanno bisogno di parametri di configurazione sono quelli che gestiscono i vari tipi di canali (es. sip.conf, h323.conf…) e quelli che configurano il funzionamento di alcune applicazioni. Per ogni tipo di canale infatti devono essere fissati parametri legati al tipo di protocollo utilizzato.

Esiste così per ogni protocollo VoIP un differente file di configurazione che specifica parametri come indirizzo e porta d'ascolto, utenti che si possono collegare al sistema e parametri sulla gestione del traffico.

Comune a tutti i file di configurazione dei canali è l'indicazione di come questi interagiscono con il dialplan (meccanismo di instradamento e commutazione) e cioè come una chiamata sarà gestita dal centralino. Oltre ai moduli relativi ai canali, anche alcune applicazioni hanno bisogno di un file di configurazione; questo se il loro funzionamento è sufficientemente articolato da non poter essere determinato da semplici parametri passati al momento della chiamata della applicazione stessa. Così mentre l'applicazione “Dial” (che permette l’esecuzione della chiamata e la vedremo successivamente) non necessita di un file di configurazione altre, come l'applicazione MusicOnHold per l'ascolto della musica d'attesa prevedono un file apposito da nel quale configurare i parametri opportuni. I moduli vengono caricati secondo le esigenze agendo sul file di configurazione: /etc/asterisk/modules.conf.

Una volta installato Asterisk, lo step successivo è lanciarlo. Esistono varie modalità di lancio. I diversi modi per avviarlo possono essere visualizzati mandando in esecuzione il seguente file:

# /usr/sbin/asterisk -h

Di seguito sono elencate alcune delle principali opzioni di lancio:

§ -c (console): permette di visuallizzare la console CLI di Asterisk. Questa si presenterà nel seguente modo:

Figura 2.1 Console di Asterisk

§ -v (verbosity): viene utilizzata per aumentare la quantità di Debug sull'output della console CLI

§

-

r (remote) questa opzione permette di riconnettersi in modo

remoto al centralino Asterisk se questo è già in esecuzione

In conclusione un modo per lanciare Asterisk, che permette di visualizzare la console e che fornisce in output informazini di debug utili per capire che

(4)

cosa sta caricando il software e se ci sono dei problemi in fase di avvio, è il seguente

asterisk -vvvvvvc

Una volta entrati nella console di Asterisk, esistono vari modi per poter controllare come e quando arrestare il sistema. Fra più frequenti ci sono:

§ stop now : arresta immediatamente Asterisk

§ stop gracefully: arresta Asterisk quando tutte le attività dei vari canali sono terminate. Una volta lanciato questo comando, non viene più accettata nessuna chiamata

Alcuni dei comandi da utlizzare nella console CLI che permettono di monitorare lo stato degli utenti appartenenti ad Asterisk sono:

§ sip show users : mostra la lista di tutti gli utenti configurati nel file sip.conf

§ show queues: fornisce informazioni su tutte le code

§ sip show user user_name: fornisce i dettagli relativi all’utente

user_name del file sip.conf

§ sip show registry : fornisce la lista degli utenti registrati

§ show dialplan [context] : mostra lo stato corrente del dialplan caricato in memoria; se viene inserito alla fine del comando anche il nome del contesto, verrà visualizzato solo il dialplan relativo a tale contesto.

Logging

A seconda delle situazioni potrebbe essere utile alzare o abbassare il livello di informazioni che Asterisk fornisce in output, in modo tale da avere una conoscenza più o meno dettagliata sulle azione che il software sta compiendo. Per provvedere a questo, Asterisk fornisce la possibilità di regolare il livello dei log attraverso l’opportuna configurazione del file

/etc/asterisk/logger.conf.

I messaggi di log che sono forniti in output possono essere classificati in cinque categorie:

§ Verbose: informazioni di carattere generale su che cosa sta succedendo nel sistema; questo genera molte informazioni di log § Debug : i messaggi di debug sono solitamente usati dai

programmatori per avere una maggiore mole di informazioni sul sistema e sul suo comportamento.

§ Notice: sono messaggi di allarme che però non notificano un urgenza

§ Warning : informano che è accaduto qualcosa che potrebbe portare ad un errore; sono messaggi di allarme che hanno una certa urgenza

§ Error

: indicano che si è verificato un errore

Il file logger.conf potrebbe essere configurato nel seguente modo:

debug => debug

messages => warning,error

console => debug, warning, error, notice, verbose

in questo modo verrebbero scritti tutti i messaggi di debug in un file che si chiama debug e che si trova in /var/log/asterisk, i messaggi di warning ed

(5)

error in un file che si chiama messages , che si trova sempre nella medesima directory; la terza riga invece dice di inviare tutti i messaggi di log in output sulla console (esempi di questi messaggi si possono vedere nell’immagine della console che è stata inserita precedentemente).

Attraverso la console di Asterisk è anche possibile abilitare (o disabilitare) la scrittura su video dei messaggi SIP relativi ad uno specifico utente che è stato inserito nel file sip.conf. Per fare questo deve essere digitato il comando:

sip [no] debug peer nome_utente

Attraverso quest’altro comando:

sip [no] debug ip indirizzo_ip

è invece possibile visualizzare sulla console i messaggi sip relativi ad uno specifico indirizzo IP. Questo è particolarmente utile nel caso in cui l’utente, di cui si desidera visualizzare i messaggi, non sia registrato e non appartenga al file sip.conf.

2.2

Esempio di configurazione per chiamare con Asterisk

Prima di vedere come si configurano i file per poter effettuare una chiamata con Asterisk usando il protocollo SIP, definiamo come Asterisk gestisce una chiamata.

Ogni chiamata viene originata da differenti “canali”, supponiamo SIP nel nostro esempio, ed è destinata verso un numero composto dall’utente chiamante.

Il processo Asterisk inizia prima a trattare la chiamata in funzione del canale

da cui arriva e decide quindi, in base ad esso, come gestirla ed in quale “contesto” inviarla, basandosi sulle informazioni contenute nel file “extensions.conf”.

Il file extension.conf è suddiviso in contesti, che non sono altro che dei gruppi di estensioni ad ognuna delle quali è associata una o più applicazioni. La caratteristica particolare è che un utente appartenente ad un contesto non può chiamare (a meno che non venga configurato in modo particolare) un utente di un altro contesto.

Attraverso il seguente esempio si può capire meglio l’utilità del contesto:

Figura 2.2 Esempio per capire il concetto si contesto

I due switch possono paragonarsi a due contesti e permettono di far parlare fra loro solo i telefoni connessi al solito switch; nulla vieta di poter collegare fra di loro i due switch così che i quattro telefoni possano dialogare l’uno con l’altro.

La suddivisione in contesti potrebbe sembrare inutile; in realtà essa è una caratteristica molto importante di Asterisk. Vediamo un esempio pratico: supponiamo di avere dei figli ognuno dei quali ha un telefono nella propria camera. Il padre vuole abilitare per i figli le chiamate verso gli amici ma non vuole che ad essi sia concesso di chiamare lo 0900 che è il numero per accedere ai propri servizi bancari. Per risolvere il problema configurerà il

(6)

file extensions.conf nel seguente modo: [figli] exten=> _0[1 -8].,1,Dial(ZAP/g1/${EXTEN} exten=>i,1,Congestion [padre] exten => _0.,1,Dial(ZAP/g1/${EXTEN}

Sono stati creati due contesti (figli e padre). Ai figli è concesso di telefonare a tutti quei numeri che iniziano con lo 0 e che come seconda cifra hanno un numero che va da 1 a 8; in caso contrario troveranno occupato. Il padre può invece telefonare a qualsiasi numero che inizi con lo 0.

Nell’esempio che è illustrato sotto definiamo un contesto “Esempio” All’arrivo dell’invite di una chiamata Asterisk, riconosciuto il canale di provenienza, verifica che il campo from di tale pacchetto corrisponda ad una delle estensioni presenti nel file extensions.conf.

Ogni contesto è caratterizzato da un set di verifiche sulle estensioni che determinano quali applicazioni devono essere eseguite e come deve essere instradata la chiamata.

La verifica è eseguita basandosi sulla priorità, un parametro numerico presente in ogni comando, svolgendo gli statement a seconda del suo valore. Saranno eseguiti prima i comandi a priorità più bassa e successivamente quelli con priorità maggiore.

Ogni linea del file extensions.conf è scritta nella seguente forma:

exten => estensione, priorità, applicazione

Per avere un’idea più precisa di come funziona il sistema supponiamo che una chiamata SIP sia realizzata dall’interno 200 verso l’interno 201. Utilizzando il file di esempio sip.conf illustrato nel seguito, si può notare che queste due estensioni appartengono al contesto “Esempio”. Una volta capito il contesto in cui lavorare, viene effettuato il confronto tra il numero chiamato e le varie estensione appartenenti a tale contesto (questo avviene attraverso l’analisi del file extensions.conf). Ovviamente il risultato sarà negativo quando il confronto viene fatto con il 200, quindi si procederà con lo statement successivo che effettua il confronto con “201”. Questa verifica offrirà un match positivo! A questo punto l’applicazione con priorità “1”, cioè Dial, sarà eseguita.

Come abbiamo visto, una volta che il matching con una estensione fornisce esito positivo, il programma esegue le applicazioni associate. Asterisk mette già a disposizione una serie di applicazioni L’applicazione standard più nota è chiamata “Dial”; essa consente di inviare la segnalazione di chiamata (lo squillo) e successivamente mette in comunicazione il canale chiamante con quello chiamato, nel caso che quest’ultimo abbia risposto.

Di seguito sono mostrate le configurazioni dei file sip.conf ed extensions.conf per far comunicare fra loro l’utente 200 con il 201:

sip.conf

[general]

port = 5060 ; Imposta la porta UDP sulla quale Astrerisk è in ascolto per i

messaggi SIP

bindaddr = 0.0.0.0 ; Indirizzi di provenienza accettati (in tal caso tutti) [200]

type=friend ; Questo utente può inviare e ricevere chiamate username=200 ; Username

(7)

secret=pwd ; Password

host=dynamic ; Permette la registrazione del client da IP che possono

cambiare (dinamici)

context=Esempio ; contesto dove finiranno le chiamate da questo client [201] type=friend username=201 secret=password host=dynamic context=Esempio

extensions.conf

[general]

static=yes ; Preveniamo la possibilità di sovrascrivere il file di

configurazione

writeprotect=yes

[Esempio] ; è il nome del contesto

exten => 200,1,Dial(SIP/200) ;Se il numero composto dal chiamante è

"200", allora viene contattato il "200" (configurato nel file sip.conf) tramite il canale SIP.

exten => 201,1,Dial(SIP/201)

2.3

Architettura di Asterisk

L'intento degli sviluppatori di Asterisk era quello di creare un centralino in grado di interfacciarsi con qualsiasi dispositivo hardware o software per cui fosse realizzata una opportuna interfaccia. Risulta immediato pensare che tale compatibilità non può essere ottenuta se non progettando il sistema con una architettura modulare, con parti ben definite ed indipendenti. Una struttura di questo tipo permette infatti di aggiungere funzionalità o eliminarne senza compromettere la stabilità del sistema. Non è infatti

necessario per ogni installazione di un sistema Asterisk utilizzare tutte le applicazioni ed i canali di comunicazione disponibili, che in molti casi risultano superflui. Allo stesso tempo è possibile per gli sviluppatori testare il singolo modulo di cui si stanno occupando, creando versioni di sviluppo a partire da un core stabile.

La scelta di una struttura monolitica avrebbe reso il progetto molto più difficile da gestire e ne avrebbe ridotto notevolmente la flessibilità.

Oltre ai nuovi moduli, esiste un componente core sempre presente e stabile che gestisce le funzionalità di base comuni ai nuovi processi. Questa scelt a consente maggiori garanzie in termini di prestazioni e stabilità.

Tali funzionalità vengono implementate dai seguenti moduli:

§ Gestore delle chiamate (PBX Switching Core): a prescindere dal tipo di canale, deve essere possibile instaurare una comunicazio ne tra le “due parti” di una chiamata. Tale funzionalità viene gestita dal core di Asterisk che astrae dalla gestione dei protocolli per la comunicazione con i vari dispositivi ma gestisce solo i flussi di dati per garantire la comunicazione.

§ Gestore applicazioni (Application Luncher): una volta aperto un canale di comunicazione è possibile metterlo in collegamento con un altro canale o in alternativa lanciare un’applicazione (come la

voicemail, il file playback…) che agisce su di esso. I compiti di

questo tipo sono svolti dall’Application Launcher.

§ Traduttore di codec: al core di Asterisk spetta anche il compito di effettuare la traduzione di differenti codec audio. La gestione dei codec da parte di Asterisk è infatti centralizzata. Per fare ciò il core

(8)

di Asterisk sfrutta moduli esterni, ognuno in grado di gestire una codifica differente.

§ Gestore dell'input/output e della schedulazione: allo stesso tempo tutte le varie operazioni che il centralino svolge devono essere sincronizzate e schedulate in maniera efficiente sotto qualsiasi condizione di carico. Tale compito è affidato a questo gestore.

§ Dynamic Module Loader: si occupa della gestione dei moduli, che è dinamica. I vari moduli possono essere caricati a seconda delle esigenze e delle configurazioni.

Per interagire con il core di Asterisk esistono quattro diverse categorie di moduli che formano delle API (Application Programming Interface) ben definite. Queste categorie di moduli permettono al core di ignorare dettagli come i codec utilizzati e il tipo di tecnologia da cui il chiamante si connette.

Le quattro API sono le seguenti:

Ø API dei canali: gestiscono la tecnologia su cui sta avvenendo la chiamata a seconda del tipo: ISDN, E1, T1, VoIP o altra tecnologia. Ø API delle applicazioni : API a cui tutti i moduli che gestiscono un

applicazione devono attenersi. Ciascuno di questi moduli viene lanciato da questo gestore delle applicazioni.

Ø API dei codec: carica i vari moduli dei codec per poter supportare

diversi formati di codifica e decodifica come GSM, Mu-Law,

A-Law e anche MP3. Per gestire ogni singolo codec deve essere creato un modulo che si adatta a questa interfaccia.

GSM G.723 Mu-Law Linear A-Law ADPCM MP3 GSM G.723 Mu-Law Linear A-Law ADPCM MP3 G.723 GSM WAV MP3 AU G.723 GSM WAV MP3 AU PBX Switching Core Application Launcher Codec Translator Dynamic Module Loader Scheduler and I/O Manager

Asterisk Application API

Asterisk Channel API

Codec Translator

API

Asterisk

File Format

Adtran VoFR ISDN VoiceModem CustomHardware

Adtran VoFR ISDN VoiceModem CustomHardware CustomApplication Voicemail Paging Conferencing Directory

Calling Cards Dialing CustomApplication Voicemail Paging Conferencing Directory

Calling Cards Dialing

GSM G.723 Mu-Law Linear A-Law ADPCM MP3 GSM G.723 Mu-Law Linear A-Law ADPCM MP3 G.723 GSM WAV MP3 AU G.723 GSM WAV MP3 AU PBX Switching Core Application Launcher Codec Translator Dynamic Module Loader Scheduler and I/O Manager

Asterisk Application API

Asterisk Channel API

Codec Translator

API

Asterisk

File Format

Adtran VoFR ISDN VoiceModem CustomHardware

Adtran VoFR ISDN VoiceModem CustomHardware CustomApplication Voicemail Paging Conferencing Directory

Calling Cards Dialing CustomApplication Voicemail Paging Conferencing Directory

Calling Cards Dialing

Ø API per i formati di file: gestiscono la lettura e la scrittura di numerosi formati di file sul filesystem.

Figura 2.3 Architettura di Asterisk

Il Core di Asterisk contiene diversi blocchi che svolgono dei ruoli critici per il corretto funzionamento del software. Quando Asterisk è lanciato per la prima volta il Dynamic Module Loader carica i driver necessari per attivare i canali, i codec, le applicazione e altro, collegando questi alle opportune API. Poi, il PBX Switching Core inizia ad accettare le chiamate provenienti dalle viarie interfacce e le gestisce in base a quanto definito nel dialplan, sfruttando l’Application Launcher per far squillare il telefono, per collegare un utente alla segreteria telefonica, per inoltrare una chiamata verso un trunk

(9)

esterno e altre. Il Codec Translator permette a canali che utilizzano codec differenti di poter comunicare fra loro; effettua quella che viene definita

transcodifica. L'utilizzo di questa architettura a due livelli permette agli

sviluppatori di aggiungere nuove funzionalità ad Asterisk, creando o modificando moduli, che si adattano ad una delle quattro API.

Questo permette ad Asterisk di funzionare da gateway per qualsiasi nuova tecnologia di trasmissione dati, fruire della gestione di un codec per tutte le tecnologie che lo utilizzano o sfruttare un’applicazione per ogni dispositivo ad esso collegato.

Di base Asterisk agisce come una soluzione di middleware tra le tecnologie telefoniche (es. protocolli ISDN , linee analogiche, protocolli SIP, H.323, etc…) e le applicazioni telefoniche, video o altro (es. voicemail, IVR, musiche di attesa, gestione di code, etc…).

L'utilizzo di moduli caricabili dinamicamente permette ad Asterisk di gestire sia codec estremamente compatti, necessari per effettuare una comunicazione VoIP su una connessione con poca banda, sia codec meno compressi per garantire una migliore qualità per quegli utenti che hanno maggiore disponibilità di banda.

La gestione dell’applicazione risulta a sua volta molto semplificata perché queste possono essere rimosse e aggiunte per offrire nuove soluzioni per la gestione delle chiamate.

Figura

Figura 2.1   Console di Asterisk
Figura 2.2   Esempio per capire il concetto si contesto
Figura 2.3    Architettura di Asterisk

Riferimenti

Documenti correlati

Journalistic accounts have explained the relative success of the Chinese community in protecting itself from the virus as due to the process of “double quarantine” both before

The interviewees are Palestinian women teachers, citizens of Israel, from various social settings (i.e. mixed Jewish Arab cities, multi-religious Arab villages, exclusively

publisher or speaker of any information provided by another information content provider.’ This protects ISPs from defamation charges based on information

1) Slow Food was born in Italy but the association looks at the world-wide level. Do you think that the generally shared Italian image may influence in a positive or negative way

follow Porter’s approach. First of all, the above mentioned model, unlike Porter’s, does consider upstream and downstream links as integrant steps/parts of the value

Prima di scegliere la vena da incannulare, è opportuno esaminare con l’ecografo – bilateralmente – le vene profonde del braccio (basilica, brachiali) e del collo

 Per leggere dati da un file presente sul disco, Per leggere dati da un file presente sul disco, occorre dapprima costruire un oggetto di tipo occorre dapprima costruire un

 La directory contiene il numero del primo blocco di ogni file sul disco.  I blocchi successivi vengono cercati