RE: OT? cRTP header compression

Mailman List Mirror (Read Only)
1

I had some kind of experience doing cRTP over Cisco routers, we use Cisco
7204 & 7206 Routers on the IP Gateways and Cisco's 3600 and 5300 as VoIP
gateways, as well we had a small setup using a Cisco 2611 router on the
termination router.

As well as increasing sample size (thereby increasing the payload:header ratio), the other thing to try is turning on voice activity detection (VAD, AKA silence suppression). For human conversation, this typically reduces packet rates by around 60%, enabling you to squeeze more conversations onto the link. It also has the side effect of reducing CPU utilization per call on your Cisco voice gateways. Note that turning on VAD does decrease the perceived voice quality a little, so whether it is worth it depends on where you want to make the trade-off between cost and voice quality.

Also, cRTP is not CEF switched on the 5300 in 12.2, AFAIK. It was on 26xx/36xx, but 5300 architecture (and hence switching code) is different. That may have changed since I last looked 6 months ago -- best bet is to ask on the Cisco-NAS mailing list at

http://www.cisco.com/warp/public/471/cisco-nas.html

  Cheers,

Mathew

2

Matthew,

Cisco-NAS and Cisco-Voice ml's didn't provide any feedback regarding my
initial question which was cRTP vs CPU usage.
Never seen any info about the fact that cRTP is not CEF switched in 12.2
on AS5300s, OTOH I've not seen any info that does specify which chassis
handles cRTP CEF switched.

From CCO:

"With Release 12.1, if TCP or RTP header compression is enabled, it
occurs by default in the fast-switched path or the Cisco Express
Forwarding-switched (CEF-switched) path, depending on which switching
method is enabled on the interface. If neither fast-switching nor CEF
switching is enabled, if RTP header compression is enabled, it will
occur in the process-switched path as before"

Cheers
Thomas

3

As well as increasing sample size (thereby increasing the payload:header
ratio), the other thing to try is turning on voice activity detection (VAD,
AKA silence suppression). For human conversation, this typically reduces
packet rates by around 60%, enabling you to squeeze more conversations onto
the link. It also has the side effect of reducing CPU utilization per call
on your Cisco voice gateways. Note that turning on VAD does decrease the
perceived voice quality a little, so whether it is worth it depends on
where you want to make the trade-off between cost and voice quality.

I am not a big fan of VAD in my network, customers do not like the silence
they get on the other end. As far as packet size, you want to use the
smallest you can get away with. I use 9 or 21 ms of G.726 on my network, I
know they are odd sizes, but we run our own version of CRTP directly over
AAL5 so we want to fill the cells correctly.

If you are looking for more info on VoIP/CRTP check out the following:

http://www.robotics.net/papers/integratedvoice.html

I also have a Excel took that will let you play see what CRTP, frame size,
CODEC, link speed look like for VoATM, VoIP, and FoFR.

http://www.robotics.net/clec/tools/index.html

<>

Nathan Stratton CTO, Exario Networks, Inc.
nathan at robotics.net nathan at exario.net
http://www.robotics.net http://www.exario.net

4

I am not a big fan of VAD in my network, customers do not
like the silence
they get on the other end.

use equipment that supports vad and comfort noise generation. with a
little tuning it can be made quite tolerable and very hard to detect.

thanks,
chris

5

Note that turning on VAD does decrease the
> perceived voice quality a little, so whether it is worth it depends on
> where you want to make the trade-off between cost and voice quality.

I am not a big fan of VAD in my network, customers do not like the silence
they get on the other end.

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.

As far as packet size, you want to use the
smallest you can get away with. I use 9 or 21 ms of G.726 on my network, I
know they are odd sizes, but we run our own version of CRTP directly over
AAL5 so we want to fill the cells correctly.

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.

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

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.

Cheers,

Mathew

6

use equipment that supports vad and comfort noise generation. with a
little tuning it can be made quite tolerable and very hard to detect.

True, but in the real world people notice. If I was building a cell
network no problem. My issues is I am replacing the PSTN, so I need to
offer as good if not better service. If we are talking calls to Japan I
can get way with less quality, but a office business line no way.

<>

Nathan Stratton CTO, Exario Networks, Inc.
nathan at robotics.net nathan at exario.net
http://www.robotics.net http://www.exario.net

7

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. :slight_smile:

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