QOS on the IP Phone is displaying wrong data

[davis124]

I was wondering if someone could point me in the right direction...
We have a few different IP Phones in our environment (16xx and 96xx) and I am running into a problem... A few months ago in some testing we noticed that we could change the QOS/Diffserv values in the IP-Network-Region form and the phones would automatically pick those up and the display would update on the phone...

Now doing further testing I notice that the phones are no longer picking up the QOS/802.2P/Q changes (Or at least the display is not updating) but they are accepting the Diffserv changes still... A reboot of the phone does not seem to fix the problem... These phones are also running the latest available H.323 firmware loads for them and are attached to a CM 5.2 S8730. I have NOT done a sniff to confirm if the change has taken affect, but I am going to assume that if the display is not updating we are not sending the correct QOS info.

So my question is, why would this be happening (Has anyone else experienced this)? And how do we go about resolving it?

There is nothing setup in the 46xxsettings file that would set the QOS values, so I am at a loss here as to why these phones just a few months ago would accept a CM Change for QOS but now not...

Any help on this would be great!

Thanks,
James

[jrwoods]

We had a similar situation a few years back and when working with R&D a trace showed that the 802.1pQ values were disabled. These values are disabled if the VLAN is set to “n” on the ip-network-map form or if the phone is not in the map. Changing this to 'y' would allow CM to push the L2 QoS values to the phone. Try setting the VLAN to 'y' on the ip-network-map screen.

[davis124]

THANK YOU... That was the bit of information I was missing...

So in testing we had some IP Phones setup in the Network-Region form, so I added the VLAN data, and rebooted the phones and whaa-laaa fixed the problem... (tried before rebooting to see if the QOS data would change and it didn't, so the next step was the reboot)

This bit of information is great, and the sad thing is for the longest time Avaya advised NOT populating this field in fear of causing other problems... So lesson learned...

Again THANK YOU for that info, that fixed my problems...

James