Technology Blog

How losing voice QoS markings on the wired made my WiFi voice call stink downstream!

Guest Blogger

Last week I had the privilege of speaking at Interop Las Vegas 2015. My topic was one that is very near and dear to my heart, Designing Today’s WiFi Network For Tomorrow’s Applications.


I shared my real world experience managing a large WiFi network in healthcare. Covering a range of topics from design to troubleshooting.  A shared a few slides on wireless QoS and the importance of wired side QoS for downstream over the air priority. A topic often misunderstood or simply overlooked. 


This blog post assumes you the reader have a basic understanding of wireless QoS. 


Real world example #1: QoS properly marked both upstream and downstream


In this example we have two wireless voice over IP phones on a call with each other. The frame on the left #3057 is headed upstream to the access point. The frame on the right #3059 is headed downstream from the access point to the wireless phone. 




If you’re wondering what happen to frame #3058, it was the ACK for frame #3057. 


How we know the frames are marked correctly is by looking at the QoS information field. We can see the value of 6 is marked on both frames. This is an indication that both frames were dropped into the voice bucket and by doing so received the smallest contention window. 


Real world example #2: QoS properly marked upstream but not properly marked downstream 


In this example we have a wireless voice over IP phone on a call with a wired voice over IP phone. The frame on the left #14985 is headed upstream from the wireless ip phone. The frame on the right #14987 is headed downstream over the access point. 




If you're wondering what happen to frame #14986, it was the ACK for frame #14985.


Looking at the QoS information field from both frames we can see the downstream frame is marked with a value of zero. While the upstream frame is marked with a value of 6. This is an indication the upstream frame received a shorter contention window while the downstream voice frame received a much higher contention window. 


This is a perfect example of QoS not properly configured on a wired network. The wired IP phone is marking packets with EF46, however since trust was not properly configured on the wired network these markings were lost as the packets crossed layer 2 and 3 boundaries.  When the packet arrived at the access point with zero markings it simply did what it was suppose to do and dropped the frame into the best effort queue. The downstream voice frame which is sensitive to network latency is now sitting in queue waiting to be triggered behind data frames with an IFS of AIFS 3 and cW of 15-1023. Not with voice priority of IFS of AIFS 2 and cW of voice 3-7 like it should have.


In this example we noticed snap, crackle, pop and the occasional missed word from time to time. After QoS was configured correctly on the wired network these issues went away. This is one the few times correcting QoS on the wired I could notice a difference immediately. 


The next time you hear we have big pipes we don't need wired QoS. The lack of wired QoS can impact your wireless QoS downstream ! 

Aruba Employee

Hi George, did you trace Lync voice call over wireless? let say a voice call with usb-headset from a laptop via wifi.  I notice some VoIP over wifi app do not map proper IP Diffserv into wifi AC=voice in Windows.

Guest Blogger


Fantastic post! Many wired network engineers dismiss the need for QoS on a high-speed LAN because they perceive there is no congestion like there is on a WAN. Unfortunately, they fail to realize that Wi-Fi is shared access and airtime does get congested. Proper end to end QoS is essential.


As to zerodegrekelvin's question regarding Lync, I wrote an entire blog post on the quirks of Microsoft QoS and how it maps from layer 3 DSCP to layer 2 CoS / WMM, thus affecting Lync traffic. See here:



Andrew von Nagy


Aruba Employee


Thanks for the link to your Lync blog.  From what I understood from your blog, the Microsoft Lync Voice over Wifi est still a work in progress, as the marking of DSCP into AC=Voice requires some extra Win7 config by the Admin in the QOS policy right? to force DSCP46 into AC=Voice.

At where I work, when doing Lync voice over wifi, I do not see the DSCP46 translated into AC=Voice for traffic from the laptop (intel6300) to the AP, more ever the traffic from the AP to the laptop, I won't tell you what AC it is mapped to, but not a good AC mapping.

What I found is the Lync certification for Voice is not as "intense" like the Spectralink phone certification, the Lync cert. does not go deep into the wifi, I have more "respect" for Spectralink phone cert. and the newer Wifi-Alliance Voice-Enterprise spec.


Chi-Thanh @zerodegrekelvin



Trusted Contributor I

Like Andrew suggests, I use DSCP 48 to get the correct mapping over the air from Windows to the AP.

Search Airheads
Showing results for 
Search instead for 
Did you mean: 
Read all about it! If it’s happening now, it’s in the community.

Check out the latest blogs from your community team, the community experts and other industry sources.