@nikmagashi I’m assuming by Teams you are referring to Microsoft Teams. In this case I’m not sure you’re going to be prioritising traffic as you expect. Microsoft Teams uses HTTPS-based REST calls for most of its signalling and I don’t believe the “All VoIP and Video Conferencing” captures these, and it definitely can’t apply any smarts to determine the real-time streams since the signalling is encrypted. The notable exception to this is signalling to a SBC for which Microsoft Teams uses SIP, and the rules “All VoIP and Video Conferencing” should catch this.
If you use the article that @DarrenOC referenced you can determine the ports used for the various traffic types in Microsoft Team and create rules to identify the Microsoft Teams traffic based on these and then mark (I.e. assign a DSCP tag), shape and prioritise appropriately. You should only need a few rules at most, one to identify/mark audio traffic, one for video, and one for application/screen sharing.
You don’t mention anything about where this traffic is going. Is it going straight to the internet, or over a AutoVPN to another site? If it’s straight to the internet then there is little point in marking the traffic as the marking will be lost/ignored the minute the traffic hits the internet. If you’re using AutoVPN then by all means mark the traffic and the markings will be carried to the other site. But you are right to use the the priority to ensure the real-time traffic leaves the MX in-front of other traffic.
After all that is said, if you’re currently not seeing any performance issues with your Teams calls at the moment, you probably won’t get any benefit from QoS. However, if you’re having issues then it’s worth working through it.
