TDMoE is for a situation where you need TDM reliability without traditional TDM hardware.
Most modern computer people naturally think of taking digital voice and dividing it into packets to be sent over a network. Telephony people didn't do it that way for a number of reasons (latency, virtual circuit guarantees, etc). Instead, they invented TDM (Time Division Multiplexing).
Network packets can transfer data very flexibly because each stream is broken into small chunks that each get sent with their own header describing their contents. Telephony people didn't like this because:
- Packets can be out of order
- More space for data is wasted by headers
- There is no guarantee that every channel will be sent reliably.
TDM still takes the digital data in chunks, but they are spaced out with a very tiny header (really only there to mark the beginning of the packets) and then the channels data is concatenated in a specific order. It's called TDM, because the channels are differentiated not by some header bits, but by when they come over the wire (that is, the signal is multiplexed by dividing up the signal in increments of time). This is roughly what happens on a T1. This seemed much more natural to them because it kept everything really simple and still preserved the idea of a circuit in that digital lines were still broken into a certain number of "channels" that can be "switched" much like a physical phone line. This was also done during an age before packet networks had proven themselves and its still useful today when a synchronous serial links needs to be cleanly divided in terms of usage.
TDMoE is useful because it allows the above familiarity, flexibility, and reliability of TDM but over inexpensive Ethernet instead of T1s or E1s.
The easiest way to picture its use is to envision the scenario of connecting two departmental PBXs. Often, in larger businesses, multiple PBXs are needed for different departments. It is not desirable to have them call each other via outside phone lines. With traditional equipment, someone might run a 25-pair trunk or T1 line between them. TDMoE emulates a T1, but wraps the T1-encoded data in a small header inside of an Ethernet frame. This permits just hooking them up to the same switch.
Note that this does NOT allow routing the data over the internet, it only functions on a single Ethernet segment.
Once the TDMoE link is up, Asterisk just sees 24-lines that appear to be a T1 instead of having to deal with all of the complexities of VoIP. This is useful, since probably 75% of the utility of VoIP is really just the fact that it can run over a network. It's also handy because it unifies the flexibility and cost-savings of a Ethernet with the telephony-friendly aspects of a T1 (alarm codes, bundling trunks, channelization).
TDMoE Mini-HOWTOJanuary 16, 2002 - <firstname.lastname@example.org>
For those of us wishing to explore Asterisk further, there is this little TDMoE thing, which Mark was kind enough to explain how to configure on the one condition that we write it up for future record...
To use TDMoE you MUST have a zaptel interface configured somewhere on the network. It can be any zaptel interface, doesn't have to be a E400P, an X100P will do. Why? Timing. Samples. Something like that. Just do it.
See Asterisk timer
The configuration to define a dynamic span (TDMoX) basically entails FOUR parameters. Look at the sample config from zaptel. Its got an example in it, ala:
- Next come the dynamic span definitions, in the form:
- Where <driver> is the name of the driver (e.g. eth), <address> is the
- driver specific address (like a MAC for eth), <numchans> is the number
- of channels, and <timing> is a timing priority, like for a normal span.
- use "0" to not use this as a timing source, or prioritize them as
- primary, secondard, etc. Note that you MUST have a REAL zaptel device
- if you are not using external timing.
- ) First you define the driver
- ) Second is the driver dependent address (REMOTE nic mac address)
- ) Third is the number of channels to be configured
- ) And, lastly, what sort of timing to provide
Timing Notes: 0 for no timing, 1 for primary, 2 for secondary, the difference is that it uses the primary to turn the zaptel gears unless it's in alarm, in which case it will take from the secondary and so on.
- The driver is generally "eth" since currently we don't have any other TDMoX drivers, although FireWire would be very very nice. [kram]
- The address is <eth interface>/<macaddress>[/subaddr]: The sub address is optional, and allows you to define more than one span on a single eth interface / macaddress pair
By configuring this, you end up with a new span, similar to the T1/E1 spans configured for the E/Tx00P cards. Access to the channels configured above is via /etc/zaptel.conf and /etc/asterisk/zapata.conf.
You can configure signalling and all just as though they were T1's or E1's, so you can run RBS or you can run PRI or whatever, they even generate RED and YELLOW alarm just like real T1's and E1's. We're still debating whether you can run ccs on it.
You do NOT need to configure a specific span=blah,blah in zaptel.conf for this, the dynamic span will take care of that for you.
Remember that TDMoE works at the ethernet layer, all you need to configure is MAC addresses and ethernet interfaces.... so in theory you could TDMoE over 802.11 (low-cost last mile) or cipe (encrypted PRI), the possibilites are limitless (well as limitless as csmacd can get)... IP does not come into play here at all...
SIMPLE 2 MINUTE EXAMPLE #105
so, if i have two * boxen running... lets say merry and pippin...
- merry has an X100P in it and a nic, pippin just has a nic
fxsls=1 # this be the FXO dynamic=eth,eth0/00:D0:B7:89:E3:86,30,0 # put the mac of pippin here e&m=2-31 # you can use ANY signalling
dynamic=eth,eth0/00:50:FC:65:33:A1,30,1 # note the timing "1", merry's mac e&m=1-30 # same signalling as merry
from this point on its like any of the friendly zaptel channels we're already used to....
load the appropriate modules, ztcfg on merry, zttool, you should have RED in the alarms.... and a dynamic span configured (not up, but configured)
do the same on pippin, bingo, the alarms should turn to OK, and you have the zap channels available for use....
[root@pippin ~]$ lsmod Module Size Used by Tainted: P ztd-eth 4032 0 (autoclean) (unused) ztdynamic 8544 30 (autoclean) [ztd-eth] zaptel 177088 60 [ztdynamic] ppp_generic 27392 0 [zaptel] slhc 6844 0 [ppp_generic]
This listing is with asterisk running, and zapata using the channels. If you got this far, you're good to go.
Enjoy... and mail any samples, suggestions, improvements... always welcome
Hail * !
Todo: multiple ethernet cards (local and remote), other signalling
examples, dummy eth driver to loopback test, caveats, benefits of TDMoE,
comparision of various signalling, cook dinner (Solo: Whos cooking dinner you or asterisk :P )
Written by wasim
Sample configs for setting up TDMoE between 2 servers without TDM hardware, using ztdummyI figured this working combo out while trying to do 4 x SPANS of T1 traffic between two Asterisk boxes. One was running Debian Sarge (2.6.8) and the other FC4 (2.6.11)
The key is to setup one box as timing source and load ztdummy and configure the other asterisk server as timing slave.
Sample configs follow;
Asterisk-One (with ztdummy)
Load zaptel modules and parse zaptel.conf in the following order;
- modprobe zaptel
- ztcfg (you may have to do this twice)
- load ztdummy
Asterisk-Two (no ztdummy)
Load only the following;
- modprobe zaptel
- ztcfg (you may have to do this twice)
All other configs in zaptel.conf/zapata.conf follow the normal rules as with regular TDM hardware.
TDMoE and Subaddress field to create multiple dynamic spansA little known option in TDMoE is the subaddress field which allows us to specify multiple spans just like TDM cards (ex. Quad T1/E1) and specify the number of channels for each:
Breakdown is as follows: dynamic=<driver>,<driver interface>,<mac address of opposite machine>/<sub address>,<numchans>,<timing>
This will create 4 spans listening on eth0 to destination mac address of 00:D0:B7:89:E3:86, 24 channels each with timing of 1,2,3,4 respectively.
Additionally, you may build on the above config with more spans by simply repeating the same pattern:
With this you have created the equivalent of 8 T1 spans.
Also, you should be able to use ztdummy as a timing device provided it is running on both boxes.
TDMoE is a solid/reliable mechanism for trunking Asterisk together or to emulate T1/E1 connectivity
Please update this page with new information, just login and click on the "Edit" or "Discussion" tab. Get a free login here: Register Thanks! - Find us on Google+