Change:
Updated terminology.
On reading the document, I find that the term "media flow" is used where draft-ietf-avtext-rtp-grouping-taxonomy suggests "source stream". Still open what to use instead of "data flow". "Data stream"?
After reconsidering, I added a definition for "flow" instead. Let's see how that scans.
rtcweb-transport: "normal", "below normal", "high" or "very high". tsvwg-rtcweb-qos: “very low”, “low”, “medium”, “high”. WEBRTC-PC: enum RTCPriorityType { "very-low", "low", "medium", "high" }; The majority should win.

Discussion:
Transports for WebRTC <del> draft-ietf-rtcweb-transports-10 </del> <ins> draft-ietf-rtcweb-transports-11 </ins> Abstract

overview, which also defines terminology used in this document, including the terms "WebRTC device" and "WebRTC browser". <ins> Terminology for RTP sources is taken fromRFC7656 . </ins> This document focuses on the data transport protocols that are used by conforming implementations, including the protocols used for interaction with intermediate boxes such as firewalls, relays and NAT

4. The WebRTC prioritization model is that the application tells the <del> WebRTC implementation about the priority of media and data flows through an API. </del> <ins> WebRTC implementation about the priority of media and data that is controlled from the API. In this context, a "flow" is used for the units that are given a specific priority through the WebRTC API. For media, a "media flow", which can be an "audio flow" or a "video flow", is what RFC7656 calls a "media source", which results in a "source RTP stream" and one or more "redundancy RTP streams".  This specification does not describe prioritization between the RTP streams that come from a single "media source". A "data flow" is the outgoing data on a single WebRTC data channel. </ins> <del> The priority associated with a media or data flow is classified as "normal", "below normal", "high" or "very high".  There are only four </del> <ins> The priority associated with a media flow or data flow is classified as "very-low", "low", "medium or "high".  There are only four </ins> priority levels at the API. The priority settings affect two pieces of behavior: Packet send

based on the stream a packet belongs to. When an WebRTC implementation has packets to send on multiple streams <del> (with each media stream and each data channel considered as one "stream" for this purpose) that are congestion-controlled under the same congestion controller, the WebRTC implementation SHOULD cause data to be emitted in such a way that each stream at each level of priority is being given approximately twice the transmission capacity (measured in payload bytes) of the level below. Thus, when congestion occurs, a "very high" priority flow will have the ability to send 8 times as much data as a "below normal" flow if </del> <ins> that are congestion-controlled under the same congestion controller, the WebRTC implementation SHOULD cause data to be emitted in such a way that each stream at each level of priority is being given approximately twice the transmission capacity (measured in payload bytes) of the level below. Thus, when congestion occurs, a "high" priority flow will have the ability to send 8 times as much data as a "very-low" priority flow if </ins> both have data to send.  This prioritization is independent of the media type.  The details of which packet to send first are implementation defined. <del> For example: If there is a very high priority audio flow sending 100 byte packets, and a normal priority video flow sending 1000 byte packets, and outgoing capacity exists for sending >5000 payload bytes, it would be appropriate to send 4000 bytes (40 packets) of audio and 1000 bytes (one packet) of video as the result of a single pass of sending decisions. </del> <ins> For example: If there is a high priority audio flow sending 100 byte packets, and a low priority video flow sending 1000 byte packets, and outgoing capacity exists for sending >5000 payload bytes, it would be appropriate to send 4000 bytes (40 packets) of audio and 1000 bytes (one packet) of video as the result of a single pass of sending decisions. </ins> <del> Conversely, if the audio flow is marked normal priority and the video flow is marked very high priority, the scheduler may decide to send 2 </del> <ins> Conversely, if the audio flow is marked low priority and the video flow is marked high priority, the scheduler may decide to send 2 </ins> video packets (2000 bytes) and 5 audio packets (500 bytes) when outgoing capacity exists for sending > 2500 payload bytes. <del> If there are two very high priority audio flows, each will be able to send 4000 bytes in the same period where a normal priority video flow is able to send 1000 bytes. </del> <ins> If there are two high priority audio flows, each will be able to send 4000 bytes in the same period where a low priority video flow is able to send 1000 bytes. </ins> Two example implementation strategies are: