[asterisk-dev] Re: TDMoE protocol

[Tony Mountifield]

In article <AEC6C66638C05B468B556EA548C1A77DAF09E2 at trantor>,
James Harper <james.harper at bendigoit.com.au> wrote:
> 
> > Paul Cadach mentioned something about a jitter buffer for TDMoE, but
> > I don't know whether he was talking about an idea or some real code.
> > 
> > I'm also thinking about a jitter buffer, but it's tricky. I might
> > decide to combine ztdummy with ztdynamic/ztd_eth in order to make the
> > timing independent of incoming packets or other zaptel devices. The
> > jitter buffer only needs to be 1ms or 2ms in length.
> 
> A jitter buffer adds delay though right? I guess 2ms fixed delay
> shouldn't cause a problem, but how would it work if tdmoe is your only
> source of timing? Is the 2.6 version of ztdummy widely held to be
> precise enough for our use?

As the one who added 2.6 RTC support to ztdummy, I'm qualified to comment!
The primary reason for ztdummy is to support SIP, IAX and MeetMe in a
system with no Zaptel cards. It is quite adequate for that, although
there is a patch on the bugtracker that aims to address a perceived
weakness in it.

However, I don't think ztdummy as it stands is quite accurate enough
for governing TDMoE, because it doesn't maintain a 1ms spacing. Since
the RTC can only do power-of-2 subdivisions of a second, it is set to
1/1024 sec (0.9765625ms), but then 3 interrupts out of every 128 are
skipped (evenly spaced) to give an average of 1000 per second. This
is ok for VoIP with a 20ms or 30ms frame size, but not for TDMoE with
a packet every 1ms. I would probably try making ztdummy use 4096 RTC
interrupts per second and skip 3096 of them. This would make the
interval between two consecutive packets either 0.9765625ms or
1.220703125ms.

> Assuming the source of TDMoE is an E1 line with exact timing, would
> there be value in using a statistical analysis of TDMoE data to correct
> ztdummy? Eg with x packets received from TDMoE over y time (for large
> enough values of y, and accounting for any dropped packets), it should
> be possible to compute the correct number of ztdummy ticks. If there is
> a variation compared to the actually number of ztdummy ticks, then add a
> fudge factor. Or maybe ztdummy drift isn't constant...

I personally don't think there's any value in this.

> If you ever get a spare moment, could you write some brief documentation
> on the flow of data from ethernet into zaptel and from zaptel out to the
> ethernet? Failing that, if I were to look through the code and write
> some doco, could you look at it and tell me where I messed up?

Realistically speaking, the latter is much more likely to happen than
the former, at least for the forseeable future!

> I'll add it to the wiki for posterity if the end result is useful to
> anyone else.

That would be good.

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