WebRTC DSCP Control API

Editor’s Draft,

This version:
http://w3c.github.io/webrtc-dscp-exp/
Feedback:
public-webrtc@w3.org with subject line “[webrtc-dscp-exp] … message topic …” (archives)
Issue Tracking:
GitHub
Editor:
(Google)

Abstract

This API defines a control surface for manipulating the network control bits (DSCP bits) of outgoing WebRTC packets.

Status of this document

This is a public copy of the editors’ draft. It is provided for discussion only and may change at any moment. Its publication here does not imply endorsement of its contents by W3C. Don’t cite this document other than as work in progress.

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-exp” in the subject, preferably like this: “[webrtc-dscp-exp] …summary of comment…”. All comments are welcome.

This document was produced by the Web Real-Time Communications Working Group.

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.

This document is governed by the 1 February 2018 W3C Process Document.

1. Introduction

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.

2. IDL specification

partial dictionary RTCRtpEncodingParameters {
    RTCPriorityType networkPriority;  // Note: No default
};

2.1. networkPriority definition

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:

Note, this is an informative note.

Index

Terms defined by this specification

Terms defined by reference

References

Normative References

[RFC2119]
S. Bradner. Key words for use in RFCs to Indicate Requirement Levels. March 1997. Best Current Practice. URL: https://tools.ietf.org/html/rfc2119
[WEBRTC]
Adam Bergkvist; et al. WebRTC 1.0: Real-time Communication Between Browsers. 27 September 2018. CR. URL: https://www.w3.org/TR/webrtc/

Informative References

[RTCWEB-TRANSPORT]
H. Alvestrand. Transports for RTCWEB. 31 October 2016. Active Internet-Draft. URL: https://tools.ietf.org/html/draft-ietf-rtcweb-transports

IDL Index

partial dictionary RTCRtpEncodingParameters {
    RTCPriorityType networkPriority;  // Note: No default
};