[cisco-voip] Class based RTP Header Compression

[Craig Staffin]

The short answer is that it will not work most likely.

IP Header compression needs to be supported on EVERY hop in order to
function.

So if your MPLS provider can not support it your only option would be to
encapsulate that traffic in something (GRE,IPSEC)

Craig

On Mon, Dec 14, 2009 at 11:36 AM, Matthew Linsemier <
mlinsemier at apassurance.com> wrote:

>  We ran into similar problems when we tried to enable RTP Header
> compression over our MPLS network.  In the end we were told by TAC that our
> MPLS provider (Sprint) would also have to enable RTP header compression on
> their routers to support this.  I was still a little caught off guard by
> this answer as I had read conflicting stories on the web.  In the end we
> ended up not enabling RTP header compression.
>
> Matt
>
>
>
> On 12/14/09 11:27 AM, "O'Brien, Neil" <nobrien at datapac.com> wrote:
>
>
> Hi Craig,
>
> See below.  I believe the WAN is MPLS but anything past our CE router is
> ISP controlled.
>
>
> class-map match-all CM-MATCH-SIG
>  match ip dscp cs3
> class-map match-all CM-MATCH-RTP
>  match protocol rtp
>
> policy-map PM-QOS
>  class CM-MATCH-RTP
>   priority percent 50
>    compress header ip rtp
>  class CM-MATCH-SIG
>   bandwidth percent 5
>  class class-default
>   fair-queue
>
> interface Serial0/3/0
> bandwidth 2000
>  ip address *.*.*.*
> service-policy output PM-QOS
>
> Thanks,
>
> Neil
>
> ------------------------------
> _______________________________________________
> cisco-voip mailing list
> cisco-voip at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
>
>  ------------------------------
>
> CONFIDENTIALITY STATEMENT
> This communication and any attachments are CONFIDENTIAL and may be
> protected by one or more legal privileges. It is intended solely for the use
> of the addressee identified above. If you are not the intended recipient,
> any use, disclosure, copying or distribution of this communication is
> UNAUTHORIZED. Neither this information block, the typed name of the sender,
> nor anything else in this message is intended to constitute an electronic
> signature unless a specific statement to the contrary is included in this
> message. If you have received this communication in error, please
> immediately contact me and delete this communication from your computer.
> Thank you.
>
> ------------------------------
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20091214/facb80ab/attachment.html>