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/.
This document was published by the Web Real-Time Communications Working Group as a Candidate Recommendation Snapshot. This document is intended to become a W3C Recommendation.
This document will remain a Candidate Recommendation at least until in order
to ensure the opportunity for wide review.
If you wish to make comments regarding this document, please file an issue or 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 Candidate Recommendation does not imply endorsement by the W3C Membership. A Candidate Recommendation Snapshot has received wide review and is intended to gather implementation experience.
The entrance criteria for this document to enter the Proposed Recommendation stage
is to have a minimum of two independent and interoperable implementations of all the features of this specification, which will be determined by
passing the tests defined in the test suite developed by the Working
Group. The Working Group will prepare an implementation report to track 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 [rfc8835] and [rfc8837] 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
Indicates the priority of an RTCRtpSender, which influences the
bandwidth allocation among RTCRtpSender objects. It is specified
in [rfc8835], Section 4. The user agent is free to sub-allocate bandwidth
between the encodings of an RTCRtpSender.
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
This API extension does not, per se, expose any new information, and none of the data handled
through this extension can be considered sensitive or personally identifiable.
In conjunction with the ability to monitor network traffic, it is possible to use this
extension to figure out which parts of the specification are actually honored by the
implementation; in particular, whether setting priority causes modification of DSCP markings
on the generated packets.
This specification allows some control over parts of network headers that are commonly used for
prioritization of network traffic (DSCP markings). If the network to which the UA is attached is
misconfigured or underprovisioned, this may influence the local network environment by emitting
packets with DSCP markings that are not expected by the configuration.
Countermeasures against this risk include proper configuration; the simplest configuration is DSCP
bleaching - always zeroing or ignoring the DSCP markings. Congestion control (always mandatory for
WebRTC) will prevent network overload in most cases.
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
This is an example of an informative example.
Informative notes begin with the word “Note”
and are set apart from the normative text
Note, this is an informative note.
Requirements phrased in the imperative as part of algorithms
(such as "strip any leading space characters"
or "return false and abort these steps")
are to be interpreted with the meaning of the key word
("must", "should", "may", etc)
used in introducing the algorithm.