An impressive set of policies, using QoS groups the way you have. Mind you, personally I would write a similar policy in a more condensed manner (I show how, below) and would approach an actual policy differently, but again, I don't believe I've seen anyone else use QoS groups as well. Just curious, did you find this approach documented somewhere or did you figure it out yourself?
Anyway, you could obtain similar using something like:
class-map match-any CM_QOS-G7
match ip precedence 5
match protocol ms-teams-audio
class-map match-any CM_QOS-G6
match precedence 4
match protocol ms-teams-video
match protocol ms-teams-media
class-map match-any CM_QOS-G5
match precedence 6 7
class-map match-any CM_QOS-G2
match precedence 2
match protocol ms-teams-app-sharing
policy-map OUT
class CM_QOS-G7
PRIORITY percent 20
set dscp ef
class CM_QOS-G6
bandwidth percent 20
set dscp af41
class CM_QOS-G5
bandwidth percent 20
class CM_QOS-G2
bandwidth percent 20
class class-default
bandwidth percent 20
Again, nothing wrong, in principal, with what you did. The above is just a way to use only an out policy and less class maps.
If you do use both an input and output policy, remember, the input policy would be on the LAN interface(s) and the output policy on the WAN interface.
This:
class CM_QOS-G7
bandwidth percent 20
PRIORITY percent 10
is incorrect. You use either the bandwidth or the priority keyword.
Router(config-pmap-c)#?
bandwidth Bandwidth
exit Exit from class action configuration mode
fair-queue Enable Flow-based Fair Queuing in this class
no Negate or set default values of a command
priority Strict Scheduling Priority for this Class
queue-limit Queue Max Threshold for Tail Drop
random-detect Enable Random Early Detection as drop policy
service-policy Configure Flow Next
set Set QoS values
shape Traffic Shaping
"I have planned to apply this only on WAN uplinks and also need your ideas if we can apply this in User connected ports as well to improve the Teams audio and video performance..?"
Well, firstly QoS books recommend using QoS configs, end-to-end, and the best reason for doing so is you don't overlook configuring QoS where it's truly needed. However, if QoS isn't truly needed, then you also don't need to configure it. As (sorry, but again) there's insufficient information to say whether your user interfaces need QoS configurations.
That said, if all your traffic is to/from the WAN gig link, and there's no branch host-to-host traffic, and your hosts are also gig interfaces, they could not become congested.
Also keep in mind, Cisco QoS features vary by platforms, Cisco switches, almost always, are much less QoS capable than Cisco routers. For example, features like protocol matching, in the past, usually not supported on Cisco switches. I.e. possibly you couldn't have exactly the same policy.
Also BTW, Cisco routers' QoS often support (what I consider to be) a very powerful QoS feature, fair-queue. This policy class feature attempts to provide every flow, within a class, the same ratio of bandwidth, which, is actually what you appear to be doing between your classes (if each has a 20% allocation - although LLQ's 20% is not exactly the same "equal").
In my, not so humble, opinion, FQ does so well, when the platforms supports it, I generally suggest the following policy-map:
policy-map GeneralPurpose
class real-time
priority percent 35
class Foreground
bandwidth remaining percent 81
fair-queue
class Background
bandwidth remaining percent 1
fair-queue
class class-default
bandwidth remaining percent 9
fair-queue
In such a policy, traffic like VoIP or video conferencing go into the real-time class, mostly everything else goes into class-default. If there's something that really, really (really) needs prioritization I direct it to the Foreground class. If there something that's a bandwidth hog, but will happily run with whatever bandwidth it gets, I'll drop that into the Background class. (BTW the way, to understand bandwidth allocations is they determine ratios when all classes want that much bandwidth or more, but it's not reserved otherwise. So, for example, a flow in the Background class could obtain 100% of link bandwidth, when it's otherwise unused, but can be pushed down to a tiny bandwidth allocation when other traffic wants bandwidth. However, it won't be totally starved of bandwidth. [In usage, what you might observe is such Background flows causing a link to run at 100% utilization, yet all other traffic acts as if the link is almost 100% bandwidth available. For example if you ping across such a QoS configured link, assuming your pings are also in the default class, and there's no traffic in real-time or Foreground classes, ping times might be almost identical for link usage 1% or 100%.])
