The QOS label is based on the DSCP or the COS value in the packet and decides the queueing and scheduling actions to perform on the packet.
The qos label is mapped according to the trust setting and the packet type. Essentially you specify which fields you want to classify for incoming traffic.
For non-ip traffic you obviously want to trust COS, trusing DSCP of IP PREC is meaningless unless the fields are IP. By trusting DSCP or IP PREC for non ip traffic will result in generating a DSCP value from the COS label in the packet. If there was no COS, the default port COS value will be applied, and the DSCP label will be derived from that.
For IP traffic you have three classifications, two of which you are already aware of, trust DSCP which defines the six most-significant bits of the TOS field. Secondly trust IP PREC, which will generate a DSCP value for the IP packet using the IP-PREC-to-DSCP map.
The third classification for both IP and non IP traffic is to configure QoS ACLs on the interface, as in your case. This will assign the DSCP as specified by the ACL to generate the QoS label.
If the DSCP label on the incoming frame is trusted on the router, then there is no apparent reason to rewrite the DSCP in these frames. I would obviously understand if there was uncertainty, and if so, then I would ensure that DSCP is set identical to the DSCP in the packet.
If the incoming frames can be trusted, then the class map should be configured to match packets based on the DSCP label for example 46 or EF for RTP for correct policing.
