On Thu, 11 Apr 2002, Mathew Lodge wrote:
> Perhaps you are not using equipment that offers comfort noise generation > when VAD is enabled. On a Cisco 2600/3600/5300, make sure you have comfort > noise generation turned on, and the gain set to a level such that your > users can hear it. I still stand by my comment that customer notice and that is why I don't use it. > In a perfect world, you wouldn't bother with VAD, cRTP, longer sample > sizes, expensive CODECs or any of the other technologies for optimizing > bandwidth. But these are all valid technologies when bandwidth is expensive. Correct, I provide 2 voice lines and data over a 192k DSL circuit using only 1 AAL5 PVC because I don't own the DSLAMs. If you play that game you need to worry about header compression. I am not a big fan of G.729 or other low bitrate codes for business voice services. > You can increase the sample size without affecting perceived voice quality, > because perceived voice quality is a step function of latency. Human > listeners don't notice voice latency until it passes a threshold, when > suddenly it becomes very apparent and perceived quality (measured by MOS) Well I am more of a PSQM guy myself. :-) > plummets. Various standards bodies argue about where that threshold is, but > my experience to date suggests it's around the 150ms mark -- your mileage > may vary. Doubling the standard Cisco voice sample size (20ms) to 40ms only > adds 20ms to end-to-end latency, halves the packet rate and doubles the > ratio of payload to header. Yes, I use 9 ms vs 21 ms most of the time because I want to keep end to end delay as low as possible. Sure I save 8 bytes if I use 21 ms, but I it requires me to up my jitter buffer. The other then you need to think about is packet loss. If I lose a 9ms same I may notice, if it is 21 ms I am MUCH more likely to notice. > Secondly, when link cost is high, it is often prohibitively expensive to > buy circuits with higher data rates. And when this happens, serialization > delay (the time it takes to get a packet on the wire) starts to become a > major issue -- and that is directly impacted by the ratio of payload to > header size. Yes, that is a big problem when you play with low speed links. I run voice and data over one PVC on a DSL circuit. If the user hits a web page and sucks a 1500 byte packet it will take over 93 ms to get over that link. I can't live with that amount of jitter so I fragment to a specified MTU that I can live with per link and then interleave the fragments between the voice samples after I compress the header. ><> Nathan Stratton CTO, Exario Networks, Inc. nathan at robotics.net nathan at exario.net http://www.robotics.net http://www.exario.net
