Call Mismatch of DSCP - CallManager 7

[TyrosAdmin]

We recently sorted out some bandwidth issues on our network, but are still having call quality issues.

We are seeing some issues with DSCP values in our calls.

I ran some packet captures of calls between two of my remote sites.

When I look at the packet captures, I'm sending DSCP 46 out, and receiving DSCP 0 back from the other side of the call session.   

One side is sending DSCP 46, and the other side is sending DSCP 0.  We're seeing tons of jitter and issues with calls sounding like we're in a tin can.

Both phones register to the same pub/subs servers, and are accepting callmanager defaults.

Anyone have any ideas why this might be occurring?

[Christopher Graham]

What endpoint is actually sending dscp 0?  It's the endpoint (phone) what fills this value initially, but it can be changed/stripped in transit depending on how the layer 3 devices are configured.

Is this an IP phone to IP phone call?  Are the phones across a WAN link from each other?  Get a packet capture from each phone to verify that DSCP is properly populated from the beginning.  If they are, then it is being stripped at some point in the network in one direction.  You'll have to get catpures from various points in the neetwork (concentrate on layer 3 devices and the WAN) to determine where DSCP is being stripped.

[TyrosAdmin]

The captures are between two cisco ip phones in alternate locations across a private MPLS network.

I also ran a capture at the switchport the router is plugged into.   I'm seeing DSCP 46 on the side of the call that's local, but comes in as 0 from the remote side. 

So I'm sure that it's being stripped out.  How might I ensure that my Cisco 2821 router isn't stripping DSCP out?    We do not have QOS on the WAN circuit from the provider, as we ran into some issue initially, and wanted to fix those before turning it back on.  

I have all of my local switchports trusting COS values for layer two, including the port the router is plugged into.   Should I change that to trust dscp?

[Christopher Graham]

It's possible that your MPLS provider is stripping DSCP.  If you do not have QoS enabled at the remote location, and your L3 switches are trusting COS, then the 2821 will not be stripping DSCP.  You can get a packet capture at the ingress of the remote router from the remote phone to see if 46 is populated.  If it is, call your provider.

[TyrosAdmin]

Ok.  I've got captures from the switchport the router's connected to.  I don't have any free ethernet ports to run a capture against on the router.  I'm not seeing any output with dscp 46, or any COS tagging.  

Here's what I'm thinking of putting in as a route policy map to make sure the DSCP tag is passed across, and COS once it hits L2   I'm looking at adding this to all Routers in my environment.  

class-map match-all Voice-Signal

  match access-group 121

class-map match-all RTP

  match access-group 120

class-map match-all P3

  match precedence 2  3

!

policy-map L3-L2

  class RTP

   set cos 5

  class Voice-Signal

   set cos 3

!

policy-map QOS

  class RTP

   priority percent 40

   set dscp 46

  class Voice-Signal

   bandwidth percent 20

   set dscp 32

  class Class3

   Bandwidth percent 20

  class class-default

   fair-queue

!

interface Multilink1

ip address x.x.x.x

ppp ipcp predictive

ppp multilink

ppp multilink group 1

ppp multilink fragment disable

max-reserved-bandwidth 100 

service-policy output QOS

interface GigabitEthernet0/0.150

encapsulation dot1Q 150

ip address 10.100.150.1 255.255.255.0

service-policy output L3-L2   

access-list 120 permit ip any any precedence critical

access-list 120 permit ip any any dscp ef

access-list 121 permit tcp any any range 2000 2002

access-list 121 permit tcp any any eq 1720

access-list 121 permit tcp any any range 11000 11999

access-list 121 permit udp any any eq 2427

access-list 121 permit tcp any any eq 2428