Compress only Data not Voice

Unanswered Question
Apr 15th, 2009
User Badges:

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


  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (1 ratings)
Loading.
Edison Ortiz Wed, 04/15/2009 - 12:31
User Badges:
  • Super Bronze, 10000 points or more
  • Hall of Fame,

    Founding Member

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 Wed, 04/15/2009 - 13:02
User Badges:

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

thotsaphon Wed, 04/15/2009 - 13:53
User Badges:
  • Gold, 750 points or more

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 Wed, 04/15/2009 - 14:01
User Badges:
  • Super Bronze, 10000 points or more
  • Hall of Fame,

    Founding Member

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 Wed, 04/15/2009 - 14:07
User Badges:
  • Gold, 750 points or more

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 Wed, 04/15/2009 - 14:09
User Badges:
  • Super Bronze, 10000 points or more
  • Hall of Fame,

    Founding Member

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


__


Edison.

thotsaphon Wed, 04/15/2009 - 14:11
User Badges:
  • Gold, 750 points or more

Edison,

Thanks for useful information.


5P!

Toshi



thotsaphon Wed, 04/15/2009 - 14:16
User Badges:
  • Gold, 750 points or more

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 Wed, 04/15/2009 - 14:24
User Badges:
  • Super Bronze, 10000 points or more
  • Hall of Fame,

    Founding Member

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.

Actions

This Discussion