VoIP and Hacking | Consulenza Documentazione

TDMoE (Time Division Multiplexing over Ethernet) rientra nella categoria più generale della tecnologia CES (Circuit Emulation Services), la quale, come indica il suo nome, permette il trasporto di circuiti sincroni come T1/E1 su network asincroni. Originariamente sviluppata per permettere la costruzione di E1/T1 su ATM, può essere estesa ad operare su networks Ethernet.

Si tratta di una tecnologia estremamente interessante per flessibilità costi ridotti e risparmi sul conto telefonico, mi riferisco ad esempio al caso di aziende con sedi e distaccamenti, in una area di tipo campus od anche metropolitana, che spesso possiedono già una lan allargata.

Queste stesse aziende potrebbero benissimo azzerare il costo del traffico telefonico fra sedi e dipartimenti distaccati ed anche scalare il numero delle postazioni telefoniche aziendali, senza dover migrare necessariamente al VoIP.

Un altro dato di fatto è la notevole economicità dell’hardware ethernet rapportato a quello de tradizionale hardware TDM. La prossima (si spera) disponibilità di operatori in grado di fornire connettività metro-ethernet, fa ben sperare in questa direzione.

Tutto cio naturalmente con Asterisk.

Caratteristiche del TDMOE

TDMoE è un modo di creare un flusso “artificiale” di tipo zaptel (come un T1 o E1) sopra Ethernet invece che sopra i convenzionali media T1 o E1.

TDMoE è particolarmente adatto a situazioni in cui si voglia ottenere la tradizionale affidabilit�TDM senza il tradizionale hardware TDM.

Le reti a pacchetto possono trasferire dati in maniera molto flessibile, e ciè vale anche per la fonia, ma introducono alcune classiche problematiche:

• I pacchettti possono giungere fuori ordine.
• Viene dedicato agli headers pi spazio a discapito del payload
• Non vi è garanzia di consegna.

TDM divide anch’esso i dati in tronconi (chunks), ma essi vengono delimitati solamente da un header molto sottile(realmente presente per marcare l’inizio dei pacchetti packets) e quindi i dati relatvi ai vari channels vengono concatenati in uno specifico ordine.
Ciò viene definito TDM, a causa del fatto che i channels sono differenziati non da alcuni header bits, ma dal momento in cui attraversano il cavo (cioè il segnale viene multiplexato dividendolo in incrementi di tempo).

Come precedentemente accennato, il modo piu semplice di rappresentare un possibile utilizzo di esso consiste nell’immaginare uno scenario che preveda di connettere due PBX dipartimentali. Non è sicuramente conveniente che si chiamino l’un l’altro tramite linee esterne.
Una soluzione di tipo tradizionale potrebbe consistere nel collegarli attraverso un flusso E1. TDMoE emula un E1, ma incapsula i dati codificati E1 all’interno di un frame Ethernet.
Ciò puo avvenire semplicemente agganciandoli allo stesso switch, oppure a switch diversi collegati tra loro che siano in grado di operare come punti terminali di una EVC (Ethernet Virtual Connection).

Una EVC, in sintesi ha due funzioni:

• Connette due o più punti terminali permettendo il trasferimento di frames ethernet tra di loro.
• Impedisce il trasferimento tra punti terminali che non appartengano ad una stessa EVC.

I frames devono essere inoltrati con l’indirizzo MAC Ethernet e i contenuti del frame invariati (in pratica l’ethernet frame deve rimanere intatto da sorgente a destinazione).
Ciò in contrasto con il modello di una tipica network basata sull’ instradamento, dove gli headers dei frame Ethernet vengono semplicemente rimossi e scartati.

Per inciso, in base a tali caratteristiche, una EVC può venire utilizzata per allestire una Virtual Private network oppure una Virtual Private Line di Livello 2.

Comunque, una volta che il link TDMoE sia attivo, Asterisk vede 30-linee che appaiono come una flusso E1.

Se in passato per usare TDMoE occorreva la presenza di una interfaccia zaptel fisica configurata da qualche parte im rete, ora si può usare qualche altra fonte di sincronizzazione, ad esempio il driver ztdummy, che utilizza l’internal timer ad alta-risoluzione del kernel e non necessita di nessun hardware addizionale. ztdummy è un kernel module caricabile col comando modprobe.

La configurazione per definire uno span dinamico (TDMoX) richiede di base quattro parametri /in /etc/zaptel.conf).

1. Dapprima viene definito il driver
2. Poi il nic mac address REMOTO
3. Terzo, viene il numero di channels da configurare
4. E infine, che tipo di temporizzazione fornire (0, nessuna, 1 per primaria, 2 per secondaria)

• Il driver è generalmente “eth” dal momento che non è ancora disponibile qualche altro driver TDMoX.
• L’indirizzo è //subaddr: Il sub address è opzionale, e permette di definire pi di uno span su una singola accoppiata interfaccia / macaddress

Con una simile configurazione si ottiene un nuovo span, simile a quelli configurati per le cards E/Tx00P cards. L’accesso ai channels configurati precedentemente avviene tramite /etc/zaptel.conf ed /etc/asterisk/zapata.conf.

E’ possibile configurare il signalling e tutto il resto come se si trattasse di reali T1 o E1,

Non vi è invece bisogno di configurare alcuna specifica direttiva tipo span=etc,etc in zaptel.conf.

Si ricordi che TDMoE opera al livello ethernet, e che tutto ciè che occorre configurare sono i MAC addresses e le interfaccie ethernet.

ESEMPIO

Nel caso in cui si voglia collegare due BPX Asterisk tramite TDMoE, e ammettendo che:

• Per comodità il primo si chiami Pippo ed il secondo Pluto
• Sia Pippo che Pluto siano dotati solamente di una ethernet card ciascuno.

questo potrebbe essere il file zaptel.conf di Pippo:

 dynamic=eth,eth0/00:D0:B7:89:E3:86,30,0 # mac di Pluto
 e&m=1-30 # un tipo qualsiasi di signalling

mentre questo lo zaptel.conf di Pluto:

 dynamic=eth,eth0/00:50:FC:65:33:A1,30,1
 e&m=1-30 # identico signalling

questo invece il zapata.conf di Pippo

 signalling=em
 channel=>1-30

e questo il zapata.conf di Pluto

 signalling=em
 channel=>1-30

Una volta caricati gli appropriati moduli…..

 root@pippo]# modprobe ztdummy (deve provocare anche il caricamento di zaptel)

…e impartito ztcfg su Pippo, si dovrebbe ottenere il seguente insieme di moduli carivayi, RED negli alarms…. ed un dynamic span configurato (non attivo, ma configurato).

 root@pippo]:/# lsmod
 Module                  Size  Used by
 ztd_eth                 5380  0
 ztdynamic               8604  1 ztd_eth
 ztdummy                 2756  0
 zaptel                217540  2 ztdynamic,ztdummy
 crc_ccitt               1536  1 zaptel

 root@pippo]:/# ztcfg -v

Zaptel Configuration
======================

Dynamic span 1: driver eth, addr eth1/00:40:D0:40:33:FC, channels 30, timing 0

30 channels configured.

Operando alla stessa maniera su Pluto, gli alarms dovrebbero rientrare, e gli zap channels relativi essere disponibili all’uso, come testimoniato dalla seguente videata da Asterisk WEB Manager e relativa al channel 10 (a caso).