Wireless Access

Hi, we recently upgraded to Aruba 7220 controllers.  After backing up and restoring the settings to the new controllers, and upgrading the software , we were getting calls of reduced call quality with Voip Phones (Voalte).  We had concerns that maybe the upgrade was not ideal for our older AP's (105's) so we reverted back to the older software (6.4.3.8).  

What we see in the UCC reporting is that WLAN call quality is averaging fair, but End to End call quality is reported as good.  Before the controller upgrade, all UCC calls were rating in the Good range, for both WLAN, and End to end.  

Is our best bet to start over with the documentation for configuring a Voip SSID, or does the fact that WLAN quality rates fair, while End to End rates good, indicate specific settings that we should review in the configuration?  

thanks,

Dave

Questions:

- Do the Voalte phones do WMM?

- Are you using encryption?

- Are you configured for end-to-end QOS?

The phones are Spectralink 8742's working with voalte software.  They support WMM and DSCP tagging.  The SSID they are on is using WPA2-AES.  We are reviewing the end to end QoS but do believe we had it configured properly before the move to the new controllers, as all UCC scores were in the Good range for both WLAN and End to End.  

 In the UCC details from the controller, we see that the Client WMM AC is 6, and the client DSCP is 46.  

thanks,

Dave

Can you do an over-the-air packet capture of a call?  If you do, you should be able to open the capture in wireshark and use the filter  wlan.qos.priority == 6 to see if the client traffic is being properly prioritized in both directions over the air.

Honestly, the main thing that matters in VOIP and Video QOS is that the traffic is properly prioritized between the client and the AP.  That is because between the client and the AP over wireless is the main place that contention occurs in a shared medium and QOS is mandatory so that voip traffic is not degraded by other traffic. The client is responsible for tagging traffic from the client to the AP and the AP is responsible for tagging traffic from the AP to the client.  Others make a big deal about QOS on the wired network, but quite frankly, most wired networks have little to no contention.  The main place where contention would occur on the wired network is on a WAN or oversubscribed link where VOIP traffic would need to be prioritized.

Making sure that the wireless QOS is in place using an over the air wireless pcap is the easiest way to ensure that your configuration is correct.

Here is an example:

Thanks we can look at that, so are you saying that the UCC reporting from the controller may be wrong in saying that the Client WMM AC for these calls is 6, and we may see something different within the packet capture?  

If the Pcap looks correct, then we need to go back over the config to make sure Voip specific settings are set as to what Aruba recommends? 

thanks,

Dave

I am saying that the packet capture is definitive.  The controller indicates QOS in a few locations and I do not know where you are looking to say whether or not QOS is occurring in both directions.  If you can do a wireless packet capture, you can determine if it is happening or not, without reviewing alot of settings.

I do see the Qos Control Priority set to 6 in captured packets to and from the phone I was testing with.  I am going to see if Spectralink has any recommended settings that maybe we are not using currently for this SSID.  The drop in UCC quality coincides with the move to the new controllers, not sure if the migration, or the upgrade of code on the new controllers may have caused some change to a setting we are missing.  

thanks,

Dave

While the call is in progress, you can also type "show datapath session table <ip address of phone>" to see if the traffic is prioritized in the datapath as well.  The drop in voice quality could very well be an anomaly.  You would have to compare the phone to phone to determine if that is the case.  Now that you have checked the packet captures and the phone is doing what it should, the next thing we should check is the RF...

What encryption is that SSID using?

Did you remove any rates on that SSID?

What is the minimum and maximum transmit power of your access points on that band in the ARM profile?

What band are the spectralink phones using?

Do you have "Drop Broadcast and Multicast" enabled on all of your Virtual APS?

The SSID is using WPA2-PSK with AES encryption.  The phones are using A band, which is configured to allow 12/18/24/36/48/54 for Transmit rates, and 12/24 for basic rates.  Min Tx EIRP is set at 9, Max Tx EIRP is set at 127 in the ARM profile used by that SSID.  

 We have Drop Broadcast and Unk Multicast on this SSID but I think we may have an SSID or two with it on due to old medical devices on those that needed broadcast to function.  I will have to research that.  

 I did find some spectralink documentation, its not definitive but seems to suggest that having Client Match turned on may cause quality issues with the spectralinks, we currently have it enabled on this SSID.  

9 and 127 is too much of a range difference for smooth roaming.  Having too much of a power difference between the device (handset) and the AP can produce poor roaming as well as one-sided audio in conversations.  The difference between the top and the bottom should be no more than six.  Some people start with 12 min and 18 max.  If you are very dense, you can leave it at 12 min and max to have even coverage.

I hope you are using only 20mhz channels...  Client Match takes some time to kick in and mostly when clients hang onto APs too long.  Adjusting the power as suggested above would eliminate that as a variable..

Thanks for all the help Colin, we will take a look at modifying the Transmit power for A band used for that SSID, and see if Client Match is causing an issue for us.