Wireshark voice capture

Unanswered Question

I captured a call from one of my remote sites to my ip phone, looking at the RTP Stream Analysis my phone call starts out great for like 30 sec, then I start dropping a number of packets. I checked everything in the LAN before MPLS, my interfaces are clean, my priority queue is not dropping any calls. Does anyone know what would cause a voice call to start our great, then just go south? The MPLS circuit is about 20% utilized. Ideas?

45% drop rate

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Loading.
allan.thomas Thu, 10/23/2008 - 13:55

As you have already captured a voice stream, a good place to start is by investigating whether the rtp packets have the correct DSCP value within the differentiated services field in the IP packet?

If the DSCP value is zero, then you have a good idea that rtp is not be trusted or is being remarked? Thus could be dropped as best-effort.

HTH

Allan.

If I am doing this sniffer capture on my pc, when my phone is the source it shows "EF", but when the other end phone is the source sending to me in the same sniffer capture, it shows default. Does that mean that the packet was reclassified somewhere in the network, or is that something within the wireshark program? Does that make sense?

CHRIS CHARLEBOIS Thu, 10/23/2008 - 14:07

I don't know Wireshark, but that definitely sounds like the packets are getting remarked. Does you MPLS provider allow DSCP markings? Alot of them clear them on the inbound interface of their equipment.

allan.thomas Thu, 10/23/2008 - 14:17

With the rtp media I would ordinarily expect that when your IP Phone is the source address the packets should be marked EF, and the same is applicable when the remote office IP Phone is the source and your IP Phone is the destination.

Packets are certainly being remarked in that case.

Firstly is the MPLS QoS enabled? If it is, the carrier should be able check the service-policy inbound from the remote CE to ascertain whether there are matches within the priority or the LLQ. If there are none, then this suggest a marking issue within the remote office LAN.

Also how are you classifying traffic at the remote office? Are your trusting your IP Phones? Or is the gateway classifying and remarking DSCP accordingly?

HTH

Allan.

1.I need to verify that Verizon has qos enabled for the MPLS circuit

2.I believe my QOS on my lan is correct, so what I would like to do, if what you say is correct, I would like to capture 2 sniffer traces at each of the cores and see how I am sending and receiving DSCP values to MPLS, because right now as it stands when I receive from the remote site, the dscp value is "default" not "EF".

Allan,

So you have captured over mpls and both directions should come out as dscp ef if you are sending it into mpls as ef?

allan.thomas Thu, 10/23/2008 - 15:31

I would certainly expect any carrier to be using IETF defined PHB values, there are essentially four AF (Assured Forwarding)classes and EF (Expedited Forwarding) each with three drop precendences low, medium and high excluding EF.

Therefore depending how the carrier is matching/classifing traffic marked as EF?, it should be treated with strict priority.

However, I would normally expect that the carrier would only provision bandwidth for EF according to your voice requirements for the remote office when QoS was ordered.

This would also be the case for voice signalling and any other traffic classes that are mapped to AF values?

HTH

Allan.

Allan first of all thank you very much for all of your help!

I believe I have figured out most of my qos issues and have fixed them. But I am wondering if someone can comment on another issue.

My Call Manager is plugged into a 6509, when I am watching CM setup (sniffer trace) a call, I noticed that when CM is the source it is not marking the signaling traffic with cs3 or af31. I am running this capture directly on the 6509 so I know there is no chance of a remark. The core is directly connected with our MPLS router. Here is the port the CM is plug into and our mpls router.

6509 CM port

interface GigabitEthernet1/16

description US-Call-1_Eth1

no ip address

mls qos trust cos

switchport

switchport access vlan 720

switchport mode access

spanning-tree portfast

6509 port to MPLS router

interface GigabitEthernet1/1

description Connection to ENG-3845-01 Gi0/0

no ip address

mls qos trust cos

switchport

switchport access vlan 3

CHRIS CHARLEBOIS Fri, 10/24/2008 - 13:39

The DSCP used by the CallManager in out-going control message packets is configrued in the Service Parameters under the Cluster-Wide QoS section (at least in CCM 4.3, I don't know about CUCM 5.x or 6.x). Check that.

allan.thomas Fri, 10/24/2008 - 14:02

No problem at all, glad to help.

Configure the ports to trust DSCP and not COS on the CallManager and gateway switchports. You do not need to change any service parameters.

HTH

Allan

Pls rate helpful posts.

Actions

This Discussion