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
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
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