Jim Van Meggelen wrote:
Ideally, I'd want to come up with some recipies that contain useful tips on troubleshooting connectivity and quality problems with the network. How many of us run VoIP sets on our customers' networks, and are forced to prove network troubles to the customer because the tell us "the network is fine", even though there is a lot of evidence to suggest that it is not? Being able to produce more detailed data on why we feel the network is "not fine" would often be of use. Being able to do that without having to spend a lot of time on it, and having access to only the Asterisk server, would make things a lot easier, I suspect.
Having a set of scripts or procedures with some metrics that you can produce would be ideal and extremely valuable.
In the last few months I've had a few client with "perfect" networks give problems. If a web page or a file takes a few milliseconds longer to open due to network issues, it is generally not even noticed, but throw a real time application into the mix and things can go south real quickly. The problem, as you say, is proving it.
I've found that because we are dealing with UDP packets, this adds to the difficulties in proving a network issue. At least with TCP, we can see whether a transmitted packet arrived or was acknowledged, whereas with UDP, unless you are monitoring both ends (which most of the time isn't possible) you cannot.
One command that has helped me is netstat - there is a wealth of network information available. Twice now when I've suspected network problems on "perfect" networks, I've used netstat to prove that packets were being dropped/lost and things weren't so happy.
Try netstat -su or netstat -suc for continuous UDP stats. Martin --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
