This API defines a control surface for manipulating the network
control bits (DSCP bits) of outgoing WebRTC packets.
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 public-webrtc@w3.org (subscribe, archives).
When sending e-mail,
please put the text “webrtc-dscp” in the subject,
preferably like this:
“[webrtc-dscp] …summary of comment…”.
All comments are welcome.
This document is a First Public Working Draft.
Publication as a First Public 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 was produced by a group operating under
the W3C Patent Policy.
W3C maintains a public list of any patent disclosures made in connection with the deliverables of the group;
that page also includes instructions for disclosing a patent.
An individual who has actual knowledge of a patent which the individual believes contains Essential Claim(s) must disclose the information in accordance with section 6 of the W3C Patent Policy.
The [WEBRTC] spec defines a "priority" field as part of its
RTCRtpEncodingParameters structure, with the possible values "very-low",
"low", "medium" and "high".
This specification adds a field to RTCRtpEncodingParameters that allows
control over the DSCP markings without affecting local prioritization.
networkPriority has the same
effect as priority, except that it only affects the DSCP markings of
the generated packets, as described in [RTCWEB-TRANSPORT] section 4.2.
If networkPriority is unset, the DSCP markings of the generated
packets are controlled by the priority member.
Conformance
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: