[Asterisk-Users] Problems with ADIT 600 - latency, loss, etc

[Steven Critchfield]

On Wed, 2004-04-07 at 17:46, Ralph Forsythe wrote:
> I'm emailing this as the customer in this case, since my carrier appears
> to be completely unable to solve this.  A brief rundown of the problem:
> - We have several voice lines going through the ADIT, of course into a
> VoIP type of arrangement.
> - Voice traffic will become choppy, even drop calls completely, at random
> but quite often.  Modem calls (which we needed unfortunately) are a joke.
> - Packet latency on the data side will be fine one minute, then high the
> next.  As I type this email through an ssh session into my server there, I
> hit keys and wait for them to appear.  This is odd for a T1 in my opinion.

You didn't do a very good job of describing your setup. Do you have
normal voice lines coming in and then going to VoIP, as in the ADIT is
providing analog to digital conversion for you to then plug into an
asterisk machine, or are you running the routing section of the ADIT and
using a data T1 for your VoIP?

Either way, don't _expect_ a modem to work with VoIP in the mix.

> Now, the carrier has replaced the hardware (breaking it twice in the
> process, leaving me to wonder how much of this they understand) and
> installed the latest hardware revision supposedly.  They are claiming that
> high data usage is causing the voice issue.  I don't buy it, and here's
> why:
> - The ADIT is designed to handle both and prioritize voice over data.
> This therefore has to use the assumption that no matter what, data will
> attempt to run at full speed, and the ADIT will throttle it back as
> necessary.  The carrier claims that using data at high speed will overload
> the CPU causing dropped calls.  Computers connect at 100mbit ethernet -
> unsure what he wants me to do here.  I call BS on this one, and in fact
> did, with silence as the response.

Last I checked, the router in the ADIT doesn't do any prioritizing. It
assigns x channels to the router and lets it deal with the conversion to
ethernet. Any left over channels are configured to be voice lines that
are standard 56 or 64kbit sections of time. No overlap at all. Since
there isn't an overlap, the data section couldn't affect a voice
channel. IF you are using a VoIP out the data line, then that may very
well be your problem.

> - I have enabled packet queueing in my firewall, with a max outbound
> badnwidth of the T1 speed.  This enables me to also monitor my realtime
> usage in 5 second polls.  While pushing out around 300kbit (on a T1), the
> voice call I was on was choppy, and I had packet latency.  1.5Mbit or
> 300kbit seems to yield the same results.

If this is VoIP only T1, then thats fine. But if it shares channels with
voice, then you don't get a full T1 of data.

> - It happens consistently, even in low-usage times.  My websites are dead
> at midnight, but phone calls still suck.

I'm assuming there may be a route this call takes via VoIP that runs
across sub par routers. This could be the problem.

> I have suggested a check of the physical line.  The technicians coming out
> only seem to be able to console into the ADIT and break it, and apparently
> our idea that a simple BER test on the line might enlighten them has not
> been welcomed.  Am I off-base here?  Is there some setting or other check
> that can be done in the ADIT?  I'd like to see the physical T1 validated
> but am becoming increasingly concerned that no one at this company knows
> how to do it (I'm hoping I don't need to bring in a Tberd and have them
> loop it, so I can do their job for them).
> 
> I found something on here about the T1 slipping and/or getting bipolar
> violations.  What else can I have these guys check?

In those cases you will experience alarms on the ADIT. You should check
and see if you see it go into error mode. Or one of those times you have
the telco guy out, ask him to see the statistics the machine provides
since it will tell you how long it spent in certain error modes. If it
doesn't show any errors, I would say your problem lies elsewhere. 
-- 
Steven Critchfield  <critch at basesys.com>