This API defines a control surface for manipulating the network
control bits (DSCP bits) of outgoing WebRTC packets, and the
queueing priority of outgoing WebRTC packets under congestion.
Status of this document
This section describes the status of this document at the time of
its publication. Other documents may supersede this document. A list of
current W3C publications and the latest revision of this technical report
can be found in the W3C technical reports
index at https://www.w3.org/TR/.
If you wish to make comments regarding this document, please send them to firstname.lastname@example.org (subscribe, archives).
When sending e-mail,
please put the text “webrtc-priority” in the subject,
preferably like this:
“[webrtc-priority] …summary of comment…”.
All comments are welcome.
Publication as a Working Draft does not imply endorsement by the W3C
Membership. This is a draft document and may be updated, replaced or
obsoleted by other documents at any time. It is inappropriate to cite this
document as other than work in progress.
This document defines a "priority" field as part of the WEBRTC RTCRtpEncodingParameters structure, with the possible values "very-low",
"low", "medium" and "high".
This feature was originally part of the [WEBRTC] specification, but was
removed in November 2019 due to lack of implementation
experience. It is now part of this document.
In addition, this specification adds fields to RTCRtpEncodingParameters that allow control over the DSCP markings without affecting local
prioritization, and vice versa.
2. Priority and QoS Model
Many applications have multiple media flows of the same data type and
often some of the flows are more important than others. WebRTC uses the
priority and Quality of Service (QoS) framework described in [RTCWEB-TRANSPORT] and [TSVWG-RTCWEB-QOS] to provide priority and
DSCP marking for packets that will help provide QoS in some networking
environments. The priority setting can be used to indicate the relative
applications to tell the browser whether a particular media flow is high,
medium, low or of very low importance to the application by setting the priority property of RTCRtpEncodingParameters objects to one of the
values defined below.
Applications that use this API should be aware that often better
overall user experience is obtained by lowering the priority of things
that are not as important rather than raising the priority of the things
The priority attribute returns the priority for
this RTCDataChannel. The priority is assigned
by the user agent at channel creation time. On getting, the
attribute MUST return the value of the
Conformance requirements are expressed with a combination of descriptive assertions and RFC 2119 terminology.
The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL”
in the normative parts of this document
are to be interpreted as described in RFC 2119.
However, for readability,
these words do not appear in all uppercase letters in this specification.
All of the text of this specification is normative
except sections explicitly marked as non-normative, examples, and notes. [RFC2119]
Examples in this specification are introduced with the words “for example”
or are set apart from the normative text with class="example", like this:
This is an example of an informative example.
Informative notes begin with the word “Note”
and are set apart from the normative text with class="note", like this: