Packs of scripts are a good idea, however something to monitor the overall quailty after the install should always be considered. There is many many many things that can go wonk on a voip install from the tos being set wrong on a switch to using a voip provider thats too far away (network speaking) Local network switches can be monitored using snmp bundled with cacti or mrtg to procude pretty graphical reports, its crude but can give you can idea of bandwidth spikes on your lan and collisions,cpu usages etc... programs like ntop will give you detailed usuage on the packets and break it down by program/protocol. Wireshark is great as a general tool to see whats happening, when a local lan is concerned its always a good tool to get an idea of the bulk/improperly configured network traffic, ie you may find some random devices like network video cameras spewing large amounts of broadcasts accross your switch.
________________________________ From: Martin Glazer [mailto:[EMAIL PROTECTED] Sent: Thu 3/6/2008 12:23 AM To: Jim Van Meggelen Cc: Philip Mullis; 'John Lange'; [email protected] Subject: Re: [on-asterisk] Tools for troubleshooting voice quality 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
