[asterisk-dev] Re: TDMoE protocol

[Tony Mountifield]

In article <AEC6C66638C05B468B556EA548C1A77DAF09AC at trantor>,
James Harper <james.harper at bendigoit.com.au> wrote:
> > 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.
>  */

Yes, that's the bit in ztdynamic.c that I was referring to.

> 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'

At the moment it's always 8. The receiver checks that this byte contains
8, and flags an error if it doesn't. But the packet format allows this
to change in the future.

> . 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?

The packet format is not ethernet specific. If running over Ethernet,
then yes, you are restricted to about 174 channels per span.

> . Is the data just exactly as it would come in from the interface?

Yes, the ethernet header is stripped off by the layer below.

> . 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.

No, just like there isn't on a real E1 or T1. You just make sure both
ends are set up compatibly.

I didn't have much success trying to run pri_cpe or pri_net, since they
put HDLC data in a channel, which is too susceptible to lost packets.
Best to stick with a simple CAS or Robbed Bit signalling protocol.

> . Maybe related to the above, what do the 4 'sig' bits per channel do?

I believe these are used to store the Robbed Bit signalling.

> 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...

Hope the above helps.

> . What about for a BRI (2B+D) where the B channels are 64kbps and the D
> channel is 16kbps?

No idea, sorry.

> An rfc would have been really really nice!

Come on, this IS Asterisk! (Well, zaptel actually). UTSL :-)

Cheers
Tony
-- 
Tony Mountifield
Work: tony at softins.co.uk - http://www.softins.co.uk
Play: tony at mountifield.org - http://tony.mountifield.org