WLC Best Practices for MS Teams Video

[awatson20]

Hello.  We have a wireless environment with 5520's currently on 8.5.171.0, moving to 8.10.  AP models vary mostly 2800/3800 with some legacy.  We utilize MS Teams for video collaboration in our company.  In the past, we have not had to make many QoS adjustments if at all to accommodate video applications.  We utilize most of the default settings, using the Platinum QoS on the wlans where there are voice devices and Apple smartphones, and on the standard corporate SSID where most of the Teams calls are joined from it is set to Gold.  Other settings are default related to QoS.  Here lately, we continue to receive reports of Teams video participants having sporadic jerky video, lag, that typically does not affect audio, while on the wireless network. Wired connections do not seem to report these issues. When we look at things like AP utilization, client connection score, these statistics are always very good, with majority of users on 5GHZ.  I am wondering if others experience this issue, and if there are some settings on the WLC that we could adjust to improve. We are not even sure at this point if this is a wireless issue, as there are many other client factors.  Most of the clients are going to be Windows laptops, Macbooks, and some iPad tablets. Just curious what others experience is with this.

[balaji.bandi]

its all depends on the design :

some good steps I followed and documented :

https://www.cisco.com/c/en/us/td/docs/wireless/controller/technotes/8-6/b_Cisco_Wireless_LAN_Controller_Configuration_Best_Practices.html

https://mrncciew.com/2012/12/26/top-10-recommendations-for-vowifi/

[Leo Laohoo]

I know of two known bugs affecting 2800/3800/4800 and Catalyst 9k wireless APs and MS Teams.  One of them is CSCwa31596 and I am unable to find the bug associated to 2800/3800/4800. 

I suspect the issue affects all OS (AireOS and IOS-XE) and affects all version.  The root to the problem is the MARVEL chipset.  

[awatson20]

Thanks Leo. I would be very interested in finding out more information about the bug that affects the Wave 2 AP model. Do you have any information on the symptoms, affected Aire-OS code, and which code resolves this?

[Leo Laohoo]

The AP radios would randomly drop packets.  

Notice that the affected APs are the "new" Cheetah OS models.  Old APs that run on "classic" IOS are not affected.  

---

@awatson20 wrote:
which code resolves this?

---

None. 

[awatson20]

Does this affect/impact Wave 2 AP models(2800/3800) running AireOS 8.5.171.0?  Any additional bug defect information would be greatly appreciated.

[Leo Laohoo]

---

@awatson20 wrote:

Any additional bug defect information would be greatly appreciated.

---

Raise a TAC Case when NAM/LATAM or EMEA desk is online and query TAC.

[Rich R]

I think they've probably combined both bugs into https://bst.cisco.com/bugsearch/bug/CSCwa31596 because that also includes AireOS fixed version and lists all the AP models.  Note the AireOS fix is in 8.10.178.27 so you would have to get an escalation image from TAC to get that fix because it's not in a released version of code yet.  TAC would also be able to tell you if it affects 8.5.171.0 (probably does) and if so then you won't see a fix for it in 8.5 because 8.5 is end of software maintenance now:
https://www.cisco.com/c/en/us/products/collateral/wireless/8500-series-wireless-controllers/bulletin-c25-744139.html

[Leo Laohoo]

Well, 8.10MR8 is about to be released.  There is one way to find out if the info about this bug getting fixed in this version is correct or not.

[awatson20]

Thanks for all of the information.  I am working with TAC and trying to find out more information about these bug defects, affected versions, and when it will be fixed.

[Rich R]

Ah yes I missed that - Announcing Cisco Wireless 8.10MR8 First EFT/Beta - 8.10.178.88 - Cisco Community

It is in the fixes there.

[Joseph W. Doherty]

I'm dated on wireless QoS, but because of the way wireless works (logically a shared media), and ideally QoS active support is needed on every wireless client (for best results), to me, effective QoS is a bit hit or miss.  I.e. the wireless environment itself, even if all QoS is done, including "correctly", your results might be less than desired.

As to other suggestions: First, often overlooked, APs tunnel back to WLC decreasing the IP MTU.  I recall (?) Cisco WLCs supported an adjust-mss option to eliminate that issue for TCP traffic.

If you cannot find any other effective solution, you might also try reducing IP MTU on all your wireless clients.  (This should allow better interleaving of different traffic types - with perhaps better sharing and/or QoS effectiveness for bandwidth management.)