WebRTC Priority Control API

1. Introduction

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 priority of various flows. The priority API allows the JavaScript 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.

3. Extensions for media priority

3.1. RTCPriorityType Enum

enum RTCPriorityType {
  "very-low",
  "low",
  "medium",
  "high"
};

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 that are.

3.2. Extension to RTCRtpEncodingParameters

partial dictionary RTCRtpEncodingParameters {
  RTCPriorityType priority = "low";
  RTCPriorityType networkPriority;
};

priority, of type RTCPriorityType, defaulting to "low"

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.

networkPriority, of type RTCPriorityType

This has the same effect as priority, except that it only affects the DSCP markings of the generated packets, as described in [rfc8835] section 4.2.

If networkPriority is unset, the DSCP markings of the generated packets are controlled by the priority member.

4. Extensions for RTCDataChannel

partial interface RTCDataChannel {
  readonly attribute RTCPriorityType priority;
};

partial dictionary RTCDataChannelInit {
  RTCPriorityType priority = "low";
};

4.1. New RTCDataChannel attribute

priority, of type RTCPriorityType, readonly

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 [[DataChannelPriority]] slot.

4.2. New RTCDataChannelInit member

priority, of type RTCPriorityType, defaulting to "low"

Priority of this channel.

4.3. RTCDataChannel processing steps

The following steps are added to the initialization steps for DataChannel:

Let DataChannel have an internal slot [[DataChannelPriority]].

In the processing steps for initializing a DataChannel, insert the following step into processing the option argument:

• Initialize channel.[[DataChannelPriority]] to option’s priority member.

• For an incoming DataChannel, initialize channel.[[DataChannelPriority]] based on the integer priority value in configuration, according to the following mapping.

5. Security and Privacy Considerations

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.