03-20-2011 10:34 AM - edited 03-16-2019 04:02 AM
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?
03-20-2011 11:41 AM
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.
03-20-2011 12:15 PM
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?
03-20-2011 12:20 PM
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.
03-20-2011 05:09 PM
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
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