Wrong voice port for conferencing used

In this documentation: https://learn.microsoft.com/en-us/microsoftteams/microsoft-teams-online-call-flows

There is following sentence: Note that open connectivity to TCP ports 80 and 443, and to UDP ports 3478 (STUN), 3479 (Audio), 3480 (Video), and 3481 (sharing/VBSS) are required.

In this documentation: https://learn.microsoft.com/en-us/microsoftteams/qos-in-teams

There is following bit about port ranges used:

Now we were doing some wiresharking and configured DSCP marking with a corresponding GPO. In wireshark we created some coloring rules that mark the different traffic classes like audio, video and screenshare. We can confirm that everything we see in wireshark, matches the documentation for a 1-to-1 call. The source ports are chosen in the correct range and we can see this diretly in wireshark when we enable video or screenshare (because of the coloring rules). 

BUT: if we do conferencing which means we will talk to the Teams server instead of P2P, we see a inconsistancy.

Good Example1:

We see traffic originating from my client with UDP source port 50042 and destination port 3481 is going out. This indeed is screen sharing as we were testing on the client. The destination port confirms this as it matches the port in the documentation. The source port verifies this as well as it is in the 50,040–50,059 range.

Good Example2:

We see traffic originating from my client with UDP source port 50035 and destination port 3480 is going out. This indeed is video traffic as we were testing on the client. The destination port confirms this as it matches the port in the documentation. The source port verifies this as well as it is in the 50,020–50,039 range. 

Bad Example:

We see traffic originating from my client with UDP source port 50014 and destination port 3480 is going out. This is voice traffic, as we were not sharing video or screenshare during this time. The source port verifies this as well as it is in the 50,000–50,019 range. But the destination port should be 3479 but instead it uses the same port as the video does and is inconsitent with the documentation I linke above.

Can anyone explain this? Is audio just carried within video as well? Can we change this somehow?

We really would like to "catch" this traffic and assign corresponding DSCP markings as the return traffic enters into our network (WAN2LAN) in order to prioritize the voice over the video in its respective class. But as voice uses the same port as video does, it is impossible to differenciate the two classes with an ACL.