Compress only Data not Voice

srroeder · ‎04-15-2009

Is there a way to turn on payload compression and only compress the data packets and not VOIP packets? I currently use the following to compress RTP headers on the voice traffic.

class-map match-any voice

description Class Map for Voice traffic from 10.1.1.1

match access-group 111

policy-map voice

description Policy Map for Voice Traffic Dedicate 50KB to Voice

class voice

priority 50

access-list 111 permit ip host 10.1.1.1 any

Is there a similar way or any method to compress just the data traffic from file servers and PCs.

Thanks

Edison Ortiz · ‎04-15-2009

Steve,

I don't see how you are compressing RTP headers with the config you've shown above.

The config above is prioritizing voice traffic on the link.

For TCP|UDP header compression in addition to RTP header compression, please use the command described on this link:

http://www.cisco.com/en/US/docs/ios/qos/command/reference/qos_a1.html#wp1015423

Keep in mind, you are only compressing the header, not the payload.

HTH,

__

Edison.

srroeder · ‎04-15-2009

Sorry , posted the wrong part of the config, yes that piece sets the bandwidth usage. Thanks for the reference.

Thotsaphon Lueangwattanaphong · ‎04-15-2009

Edison,

I used to do this on the interface level on both sides(Point-to-Point). Such as

!

interface Serial4/0

ip rtp header-compression

!

If I already configured rtp header compression by using MQC on one side. Then who will decompress. And how to configure this on the other side.

Thanks

Toshi

Edison Ortiz · ‎04-15-2009

Toshi,

The command you've illustrated and the comand I've illustrated perform similar functions. The difference between the 2 is that with your command, you are compressing all RTP flows leaving that interface. With my command, you can specify what RTP flows qualify for compression.

As for the 'decompress' query, once the packets are compressed by the commands outlined, they will remain compressed until it reaches the end-device(s).

An uncompressed RTP header averages 40bytes while a compressed one average 20bytes. On a slow link, this can be vital in terms of throughput. With today's network, this procedure is rarely done as we have fast links everywhere and the compression mechanism can take CPU cycles from the router.

__

Edison.

Thotsaphon Lueangwattanaphong · ‎04-15-2009

Edison,

As for the 'decompress' query, once the packets are compressed by the commands outlined, they will remain compressed until it reaches the end-device(s).

Do we have to tell the other end to decompress rtp packets?

Toshi

Edison Ortiz · ‎04-15-2009

No. the packet is understood by the end devices and you are only compressing the header, not the payload.

__

Edison.

Thotsaphon Lueangwattanaphong · ‎04-15-2009

Edison,

Thanks for useful information.

5P!

Toshi

Thotsaphon Lueangwattanaphong · ‎04-15-2009

Edison,

I'm not sure. Like I mentioned, I used to do that on both ends.

Prerequisites for Configuring RTP Header Compression

â€¢Before configuring RTP header compression, read the information in the "Header Compression" module.

â€¢You must configure RTP header compression on both ends of the network.

Ref: http://www.cisco.com/en/US/docs/ios/qos/configuration/guide/config_rtp_hdr_comp.html

Not sure about MQC.

Toshi

Edison Ortiz · ‎04-15-2009

You need to do that at both ends because you are traversing the same slow link and the return packet will come back uncompressed hence negating the effect of compression overall.

I believe you are confused on the part of having compression enabled at both end of links somehow enables some kind of decompression, which is not the case.

__

Edison.