WebRTC Extensions

{{RTCRtpTransceiver}} extensions

The {{RTCRtpTransceiver}} interface is defined in [[WEBRTC]]. This document extends that interface by adding an additional method and attribute in order to control negotiation of RTP header extensions.

partial dictionary RTCRtpHeaderExtensionCapability {
  required RTCRtpTransceiverDirection direction;
};

partial interface RTCRtpTransceiver {
  sequence<RTCRtpHeaderExtensionCapability> getHeaderExtensionsToNegotiate();
  undefined setHeaderExtensionsToNegotiate(
      sequence<RTCRtpHeaderExtensionCapability> extensions);
  sequence<RTCRtpHeaderExtensionCapability> getNegotiatedHeaderExtensions();
};

Let {{RTCRtpTransceiver/[[HeaderExtensionsToNegotiate]]}} and {{RTCRtpTransceiver/[[NegotiatedHeaderExtensions]]}} be internal slots of the {{RTCRtpTransceiver}}, initialized as follows:

Set {{RTCRtpTransceiver/[[HeaderExtensionsToNegotiate]]}} to the platform-specific list of implemented RTP header extensions. The {{RTCRtpHeaderExtensionCapability/direction}} attribute for all extensions that are mandatory to use MUST be initialized to an appropriate value other than {{RTCRtpTransceiverDirection/"stopped"}}. The {{RTCRtpHeaderExtensionCapability/direction}} attribute for extensions that will not be offered by default in an initial offer MUST be initialized to {{RTCRtpTransceiverDirection/"stopped"}}.

The list of header extensions that MUST/SHOULD be supported is listed in [[RTCWEB-RTP]], section 5.2. The "mid" extension is mandatory to use when BUNDLE is in use, per [[BUNDLE]] section 9.1.
Set {{RTCRtpTransceiver/[[HeaderExtensionsToNegotiate]]}} to an empty list.

Modifications to existing procedures

Make the following modifications to the set a session description algorithm:

In the steps for processing each media description of a remote description (remote is true), after transceiver has been found or created, insert the following steps:
1. If description is of type {{RTCSdpType/"offer"}}, then for each extension in transceiver.{{RTCRtpTransceiver/[[HeaderExtensionsToNegotiate]]}}, run the following steps:
  1. Let offeredDirection be the direction attribute of the "a=extmap" line in the remote offer's media description that correspond to this extension if one exists, otherwise set offeredDirection to {{RTCRtpTransceiverDirection/"stopped"}}.
  2. Reverse offeredDirection to represent the peer's point if view.
  3. If necessary, restrict offeredDirection as to not exceed the user agent's capabilities for this extension.
  4. Set extension.{{RTCRtpHeaderExtensionCapability/direction}} to offeredDirection.
In the later steps for processing a description of type {{RTCSdpType/"answer"}} that runs for both local and remote descriptions, insert the following steps:
1. For each media description and corresponding transceiver, let negotiatedExtensions be the value of transceiver.{{RTCRtpTransceiver/[[HeaderExtensionsToNegotiate]]}}.
2. For each extension in negotiatedExtensions, run the following steps:
  1. Let answeredDirection be the direction attribute of the "a=extmap" line in the answer's media description that correspond to this extension if one exists, otherwise set answeredDirection to {{RTCRtpTransceiverDirection/"stopped"}}.
  2. If description is a remote description, reverse answeredDirection to represent the peer's point of view.
  3. Set extension.{{RTCRtpHeaderExtensionCapability/direction}} to answeredDirection.
3. Set transceiver.{{RTCRtpTransceiver/[[NegotiatedHeaderExtensions]]}} to negotiatedExtensions.

In the algorithms for generating initial offers in [[RTCWEB-JSEP]] section 5.2.1, replace "for each supported RTP header extension, an "a=extmap" line, as specified in [[RFC5285]], section 5" " with "For each RTP header extension "e" listed in {{RTCRtpTransceiver/[[HeaderExtensionsToNegotiate]]}} where {{RTCRtpHeaderExtensionCapability/direction}} is not {{RTCRtpTransceiverDirection/"stopped"}}, an "a=extmap" line, as specified in [[RFC5285]], section 5, with direction taken from "e"'s {{RTCRtpHeaderExtensionCapability/direction}} attribute."

In the algorithm for generating subsequent offers in [[RTCWEB-JSEP]] section 5.2.2, replace "The RTP header extensions MUST only include those that are present in the most recent answer" with "For each RTP header extension listed in {{RTCRtpTransceiver/[[HeaderExtensionsToNegotiate]]}}, and where {{RTCRtpHeaderExtensionCapability/direction}} is not {{RTCRtpTransceiverDirection/"stopped"}}, generate an appropriate "a=extmap" line with "direction" set according to the rules of [[RFC5285]] section 6, considering the {{RTCRtpHeaderExtensionCapability/direction}} in {{RTCRtpTransceiver/[[HeaderExtensionsToNegotiate]]}} to indicate the answerer's desired usage".

In the algorithm for generating initial answers in [[RTCWEB-JSEP]] section 5.3.1, replace "For each supported RTP header extension that is present in the offer" with "For each supported RTP header extension that is present in the offer and is also present in {{RTCRtpTransceiver/[[HeaderExtensionsToNegotiate]]}} with a {{RTCRtpHeaderExtensionCapability/direction}} different from {{RTCRtpTransceiverDirection/"stopped"}}, set the appropriate direction based on {{RTCRtpHeaderExtensionCapability/direction}} that does not exceed the direction in the offer".

Since JSEP does not know about WebRTC internal slots, merging this change requires more work on a JSEP revision.

Methods

getHeaderExtensionsToNegotiate

Execute the following steps:

Let transceiver be the {{RTCRtpTransceiver}} that this method was invoked on.
Return transceiver.{{RTCRtpTransceiver/[[HeaderExtensionsToNegotiate]]}}.

setHeaderExtensionsToNegotiate

Execute the following steps:

Let transceiver be the {{RTCRtpTransceiver}} that this method was invoked on.
Let extensions be the first argument of this method.
If the size of extensions does not match the size of transceiver.{{RTCRtpTransceiver/[[HeaderExtensionsToNegotiate]]}} [=exception/throw=] an {{InvalidModificationError}}.
For each index i of extensions, run the following steps:
1. Let extension be the i-th element of extensions.
2. If extension.{{RTCRtpHeaderExtensionCapability/uri}} is not equal to the {{RTCRtpHeaderExtensionCapability/uri}} of the i-th element of transceiver.{{RTCRtpTransceiver/[[HeaderExtensionsToNegotiate]]}}, [=exception/throw=] an {{InvalidModificationError}}.
3. If extension.{{RTCRtpHeaderExtensionCapability/direction}} is not {{RTCRtpTransceiverDirection/"sendrecv"}} and {{RTCRtpHeaderExtensionParameters/uri}} indicates a mandatory-to-use attribute that is required to be both sent and received, [=exception/throw=] an {{InvalidModificationError}}.
4. If extension.{{RTCRtpHeaderExtensionCapability/direction}} is {{RTCRtpTransceiverDirection/"stopped"}} and {{RTCRtpHeaderExtensionCapability/uri}} indicates a mandatory-to-implement extension, [=exception/throw=] an {{InvalidModificationError}}.
5. If necessary, restrict extension.{{RTCRtpHeaderExtensionCapability/direction}} as to not exceed the user agent's capabilities for this extension.
Set transceiver.{{RTCRtpTransceiver/[[HeaderExtensionsToNegotiate]]}} to extensions.

getNegotiatedHeaderExtensions

Execute the following steps:

Let transceiver be the {{RTCRtpTransceiver}} that this method was invoked on.
Return transceiver.{{RTCRtpTransceiver/[[NegotiatedHeaderExtensions]]}}.

{{RTCRtpReceiver}} extensions

The {{RTCRtpReceiver}} interface is defined in [[WEBRTC]]. This document extends that interface by adding an additional internal slot and attribute.

Let {{RTCRtpReceiver}} objects have a [[\PlayoutDelay]] internal slot initially initialized to null.

partial interface RTCRtpReceiver {
  attribute double? playoutDelay;
  };

Attributes

playoutDelay of type double, nullable

This attribute allows the application to specify a target duration of time between network reception of media and playout. The user agent SHOULD NOT playout audio or video that is received unless this amount of time has passed in seconds, allowing the user agent to perform more or less buffering than it might otherwise do. This allows to influence the tradeoffs between having a higher delay and the risk that buffers such as the jitter buffer will run out of audio or video frames to play due to network jitter.

The user agent may have a minimum allowed delay and a maximum allowed delay reflecting what the user agent is able or willing to provide based on network conditions and memory constraints.

The playout delay hint applies even if DTX is used. For example, if DTX is used and packets start flowing after silence, the hint can influence the user agent to buffer these packets rather than playing them out.

If the track is paired with other tracks through {{RTCRtpReceiver}} [[\AssociatedRemoteMediaStreams]] internal slot, then it will be synchronized with other tracks (for e.g. audio video synchronization). This means that even if one of the paired tracks is delayed through {{RTCRtpReceiver/[[PlayoutDelay]]}} then the user agent synchronization mechanism will automatically delay all others paired tracks. If multiple such paired tracks are delayed through {{RTCRtpReceiver/[[PlayoutDelay]]}} by different amounts then the largest of those hints will take precedence in synchronization mechanism.

The receiver's average delay can be measured as the delta {{RTCInboundRtpStreamStats/jitterBufferDelay}} divided by the delta {{RTCInboundRtpStreamStats/jitterBufferEmittedCount}}.

On getting, this attribute MUST return the value of the {{RTCRtpReceiver/[[PlayoutDelay]]}} internal slot.

On setting, the user agent MUST run the following steps:

Let receiver be the {{RTCRtpReceiver}} object on which the setter is invoked.
Let delay be the argument to the setter.
If delay is negative or larger than 4 seconds then, [=exception/throw=] a {{RangeError}} and abort these steps.
Set the value of receiver's {{RTCRtpReceiver/[[PlayoutDelay]]}} internal slot to delay.
In parallel, begin executing the following steps:
1. Update the underlying system about the new delay request, or that there is no hint if delay is null.
  
  If the given delay value is below minimum allowed delay or above maximum allowed delay then the value used MUST be clamped to minimum allowed delay or maximum allowed delay to be as close as possible to the requested one.
  
  If the user agent chooses a delay different from the requested one (e.g. due to network conditions or physical memory constraints), this is not reflected in the {{RTCRtpReceiver/[[PlayoutDelay]]}} internal slot.
2. Modifying the delay of the underlying system SHOULD affect the internal audio or video buffering gradually in order not to hurt user experience. Audio samples or video frames SHOULD be accelerated or decelerated before playout, similarly to how it is done for audio/video synchronization or in response to congestion control.
  
  The acceleration or deceleration rate may vary depending on network conditions or the type of audio received (e.g. speech or background noise). It MAY take several seconds to achieve 1 second of buffering but SHOULD not take more than 30 seconds assuming packets are being received. The speed MAY be different for audio and video.
  
  For audio, acceleration and deceleration can be measured with {{RTCInboundRtpStreamStats/insertedSamplesForDeceleration}} and {{RTCInboundRtpStreamStats/removedSamplesForAcceleration}}. For video, this may result in the same frame being rendered multiple times or frames may be dropped.

RTCRtpEncodingParameters extensions

The {{RTCRtpEncodingParameters}} dictionary is defined in [[WEBRTC]]. This document extends that dictionary with additional members.

partial dictionary RTCRtpEncodingParameters {
      unsigned long ptime;
      boolean adaptivePtime = false;
    };

Dictionary {{RTCRtpEncodingParameters}} Members

ptime of type unsigned long

The preferred duration of media represented by a packet in milliseconds.

{{RTCRtpEncodingParameters/ptime}} was moved from [[WEBRTC]] to this specification due to lack of support from implementers. It is therefore marked as a feature at risk.

adaptivePtime of type boolean, defaulting to false.

Indicates whether this encoding MAY dynamically change the frame length. If the value is true, the user agent MAY use any valid frame length for any of its frames, and MAY change this at any time. Valid values are multiples of 10ms. If the maxptime attribute (defined in [[RFC4566]] Section 6) is specified, that maximum applies. If the value is false, the user agent MUST use a fixed frame length.

If {{adaptivePtime}} is set to true, {{ptime}} MUST NOT be set; otherwise, {{InvalidModificationError}} MUST be [=exception/throw|thrown=].

Using a longer frame length reduces the bandwidth consumption due to overhead, but does so at the cost of increased latency. Changing the frame length dynamically allows the user agent to adapt its bandwidth allocation strategy based on the current network conditions.

{{RTCRtpContributingSource}} extensions

The {{RTCRtpContributingSource}} dictionary is defined in [[WEBRTC]]. This document extends that dictionary by adding two additional members.

In this section, the capture system refers to the system where media is sourced from and the sender system refers to the system that is sending RTP and RTCP packets to the receiver system where {{RTCRtpContributingSource}} data is populated.

In a direct connection, the capture system is the same as the sender system. But when one or more RTCP-terminating intermediate systems (e.g. mixers) are involved this is not the case. In such cases, media is sourced from the capture system, may be relayed through a number of intermediate systems and is then finally sent from the sender system to the receiver system. The sender system-receiver system path only represents the "last hop".

Despite {{RTCRemoteInboundRtpStreamStats.roundTripTime}} measurements only accounting for the "last hop", one-way delay from the [=capture system=]'s time of capture to the [=receiver system=]'s time of playout can be estimated if the [=RTP Header Extension for Absolute Capture Time=] is used all hops of the way, where each RTCP-terminating intermediate system appropriately updates the [=estimated capture clock offset=].

partial dictionary RTCRtpContributingSource {
      DOMHighResTimeStamp captureTimestamp;
      DOMHighResTimeStamp senderCaptureTimeOffset;
    };

Dictionary {{RTCRtpContributingSource}} Members

captureTimestamp of type {{DOMHighResTimeStamp}}.

The {{captureTimestamp}} is the timestamp that, the most recent frame (from an RTP packet originating from this source) delivered to the {{RTCRtpReceiver}}'s {{MediaStreamTrack}}, was originally captured. Its reference clock is the capture system's NTP clock (same clock used to generate NTP timestamps for RTCP sender reports on that system).

On populating this member, the user agent MUST run the following steps:

If the relevant RTP packet contains the RTP Header Extension for Absolute Capture Time, return the value of the absolute capture timestamp field and abort these steps.
Otherwise, if the relevant RTP packet does not contain the RTP Header Extension for Absolute Capture Time but a previous RTP packet did, return the result of calculating the absolute capture timestamp according to timestamp interpolation and abort these steps.
Otherwise, return undefined.

If multiple receiving tracks are sourced from the same capture system, two {{captureTimestamp}}s can be used to accurately measure audio-video synchronization since both timestamps are based on the same system's clock.

senderCaptureTimeOffset of type {{DOMHighResTimeStamp}}.

The {{senderCaptureTimeOffset}} is the sender system's estimate of the offset between its own NTP clock and the capture system's NTP clock, for the same frame that the {{captureTimestamp}} was originated from.

On populating this member, the user agent MUST run the following steps:

If the relevant RTP packet contains the RTP Header Extension for Absolute Capture Time and the estimated capture clock offset field is present, return the value of the estimated capture clock offset field and abort these steps.
Otherwise, if the relevant RTP packet does not contain the RTP Header Extension for Absolute Capture Time's estimated capture clock offset field, but a previous RTP packet did, return the most recent value that was present and abort these steps.
Otherwise, return undefined.

The time of capture can estimatedly be expressed in the sender system's clock as follows: senderCaptureTimestamp = {{captureTimestamp}} + {{senderCaptureTimeOffset}}.

The offset between the sender system's clock and the receiver system's clock can be estimated as follows: senderReceiverTimeOffset = {{RTCRemoteOutboundRtpStreamStats}}.timestamp}} - ({{RTCRemoteOutboundRtpStreamStats.remoteTimestamp}} + {{RTCRemoteInboundRtpStreamStats.roundTripTime}} / 2).

The time of capture can estimatedly be expressed in the receiver system's clock as follows: receiverCaptureTimestamp = senderCaptureTimestamp + senderReceiverTimeOffset.

The one-way delay between the capture system's time of capture and the receiver system's time of playout can be estimated as follows: {{RTCRtpContributingSource.timestamp}} - receiverCaptureTimestamp.

{{RTCDataChannel}} extensions

Transferable Data Channels

This document extends {{RTCDataChannel}} by making it transferable.

This allows sending and receiving messages outside the context the connection was created, for instance in workers or third-party iframes.

The WebIDL changes are the following:

[Exposed=(Window,Worker), Transferable]
partial interface RTCDataChannel {
};

The create an RTCDataChannel algorithm is updated by adding the following steps after step 4 of the original algorithm:

Initialize channel.`[[IsTransferable]]` to true.
Queue a task to run the following step:
1. Set channel.`[[IsTransferable]]` to false.

This task needs to run before any task enqueued by the receiving messages on a data channel algorithm for channel. This ensures that no message is lost during the transfer of a {{RTCDataChannel}}.

The send() algorithm is modified by adding the following step after step 1 of the original algorithm:

Set channel.`[[IsTransferable]]` to false.

The {{RTCDataChannel}} transfer steps, given value and dataHolder, are:

If value.`[[IsTransferable]]` is false, throw a "DataCloneError" DOMException.
Set dataHolder.`[[ReadyState]]` to value.`[[ReadyState]]`.
Set dataHolder.`[[DataChannelLabel]]` to value.`[[DataChannelLabel]]`.
Set dataHolder.`[[Ordered]]` to value.`[[Ordered]]`.
Set dataHolder.`[[MaxPacketLifeTime]]` to value..`[[MaxPacketLifeTime]]`
Set dataHolder.`[[MaxRetransmits]]` to value.`[[MaxRetransmits]]`.
Set dataHolder.`[[DataChannelProtocol]]` to value.`[[DataChannelProtocol]]`.
Set dataHolder.`[[Negotiated]]` to value.`[[Negotiated]]`.
Set dataHolder.`[[DataChannelId]]` to value.`[[DataChannelId]]`.
Set dataHolder.`[[underlyingDataTransport]]` to value underlying data transport.
Set value.`[[IsTransferable]]` to false.
Set value.`[[ReadyState]]` to "closed".

The {{RTCDataChannel}} transfer-receiving steps, given dataHolder and channel, are:

Initialize channel.`[[ReadyState]]` to dataHolder.`[[ReadyState]]`.
Initialize channel.`[[DataChannelLabel]]` to dataHolder.`[[\DataChannelLabel]]`.
Initialize channel.`[[Ordered]]` to dataHolder.`[[Ordered]]`.
Initialize channel.`[[MaxPacketLifeTime]]` to dataHolder.`[[MaxPacketLifeTime]]`.
Initialize channel.`[[MaxRetransmits]]` to dataHolder.`[[MaxRetransmits]]`.
Initialize channel.`[[DataChannelProtocol]]` to dataHolder.`[[DataChannelProtocol]]`.
Initialize channel.`[[Negotiated]]` to dataHolder.`[[Negotiated]]`.
Initialize channel.`[[DataChannelId]]` to dataHolder.`[[DataChannelId]]`.
Initialize channel underlying data transport to dataHolder.`[[underlyingDataTransport]]`.

The above steps do not need to transfer `[[BufferedAmount]]` as its value will always be equal to 0. The reason is an {{RTCDataChannel}} can be transferred only if its send() algorithm was not called prior the transfer.

If the underlying data transport is closed at the time of the transfer-receiving steps, the {{RTCDataChannel}} object will be closed by running the announcing a data channel as closed algorithm immediately after the transfer-receiving steps.

RTP Header Extension Encryption

RTCRtpHeaderEncryptionPolicy Enum

RTP header extension encryption policy affects whether RTP header extension encryption is negotiated if the remote endpoint does not support [[CRYPTEX]]. If the remote endpoint supports [[CRYPTEX]], all media streams are sent utilizing [[CRYPTEX]].

enum RTCRtpHeaderEncryptionPolicy {
"negotiate",
"require"
};

Enumeration description (non-normative)

Enumeration description (non-normative)
negotiate	Negotiate RTP header extension encryption as defined in [[CRYPTEX]]. If encryption cannot be negotiated, RTP header extensions are sent in the clear.
require	Require RTP header extension encryption. In [[WEBRTC]] Section 4.4.1.5, add the following check after Step 4.4.4: If `remote` is `true`, the `connection`'s {{RTCRtpHeaderEncryptionPolicy}} is {{RTCRtpHeaderEncryptionPolicy/require}} and the description does not support [[CRYPTEX]], then [= reject =] `p` with a newly [= exception/created =] {{InvalidAccessError}} and abort these steps.

negotiate

Negotiate RTP header extension encryption as defined in [[CRYPTEX]]. If encryption cannot be negotiated, RTP header extensions are sent in the clear.

require

Require RTP header extension encryption. In [[WEBRTC]] Section 4.4.1.5, add the following check after Step 4.4.4: If remote is true, the connection's {{RTCRtpHeaderEncryptionPolicy}} is {{RTCRtpHeaderEncryptionPolicy/require}} and the description does not support [[CRYPTEX]], then [= reject =] p with a newly [= exception/created =] {{InvalidAccessError}} and abort these steps.

{{RTCRtpTransceiver}} extensions

{{RTCRtpTransceiver/rtpHeaderEncryptionNegotiated}} defines whether the transceiver is sending enrypted RTP header extensions as defined in [[CRYPTEX]].

partial interface RTCRtpTransceiver {
  readonly attribute boolean rtpHeaderEncryptionNegotiated;
};

Attributes

rtpHeaderEncryptionNegotiated of type Boolean, readonly, nullable: The {{rtpHeaderEncryptionNegotiated}} attribute indicates whether [[CRYPTEX]] has been negotiated. On getting, the attribute MUST return the value of the {{RTCRtpTransceiver/[[RtpHeaderEncryptionNegotiated]]}} slot. In [[WEBRTC]] Section 5.4, add the following step to "create an {{RTCRtpTransceiver}}": Let transceiver have a [[\RtpHeaderEncryptionNegotiated]] internal slot, initialized to false.

{{RTCConfiguration}} extensions

{{RTCConfiguration/rtpHeaderEncryptionPolicy}} defines the policy for negotiation of RTP header encryption using [[CRYPTEX]].

partial dictionary RTCConfiguration {
  RTCRtpHeaderEncryptionPolicy rtpHeaderEncryptionPolicy = "negotiate";
};

Dictionary {{RTCConfiguration}} Members

rtpHeaderEncryptionPolicy of type RTCRtpHeaderEncryptionPolicy: {{RTCConfiguration/rtpHeaderEncryptionPolicy}} is marked as a feature at risk, since there is no clear commitment from implementers.

Disabling hardware acceleration

While hardware acceleration of video encoding and decoding is generally desirable, it has proven to be operationally challenging to achieve in the environment of a browser with no detailed information about the underlying hardware. In some cases, falling back to software encoding yields better results.

The methods specified in this section should be used sparingly and not for extended amounts of time.

In privacy-sensitive contexts, browsers may disable hardware acceleration by default to reduce the fingerprinting surface.

{{RTCRtpReceiver}} extensions

The {{RTCRtpReceiver}} interface is defined in [[WEBRTC]]. This document extends this interface by adding a static method and internal slot {{RTCRtpReceiver/[[HardwareDisabled]]}} initialized to false.

partial interface RTCRtpReceiver {
    static undefined disableHardwareDecoding();
};

When the {{RTCRtpReceiver}}'s disableHardwareDecoding method is called, the user agent MUST run the following steps:

When the RTCPeerConnection.constructor() has been invoked abort these steps.
Set the RTCRtpReceiver's {{RTCRtpReceiver/[[HardwareDisabled]]}} slot to true.

{{RTCRtpSender}} extensions

The {{RTCRtpSender}} interface is defined in [[WEBRTC]]. This document extends this interface by adding a static method and internal slot {{RTCRtpSender/[[HardwareDisabled]]}} initialized to false.

partial interface RTCRtpSender {
    static undefined disableHardwareEncoding();
};

When the {{RTCRtpSender}}'s disableHardwareEncoding method is called, the user agent MUST run the following steps:

When the RTCPeerConnection.constructor() has been invoked abort these steps.
Set the RTCRtpSender's {{RTCRtpSender/[[HardwareDisabled]]}} slot to true.

Modifications to existing procedures

In the set a session description algorithm, add a step right after the step that sets transceiver.[[\Receiver]].[[\ReceiveCodecs]], saying "If the RTCRtpReceiver's {{RTCRtpReceiver/[[HardwareDisabled]]}} slot is true, remove any codec from transceiver.[[\Receiver]].[[\ReceiveCodecs]] for which the underlying decoder is hardware-accelerated".

In the set a session description algorithm, add a step right after the step that sets transceiver.[[\Sender]].[[\SendCodecs]], saying "If the RTCRtpSender's {{RTCRtpSender/[[HardwareDisabled]]}} slot is true, remove any codec from transceiver.[[\Sender]].[[\SendCodecs]] for which the underlying encoder is hardware-accelerated".

Introduction

Terminology

Overviews

RTP header control

{{RTCPeerConnection}} extensions

Modifications to existing procedures

{{RTCRtpTransceiver}} extensions

Modifications to existing procedures

Methods

{{RTCRtpReceiver}} extensions

Attributes

RTCRtpEncodingParameters extensions

Dictionary {{RTCRtpEncodingParameters}} Members

{{RTCRtpContributingSource}} extensions

Dictionary {{RTCRtpContributingSource}} Members

{{RTCDataChannel}} extensions

Transferable Data Channels

RTP Header Extension Encryption

RTCRtpHeaderEncryptionPolicy Enum

{{RTCRtpTransceiver}} extensions

Attributes

{{RTCConfiguration}} extensions

Dictionary {{RTCConfiguration}} Members

Disabling hardware acceleration

{{RTCRtpReceiver}} extensions

{{RTCRtpSender}} extensions

Modifications to existing procedures

Security Considerations

Impact on local network

Confidentiality of Communications

Privacy Considerations

Revealing IP addresses

Persistent information exposed by WebRTC

Accessibility Considerations

Acknowledgements