RTP Header Compression: How does it effect flow through ne..

Archived from groups: comp.dcom.voice-over-ip (More info?)

"CCGolfer" <apage_88@hotmail.com> wrote in message
news:1e208886.0406081241.78915206@posting.google.com...
> It seems that RTP header compression would be a good idea, but as the
> packets flow through the network they need to be uncompressed at each
> hop don't they? What's the trade-off in todays routing equipment for
> handling RTP header compressed packets vs. the bandwidth that they
> save?

it depends. (stock answer - sorry)

1st - a lot of soho type routers dont seem to do this anyway. You need to
support compression at both ends of the link, (or VPN tunnel).
2nd - devices that do support (eg cisco), tend to run compression in
software for this - hit on the router CPU depends on router, line speed, and
the amount of voice traffic.
3rd - the "choke point" is often a router at a aggregation point - eg a
frame relay site where lots of PVCs terminate - you need to check processor
load at each RTP compression point.
4th - you need to be careful about interactions between compression, QoS and
call admission control. Basically, the router may not look at compressed
data to calculate QoS thresholds, so you may end up deliberately
misconfiguring things to compensate (e.g. with RSVP) - which is great until
someone alters the config and "corrects" the mistake.

since you can get compression in hardware as an option in many routers (and
you may have to use that in an aggregation router to get enough compression
without CPU overload), it may make more sense to compress everything - that
way you gain on data traffic as well.
>
> Thanks,
>
> Greg in MA
--
Regards

Stephen Hope - return address needs fewer xxs