04-15-2009 11:38 AM - edited 03-04-2019 04:23 AM
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
04-15-2009 12:31 PM
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.
04-15-2009 01:02 PM
Sorry , posted the wrong part of the config, yes that piece sets the bandwidth usage. Thanks for the reference.
04-15-2009 01:53 PM
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
04-15-2009 02:01 PM
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.
04-15-2009 02:07 PM
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
04-15-2009 02:09 PM
No. the packet is understood by the end devices and you are only compressing the header, not the payload.
__
Edison.
04-15-2009 02:11 PM
Edison,
Thanks for useful information.
5P!
Toshi
04-15-2009 02:16 PM
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
04-15-2009 02:24 PM
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.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide