spidey07, if you have infinite bandwidth (and a non brain-dead technology), your latency is fixed, and QoS is not needed. QoS comes into play when you have a resource scarcity, even transiently. One packet is going down the line, the next packet - or packets, have to sit in a queue and wait their turn. This creates a variable delay - jitter - which creates many problems for VoIP. If you have a situation where this is happenning, then QoS techniques will help. A low-latency queue will help reduce the time a packet has to wait, at least letting it jump in front of the bulk data packets, and tends to keep your jitter down to the delay caused by a MTU-sized packet up ahead plus however many packets are waiting in the LLQ already. If you still have too much jitter, then more aggressive techniques like dividing into TDM channels might be a good idea.
But QoS is only a cure for a specific problem, and VoIP has *lots* of potential problems. Unfortunately, the VoIP arena brings together people who are new to networking with people who are new to voice, mixes them up, and creates lots of opportunities to be confused. Many people treat QoS as a sort of magic pixie dust for VoIP networking, configure it correctly (ah, but what is correctly? that itself is a long discussion
and everything will Just Work. Well, it doesn't work that way. QoS only solves a certain set of problems, those of queueing delay/jitter and drop priority. Your phone guys might not really know networking, and so to them, sure, QoS is the solution - they don't have to do anything, and it's mentioned in the documentation that you should set it up, so obviously that must be the problem, right?
Echo is a great example of a problem that can come from many many sources. In my experience, echo is not usually due to any of the problems QoS would solve. Echo is easist to introduce whenever there is an analog to digital (or back) conversion, due to the way analog phone systems work. Echo can also be created by mismatched echo cancellers, sometimes they help each other and sometimes they hurt each other. There are other causes, too.
The way I like to debug problems is to isolate into testable parts. In this case, the way to test whether QoS is the solution to this echo problem is straightforward (if not simple in the particular environment of the original poster) - get the T1 line to be otherwise idle, and make a call. If it works great when idle, and echos when there's data on it, then QoS is likely to be the solution to your problem. If it continues to have the echo problem when idle, then the problem is somewhere else, and QoS is *not* the solution to your problem.
QoS is still a good idea in a VoIP installation - a simple low-latency queue is a big help. But before you go off and reconfigure your network to do it, make sure the exercise is going to solve today's problem.
Facebook
Twitter