asterisk users - Oct 2003 - Number of TDMoE Channels?

I was trying to establish a TDMoE span of 4 channels between two Asterisk
servers.  Machine A has a T100P to our PBX.  Machine B has no Zaptel
hardware.  With 4 channels (e&m signalling) the red alarm never clears, and
eventually machine A panics.  With 24 channels, the TDMoE span seems to work
perfectly.  Is this hardcoded somewhere?  I don't really need a full 1.544
Mbps between my two boxes.  4 channels would be just about right for my
needs.  Actually, 3B+1D with PRI signalling would be perfect, but that
didn't work either...

I saw this message with the 4 channel configuration, but not with 24.  Is
this something to be concerned about?
Span ZTD/eth/eth0/00:06:5B:F1:54:EE: Expected message size 40, but was 44
instead 

Thanks,
Randy Johnson

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://lists.digium.com/pipermail/asterisk-users/attachments/20031023/276c8061/attachment.htm

On Thu, 2003-10-23 at 13:34, Johnson, Randy wrote:
> I was trying to establish a TDMoE span of 4 channels between two
> Asterisk servers.  Machine A has a T100P to our PBX.  Machine B has no
> Zaptel hardware.  With 4 channels (e&m signalling) the red alarm never
> clears, and eventually machine A panics.  With 24 channels, the TDMoE
> span seems to work perfectly.  Is this hardcoded somewhere?  I don't
> really need a full 1.544 Mbps between my two boxes.  4 channels would
> be just about right for my needs.  Actually, 3B+1D with PRI signalling
> would be perfect, but that didn't work either...
> 
> I saw this message with the 4 channel configuration, but not with 24. 
> Is this something to be concerned about?
> Span ZTD/eth/eth0/00:06:5B:F1:54:EE: Expected message size 40, but was
> 44 instead 

Use IAX or IAX2. TDMoE tries to be a T1 over ethernet, and all the bad
of circuit switched systems bite you in the ass. If you want to expand
the system, you have to restart it and it uses all that bandwidth all of
the time instead of just when it is needed.

-- 
Steven Critchfield  <critch@basesys.com>