Great quesitons!
"how, when a client has both data, voice and video to send, and is contending with its peers, does voice get prioritised?"
On a client device that is WMM capable (Pretty much all modern WLAN clients) when the application (or Windows Group Policy) mark a packet in the IP stack, the wireless driver will take that marking and convert it to a WMM value 7 for voice or 5 for video. As long as the driver is working as it should (Early versions of the MS Surface driver didn't have WMM enabled) the packets will get prioritized. "How?" you ask " can a shared medium prioritize packets?" Well it's all down to how the contention window works in 802.11. Non prioritized packets all work the same way:
- Client has a packet to transmit.
- It listens on the channel
- If no one is transmitting it waits a standard period of time and then listens again (EDCA backoff timer)
- If no one is transmitting, that client transmits.
A voice or video packet has a shorter backoff timer than a standard packet. This gives the voice packet a greater chance of being transmitted on the medium.
"f so, what values should be used, I was reading that DSCP 46 doesn't map correctly to WMM and as such I should consider something higher i.e. 48 or 56. Is this correct?"
What we found was that the WMM drivers in most wireless clients map EF46 to the video queue. Why? Because in 2003 the WiFi Alliance used 802.1p strict mapping rules and ignored Cisco's use of EF 46 for Voice. (There was one samsung phone that DID use WMM voice for EF 46!!)
So what should you do here? Well I recommend you not worry about it. Altering the standard 46 voice, 34 Video DSCP markings mean that you need to re-configure your wired network end-to-end. If you leave it as it is and the voice is mis-marked what will happen is that the heuristics you configured on the controller will re-map the voice traffic mis-marked with 34 back to 46 and send it out correctly. Your only potential congestion point is between the AP and the controller, one not likely to need QOS. (If it is then you could consider re-mapping to something higher)
BTW the only clients that send DSCP for Lync/Skype are windows devices with GPO applied all others send no DSCP to the wireless driver.
One last note: Heuristics is the best choice when you cannot use SDN API (Now called SDN interface) Microsoft, and me, recommend SDN API whenever possible. (Skype for business online does not YET support SDN API)
Hope this helped!
(How do I know all this? I wrote the guides when I worked for Aruba :-)