[asterisk-dev] Re: TDMoE protocol

[Paul Cadach]

Hello,

James Harper wrote:
[skipped]
> > 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?

See my previous mail - 2 ms fixed delay is the maximum required by TDMoE (to hold "very fast" packet and to pick a
packet when one is late).

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

TDMoE could work as its own timing source (not so exact as E1 but for +/- some microseconds). Timing of non-synchronized
part is not needed to be exact, the problems comes when packets from this part is received by externally synchronized
(from E1, for example) peer.

The timing scheme is next:
       BOX1[E1(master)->TDMoE(slave)]->network->BOX2[TDMoE(master)]
TDMoE(master) is perform as timing source for BOX2, but because it's not so preciese as E1/T1 timing) packets being
transmitted from BOX2 to BOX1 will have some sort of very little jitter (about some microseconds). But because BOX1 have
externally synchronized timing source (E1 stream), there is possible for "late" or "early" conditions of TDMoE packets
received by BOX1, so constant delay jitter buffer is required. Be noted about BOX1 and BOX2 are still SYNCHRONIZED but
jitter introduced by networking and processing delays at BOX2 should be eliminated.

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

Zaptel could have only ONE,. SINGLE timing source. For BOX2 in scheme shown above timing source is TDMoE stream coming
from externally synchronyzed BOX1, so dummy timing source isn't required until something is being to fail (especially
network connection between BOX1 and BOX2).

ztdummy is required for BOX2 as "last resort" timing source to handle missing timing from TDMoE and make system works
without external timing (TDMoE link brought into RED ALARM condition). ztdummy is more-or-less accurate withing its own
time domain, so it's not a big problem to switch to different timing source while main source is out of work.

Be noted ztdummy isn't requires for BOX1 just because E1/T1 card have internal timing circuit which will generate timing
even without E1/T1 connections, but accuracy of this timing will be much more bad than when T1/E1 connections from
synchronized source are presented.


TDM clocking rules is very easy:
1) timing source within a system should be single;
2) two boxes on the same TDM connection should be synchronized from the same timing source;
3) when main timing source is get failed system should switch to any sort of internal timing or to elect another
external timing source.


WBR,
Paul.