Re: MQC, shaping and RTP header compression

fcocciari · ‎10-28-2010

Hi all,

I have ths config

class-map match-any VOIP_SIGNALING
match protocol sip
match protocol h323
match protocol mgcp
match protocol skinny
class-map match-any VOIP_RTP
match protocol rtp
!
!
policy-map VOIP_LLQ
class VOIP_RTP
    priority 400
   compress header ip rtp
class VOIP_SIGNALING
    priority 50
class class-default
    fair-queue
     random-detect dscp-based
policy-map SHAPE_ALL
class class-default
    shape peak percent 25 10 ms
service-policy VOIP_LLQ
!
interface Serial1/1
bandwidth 2048
ip address 172.16.252.6 255.255.255.252
encapsulation ppp
load-interval 30
serial restart-delay 0
service-policy output SHAPE_ALL
!

Simulating voice calls with RTP flows I expect that the router compress the header of the RPT packets.

But nothing happens ?

I applied identical policy on both ends of the link.

Why ?

Below is the output of the show policy map interface:

CE1#sh policy-map interface serial 1/1
Serial1/1

Service-policy output: SHAPE_ALL

    Class-map: class-default (match-any)
      97573 packets, 26989365 bytes
      30 second offered rate 304000 bps, drop rate 0 bps
      Match: any
      Queueing
      queue limit 64 packets
      (queue depth/total drops/no-buffer drops) 0/1/0
      (pkts output/bytes output) 97647/26991506
      shape (peak) cir 512000, bc 5120, be 5120
      target shape rate 1024000

Service-policy : VOIP_LLQ

        queue stats for all priority classes:
          Queueing
          queue limit 64 packets
          (queue depth/total drops/no-buffer drops) 0/0/0
          (pkts output/bytes output) 96327/26436468

        Class-map: VOIP_RTP (match-any)
          96322 packets, 26435048 bytes
          30 second offered rate 298000 bps, drop rate 0 bps
          Match: protocol rtp
            96322 packets, 26435048 bytes
            30 second rate 298000 bps
          Priority: 400 kbps, burst bytes 10000, b/w exceed drops: 0

          compress:
              header ip rtp
              UDP/RTP (compression on, IPHC, RTP)
                Sent:    0 total, 0 compressed,
                         0 bytes saved, 0 bytes sent
                         rate 0 bps

        Class-map: VOIP_SIGNALING (match-any)
          1181 packets, 553197 bytes
          30 second offered rate 5000 bps, drop rate 0 bps
          Match: protocol sip
            1181 packets, 553197 bytes
            30 second rate 5000 bps
          Match: protocol h323
            0 packets, 0 bytes
            30 second rate 0 bps
          Match: protocol mgcp
            0 packets, 0 bytes
            30 second rate 0 bps
          Match: protocol skinny
            0 packets, 0 bytes
            30 second rate 0 bps
          Priority: 50 kbps, burst bytes 1500, b/w exceed drops: 1

        Class-map: class-default (match-any)
          70 packets, 1120 bytes
          30 second offered rate 0 bps, drop rate 0 bps
          Match: any
          Queueing
          queue limit 64 packets
          (queue depth/total drops/no-buffer drops/flowdrops) 0/0/0/0
          (pkts output/bytes output) 140/2240
          Fair-queue: per-flow queue limit 16
            Exp-weight-constant: 9 (1/512)
            Mean queue depth: 1 packets
            dscp     Transmitted       Random drop      Tail/Flow drop Minimum Maximum Mark
                      pkts/bytes    pkts/bytes       pkts/bytes    thresh thresh prob

            default      146/2336            0/0              0/0                 20            40 1/10

Steven Holl · ‎11-02-2010

What happens if you remove the cRTP config from the QoS policy, and you apply it to the actualy WAN interface? Does that change behavior regarding the cRTP stats? There were some bugs a couple years ago with cRTP in MQC, I think. Are you running a recent IOS release?

fcocciari · ‎11-08-2010

Hi Steven,

thank you for your reply.

With global cRTP configuration ( applied to interface ) compression works. I think the issue is on the MQC configuration of cRTP. I tried various IOSes, the last mainline 12.4.25 and the 12.4.22T5. I haven't tried the version 15.

Steven Holl · ‎11-08-2010

I'd say just keep it on the interface for it to function properly, then.

If you want to pursue if this is an existing bug, you can test on the latest IOS (15.1(2)T1 or T2 may be out now) and if the issue is still seen there, open a TAC SR to get a bug filed on that.

Jason@Coollink · ‎03-02-2011

I have the same problem with one of our sites. We have 150 or so MPLS sites, some are Multilink with 3mb, some are 1.5mb T1, and some are 512k, 95% of the 512k sites are AT&T frame-relay over MPLS. Here is our policy-map standard config for our 512k sites.

policy-map MPLS-EDGE-512
class VOICE
priority percent 20

compress header ip rtp (I have removed this to get the site to have 2 way audio.
class VOICE-CALL-CONTROL
bandwidth remaining percent 5
class BGP
bandwidth remaining percent 10
class PRIORITY
bandwidth remaining percent 30
set dscp af21
class EXCHANGE
set dscp af11
class class-default
fair-queue
random-detect dscp-based
policy-map SHAPE-MPLS-512
class class-default
shape average 486400
service-policy MPLS-EDGE-512

I am still working with the provider to see if it something on thier side, but from what it sounds like, its a Cisco bug. We are running 12.4(21), I might try 12.4(25d) but from the previous post that may not fix the issue. Let me know your thoughts.