cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
3626
Views
5
Helpful
12
Replies

Phone Not Marking Packets Correctly

ds6123
Level 1
Level 1

For some reason, a bunch of Cisco phones are marking RTP packets with a DSCP of 11, instead of 46.  I've confirmed this with a packet capture as well as looking at the DSCP statistics on the switch ("show mls qos int x statistics" on the Catalyst 3750).

On the same packet capture, I can look at the SKINNY "StartMediaTransmission" packet, and it appears the call manager is telling the phone to use DSCP 46 (well, Wireshark decodes it as "Predecence: 46"... which I assume really meant *DSCP* of 46).  Yet, the phone keeps marking it as DSCP 11.

Has anyone see this before?  Maybe a bug in the phone's firmware?

Phone is a 7960, running software version P00308000700.

Thanks!

12 Replies 12

Marwan ALshawi
VIP Alumni
VIP Alumni

It has to be difserv of differentiate serve field for the dscp value in wireshark !!

Sent from Cisco Technical Support iPhone App


marwanshawi wrote:

It has to be difserv of differentiate serve field for the dscp value in wireshark !!

Sent from Cisco Technical Support iPhone App

Thanks for the response.  But I don't understand what you mean.

When I'm talking about the QoS marking the call manager tells the phone to use, I'm talking about the field in the SKINNY payload of the IP packet that wireshark decodes as "Precedence".

// here is that skinny payload that the call manager sends to the phone:

Skinny Client Control Protocol

    Data Length: 108

    Reserved: 0x00000000

    Message ID: StartMediaTransmission (0x0000008a)

    Conference ID: 42593650

    PassThruPartyID: 33633647

    Remote Ip Address: 10.89.2.52 (10.89.2.52)

    Remote Port: 20094

    MS/Packet: 20

    PayloadCapability: G.711 u-law 64k (4)

    Precedence: 46

    Silence Suppression: Media_SilenceSuppression_Off (0x00000000)

    MaxFramesPerPacket: 0

    G723 BitRate: Unknown (0)

// Then this is the very next packet the phone sends (ie an RTP packet to the remote phone):

Internet Protocol, Src: 10.91.2.51 (10.91.2.51), Dst: 10.89.2.52 (10.89.2.52)

    Version: 4

    Header length: 20 bytes

    Differentiated Services Field: 0x2e (DSCP 0x0b: Unknown DSCP; ECN: 0x02)

        0010 11.. = Differentiated Services Codepoint: Unknown (0x0b)

        .... ..1. = ECN-Capable Transport (ECT): 1

        .... ...0 = ECN-CE: 0

What's the switch port config of this phone ?

Hi,

I think Marwan is right (+5)

This looks like a bug in the version of wireshark

Please see

https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=3320

Looks like the wireshark is reading  a field back to front

I am running Version 1.6.0

It seems to be OK

Regards

Alex

Regards, Alex. Please rate useful posts.

acampbell wrote:

Hi,

I think Marwan is right (+5)

This looks like a bug in the version of wireshark

Please see

https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=3320

Looks like the wireshark is reading  a field back to front

I am running Version 1.6.0

It seems to be OK

Regards

Alex

Interesting.  So if we switch the entire byte around.... instead of 0010 1110, it becomes 0111 0100 and then group it into 6 bits for DSCP and 2 for ECN (00 - 101110).... then you're right!!  DSCP = 46!  I'm running Wireshark version 1.4

But, the counters on the switchport (show mls qos int x) also show DSCP 11 inbound from the phone incrementing. 

I'll have to double check everything again.  Thanks for the tip!

marwanshawi wrote:

What's the switch port config of this phone ?

I don't have access to the network at the moment, but it's configured using auto qos -- to conditionally trust the markings from the phone if CDP is detected. 

Also, from the "show mls qos int x statistics" from the switch, the switch itself is seeing DSCP 11 inbound from the phone.

Hi,

The key part here is the line

From your trace RTP packet

Differentiated Services Field: 0x2e

So -->  2E (HEX) = 00010 1110 (BIN) = 46 (DEC)

So DSCP 46 (EF)

I still think you need to change your weireshark version

HTH

Alex

Please rate useful posts

Regards, Alex. Please rate useful posts.

acampbell wrote:

Hi,

The key part here is the line

From your trace RTP packet

Differentiated Services Field: 0x2e

So -->  2E (HEX) = 00010 1110 (BIN) = 46 (DEC)

So DSCP 46 (EF)

I still think you need to change your weireshark version

HTH

Alex

Please rate useful posts

I just updated Wireshark to 1.6.4 and get the same result.

I also notice that when the phone initiates SKINNY messages, they're marked with DSCP CS3 -- which is correct:

Internet Protocol Version 4, Src: 10.91.2.51 (10.91.2.51), Dst: 10.99.20.7 (10.99.20.7)

    Version: 4

    Header length: 20 bytes

    Differentiated Services Field: 0x60 (DSCP 0x18: Class Selector 3; ECN: 0x00: Not-ECT (Not ECN-Capable Transport))

        0110 00.. = Differentiated Services Codepoint: Class Selector 3 (0x18)

        .... ..00 = Explicit Congestion Notification: Not-ECT (Not ECN-Capable Transport) (0x00)

So it just seems the RTP stream isn't marked correctly.  Plus, the "show mls qos int x statistics" still shows DSCP 11 inbound increment during phone calls.

I'm guessing it's a firmware issue on the phone, but I'll keep everyone posted.

Thanks for the help everyone!

marwanshawi wrote:

What's the switch port config of this phone ?

Here's the config, just standard auto-qos conditionally trusting the phone:

interface FastEthernet3/0/9

switchport access vlan 10

switchport mode access

switchport voice vlan 2

switchport port-security maximum 2

switchport port-security

switchport port-security aging time 2

switchport port-security aging type inactivity

srr-queue bandwidth share 10 10 60 20

srr-queue bandwidth shape  10  0  0  0

priority-queue out

mls qos trust device cisco-phone

mls qos trust cos

auto qos voip cisco-phone

no mdix auto

spanning-tree portfast

spanning-tree bpdufilter enable

spanning-tree bpduguard enable

service-policy input AutoQoS-Police-CiscoPhone

Hi,

Is the phone on CUCM or CME

Regards

Alex

Regards, Alex. Please rate useful posts.

acampbell wrote:

Hi,

Is the phone on CUCM or CME

Regards

Alex

CUCM.  We're gonna try upgrading the phone firmware and see what happens.

Did the CUCM upgrade worked?

 

Regards