[asterisk-users] Phones cutting out.....again - PLEASE HELP!! !

[Colin Anderson]

>Also, when I connect to the server locally (the server is in the room
>next to me, in other words, and i have 1 Gbit of bandwidth all the way
>to the back of the server, I still get call dropouts.  

>However, this IS the only server (of 8 total, all in the same rack and
>connected to the telco via the same DS3) that is having the issue,
>which DOES point to it being the WAN, as that is our ONLY remote
>location.

So perhaps what you are seeing is two or more subtle issues with the same
symptom, so subjectively it looks like the *same* issue. 

1. Definitely try the remote IAX box to rule out bandwidth starvation.
2. Definitely try the ping test to rule out connectivity.
3. You have to figure out what the problem is with your big Asterisk box.
There should be no reason why you are getting dropouts on the local LAN.
What is the output of zttest? Is it good? Does zttool indicate IRQ misses?
If it's OK, then your hardware - T1 setup is good, so you have ruled out
your Asterisk box. It is also a worthwhile excercise to rule out the onboard
ethernet card in the Dell. In fact, whenever I do a new box, I automatically
disable the onboard LAN and replace it with an add-in 3com or Intel. It is
also a worthwhile excercise to user setpci to change the latency of the
cards in the Dell so that your Zap boards can grab the bus as much as
possible. 
4. The thing that is common in all scenarios is the EyeBeam client itself.
Any soft phone is subject to the strengths and weaknesses of the audio
chipset in the PC, with issues to consider like latency, audio threshold
before it starts the TX, and duplex settings. Because troubleshooting these
variables is often as hard as troubleshooting an entire Asterisk install, I
would never run a soft-phone and expect people to use it productively. What
happens when you put in a "real" phone? If you don't have a hardphone, maybe
try something else like the Snom soft-phone. 

In the end, this is all about eliminating variables as much as possible, and
this will determine your "decision matrix" of things to try. The first
matrix will be the most difficult to implement because you have a whole wack
of stuff to eliminate, but they will get smaller and smaller as you
eliminate variables and eventually you will only have 2 or 3 variables to
test for, and then you are golden. 

OT: I find it useful to make painstaking notes or keep a spreadsheet of test
results when going through a troubleshooting process like this. Often,
referring back to the spreadsheet gives me valuable insight into a problem.
I read this book, and I got shivers down my spine because it's like these
guys got into my brain and stole (what I thought) was an original
problem-solving idea of mine:

http://www.transcendstrategy.com/html/index.php?module=htmlpages&func=displa
y&pid=7

Every person that troubleshoots a complex system should read this book
(disclaimer: I just read it, I have nothing to do with these guys) 

good luck