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