[asterisk-dev] Re: TDMoE protocol

[Tony Mountifield]

In article <AEC6C66638C05B468B556EA548C1A77DAF09BD at trantor>,
James Harper <james.harper at bendigoit.com.au> wrote:
> > > . 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.
> 
> Assuming no hardware issues, do you ever actually get lost packets on
> the lan? And if you were using pri_cpi and someone pulled the plug on
> the nic for a few seconds (eg not just 1 or 2 dropped packets), what
> would happen? How long would re-synchronisation take?

I think if the D-channel goes down, then the calls it was controlling
get dropped. But I'm not completely certain.

> Just to clarify, as I'm not sure I totally understand, if you had a
> E1<->TDMoE bridge, would the TDMoE packets contain exactly the same data
> as came out of the E1?

When I referred to "lost packets", I was meaning from the perspective of
the Zaptel layer. In the current TDMoE implementation, there is absolutely
no jitter buffer. Packets can come in on the Ethernet with jitter,
depending on what else is sharing the LAN and the NIC, but the zaptel
driver expects to access readchunk and writechunk exactly on 1ms intervals.
If a packet is late, then zaptel will see the previous chunk of data
again. If the subsequent packet is not late, then the previous late one
won't be seen by zaptel at all.

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.

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