locked
Lync Phone Edition QoS RRS feed

  • Question

  • We're currently in mid-deployment of a Lync 2010 system using Aastra 6725ip phones. We have a seperate switched voice network (no data traffic on here) generally consisting of HP Procurve 26xx PoE and non-PoE switches. This means the PC's running Lync client are not passing traffic through the phones. All voice traffic is still VLAN tagged though, and we assign a 'Voice' setting to the Procurve switches for QoS as there are a couple of points the voice network has to traverse the data network backbone.

    Anyway, my question is about the Lync Quality of Service settings for Lync Phone Edition. The company who we worked with on installation used the Voice qualilty of service setting 46, which I'm curious about. They used this value, as it's a best practise setting (they said), but all their other installations involved the clients connecting through the phones, so there's a single uplink. From what I've read, Lync clients and Phones should have difference QoS settings, specifically I've read 40 (Express Forwarding) should be assigned to phones, and 46 to Lync clients.

    The Voice setting on Procurve VLAN's is meant to handle all the DSCP prioritization automatically, but I'm guessing this DSCP value should be the same as the phones.

    Can anyone confirm what the setting should be on the Lync phones in our setup, and whether I'd still need to modify anything on the Procurve switches?

    Monday, December 17, 2012 12:48 PM

Answers

  • You can use whichever value you need to for your environment as the values themselves don't mean much alone.  The phones are set to 40 by default but you should change this to match the value that your switches use.

    Also 46 is not CS7, that's 56.  The common hexadecimal value of 0x46 is actually EF and it used more often than other values for prioritizing VoIP traffic.

    In case you haven't seen this yet, there is some guidance and DSCP value explanation in this article:
    http://blog.schertz.name/2011/08/lync-qos-behavior/


    Jeff Schertz | Microsoft Solutions Architect - Polycom | Lync MVP

    • Proposed as answer by Lisa.zheng Wednesday, January 2, 2013 9:25 AM
    • Marked as answer by Lisa.zheng Thursday, January 3, 2013 2:07 AM
    Wednesday, December 19, 2012 10:07 PM

All replies

  • In most networks, marking Lync Phone Edition packets with a VoiceDiffServTag of 40 should not cause any problems. However, 40 is not the value typically used for audio traffic; instead, audio traffic is almost always marked with the DSCP code 46. In order to maintain consistency throughout your network, you might want to change the VoiceDiffServTag property of your UC phones to 46.


    Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.

    Tuesday, December 18, 2012 9:48 AM
  • Thanks for the reply. It's become apparent that 46 (cs7) is the correct setting to use for Lync Phone Edition clients, so this is what I'm going to stick with. As were using LLDP-MED on the switches that the phones connect to, the DSCP value (46, 111000)  is automatically assigned to voice packets. The corresponds with qos priority 7 on the Procurve switches.

    In our case, voice packets have to traverse the data backbone at a few points on the network, so on these switches, I set qos priority 7 on the voice vlan.

    Hopefully that should do the trick.

    Wednesday, December 19, 2012 3:14 PM
  • You can use whichever value you need to for your environment as the values themselves don't mean much alone.  The phones are set to 40 by default but you should change this to match the value that your switches use.

    Also 46 is not CS7, that's 56.  The common hexadecimal value of 0x46 is actually EF and it used more often than other values for prioritizing VoIP traffic.

    In case you haven't seen this yet, there is some guidance and DSCP value explanation in this article:
    http://blog.schertz.name/2011/08/lync-qos-behavior/


    Jeff Schertz | Microsoft Solutions Architect - Polycom | Lync MVP

    • Proposed as answer by Lisa.zheng Wednesday, January 2, 2013 9:25 AM
    • Marked as answer by Lisa.zheng Thursday, January 3, 2013 2:07 AM
    Wednesday, December 19, 2012 10:07 PM