asterisk users - Jun 2004 - Module nonsense (zaptel, wcfxs and wxfxo)

Hello!

I've been playing with two pieces of hardware:  a X100P and a TDM400P with 
an FXO and two FXS modules.  I had been using just the TDM card;  however, 
the TDM FXO module seems to hear things and "answer" the telephone for
no
reason, and I wanted to compare the results with an X100P card.

If you want further details, I can give them to you, but suffice it to say 
that trying to work with both cards and both modules has been incredibly 
frustrating.  Modules that won't load, or that load but don't work when 
you run Asterisk, or Asterisk segfaulting even though the modules *seem* 
to load properly...

Am I the only person who finds the combination of seeminly awkward 
separation between modules, duplicated information (between zaptel.conf 
and zapata.conf), strange interactions and limitations between different 
modules for what would seem to be very similar hardware?  This is not a 
rhetorical question, nor is it a shot at the developers.  I'm really 
asking two things:  am I alone in this?  Or are my expectations too high?

I would be thrilled to give you whatever information you might desire if 
you're interested in seeing what I'm talking about.  I'm using a 
dirt-simple configuration:  basically four-line configuration files, just 
the minimum necessary to make the hardware work.  Even these 
configurations cause a dizzying variety of issues...

Again, I'm not trying to blast anyone.  I just wonder what I can do to 
improve my success!  :)  Mostly, I would like to hear how others are 
fairing, particularly with a variety of analog devices.  Am I alone?

Thank you,

Tim Massey
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://lists.digium.com/pipermail/asterisk-users/attachments/20040607/82b36d78/attachment.htm

> I've been playing with two pieces of hardware:  a X100P and a TDM400P
with an
> FXO and two FXS modules.  I had been using just the TDM
> card;  however, the TDM FXO module seems to hear things and
"answer" the
> telephone for no reason, and I wanted to compare the results
> with an X100P card.
Yes, same issue here. I'm not a programmer, so my comments are based on 
observations only. For whatever reason, the TDM card is far more sensitive
to analog line activities then was the x100p. Simply taking a bridged analog
phone off hook and back on hook causes the TDM card to assume the phone is
ringing. Also, female voices on the analog side tend to be interpreted
as ringing as well (that's with callprogress=no).
> If you want further details, I can give them to you, but suffice it to say 
> that trying to work with both cards and both modules has been
> incredibly frustrating.  Modules that won't load, or that load but
don't
> work when you run Asterisk, or Asterisk segfaulting even though the
> modules *seem* to load properly...
Observed the same here on RH v9. System has been mostly stable for over six
months in terms of processing calls, but doing 'service zaptel stop' and
start (after stopping *) leads to unpredictable results. Usually can get 
by with one or two, but anything after that leads to failures that 
require a system reboot. The exact number varies.

Other observations tend to suggest echo cancellation is not any better 
on the TDM compared to the x100p, and the amount of echo seems to change
from time to time with no noticable correlation to other system events.
CallerID on the TDM seems to be less reliable then the x100p (more ID's
showing up as 'asterisk' when a bridged analog phone receives the
ID's
just fine).

I'm using three pstn lines from two different central offices and two
different ring cadences. Inbound and outbound calls are processed correctly,
and echo (and other unusual * activities) is the same across all three 
lines. (The TDM card runs on a dedicated interrupt, and CVS-HEAD-05/28/04.)

Unplugging a pstn line from the TDM card (and reconnecting) creates some
rather unusual events too.

Guess its time to open a bug report even though we don't have any
significant
technical data that would help debug the problems.

Rich