[asterisk-dev] Re: TDMoE protocol

[James Harper]

> Richard Lyman <pchammer at dynx.net> wrote:
> > James Harper wrote:
> >
> > >Is there an RFC or other technical documentation for the zaptel
TDMoE
> > >protocol anywhere?
> > >
> > http://www.dynx.net/ASTERISK/TDMOE/TDMoE-HOWTO
> >
> > is the only thing i've ever seen on the issue.,
> 
> The TDMoX message format is documented in the source file ztdynamic.c
> 
> When encapsulated in Ethernet frames, the protocol identifier 0xD00D
> is used, but that can be changed by altering this line in ztd-eth.c:
> 
> #define ETH_P_ZTDETH    0xd00d
> 
> Note that in their current form, the TDMoE drivers do not play well
> with 2.6 kernels. They do run under 2.4 kernels, but you still have
> to be careful of timing issues with some drivers.
> 
> (No, I'm not an expert - I'm still fighting with this stuff myself!)

This is the only thing that passes vaguely for documentation:

/*
 *  Dynamic spans implemented using TDM over X with standard message
 *  types.  Message format is as follows:
 *
 *         Byte #:          Meaning
 *         0                Number of samples per channel
 *         1                Current flags on span
 *                              Bit    0: Yellow Alarm
 *                              Bit    1: Sig bits present
 *                              Bits 2-7: reserved for future use
 *         2-3              16-bit counter value for detecting drops,
network byte order.
 *         4-5              Number of channels in the message, network
byte order
 *         6...             16-bit words, containing sig bits for each
 *                          four channels, least significant 4 bits
being
 *                          the least significant channel, network byte
order.
 *         the rest         data for each channel, all samples per
channel
                            before moving to the next.
 */

But maybe that's all I need to know.... except for these questions :)
. Is there always 8 bytes of sample data per channel per frame? I
thought this was the case but byte 0 = 'samples per channel'
. Assuming the above statement is true, 256 channels would be 2048
bytes, which is larger than a single Ethernet frame. So why two bytes
for # of channels? Maybe gigabit 'jumbo' frames? Or just general future
expansion?
. Is the data just exactly as it would come in from the interface?
. Is there any indication of actual signalling format in the protocol
(eg pri_net, pri_cpe)? The answer to the above question may obsolete
this one.
. Maybe related to the above, what do the 4 'sig' bits per channel do?
I'll check out the source but I'm not sure if I'll be able to make sense
if it without some more background knowledge...
. What about for a BRI (2B+D) where the B channels are 64kbps and the D
channel is 16kbps?

An rfc would have been really really nice!

Thanks

James