Wireless QoS and Zoom meetings

[RJordan-CCS]

This question is about two different sites.  One has all MR44 APs and can use the new NBAR QoS selections, the other has older APs.  Both have MX firewalls so have NBAR on the MX.

I do have a support ticket open for this but hoping someone has had live experience.

Online best practice info about zoom and videoconferencing in general, including Teams, seems to require setting different priorities for audio vs video.  Audio gets higher priority.  However NBAR only has one selection for zoom (unlike MS Teams that has, I think, five different selections and breaks out audio and video).  So if we create a traffic shaping rule for 'zoom' we can only pick one per-client bandwidth and one setting for either PCP or DSCP tag (APs) or just the DSCP tag and priority (low, normal, high)(MX), which would seem to put video and audio (and sharing?, etc) all at the same priority level, not matching alleged best practice.  We can do the NBAR custom rules for the site with MR44s on both the APs and the firewall, or just the firewall at the other site.

Default QoS rules are enabled

Switches are set to accept QoS in settings on voice, production, and office wifi VLANs

Both sites need to support zoom meetings from multiple sources, not just the customer running their own (coworking spaces), some of which may have QoS enabled and some not, but we do not have control over that; it sounds like we might need to force QoS as opposed to accepting and not changing what the client (or upstream) puts out, but again that leaves us with audio and video and whatever else all at the same priority.

What is the proper way to deal with this?

Thanks

[PhilipDAth]

See if you can get Zoom to apply the DSCP markings for you, so you can act on that and not worry about NBAR.

https://support.zoom.us/hc/en-us/articles/207368756-Using-QoS-DSCP-Marking 

[RJordan-CCS]

Philip,

     we are doing that with our customer's own zoom setup.  However we (and they) cannot do anything about _their_ clients' zoom setups; the people using the coworking spaces generally don't even know if their own organizations configure QoS, or they're using one of the 'free' zoom options which by my understanding do not have the option.  Enabling the Meraki default QoS rules has not noticeably helped with those users.

We've tried a couple of packet traces when we can ID the particular user's device; one had Zoom QoS enabled per the tech who looked at it, the other did not; nothing we can do about the latter.