GV

GeezerVison

The World Wide Web, restored to 800 pixels of glory.

Home|About|Gaming cabinet|Archives|How it works|Starter sites

On this site

  • close

This view

  • Original page
  • New address

GeezerVison is showing w3c.github.io (truncated) — WebRTC: Real-Time Communication in Browsers

Initial Author of this Specification was Ian Hickson, Google Inc., with the following copyright statement:
© Copyright 2004-2011 Apple Computer, Inc., Mozilla Foundation, and Opera Software ASA. You are granted a license to use, reproduce and create derivative works of this document. All subsequent changes since 26 July 2011 done by the W3C WebRTC Working Group are under the following Copyright:
Copyright © 2011-2025 World Wide Web Consortium. W3C® liability, trademark and permissive document license rules apply.

This document defines a set of ECMAScript APIs in WebIDL to allow media and generic application data to be sent to and received from another browser or device implementing the appropriate set of real-time protocols. This specification is being developed in conjunction with a protocol specification developed by the IETF RTCWEB group and an API specification to get access to local media devices.

This document includes Candidate Amendments.

Its associated test suite has been used to build an implementation report of the API at the time of its initial publication as a Recommendation. That test suite has been updated to integrate proposed and candidates amendments identified since then, and an updated implementation report focused on the implementation status of these amendments has been used to select features with double implementation as proposed amendments, now fully incorporated in this version of the Recommendation.

Introduction

There are a number of facets to peer-to-peer communications and video-conferencing in HTML covered by this specification:

  • Connecting to remote peers using NAT-traversal technologies such as ICE, STUN, and TURN.
  • Sending the locally-produced tracks to remote peers and receiving tracks from remote peers.
  • Sending arbitrary data directly to remote peers.

This document defines the APIs used for these features. This specification is being developed in conjunction with a protocol specification developed by the IETF RTCWEB group and an API specification to get access to local media devices [[GETUSERMEDIA]] developed by the WebRTC Working Group. An overview of the system can be found in [[RFC8825]] and [[RFC8826]].

This specification defines conformance criteria that apply to a single product: the user agent that implements the interfaces that it contains.

Conformance requirements phrased as algorithms or specific steps may be implemented in any manner, so long as the end result is equivalent. (In particular, the algorithms defined in this specification are intended to be easy to follow, and not intended to be performant.)

Implementations that use ECMAScript to implement the APIs defined in this specification MUST implement them in a manner consistent with the ECMAScript Bindings defined in the Web IDL specification [[!WEBIDL]], as this specification uses that specification and terminology.

Terminology

The {{EventHandler}} interface, representing a callback used for event handlers, is defined in [[!HTML]].

The concepts [= queue a task =] and [= networking task source =] are defined in [[!HTML]].

The concept [= fire an event =] is defined in [[!DOM]].

The terms [= event =], [= event handlers =] and [= event handler event types =] are defined in [[!HTML]].

{{Performance.timeOrigin}} and {{Performance.now()}} are defined in [[!hr-time]].

The terms serializable objects, [= serialization steps =], and [= deserialization steps =] are defined in [[!HTML]].

The terms {{MediaStream}}, {{MediaStreamTrack}}, and {{MediaStreamConstraints}} are defined in [[!GETUSERMEDIA]]. Note that {{MediaStream}} is extended in in this document while {{MediaStreamTrack}} is extended in in this document.

The term {{Blob}} is defined in [[!FILEAPI]].

The term media description is defined in [[!RFC4566]].

The term media transport is defined in [[!RFC7656]].

The term generation is defined in [[RFC8838]] Section 2.

The terms stats object and monitored object are defined in [[!WEBRTC-STATS]].

When referring to exceptions, the terms [= exception/throw =] and [= exception/created =] are defined in [[!WEBIDL]].

The callback {{VoidFunction}} is defined in [[!WEBIDL]].

The term "throw" is used as specified in [[!INFRA]]: it terminates the current processing steps.

The terms fulfilled, rejected, resolved, and settled used in the context of Promises are defined in [[!ECMASCRIPT-6.0]].

The AlgorithmIdentifier is defined in [[!WebCryptoAPI]].

The general principles for Javascript APIs apply, including the principle of run-to-completion and no-data-races as defined in [[API-DESIGN-PRINCIPLES]]. That is, while a task is running, external events do not influence what's visible to the Javascript application. For example, the amount of data buffered on a data channel will increase due to "send" calls while Javascript is executing, and the decrease due to packets being sent will be visible after a task checkpoint.
It is the responsibility of the user agent to make sure the set of values presented to the application is consistent - for instance that getContributingSources() (which is synchronous) returns values for all sources measured at the same time.

Peer-to-peer connections

Introduction

An {{RTCPeerConnection}} instance allows an application to establish peer-to-peer communications with another {{RTCPeerConnection}} instance in another browser, or to another endpoint implementing the required protocols. Communications are coordinated by the exchange of control messages (called a signaling protocol) over a signaling channel which is provided by unspecified means, but generally by a script in the page via the server, e.g. using {{WebSocket}} or {{XMLHttpRequest}}.

Configuration

RTCConfiguration Dictionary

The {{RTCConfiguration}} defines a set of parameters to configure how the peer-to-peer communication established via {{RTCPeerConnection}} is established or re-established.

dictionary RTCConfiguration {
  sequence<RTCIceServer> iceServers = [];
  RTCIceTransportPolicy iceTransportPolicy = "all";
  RTCBundlePolicy bundlePolicy = "balanced";
  RTCRtcpMuxPolicy rtcpMuxPolicy = "require";
  sequence<RTCCertificate> certificates = [];
  [EnforceRange] octet iceCandidatePoolSize = 0;
};

Dictionary {{RTCConfiguration}} Members

iceServers of type sequence<{{RTCIceServer}}>, defaulting to [].

An array of objects describing servers available to be used by ICE, such as STUN and TURN servers. If the number of ICE servers exceeds an implementation-defined limit, ignore the ICE servers above the threshold. This implementation defined limit MUST be at least 32.

iceTransportPolicy of type {{RTCIceTransportPolicy}}, defaulting to "all".

Indicates which candidates the [= ICE Agent =] is allowed to use.

bundlePolicy of type {{RTCBundlePolicy}}, defaulting to "balanced".

Indicates which media-bundling policy to use when gathering ICE candidates.

rtcpMuxPolicy of type {{RTCRtcpMuxPolicy}}, defaulting to "require".

Indicates which rtcp-mux policy to use when gathering ICE candidates.

certificates of type sequence<{{RTCCertificate}}>, defaulting to [].

A set of certificates that the {{RTCPeerConnection}} uses to authenticate.

Valid values for this parameter are created through calls to the {{RTCPeerConnection/generateCertificate()}} function.

Although any given DTLS connection will use only one certificate, this attribute allows the caller to provide multiple certificates that support different algorithms. The final certificate will be selected based on the DTLS handshake, which establishes which certificates are allowed. The {{RTCPeerConnection}} implementation selects which of the certificates is used for a given connection; how certificates are selected is outside the scope of this specification.

Existing implementations only utilize the first certificate provided; the others are ignored.

If this value is [=map/exists|absent=], then a default set of certificates is generated for each {{RTCPeerConnection}} instance.

This option allows applications to establish key continuity. An {{RTCCertificate}} can be persisted in [[?INDEXEDDB]] and reused. Persistence and reuse also avoids the cost of key generation.

The value for this configuration option cannot change after its value is initially selected.

iceCandidatePoolSize of type octet, defaulting to 0

Size of the prefetched ICE pool as defined in [[!RFC9429]].

RTCIceServer Dictionary

The {{RTCIceServer}} dictionary is used to describe the STUN and TURN servers that can be used by the [= ICE Agent =] to establish a connection with a peer.

dictionary RTCIceServer {
  required (USVString or sequence<USVString>) urls;
  DOMString username;
  DOMString credential;
};

Dictionary {{RTCIceServer}} Members

urls of type (USVString or sequence<USVString>), required

STUN or TURN URI(s) as defined in [[!RFC7064]] and [[!RFC7065]] or other URI types.

username of type DOMString

If this {{RTCIceServer}} object represents a TURN server, then this attribute specifies the username to use with that TURN server.

credential of type {{DOMString}}

If this {{RTCIceServer}} object represents a TURN server, then this attribute specifies the credential to use with that TURN server.

{{credential}} represents a long-term authentication password, as described in [[!RFC5389]], Section 10.2.

An example array of {{RTCIceServer}} objects is:

[
  {urls: 'stun:stun1.example.net'},
  {urls: ['turns:turn.example.org', 'turn:turn.example.net'],
    username: 'user',
    credential: 'myPassword',
];
        

RTCIceTransportPolicy Enum

As described in [[!RFC9429]], if the {{RTCConfiguration/iceTransportPolicy}} member of the {{RTCConfiguration}} is specified, it defines the ICE candidate policy [[!RFC9429]] the browser uses to surface the permitted candidates to the application; only these candidates will be used for connectivity checks.

enum RTCIceTransportPolicy {
  "relay",
  "all"
};
{{RTCIceTransportPolicy}} Enumeration description
Enum valueDescription
relay

The [= ICE Agent =] uses only media relay candidates such as candidates passing through a TURN server.

This can be used to prevent the remote endpoint from learning the user's IP addresses, which may be desired in certain use cases. For example, in a "call"-based application, the application may want to prevent an unknown caller from learning the callee's IP addresses until the callee has consented in some way.
all

The [= ICE Agent =] can use any type of candidate when this value is specified.

The implementation can still use its own candidate filtering policy in order to limit the IP addresses exposed to the application, as noted in the description of {{RTCIceCandidate}}.{{RTCIceCandidate/address}}.

RTCBundlePolicy Enum

As described in [[!RFC9429]], bundle policy affects which media tracks are negotiated if the remote endpoint is not bundle-aware, and what ICE candidates are gathered. If the remote endpoint is bundle-aware, all media tracks and data channels are bundled onto the same transport.

enum RTCBundlePolicy {
  "balanced",
  "max-compat",
  "max-bundle"
};
{{RTCBundlePolicy}} Enumeration description
Enum valueDescription
balanced Gather ICE candidates for each media type in use (audio, video, and data). If the remote endpoint is not bundle-aware, negotiate only one audio and video track on separate transports.
max-compat Gather ICE candidates for each track. If the remote endpoint is not bundle-aware, negotiate all media tracks on separate transports.
max-bundle Gather ICE candidates for only one track. If the remote endpoint is not bundle-aware, negotiate only one media track.

RTCRtcpMuxPolicy Enum

As described in [[!RFC9429]], the {{RTCRtcpMuxPolicy}} affects what ICE candidates are gathered to support non-multiplexed RTCP. The only value defined in this spec is {{RTCRtcpMuxPolicy/"require"}}.

              enum RTCRtcpMuxPolicy {
                "require"
              };
            
{{RTCRtcpMuxPolicy}} Enumeration description
Enum valueDescription
require Gather ICE candidates only for RTP and multiplex RTCP on the RTP candidates. If the remote endpoint is not capable of rtcp-mux, session negotiation will fail.

Offer/Answer Options

These dictionaries describe the options that can be used to control the offer/answer creation process.

dictionary RTCOfferAnswerOptions {};

Dictionary RTCOfferAnswerOptions Members

dictionary RTCOfferOptions : RTCOfferAnswerOptions {
  boolean iceRestart = false;
};

Dictionary RTCOfferOptions Members

iceRestart of type boolean, defaulting to false

When the value of this dictionary member is true, or the relevant {{RTCPeerConnection}} object's {{RTCPeerConnection/[[LocalIceCredentialsToReplace]]}} slot is not empty, then the generated description will have ICE credentials that are different from the current credentials (as visible in the {{RTCPeerConnection/currentLocalDescription}} attribute's SDP). Applying the generated description will restart ICE, as described in section 9.1.1.1 of [[RFC5245]].

When the value of this dictionary member is false, and the relevant {{RTCPeerConnection}} object's {{RTCPeerConnection/[[LocalIceCredentialsToReplace]]}} slot is empty, and the {{RTCPeerConnection/currentLocalDescription}} attribute has valid ICE credentials, then the generated description will have the same ICE credentials as the current value from the {{RTCPeerConnection/currentLocalDescription}} attribute.

Performing an ICE restart is recommended when {{RTCPeerConnection/iceConnectionState}} transitions to {{RTCIceConnectionState/"failed"}}. An application may additionally choose to listen for the {{RTCPeerConnection/iceConnectionState}} transition to {{RTCIceConnectionState/"disconnected"}} and then use other sources of information (such as using {{RTCPeerConnection/getStats}} to measure if the number of bytes sent or received over the next couple of seconds increases) to determine whether an ICE restart is advisable.

The RTCAnswerOptions dictionary describe options specific to session description of type {{RTCSdpType/"answer"}} (none in this version of the specification).

dictionary RTCAnswerOptions : RTCOfferAnswerOptions {};

State Definitions

RTCSignalingState Enum

enum RTCSignalingState {
  "stable",
  "have-local-offer",
  "have-remote-offer",
  "have-local-pranswer",
  "have-remote-pranswer",
  "closed"
};
{{RTCSignalingState}} Enumeration description
Enum valueDescription
stable There is no offer/answer exchange in progress. This is also the initial state, in which case the local and remote descriptions are empty.
have-local-offer A local description, of type {{RTCSdpType/"offer"}}, has been successfully applied.
have-remote-offer A remote description, of type {{RTCSdpType/"offer"}}, has been successfully applied.
have-local-pranswer A remote description of type {{RTCSdpType/"offer"}} has been successfully applied and a local description of type {{RTCSdpType/"pranswer"}} has been successfully applied.
have-remote-pranswer A local description of type {{RTCSdpType/"offer"}} has been successfully applied and a remote description of type {{RTCSdpType/"pranswer"}} has been successfully applied.
closed The {{RTCPeerConnection}} has been closed; its {{RTCPeerConnection/[[IsClosed]]}} slot is true.
signaling state transition diagram
Non-normative signaling state transitions diagram. Method calls abbreviated.

An example set of transitions might be:

Caller transition:
  • new RTCPeerConnection(): {{RTCSignalingState/"stable"}}
  • setLocalDescription(offer): {{RTCSignalingState/"have-local-offer"}}
  • setRemoteDescription(pranswer): {{RTCSignalingState/"have-remote-pranswer"}}
  • setRemoteDescription(answer): {{RTCSignalingState/"stable"}}
Callee transition:
  • new RTCPeerConnection(): {{RTCSignalingState/"stable"}}
  • setRemoteDescription(offer): {{RTCSignalingState/"have-remote-offer"}}
  • setLocalDescription(pranswer): {{RTCSignalingState/"have-local-pranswer"}}
  • setLocalDescription(answer): {{RTCSignalingState/"stable"}}

RTCIceGatheringState Enum

enum RTCIceGatheringState {
  "new",
  "gathering",
  "complete"
};
{{RTCIceGatheringState}} Enumeration description
Enum valueDescription
new Any of the {{RTCIceTransport}}s are in the {{RTCIceGathererState/"new"}} gathering state and none of the transports are in the {{RTCIceGathererState/"gathering"}} state, or there are no transports.
gathering Any of the {{RTCIceTransport}}s are in the {{RTCIceGathererState/"gathering"}} state.
complete At least one {{RTCIceTransport}} exists, and all {{RTCIceTransport}}s are in the {{RTCIceGathererState/"complete"}} gathering state.

The set of transports considered is the one presently referenced by the {{RTCPeerConnection}}'s [= set of transceivers =] and the {{RTCPeerConnection}}'s {{RTCPeerConnection/[[SctpTransport]]}} internal slot if not null.

RTCPeerConnectionState Enum

enum RTCPeerConnectionState {
  "closed",
  "failed",
  "disconnected",
  "new",
  "connecting",
  "connected"
};
{{RTCPeerConnectionState}} Enumeration description
Enum valueDescription
closed {{RTCPeerConnection/[[IceConnectionState]]}} is {{RTCIceConnectionState/"closed"}}.
failed The previous state doesn't apply, and either {{RTCPeerConnection/[[IceConnectionState]]}} is {{RTCIceConnectionState/"failed"}} or any {{RTCDtlsTransport}}s are in the {{RTCDtlsTransportState/"failed"}} state.
disconnected None of the previous states apply, and {{RTCPeerConnection/[[IceConnectionState]]}} is {{RTCIceConnectionState/"disconnected"}}.
new None of the previous states apply, and either {{RTCPeerConnection/[[IceConnectionState]]}} is {{RTCIceConnectionState/"new"}}, and all {{RTCDtlsTransport}}s are in the {{RTCDtlsTransportState/"new"}} or {{RTCDtlsTransportState/"closed"}} state, or there are no transports.
connected None of the previous states apply, {{RTCPeerConnection/[[IceConnectionState]]}} is {{RTCIceConnectionState/"connected"}}, and all {{RTCDtlsTransport}}s are in the {{RTCDtlsTransportState/"connected"}} or {{RTCDtlsTransportState/"closed"}} state.
connecting None of the previous states apply.

In the {{RTCPeerConnectionState/"connecting"}} state, one or more {{RTCIceTransport}}s are in the {{RTCIceTransportState/"new"}} or {{RTCIceTransportState/"checking"}} state, or one or more {{RTCDtlsTransport}}s are in the {{RTCDtlsTransportState/"new"}} or {{RTCDtlsTransportState/"connecting"}} state.

The set of transports considered is the one presently referenced by the {{RTCPeerConnection}}'s [= set of transceivers =] and the {{RTCPeerConnection}}'s {{RTCPeerConnection/[[SctpTransport]]}} internal slot if not null.

RTCIceConnectionState Enum

enum RTCIceConnectionState {
  "closed",
  "failed",
  "disconnected",
  "new",
  "checking",
  "completed",
  "connected"
};
{{RTCIceConnectionState}} Enumeration description
Enum valueDescription
closed The {{RTCPeerConnection}} object's {{RTCPeerConnection/[[IsClosed]]}} slot is true.
failed The previous state doesn't apply and any {{RTCIceTransport}}s are in the {{RTCIceTransportState/"failed"}} state.
disconnected None of the previous states apply and any {{RTCIceTransport}}s are in the {{RTCIceTransportState/"disconnected"}} state.
new None of the previous states apply and all {{RTCIceTransport}}s are in the {{RTCIceTransportState/"new"}} or {{RTCIceTransportState/"closed"}} state, or there are no transports.
checking None of the previous states apply and any {{RTCIceTransport}}s are in the {{RTCIceTransportState/"new"}} or {{RTCIceTransportState/"checking"}} state.
completed None of the previous states apply and all {{RTCIceTransport}}s are in the {{RTCIceTransportState/"completed"}} or {{RTCIceTransportState/"closed"}} state.
connected None of the previous states apply and all {{RTCIceTransport}}s are in the {{RTCIceTransportState/"connected"}}, {{RTCIceTransportState/"completed"}} or {{RTCIceTransportState/"closed"}} state.

The set of transports considered is the one presently referenced by the {{RTCPeerConnection}}'s [= set of transceivers =] and the {{RTCPeerConnection}}'s {{RTCPeerConnection/[[SctpTransport]]}} internal slot if not null.

Note that if an {{RTCIceTransport}} is discarded as a result of signaling (e.g. RTCP mux or bundling), or created as a result of signaling (e.g. adding a new [= media description =]), the state may advance directly from one state to another.

RTCPeerConnection Interface

The [[!RFC9429]] specification, as a whole, describes the details of how the {{RTCPeerConnection}} operates. References to specific subsections of [[!RFC9429]] are provided as appropriate.

Operation

Calling new {{RTCPeerConnection}}(configuration) creates an {{RTCPeerConnection}} object.

configuration.{{RTCConfiguration/iceServers}} contains information used to find and access the servers used by ICE. The application can supply multiple servers of each type, and any TURN server MAY also be used as a STUN server for the purposes of gathering server reflexive candidates.

An {{RTCPeerConnection}} object has a {{RTCPeerConnection/[[SignalingState]]}}, and the aggregated states {{RTCPeerConnection/[[ConnectionState]]}}, {{RTCPeerConnection/[[IceGatheringState]]}}, and {{RTCPeerConnection/[[IceConnectionState]]}}. These are initialized when the object is created.

The ICE protocol implementation of an {{RTCPeerConnection}} is represented by an ICE agent [[RFC5245]]. Certain {{RTCPeerConnection}} methods involve interactions with the [= ICE Agent =], namely {{addIceCandidate}}, {{setConfiguration}}, {{setLocalDescription}}, {{setRemoteDescription}} and {{close}}. These interactions are described in the relevant sections in this document and in [[!RFC9429]]. The [= ICE Agent =] also provides indications to the user agent when the state of its internal representation of an {{RTCIceTransport}} changes, as described in .

The task source for the tasks listed in this section is the [= networking task source =].

The state of the SDP negotiation is represented by the internal variables {{RTCPeerConnection/[[SignalingState]]}}, {{RTCPeerConnection/[[CurrentLocalDescription]]}}, {{RTCPeerConnection/[[CurrentRemoteDescription]]}}, {{RTCPeerConnection/[[PendingLocalDescription]]}} and {{RTCPeerConnection/[[PendingRemoteDescription]]}}. These are only set inside the {{setLocalDescription}} and {{setRemoteDescription}} operations, and modified by the {{addIceCandidate}} operation and the [= surface a candidate =] procedure. In each case, all the modifications to all the five variables are completed before the procedures fire any events or invoke any callbacks, so the modifications are made visible at a single point in time.

As one of the unloading document cleanup steps, run the following steps:

  1. Let window be document's [=relevant global object=].

  2. For each {{RTCPeerConnection}} object connection whose [=relevant global object=] is window, [= close the connection =] with connection and the value true.

Constructor

When the RTCPeerConnection.constructor() is invoked, the user agent MUST run the following steps:

  1. If any of the steps enumerated below fails for a reason not specified here, [= exception/throw =] an {{UnknownError}} with the {{DOMException/message}} attribute set to an appropriate description.

  2. Let connection be a newly created {{RTCPeerConnection}} object.

  3. Let connection have a [[\DocumentOrigin]] internal slot, initialized to the [= relevant settings object =]'s [=environment settings object/origin=].

  4. Let configuration be the method's first argument.
  5. If the {{RTCConfiguration/certificates}} value in configuration is non-empty, run the following steps for each certificate in certificates:

    1. If the value of certificate.{{RTCCertificate/expires}} is less than the current time, [= exception/throw =] an {{InvalidAccessError}}.

    2. If certificate.{{RTCCertificate/[[Origin]]}} is not same origin with connection.{{RTCPeerConnection/[[DocumentOrigin]]}}, [= exception/throw =] an {{InvalidAccessError}}.

    3. Store certificate.

  6. Else, generate one or more new {{RTCCertificate}} instances with this {{RTCPeerConnection}} instance and store them. This MAY happen asynchronously and the value of {{RTCConfiguration/certificates}} remains undefined for the subsequent steps. As noted in Section 4.3.2.3 of [[RFC8826]], WebRTC utilizes self-signed rather than Public Key Infrastructure (PKI) certificates, so that the expiration check is to ensure that keys are not used indefinitely and additional certificate checks are unnecessary.

  7. Initialize connection's [= ICE Agent =].

  8. Let connection have a [[\Configuration]] internal slot, initialized to null. [= Set the configuration =] specified by configuration.

  9. Let connection have an [[\IsClosed]] internal slot, initialized to false.

  10. Let connection have a [[\NegotiationNeeded]] internal slot, initialized to false.

  11. Let connection have an [[\SctpTransport]] internal slot, initialized to null.

  12. Let connection have an [[\LastStableStateSctpTransport]] internal slot, initialized to null.

  13. Let connection have a [[\DataChannels]] internal slot, initialized to an empty [=ordered set=].

  14. Let connection have an [[\Operations]] internal slot, representing an [= operations chain =], initialized to an empty list.

  15. Let connection have a [[\UpdateNegotiationNeededFlagOnEmptyChain]] internal slot, initialized to false.

  16. Let connection have an [[\LastCreatedOffer]] internal slot, initialized to "".

  17. Let connection have an [[\LastCreatedAnswer]] internal slot, initialized to "".

  18. Let connection have an [[\EarlyCandidates]] internal slot, initialized to an empty list.

  19. Let connection have an [[\SignalingState]] internal slot, initialized to {{RTCSignalingState/"stable"}}.

  20. Let connection have an [[\IceConnectionState]] internal slot, initialized to {{RTCIceConnectionState/"new"}}.

  21. Let connection have an [[\IceGatheringState]] internal slot, initialized to {{RTCIceGatheringState/"new"}}.

  22. Let connection have an [[\ConnectionState]] internal slot, initialized to {{RTCPeerConnectionState/"new"}}.

  23. Let connection have a [[\PendingLocalDescription]] internal slot, initialized to null.

  24. Let connection have a [[\CurrentLocalDescription]] internal slot, initialized to null.

  25. Let connection have a [[\PendingRemoteDescription]] internal slot, initialized to null.

  26. Let connection have a [[\CurrentRemoteDescription]] internal slot, initialized to null.

  27. Let connection have a [[\LocalIceCredentialsToReplace]] internal slot, initialized to an empty set.

  28. Return connection.

Chain an asynchronous operation

An {{RTCPeerConnection}} object has an operations chain, {{RTCPeerConnection/[[Operations]]}}, which ensures that only one asynchronous operation in the chain executes concurrently. If subsequent calls are made while the returned promise of a previous call is still not [= settled =], they are added to the chain and executed when all the previous calls have finished executing and their promises have [= settled =].

To chain an operation to an {{RTCPeerConnection}} object's [= operations chain =], run the following steps:

  1. Let connection be the {{RTCPeerConnection}} object.

  2. If connection.{{RTCPeerConnection/[[IsClosed]]}} is true, return a promise [= rejected =] with a newly [= exception/created =] {{InvalidStateError}}.

  3. Let operation be the operation to be chained.

  4. Let p be a new promise.

  5. Append operation to {{RTCPeerConnection/[[Operations]]}}.

  6. If the length of {{RTCPeerConnection/[[Operations]]}} is exactly 1, execute operation.

  7. Upon [= fulfillment =] or [= rejection =] of the promise returned by the operation, run the following steps:

    1. If connection.{{RTCPeerConnection/[[IsClosed]]}} is true, abort these steps.

    2. If the promise returned by operation was [= fulfilled =] with a value, [= fulfill =] p with that value.

    3. If the promise returned by operation was [= rejected =] with a value, [= reject =] p with that value.

    4. Upon [= fulfillment =] or [= rejection =] of p, execute the following steps:

      1. If connection.{{RTCPeerConnection/[[IsClosed]]}} is true, abort these steps.

      2. Remove the first element of {{RTCPeerConnection/[[Operations]]}}.

      3. If {{RTCPeerConnection/[[Operations]]}} is non-empty, execute the operation represented by the first element of {{RTCPeerConnection/[[Operations]]}}, and abort these steps.

      4. If connection.{{RTCPeerConnection/[[UpdateNegotiationNeededFlagOnEmptyChain]]}} is false, abort these steps.

      5. Set connection.{{RTCPeerConnection/[[UpdateNegotiationNeededFlagOnEmptyChain]]}} to false.

      6. Update the negotiation-needed flag for connection.

  8. Return p.

Update the connection state

An {{RTCPeerConnection}} object has an aggregated {{RTCPeerConnection/[[ConnectionState]]}}. Whenever the state of an {{RTCDtlsTransport}} changes, the user agent MUST queue a task that runs the following steps:

  1. Let connection be this {{RTCPeerConnection}} object associated with the {{RTCDtlsTransport}} object whose state changed.

  2. If connection.{{RTCPeerConnection/[[IsClosed]]}} is true, abort these steps.

  3. Let newState be the value of deriving a new state value as described by the {{RTCPeerConnectionState}} enum.

  4. If connection.{{RTCPeerConnection/[[ConnectionState]]}} is equal to newState, abort these steps.

  5. Set connection.{{RTCPeerConnection/[[ConnectionState]]}} to newState.

  6. [= Fire an event =] named {{RTCPeerConnection/connectionstatechange}} at connection.

Set the session description

To set a local session description description on an {{RTCPeerConnection}} object connection, [= set a session description | set the session description =] description on connection with the additional value false.

To set a remote session description description on an {{RTCPeerConnection}} object connection, [= set a session description | set the session description =] description on connection with the additional value true.

To set a session description description on an {{RTCPeerConnection}} object connection, given a remote boolean, run the following steps:

  1. Let p be a new promise.

  2. If description.{{RTCSessionDescriptionInit/type}} is {{RTCSdpType/"rollback"}} and connection.{{RTCPeerConnection/[[SignalingState]]}} is either {{RTCSignalingState/"stable"}}, {{RTCSignalingState/"have-local-pranswer"}}, or {{RTCSignalingState/"have-remote-pranswer"}}, then [= reject =] p with a newly [= exception/created =] {{InvalidStateError}} and abort these steps.

  3. Let jsepSetOfTransceivers be a shallow copy of connection's [= set of transceivers =].

  4. [=In parallel=], start the process to apply description as described in [[!RFC9429]], with these additional restrictions:

    1. Use jsepSetOfTransceivers as the source of truth with regard to what "RtpTransceivers" exist, and their {{RTCRtpTransceiver/[[JsepMid]]}} internal slot as their "mid property".

    2. If remote is false and this triggers the ICE candidate gathering process in [[!RFC9429]], the [= ICE Agent =] MUST NOT gather candidates from gathering sources that are [= administratively prohibited =].

    3. If remote is true and this triggers ICE connectivity checks in [[!RFC9429]], the [= ICE Agent =] MUST NOT attempt to connect to candidates that are [= administratively prohibited =].

    4. If remote is true, validate back-to-back offers as if answers were applied in between, by running the check for subsequent offers as if it were in stable state.

    5.  
    6. If the process to apply description fails for any reason, then the user agent MUST queue a task that runs the following steps:

      1. If connection.{{RTCPeerConnection/[[IsClosed]]}} is true, then abort these steps.

      2. If description.{{RTCSessionDescriptionInit/type}} is invalid for the current connection.{{RTCPeerConnection/[[SignalingState]]}} as described in [[!RFC9429]], then [= reject =] p with a newly [= exception/created =] {{InvalidStateError}} and abort these steps.

      3. If the process to apply description failed to parse the SDP as defined in [[!RFC9429]] Section 5.8. including session-level parsing (5.8.1.) and media-level parsing (5.8.2.), but excluding semantics verification (5.8.3.), then [= reject =] p with an {{RTCError}} (with {{RTCError/errorDetail}} set to {{RTCErrorDetailType/"sdp-syntax-error"}} and the {{RTCError/sdpLineNumber}} attribute set to the line number in the SDP where the syntax error was detected) and abort these steps.

      4. If remote is true, the connection's {{RTCRtcpMuxPolicy}} is {{RTCRtcpMuxPolicy/require}} and the description does not use RTCP mux, then [= reject =] p with a newly [= exception/created =] {{InvalidAccessError}} and abort these steps.

      5. If the description attempted to renegotiate RIDs, as described above, then [= reject =] p with a newly [= exception/created =] {{InvalidAccessError}} and abort these steps.

      6. If the description failed semantics validation as defined in [[!RFC9429]] Section 5.8.3., then [= reject =] p with a newly [= exception/created =] {{InvalidAccessError}} and abort these steps.

      7. For all other errors, [= reject =] p with a newly [= exception/created =] {{OperationError}}.

    7. If description is applied successfully, the user agent MUST queue a task that runs the following steps:

      1. If connection.{{RTCPeerConnection/[[IsClosed]]}} is true, then abort these steps.

      2. If remote is true and description is of type {{RTCSdpType/"offer"}}, then if any {{RTCPeerConnection/addTrack()}} methods on connection succeeded during the process to apply description, abort these steps and start the process over as if they had succeeded prior, to include the extra transceiver(s) in the process.

      3. If any promises from {{RTCRtpSender/setParameters}} methods on {{RTCRtpSender}}s associated with connection are not [=settled=], abort these steps and start the process over.

      4. If description is of type {{RTCSdpType/"offer"}} and connection.{{RTCPeerConnection/[[SignalingState]]}} is {{RTCSignalingState/"stable"}}, then run the following steps:

        1. Set connection.{{RTCPeerConnection/[[LastStableStateSctpTransport]]}} to connection.{{RTCPeerConnection/[[SctpTransport]]}}.

        2. For each transceiver in connection's [= set of transceivers =], run the following steps:

          1. Set transceiver.{{RTCRtpTransceiver/[[Sender]]}}.{{RTCRtpSender/[[LastStableStateSenderTransport]]}} to transceiver.{{RTCRtpTransceiver/[[Sender]]}}.{{RTCRtpSender/[[SenderTransport]]}}.

          2. If transceiver.{{RTCRtpTransceiver/[[Sender]]}}.{{RTCRtpSender/[[SendEncodings]]}}.length is `1` and the lone encoding [=map/contains=] no {{RTCRtpCodingParameters/rid}} member, then set transceiver.{{RTCRtpTransceiver/[[Sender]]}}.{{RTCRtpSender/[[LastStableRidlessSendEncodings]]}} to transceiver.{{RTCRtpTransceiver/[[Sender]]}}.{{RTCRtpSender/[[SendEncodings]]}}; Otherwise, set transceiver.{{RTCRtpTransceiver/[[Sender]]}}.{{RTCRtpSender/[[LastStableRidlessSendEncodings]]}} to `null`.

          3. Set transceiver.{{RTCRtpTransceiver/[[Receiver]]}}.{{RTCRtpReceiver/[[LastStableStateReceiverTransport]]}} to transceiver.{{RTCRtpTransceiver/[[Receiver]]}}.{{RTCRtpReceiver/[[ReceiverTransport]]}}.

          4. Set transceiver.{{RTCRtpTransceiver/[[Receiver]]}}.{{RTCRtpReceiver/[[LastStableStateAssociatedRemoteMediaStreams]]}} to transceiver.{{RTCRtpTransceiver/[[Receiver]]}}.{{RTCRtpReceiver/[[AssociatedRemoteMediaStreams]]}}.

          5. Set transceiver.{{RTCRtpTransceiver/[[Receiver]]}}.{{RTCRtpReceiver/[[LastStableStateReceiveCodecs]]}} to transceiver.{{RTCRtpTransceiver/[[Receiver]]}}.{{RTCRtpReceiver/[[ReceiveCodecs]]}}.

      5. If remote is false, then run one of the following steps:

        1. If description is of type {{RTCSdpType/"offer"}}, set connection.{{RTCPeerConnection/[[PendingLocalDescription]]}} to a new {{RTCSessionDescription}} object constructed from description, set connection.{{RTCPeerConnection/[[SignalingState]]}} to {{RTCSignalingState/"have-local-offer"}}, and [= release early candidates =].

        2. If description is of type {{RTCSdpType/"answer"}}, then this completes an offer answer negotiation. Set connection.{{RTCPeerConnection/[[CurrentLocalDescription]]}} to a new {{RTCSessionDescription}} object constructed from description, and set connection.{{RTCPeerConnection/[[CurrentRemoteDescription]]}} to connection.{{RTCPeerConnection/[[PendingRemoteDescription]]}}. Set both connection.{{RTCPeerConnection/[[PendingRemoteDescription]]}} and connection.{{RTCPeerConnection/[[PendingLocalDescription]]}} to null. Set both connection.{{RTCPeerConnection/[[LastCreatedOffer]]}} and connection.{{RTCPeerConnection/[[LastCreatedAnswer]]}} to "", set connection.{{RTCPeerConnection/[[SignalingState]]}} to {{RTCSignalingState/"stable"}}, and [= release early candidates =]. Finally, if none of the ICE credentials in connection.{{RTCPeerConnection/[[LocalIceCredentialsToReplace]]}} are present in description, then set connection.{{RTCPeerConnection/[[LocalIceCredentialsToReplace]]}} to an empty set.

        3. If description is of type {{RTCSdpType/"pranswer"}}, then set connection.{{RTCPeerConnection/[[PendingLocalDescription]]}} to a new {{RTCSessionDescription}} object constructed from description, set connection.{{RTCPeerConnection/[[SignalingState]]}} to {{RTCSignalingState/"have-local-pranswer"}}, and [= release early candidates =].

      6. Otherwise, (if remote is true) run one of the following steps:

        1. If description is of type {{RTCSdpType/"offer"}}, set connection.{{RTCPeerConnection/[[PendingRemoteDescription]]}} attribute to a new {{RTCSessionDescription}} object constructed from description, and set connection.{{RTCPeerConnection/[[SignalingState]]}} to {{RTCSignalingState/"have-remote-offer"}}.

        2. If description is of type {{RTCSdpType/"answer"}}, then this completes an offer answer negotiation. Set connection.{{RTCPeerConnection/[[CurrentRemoteDescription]]}} to a new {{RTCSessionDescription}} object constructed from description, and set connection.{{RTCPeerConnection/[[CurrentLocalDescription]]}} to connection.{{RTCPeerConnection/[[PendingLocalDescription]]}}. Set both connection.{{RTCPeerConnection/[[PendingRemoteDescription]]}} and connection.{{RTCPeerConnection/[[PendingLocalDescription]]}} to null. Set both connection.{{RTCPeerConnection/[[LastCreatedOffer]]}} and connection.{{RTCPeerConnection/[[LastCreatedAnswer]]}} to "", and set connection.{{RTCPeerConnection/[[SignalingState]]}} to {{RTCSignalingState/"stable"}}. Finally, if none of the ICE credentials in connection.{{RTCPeerConnection/[[LocalIceCredentialsToReplace]]}} are present in the newly set connection.{{RTCPeerConnection/[[CurrentLocalDescription]]}}, then set connection.{{RTCPeerConnection/[[LocalIceCredentialsToReplace]]}} to an empty set.

        3. If description is of type {{RTCSdpType/"pranswer"}}, then set connection.{{RTCPeerConnection/[[PendingRemoteDescription]]}} to a new {{RTCSessionDescription}} object constructed from description and set connection.{{RTCPeerConnection/[[SignalingState]]}} to {{RTCSignalingState/"have-remote-pranswer"}}.

      7. If description is of type {{RTCSdpType/"offer"}}, and it describes an SCTP association as defined in [[RFC8841]] Section 10.2, and connection.{{RTCPeerConnection/[[SctpTransport]]}} is null, set connection.{{RTCPeerConnection/[[SctpTransport]]}} to the result of [= create an RTCSctpTransport|creating an RTCSctpTransport =] with an initial state of {{RTCSctpTransportState/"connecting"}}.

      8. If description is of type {{RTCSdpType/"answer"}}, and it initiates the closure of an existing SCTP association, as defined in [[RFC8841]], Sections 10.3 and 10.4, set connection.{{RTCPeerConnection/[[SctpTransport]]}} to null.

      9. Let trackEventInits, muteTracks, addList, removeList and errorList be empty lists.

      10. If description is of type {{RTCSdpType/"answer"}} or {{RTCSdpType/"pranswer"}}, then run the following steps:

        1. If description initiates the establishment of a new SCTP association, as defined in [[RFC8841]], Sections 10.3 and 10.4, or an SCTP association already exists, [= update the data max message size =] of connection.{{RTCPeerConnection/[[SctpTransport]]}}.

        2. If description negotiates the DTLS role of the SCTP transport, then for each {{RTCDataChannel}}, channel, with a null {{RTCDataChannel/id}}, run the following step:

          1. Give channel a new ID generated according to [[RFC8832]]. If no available ID could be generated, set channel.{{RTCDataChannel/[[ReadyState]]}} to {{RTCDataChannelState/"closed"}}, and add channnel to errorList.
      11. If description is not of type {{RTCSdpType/"rollback"}}, then run the following steps:

        1. If remote is false, then run the following steps for each [= media description =] in description:

          1. If the [= media description =] was not yet [= associated =] with an {{RTCRtpTransceiver}} object then run the following steps:

            1. Let transceiver be the {{RTCRtpTransceiver}} used to create the [= media description =].

            2. Set transceiver.{{RTCRtpTransceiver/[[Mid]]}} to transceiver.{{RTCRtpTransceiver/[[JsepMid]]}}.

            3. If transceiver.{{RTCRtpTransceiver/[[Stopped]]}} is true, abort these sub steps.

            4. If the [= media description =] is indicated as using an existing [= media transport =] according to [[RFC8843]], let transport be the {{RTCDtlsTransport}} object representing the RTP/RTCP component of that transport.

            5. Otherwise, let transport be a newly created {{RTCDtlsTransport}} object with a new underlying {{RTCIceTransport}}.

            6. Set transceiver.{{RTCRtpTransceiver/[[Sender]]}}.{{RTCRtpSender/[[SenderTransport]]}} to transport.

            7. Set transceiver.{{RTCRtpTransceiver/[[Receiver]]}}.{{RTCRtpReceiver/[[ReceiverTransport]]}} to transport.

          2. Let transceiver be the {{RTCRtpTransceiver}} [= associated =] with the [= media description =].

          3. If transceiver.{{RTCRtpTransceiver/[[Stopped]]}} is true, abort these sub steps.

          4. Let direction be an {{RTCRtpTransceiverDirection}} value representing the direction from the [= media description =].

          5. If direction is {{RTCRtpTransceiverDirection/"sendrecv"}} or {{RTCRtpTransceiverDirection/"recvonly"}}, set transceiver.{{RTCRtpTransceiver/[[Receptive]]}} to true, otherwise set it to false.

          6. Set transceiver.{{RTCRtpTransceiver/[[Receiver]]}}.{{RTCRtpReceiver/[[ReceiveCodecs]]}} to the codecs that description negotiates for receiving and which the user agent is currently prepared to receive.

            If the direction is {{RTCRtpTransceiverDirection/"sendonly"}} or {{RTCRtpTransceiverDirection/"inactive"}}, the receiver is not prepared to receive anything, and the list will be empty.

          7. If description is of type {{RTCSdpType/"answer"}} or {{RTCSdpType/"pranswer"}}, then run the following steps:

            1. If transceiver. {{RTCRtpTransceiver/[[Sender]]}}.{{RTCRtpSender/[[SendEncodings]]}} .length is greater than 1, then run the following steps:

              1. If description is missing all of the previously negotiated layers, then remove all dictionaries in transceiver.{{RTCRtpTransceiver/[[Sender]]}}.{{RTCRtpSender/[[SendEncodings]]}} except the first one, and skip the next step.

              2. If description is missing any of the previously negotiated layers, then remove the dictionaries that correspond to the missing layers from transceiver.{{RTCRtpTransceiver/[[Sender]]}}.{{RTCRtpSender/[[SendEncodings]]}}.

            2. Set transceiver.{{RTCRtpTransceiver/[[Sender]]}}.{{RTCRtpSender/[[SendCodecs]]}} to the codecs that description negotiates for sending and which the user agent is currently capable of sending, and set transceiver.{{RTCRtpTransceiver/[[Sender]]}}.{{RTCRtpSender/[[LastReturnedParameters]]}} to null.

            3. If direction is {{RTCRtpTransceiverDirection/"sendonly"}} or {{RTCRtpTransceiverDirection/"inactive"}}, and transceiver.{{RTCRtpTransceiver/[[FiredDirection]]}} is either {{RTCRtpTransceiverDirection/"sendrecv"}} or {{RTCRtpTransceiverDirection/"recvonly"}}, then run the following steps:

              1. [= Set the associated remote streams =] given transceiver.{{RTCRtpTransceiver/[[Receiver]]}}, an empty list, another empty list, and removeList.

              2. [= process the removal of a remote track =] for the [= media description =], given transceiver and muteTracks.

            4. Set transceiver.{{RTCRtpTransceiver/[[CurrentDirection]]}} and transceiver.{{RTCRtpTransceiver/[[FiredDirection]]}} to direction.

        2. Otherwise, (if remote is true) run the following steps for each [= media description =] in description:

          1. If the description is of type {{RTCSdpType/"offer"}} and the [= media description =] contains a request to receive simulcast, use the order of the rid values specified in the simulcast attribute to create an {{RTCRtpEncodingParameters}} dictionary for each of the simulcast layers, populating the {{RTCRtpCodingParameters/rid}} member according to the corresponding rid value (using only the first value if comma-separated alternatives exist), and let proposedSendEncodings be the list containing the created dictionaries. Otherwise, let proposedSendEncodings be an empty list.

          2. For each encoding, encoding, in proposedSendEncodings in reverse order, if encoding's {{RTCRtpCodingParameters/rid}} matches that of another encoding in proposedSendEncodings, remove encoding from proposedSendEncodings.

          3. Let supportedEncodings be the maximum number of encodings that the implementation can support. If the length of proposedSendEncodings is greater than supportedEncodings, truncate proposedSendEncodings so that its length is supportedEncodings.
          4. If proposedSendEncodings is non-empty, set each encoding's {{RTCRtpEncodingParameters/scaleResolutionDownBy}} to 2^(length of proposedSendEncodings - encoding index - 1).
          5. As described by [[!RFC9429]], attempt to find an existing {{RTCRtpTransceiver}} object, transceiver, to represent the [= media description =].

          6. If a suitable transceiver was found (transceiver is set), and proposedSendEncodings is non-empty, run the following steps:

            1. If the length of transceiver.{{RTCRtpTransceiver/[[Sender]]}}.{{RTCRtpSender/[[SendEncodings]]}} is `1`, and the lone encoding [=map/contains=] no {{RTCRtpCodingParameters/rid}} member, set transceiver.{{RTCRtpTransceiver/[[Sender]]}}.{{RTCRtpSender/[[SendEncodings]]}} to proposedSendEncodings, and set transceiver.{{RTCRtpTransceiver/[[Sender]]}}.{{RTCRtpSender/[[LastReturnedParameters]]}} to null.

          7. If no suitable transceiver was found (transceiver is unset), run the following steps:

            1. [= Create an RTCRtpSender =], sender, from the [= media description =] using proposedSendEncodings.

            2. [= Create an RTCRtpReceiver =], receiver, from the [= media description =].

            3. [= Create an RTCRtpTransceiver =] with sender, receiver and an {{RTCRtpTransceiverDirection}} value of {{RTCRtpTransceiverDirection/"recvonly"}}, and let transceiver be the result.

            4. Add transceiver to the connection's [= set of transceivers =].

          8. If description is of type {{RTCSdpType/"answer"}} or {{RTCSdpType/"pranswer"}}, and transceiver. {{RTCRtpTransceiver/[[Sender]]}}.{{RTCRtpSender/[[SendEncodings]]}} .length is greater than 1, then run the following steps:

            1. If description indicates that simulcast is not supported or desired, or description is missing all of the previously negotiated layers, then remove all dictionaries in transceiver.{{RTCRtpTransceiver/[[Sender]]}}.{{RTCRtpSender/[[SendEncodings]]}} except the first one and abort these sub steps.

            2. If description is missing any of the previously negotiated layers, then remove the dictionaries that correspond to the missing layers from transceiver.{{RTCRtpTransceiver/[[Sender]]}}.{{RTCRtpSender/[[SendEncodings]]}}.

          9. Set transceiver.{{RTCRtpTransceiver/[[Mid]]}} to transceiver.{{RTCRtpTransceiver/[[JsepMid]]}}.

          10. Let direction be an {{RTCRtpTransceiverDirection}} value representing the direction from the [= media description =], but with the send and receive directions reversed to represent this peer's point of view. If the [= media description =] is rejected, set direction to {{RTCRtpTransceiverDirection/"inactive"}}.

          11. If direction is {{RTCRtpTransceiverDirection/"sendrecv"}} or {{RTCRtpTransceiverDirection/"recvonly"}}, let msids be a list of the MSIDs that the media description indicates transceiver.{{RTCRtpTransceiver/[[Receiver]]}}.{{RTCRtpReceiver/[[ReceiverTrack]]}} is to be associated with. Otherwise, let msids be an empty list.

            msids will be an empty list here if [= media description =] is rejected.
          12. [= Process remote tracks =] with transceiver, direction, msids, addList, removeList, and trackEventInits.

          13. Set transceiver.{{RTCRtpTransceiver/[[Receiver]]}}.{{RTCRtpReceiver/[[ReceiveCodecs]]}} to the codecs that description negotiates for receiving and which the user agent is currently prepared to receive.

          14. If description is of type {{RTCSdpType/"answer"}} or {{RTCSdpType/"pranswer"}}, then run the following steps:

            1. Set transceiver.{{RTCRtpTransceiver/[[Sender]]}}.{{RTCRtpSender/[[SendCodecs]]}} to the codecs that description negotiates for sending and which the user agent is currently capable of sending.

            2. Set transceiver.{{RTCRtpTransceiver/[[CurrentDirection]]}} to direction.

            3. Let transport be the {{RTCDtlsTransport}} object representing the RTP/RTCP component of the [= media transport =] used by transceiver's [= associated =] [= media description =], according to [[RFC8843]].

            4. Set transceiver.{{RTCRtpTransceiver/[[Sender]]}}.{{RTCRtpSender/[[SenderTransport]]}} to transport.

            5. Set transceiver.{{RTCRtpTransceiver/[[Receiver]]}}.{{RTCRtpReceiver/[[ReceiverTransport]]}} to transport.

            6. Set the {{RTCIceTransport/[[IceRole]]}} of transport according to the rules of [[RFC8445]].

              The rules of [[RFC8445]] that apply here are:
              • If {{RTCIceTransport/[[IceRole]]}} is not {{RTCIceRole/unknown}}, do not modify {{RTCIceTransport/[[IceRole]]}}.
              • If description is a local offer, set it to {{RTCIceRole/controlling}}.
              • If description is a remote offer, and contains a=ice-lite, set {{RTCIceTransport/[[IceRole]]}} to {{RTCIceRole/controlling}}.
              • If description is a remote offer, and does not contain a=ice-lite, set {{RTCIceTransport/[[IceRole]]}} to {{RTCIceRole/controlled}}.
              This ensures that {{RTCIceTransport/[[IceRole]]}} always has a value after the first offer is processed.
          15. If the [= media description =] is rejected, and transceiver.{{RTCRtpTransceiver/[[Stopped]]}} is false, then [= stop the RTCRtpTransceiver =] transceiver.

      12. Otherwise, (if description is of type {{RTCSdpType/"rollback"}}) run the following steps:

        1. Let pendingDescription be either connection.{{RTCPeerConnection/[[PendingLocalDescription]]}} or connection.{{RTCPeerConnection/[[PendingRemoteDescription]]}}, whichever one is not null.

        2. Set connection.{{RTCPeerConnection/[[SctpTransport]]}} to connection.{{RTCPeerConnection/[[LastStableStateSctpTransport]]}}.

        3. For each transceiver in the connection's [= set of transceivers =] run the following steps:

          1. If transceiver was not [= associated =] with a [= media description =] prior to pendingDescription being set, disassociate it and set both transceiver.{{RTCRtpTransceiver/[[JsepMid]]}} and transceiver.{{RTCRtpTransceiver/[[Mid]]}} to null.

          2. Set transceiver.{{RTCRtpTransceiver/[[Sender]]}}.{{RTCRtpSender/[[SenderTransport]]}} to transceiver.{{RTCRtpTransceiver/[[Sender]]}}.{{RTCRtpSender/[[LastStableStateSenderTransport]]}}.

          3. If transceiver.{{RTCRtpTransceiver/[[Sender]]}}.{{RTCRtpSender/[[LastStableRidlessSendEncodings]]}} is not `null`, and any encoding in transceiver.{{RTCRtpTransceiver/[[Sender]]}}.{{RTCRtpSender/[[SendEncodings]]}} [=map/contains=] a {{RTCRtpCodingParameters/rid}} member, then set transceiver.{{RTCRtpTransceiver/[[Sender]]}}.{{RTCRtpSender/[[SendEncodings]]}} to transceiver.{{RTCRtpTransceiver/[[Sender]]}}.{{RTCRtpSender/[[LastStableRidlessSendEncodings]]}}.

          4. Set transceiver.{{RTCRtpTransceiver/[[Receiver]]}}.{{RTCRtpReceiver/[[ReceiverTransport]]}} to transceiver.{{RTCRtpTransceiver/[[Receiver]]}}.{{RTCRtpReceiver/[[LastStableStateReceiverTransport]]}}.

          5. Set transceiver.{{RTCRtpTransceiver/[[Receiver]]}}.{{RTCRtpReceiver/[[ReceiveCodecs]]}} to transceiver.{{RTCRtpTransceiver/[[Receiver]]}}.{{RTCRtpReceiver/[[LastStableStateReceiveCodecs]]}}.

          6. If connection.{{RTCPeerConnection/[[SignalingState]]}} is {{RTCSignalingState/"have-remote-offer"}}, run the following sub steps:

            1. Let msids be a list of the ids of all {{MediaStream}} objects in transceiver.{{RTCRtpTransceiver/[[Receiver]]}}.{{RTCRtpReceiver/[[LastStableStateAssociatedRemoteMediaStreams]]}}, or an empty list if there are none.

            2. Process remote tracks with transceiver, transceiver.{{RTCRtpTransceiver/[[CurrentDirection]]}}, msids, addList, removeList, and trackEventInits.

          7. If transceiver was created when pendingDescription was set, and a track has never been attached to it via {{RTCPeerConnection/addTrack()}}, then [= stop the RTCRtpTransceiver =] transceiver, and remove it from connection's [= set of transceivers =].

        4. Set connection.{{RTCPeerConnection/[[PendingLocalDescription]]}} and connection.{{RTCPeerConnection/[[PendingRemoteDescription]]}} to null, and set connection.{{RTCPeerConnection/[[SignalingState]]}} to {{RTCSignalingState/"stable"}}.

      13. If description is of type {{RTCSdpType/"answer"}}, then run the following steps:

        1. For each transceiver in the connection's [= set of transceivers =] run the following steps:

          1. If transceiver is {{RTCRtpTransceiver/stopped}}, [= associated =] with an m= section and the associated m= section is rejected in connection.{{RTCPeerConnection/[[CurrentLocalDescription]]}} or connection.{{RTCPeerConnection/[[CurrentRemoteDescription]]}}, remove the transceiver from the connection's [= set of transceivers =].

      14. If connection.{{RTCPeerConnection/[[SignalingState]]}} is now {{RTCSignalingState/"stable"}}, run the following steps:

        1. For any transceiver that was removed from the [= set of transceivers =] in a previous step, if any of its transports (transceiver.{{RTCRtpTransceiver/[[Sender]]}}.{{RTCRtpSender/[[SenderTransport]]}} or transceiver.{{RTCRtpTransceiver/[[Receiver]]}}.{{RTCRtpReceiver/[[ReceiverTransport]]}}) are still not closed and they're no longer referenced by a non-stopped transceiver, close the {{RTCDtlsTransport}}s and their associated {{RTCIceTransport}}s. This results in events firing on these objects in a queued task.

        2. For each transceiver in connection's [= set of transceivers =]:

          1. Let codecs be transceiver.{{RTCRtpTransceiver/[[Sender]]}}.{{RTCRtpSender/[[SendCodecs]]}}.

          2. If codecs is not an empty list:

            1. For each encoding in transceiver.{{RTCRtpTransceiver/[[Sender]]}}.{{RTCRtpSender/[[SendEncodings]]}}, if encoding.{{RTCRtpEncodingParameters/codec}} does not match any entry in codecs, using the [= codec dictionary match =] algorithm with ignoreAsymmetricalParameters set to true, [=map/remove=] encoding.{{RTCRtpEncodingParameters/codec}}.

        3. [= Clear the negotiation-needed flag =] and [= update the negotiation-needed flag =].

      15. If connection.{{RTCPeerConnection/[[SignalingState]]}} changed above, [= fire an event =] named {{RTCPeerConnection/signalingstatechange}} at connection.

      16. For each channel in errorList, [= fire an event =] named {{RTCDataChannel/error}} using the {{RTCErrorEvent}} interface with the {{RTCError/errorDetail}} attribute set to {{RTCErrorDetailType/"data-channel-failure"}} at channel.

      17. For each track in muteTracks, [= set the muted state =] of track to the value true.

      18. For each stream and track pair in removeList, [= remove the track =] track from stream.

      19. For each stream and track pair in addList, [= add the track =] track to stream.

      20. For each entry entry in trackEventInits, [= fire an event =] named {{RTCPeerConnection/track}} using the {{RTCTrackEvent}} interface with its {{RTCTrackEvent/receiver}} attribute initialized to entry.{{RTCTrackEventInit/receiver}}, its {{RTCTrackEvent/track}} attribute initialized to entry.{{RTCTrackEventInit/track}}, its {{RTCTrackEvent/streams}} attribute initialized to entry.{{RTCTrackEventInit/streams}} and its {{RTCTrackEvent/transceiver}} attribute initialized to entry.{{RTCTrackEventInit/transceiver}} at the connection object.

      21. [= Resolve =] p with undefined.

  5. Return p.

Set the configuration

To set a configuration with configuration, run the following steps:

  1. Let connection be the target {{RTCPeerConnection}} object.

  2. Let oldConfig be connection.{{RTCPeerConnection/[[Configuration]]}}.

  3. If oldConfig is not null, run the following steps, and if any of them fail, [= exception/throw =] an {{InvalidModificationError}}:

    1. If the length of configuration.{{RTCConfiguration/certificates}} is different from the length of oldConfig.{{RTCConfiguration/certificates}}, fail.

    2. Let index be 0.

    3. While index is less than the length of configuration.{{RTCConfiguration/certificates}}, run the following steps:

      1. If the ECMAScript object represented by the value of configuration.{{RTCConfiguration/certificates}} at index is not the same as the ECMAScript object represented by the value of oldConfig.{{RTCConfiguration/certificates}} at index, then fail.

      2. Increment index by 1.

    4. If the value of configuration.{{RTCConfiguration/bundlePolicy}} differs from oldConfig.{{RTCConfiguration/bundlePolicy}}, then fail.

    5. If the value of configuration.{{RTCConfiguration/rtcpMuxPolicy}} differs from oldConfig.{{RTCConfiguration/rtcpMuxPolicy}}, then fail.

    6. If the value of configuration.{{RTCConfiguration/iceCandidatePoolSize}} differs from oldConfig.{{RTCConfiguration/iceCandidatePoolSize}}, and {{RTCPeerConnection/setLocalDescription}} has already been called, then fail.

  4. Let iceServers be configuration.{{RTCConfiguration/iceServers}}.

  5. Truncate iceServers to the maximum number of supported elements.

  6. For each server in iceServers, run the following steps:

    1. Let urls be server.{{RTCIceServer/urls}}.

    2. If urls is a string, set urls to a list consisting of just that string.

    3. If urls is empty, [= exception/throw =] a "{{SyntaxError}}" {{DOMException}}.

    4. For each url in urls, run the [=validate an ICE server URL=] algorithm on url.

  7. Set the [= ICE Agent =]'s ICE transports setting to the value of configuration.{{RTCConfiguration/iceTransportPolicy}}. As defined in [[!RFC9429]], if the new [= ICE transports setting =] changes the existing setting, no action will be taken until the next gathering phase. If a script wants this to happen immediately, it should do an ICE restart.

  8. Set the [= ICE Agent =]'s prefetched ICE candidate pool size as defined in [[!RFC9429]] to the value of configuration.{{RTCConfiguration/iceCandidatePoolSize}}. If the new [= ICE candidate pool size =] changes the existing setting, this may result in immediate gathering of new pooled candidates, or discarding of existing pooled candidates, as defined in [[!RFC9429]].

  9. Set the [= ICE Agent =]'s ICE servers list to iceServers.

    As defined in [[!RFC9429]], if a new list of servers replaces the [= ICE Agent =]'s existing [= ICE servers list=], no action will be taken until the next gathering phase. If a script wants this to happen immediately, it should do an ICE restart. However, if the [= ICE candidate pool size | ICE candidate pool =] has a nonzero size, any existing pooled candidates will be discarded, and new candidates will be gathered from the new servers.

  10. Store configuration in the {{RTCPeerConnection/[[Configuration]]}} internal slot.

To validate an ICE server URL url, run the following steps:

  1. Let parsedURL be the result of [=basic url parser|parsing=] url.

  2. If any of the following conditions apply, then [=exception/throw=] a "{{SyntaxError}}" {{DOMException}}:

    • parsedURL is failure
    • parsedURL's [=url/scheme=] is neither `"stun"`, `"stuns"`, `"turn"`, nor `"turns"`
    • parsedURL does not have an [=url/opaque path=]
    • parsedURL's [=url/opaque path=] contains one or more `"/"` or `"@"`
    • parsedURL's [=url/fragment=] is non-null
    • parsedURL's [=url/scheme=] is `"stun"` or `"stuns"`, and parsedURL's [=url/query=] is non-null
  3. If parsedURL's [=url/scheme=] is not implemented by the user agent, then [=exception/throw=] a {{NotSupportedError}}.

  4. Let hostAndPortURL be result of [=basic url parser|parsing=] the concatenation of `"https://"` and parsedURL's [=url/path=].

  5. If hostAndPortURL is failure, then [=exception/throw=] a "{{SyntaxError}}" {{DOMException}}.

    If hostAndPortURL's [=url/path=], [=url/username=], or [=url/password=] is non-null, then [=exception/throw=] a "{{SyntaxError}}" {{DOMException}}.

    For "stun" and "stuns" schemes, this validates [[!RFC7064]] section 3.1.
    For "turn" and "turns" schemes, this and the steps below validate [[!RFC7065]] section 3.1.

  6. If parsedURL's [=url/query=] is non-null and if parsedURL's [=url/query=] is different from either "transport=udp" or "transport=tcp", [=exception/throw=] a "{{SyntaxError}}" {{DOMException}}.

  7. If parsedURL's' [=url/scheme=] is "turn" or "turns", and either of server.{{RTCIceServer/username}} or server.{{RTCIceServer/credential}} are [=map/exist|missing=] or their UTF-8 representations fail to conform to [[RFC8489]] section 14.3 and [[RFC8265]] section 4.1 respectively, then [= exception/throw =] an {{InvalidAccessError}}.

Interface Definition

The RTCPeerConnection interface presented in this section is extended by several partial interfaces throughout this specification. Notably, the [= RTP Media API =] section, which adds the APIs to send and receive {{MediaStreamTrack}} objects.

[Exposed=Window]
interface RTCPeerConnection : EventTarget  {
  constructor(optional RTCConfiguration configuration = {});
  Promise<RTCSessionDescriptionInit> createOffer(optional RTCOfferOptions options = {});
  Promise<RTCSessionDescriptionInit> createAnswer(optional RTCAnswerOptions options = {});
  Promise<undefined> setLocalDescription(optional RTCLocalSessionDescriptionInit description = {});
  readonly attribute RTCSessionDescription? localDescription;
  readonly attribute RTCSessionDescription? currentLocalDescription;
  readonly attribute RTCSessionDescription? pendingLocalDescription;
  Promise<undefined> setRemoteDescription(RTCSessionDescriptionInit description);
  readonly attribute RTCSessionDescription? remoteDescription;
  readonly attribute RTCSessionDescription? currentRemoteDescription;
  readonly attribute RTCSessionDescription? pendingRemoteDescription;
  Promise<undefined> addIceCandidate(optional RTCIceCandidateInit candidate = {});
  readonly attribute RTCSignalingState signalingState;
  readonly attribute RTCIceGatheringState iceGatheringState;
  readonly attribute RTCIceConnectionState iceConnectionState;
  readonly attribute RTCPeerConnectionState connectionState;
  readonly attribute boolean? canTrickleIceCandidates;
  undefined restartIce();
  RTCConfiguration getConfiguration();
  undefined setConfiguration(optional RTCConfiguration configuration = {});
  undefined close();
  attribute EventHandler onnegotiationneeded;
  attribute EventHandler onicecandidate;
  attribute EventHandler onicecandidateerror;
  attribute EventHandler onsignalingstatechange;
  attribute EventHandler oniceconnectionstatechange;
  attribute EventHandler onicegatheringstatechange;
  attribute EventHandler onconnectionstatechange;

  // Legacy Interface Extensions
  // Supporting the methods in this section is optional.
  // If these methods are supported
  // they must be implemented as defined
  // in section "Legacy Interface Extensions"
  Promise<undefined> createOffer(RTCSessionDescriptionCallback successCallback,
                            RTCPeerConnectionErrorCallback failureCallback,
                            optional RTCOfferOptions options = {});
  Promise<undefined> setLocalDescription(RTCLocalSessionDescriptionInit description,
                                    VoidFunction successCallback,
                                    RTCPeerConnectionErrorCallback failureCallback);
  Promise<undefined> createAnswer(RTCSessionDescriptionCallback successCallback,
                             RTCPeerConnectionErrorCallback failureCallback);
  Promise<undefined> setRemoteDescription(RTCSessionDescriptionInit description,
                                     VoidFunction successCallback,
                                     RTCPeerConnectionErrorCallback failureCallback);
  Promise<undefined> addIceCandidate(RTCIceCandidateInit candidate,
                                VoidFunction successCallback,
                                RTCPeerConnectionErrorCallback failureCallback);
};

Attributes

localDescription of type {{RTCSessionDescription}}, readonly, nullable

The {{localDescription}} attribute MUST return the [=local description=].

The local description is {{RTCPeerConnection/[[PendingLocalDescription]]}} if it is not null, otherwise it is {{RTCPeerConnection/[[CurrentLocalDescription]]}}.

Note that {{RTCPeerConnection/[[CurrentLocalDescription]]}}.{{RTCSessionDescription/sdp}} and {{RTCPeerConnection/[[PendingLocalDescription]]}}.{{RTCSessionDescription/sdp}} need not be string-wise identical to the {{RTCSessionDescriptionInit/sdp}} value passed to the corresponding {{setLocalDescription}} call (i.e. SDP may be parsed and reformatted, and ICE candidates may be added).

currentLocalDescription of type {{RTCSessionDescription}}, readonly, nullable

The {{currentLocalDescription}} attribute MUST return {{RTCPeerConnection/[[CurrentLocalDescription]]}}.

It represents the local description that was successfully negotiated the last time the {{RTCPeerConnection}} transitioned into the stable state plus any local candidates that have been generated by the [= ICE Agent =] since the offer or answer was created.

pendingLocalDescription of type {{RTCSessionDescription}}, readonly, nullable

The {{pendingLocalDescription}} attribute MUST return {{RTCPeerConnection/[[PendingLocalDescription]]}}.

It represents a local description that is in the process of being negotiated plus any local candidates that have been generated by the [= ICE Agent =] since the offer or answer was created. If the {{RTCPeerConnection}} is in the stable state, the value is null.

remoteDescription of type {{RTCSessionDescription}}, readonly, nullable

The {{remoteDescription}} attribute MUST return the [=remote description=].

The remote description is {{RTCPeerConnection/[[PendingRemoteDescription]]}} if it is not null, otherwise it is {{RTCPeerConnection/[[CurrentRemoteDescription]]}}.

Note that {{RTCPeerConnection/[[CurrentRemoteDescription]]}}.{{RTCSessionDescription/sdp}} and {{RTCPeerConnection/[[PendingRemoteDescription]]}}.{{RTCSessionDescription/sdp}} need not be string-wise identical to the {{RTCSessionDescriptionInit/sdp}} value passed to the corresponding {{setRemoteDescription}} call (i.e. SDP may be parsed and reformatted, and ICE candidates may be added).

currentRemoteDescription of type {{RTCSessionDescription}}, readonly, nullable

The {{currentRemoteDescription}} attribute MUST return {{RTCPeerConnection/[[CurrentRemoteDescription]]}}.

It represents the last remote description that was successfully negotiated the last time the {{RTCPeerConnection}} transitioned into the stable state plus any remote candidates that have been supplied via {{RTCPeerConnection/addIceCandidate()}} since the offer or answer was created.

pendingRemoteDescription of type {{RTCSessionDescription}}, readonly, nullable

The {{pendingRemoteDescription}} attribute MUST return {{RTCPeerConnection/[[PendingRemoteDescription]]}}.

It represents a remote description that is in the process of being negotiated, complete with any remote candidates that have been supplied via {{RTCPeerConnection/addIceCandidate()}} since the offer or answer was created. If the {{RTCPeerConnection}} is in the stable state, the value is null.

signalingState of type {{RTCSignalingState}}, readonly

The {{signalingState}} attribute MUST return the {{RTCPeerConnection/RTCPeerConnection}} object's {{RTCPeerConnection/[[SignalingState]]}}.

iceGatheringState of type {{RTCIceGatheringState}}, readonly

The {{iceGatheringState}} attribute MUST return the {{RTCPeerConnection}} object's {{RTCPeerConnection/[[IceGatheringState]]}}.

iceConnectionState of type {{RTCIceConnectionState}}, readonly

The {{iceConnectionState}} attribute MUST return the {{RTCPeerConnection}} object's {{RTCPeerConnection/[[IceConnectionState]]}}.

connectionState of type {{RTCPeerConnectionState}}, readonly

The {{connectionState}} attribute MUST return the {{RTCPeerConnection}} object's {{RTCPeerConnection/[[ConnectionState]]}}.

canTrickleIceCandidates of type boolean, readonly, nullable

The {{canTrickleIceCandidates}} attribute indicates whether the remote peer is able to accept trickled ICE candidates [[RFC8838]]. The value is determined based on whether a remote description indicates support for trickle ICE, as defined in [[!RFC9429]]. Prior to the completion of {{RTCPeerConnection/setRemoteDescription}}, this value is null.

onnegotiationneeded of type EventHandler
The event type of this event handler is {{RTCPeerConnection/negotiationneeded}}.
onicecandidate of type EventHandler
The event type of this event handler is {{RTCPeerConnection/icecandidate}}.
onicecandidateerror of type EventHandler
The event type of this event handler is {{RTCPeerConnection/icecandidateerror}}.
onsignalingstatechange of type EventHandler
The event type of this event handler is {{RTCPeerConnection/signalingstatechange}}.
oniceconnectionstatechange of type EventHandler
The event type of this event handler is {{RTCPeerConnection/iceconnectionstatechange}}
onicegatheringstatechange of type EventHandler
The event type of this event handler is {{RTCPeerConnection/icegatheringstatechange}}.
onconnectionstatechange of type EventHandler
The event type of this event handler is {{RTCPeerConnection/connectionstatechange}}.

Methods

createOffer

The {{createOffer}} method generates a blob of SDP that contains an RFC 3264 offer with the supported configurations for the session, including descriptions of the local {{MediaStreamTrack}}s attached to this {{RTCPeerConnection}}, the codec/RTP/RTCP capabilities supported by this implementation, and parameters of the [= ICE agent =] and the DTLS connection. The options parameter may be supplied to provide additional control over the offer generated.

If a system has limited resources (e.g. a finite number of decoders), {{createOffer}} needs to return an offer that reflects the current state of the system, so that {{setLocalDescription}} will succeed when it attempts to acquire those resources. The session descriptions MUST remain usable by {{setLocalDescription}} without causing an error until at least the end of the [= fulfillment =] callback of the returned promise.

Creating the SDP MUST follow the appropriate process for generating an offer described in [[!RFC9429]], except the user agent MUST treat a {{RTCRtpTransceiver/stopping}} transceiver as {{RTCRtpTransceiver/stopped}} for the purposes of RFC9429 in this case.

As an offer, the generated SDP will contain the full set of codec/RTP/RTCP capabilities supported or preferred by the session (as opposed to an answer, which will include only a specific negotiated subset to use). In the event {{createOffer}} is called after the session is established, {{createOffer}} will generate an offer that is compatible with the current session, incorporating any changes that have been made to the session since the last complete offer-answer exchange, such as addition or removal of tracks. If no changes have been made, the offer will include the capabilities of the current local description as well as any additional capabilities that could be negotiated in an updated offer.

The generated SDP will also contain the [= ICE agent =]'s {{RTCIceParameters/usernameFragment}}, {{RTCIceParameters/password}} and ICE options (as defined in [[RFC5245]], Section 14) and may also contain any local candidates that have been gathered by the agent.

The {{RTCConfiguration/certificates}} value in configuration for the {{RTCPeerConnection}} provides the certificates configured by the application for the {{RTCPeerConnection}}. These certificates, along with any default certificates are used to produce a set of certificate fingerprints. These certificate fingerprints are used in the construction of SDP.

The process of generating an SDP exposes a subset of the media capabilities of the underlying system, which provides generally persistent cross-origin information on the device. It thus increases the fingerprinting surface of the application. In privacy-sensitive contexts, browsers can consider mitigations such as generating SDP matching only a common subset of the capabilities.

When the method is called, the user agent MUST run the following steps:

  1. Let connection be the {{RTCPeerConnection}} object on which the method was invoked.

  2. If connection.{{RTCPeerConnection/[[IsClosed]]}} is true, return a promise [= rejected =] with a newly [= exception/created =] {{InvalidStateError}}.

  3. Return the result of [= chaining =] the result of [= creating an offer =] with connection to connection's [= operations chain =].

To create an offer given connection run the following steps:

  1. If connection.{{RTCPeerConnection/[[SignalingState]]}} is neither {{RTCSignalingState/"stable"}} nor {{RTCSignalingState/"have-local-offer"}}, return a promise [= rejected =] with a newly [= exception/created =] {{InvalidStateError}}.

  2. Let p be a new promise.

  3. [=In parallel=], begin the [= in-parallel steps to create an offer =] given connection and p.

  4. Return p.

The in-parallel steps to create an offer given connection and a promise p are as follows:

  1. If connection was not constructed with a set of certificates, and one has not yet been generated, wait for it to be generated.

  2. Inspect the offerer's system state to determine the currently available resources as necessary for generating the offer, as described in [[!RFC9429]].

  3. If this inspection failed for any reason, [= reject =] p with a newly [= exception/created =] {{OperationError}} and abort these steps.

  4. Queue a task that runs the [= final steps to create an offer =] given connection and p.

The final steps to create an offer given connection and a promise p are as follows:

  1. If connection.{{RTCPeerConnection/[[IsClosed]]}} is true, then abort these steps.

  2. If connection was modified in such a way that additional inspection of the [= offerer's system state =] is necessary, then [=in parallel=] begin the [= in-parallel steps to create an offer =] again, given connection and p, and abort these steps.

    This may be necessary if, for example, {{createOffer}} was called when only an audio {{RTCRtpTransceiver}} was added to connection, but while performing the [= in-parallel steps to create an offer =], a video {{RTCRtpTransceiver}} was added, requiring additional inspection of video system resources.
  3. Given the information that was obtained from previous inspection, the current state of connection and its {{RTCRtpTransceiver}}s, generate an SDP offer, sdpString, as described in [[!RFC9429]].

    1. As described in [[RFC8843]] (Section 7), if bundling is used (see {{RTCBundlePolicy}}) an offerer tagged m= section must be selected in order to negotiate a BUNDLE group. The user agent MUST choose the m= section that corresponds to the first non-stopped transceiver in the [= set of transceivers =] as the offerer tagged m= section. This allows the remote endpoint to predict which transceiver is the offerer tagged m= section without having to parse the SDP.

    2. Let filteredCodecs be the result of applying the following filter on transceiver.{{RTCRtpTransceiver/[[PreferredCodecs]]}}. The filtering MUST NOT change the order of the codec preferences:

      1. Let kind be transceiver's {{RTCRtpTransceiver/[[Receiver]]}}'s {{RTCRtpReceiver/[[ReceiverTrack]]}}'s {{MediaStreamTrack/kind}}.

      2. If transceiver.{{RTCRtpTransceiver/direction}} is {{RTCRtpTransceiverDirection/"sendonly"}} or {{RTCRtpTransceiverDirection/"sendrecv"}}, exclude any codecs not included in the [=RTCRtpSender/list of implemented send codecs=] for kind, using the [= codec dictionary match =] algorithm with ignoreAsymmetricalParameters set to true.

      3. If transceiver.{{RTCRtpTransceiver/direction}} is {{RTCRtpTransceiverDirection/"recvonly"}} or {{RTCRtpTransceiverDirection/"sendrecv"}}, exclude any codecs not included in the [=list of implemented receive codecs=] for kind, using the [= codec dictionary match =] algorithm with ignoreAsymmetricalParameters set to true.

      The codec preferences of a [= media description =]'s [= associated =] transceiver, transceiver, is said to be the value of filteredCodecs if non-empty and said to be unset otherwise.

    3. If the length of the {{RTCRtpSender/[[SendEncodings]]}} slot of the {{RTCRtpSender}} is larger than 1, then for each encoding given in {{RTCRtpSender/[[SendEncodings]]}} of the {{RTCRtpSender}}, add an a=rid send line to the corresponding media section, and add an a=simulcast:send line giving the RIDs in the same order as given in the {{RTCRtpSendParameters/encodings}} field. No RID restrictions are set.

      [[RFC8853]] section 5.2 specifies that the order of RIDs in the a=simulcast line suggests a proposed order of preference. If the browser decides not to transmit all encodings, one should expect it to stop sending the last encoding in the list first.

  4. Let offer be a newly created {{RTCSessionDescriptionInit}} dictionary with its {{RTCSessionDescriptionInit/type}} member initialized to the string {{RTCSdpType/"offer"}} and its {{RTCSessionDescriptionInit/sdp}} member initialized to sdpString.

  5. Set the {{RTCPeerConnection/[[LastCreatedOffer]]}} internal slot to sdpString.

  6. [= Resolve =] p with offer.

createAnswer

The {{createAnswer}} method generates an [[!SDP]] answer with the supported configuration for the session that is compatible with the parameters in the remote configuration. Like {{createOffer}}, the returned blob of SDP contains descriptions of the local {{MediaStreamTrack}}s attached to this {{RTCPeerConnection}}, the codec/RTP/RTCP options negotiated for this session, and any candidates that have been gathered by the [= ICE Agent =]. The options parameter may be supplied to provide additional control over the generated answer.

Like {{createOffer}}, the returned description SHOULD reflect the current state of the system. The session descriptions MUST remain usable by {{setLocalDescription}} without causing an error until at least the end of the [= fulfillment =] callback of the returned promise.

As an answer, the generated SDP will contain a specific codec/RTP/RTCP configuration that, along with the corresponding offer, specifies how the media plane should be established. The generation of the SDP MUST follow the appropriate process for generating an answer described in [[!RFC9429]].

The generated SDP will also contain the [= ICE agent =]'s {{RTCIceParameters/usernameFragment}}, {{RTCIceParameters/password}} and ICE options (as defined in [[RFC5245]], Section 14) and may also contain any local candidates that have been gathered by the agent.

The {{RTCConfiguration/certificates}} value in configuration for the {{RTCPeerConnection}} provides the certificates configured by the application for the {{RTCPeerConnection}}. These certificates, along with any default certificates are used to produce a set of certificate fingerprints. These certificate fingerprints are used in the construction of SDP.

An answer can be marked as provisional, as described in [[!RFC9429]], by setting the {{RTCSessionDescriptionInit/type}} to {{RTCSdpType/"pranswer"}}.

When the method is called, the user agent MUST run the following steps:

  1. Let connection be the {{RTCPeerConnection}} object on which the method was invoked.

  2. If connection.{{RTCPeerConnection/[[IsClosed]]}} is true, return a promise [= rejected =] with a newly [= exception/created =] {{InvalidStateError}}.

  3. Return the result of [= chaining =] the result of [= creating an answer =] with connection to connection's [= operations chain =].

To create an answer given connection run the following steps:

  1. If connection.{{RTCPeerConnection/[[SignalingState]]}} is neither {{RTCSignalingState/"have-remote-offer"}} nor {{RTCSignalingState/"have-local-pranswer"}}, return a promise [= rejected =] with a newly [= exception/created =] {{InvalidStateError}}.

  2. Let p be a new promise.

  3. [=In parallel=], begin the [= in-parallel steps to create an answer =] given connection and p.

  4. Return p.

The in-parallel steps to create an answer given connection and a promise p are as follows:

  1. If connection was not constructed with a set of certificates, and one has not yet been generated, wait for it to be generated.

  2. Inspect the answerer's system state to determine the currently available resources as necessary for generating the answer, as described in [[!RFC9429]].

  3. If this inspection failed for any reason, [= reject =] p with a newly [= exception/created =] {{OperationError}} and abort these steps.

  4. Queue a task that runs the [= final steps to create an answer =] given p.

The final steps to create an answer given a promise p are as follows:

  1. If connection.{{RTCPeerConnection/[[IsClosed]]}} is true, then abort these steps.

  2. If connection was modified in such a way that additional inspection of the [= answerer's system state =] is necessary, then [=in parallel=] begin the [= in-parallel steps to create an answer =] again given connection and p, and abort these steps.

    This may be necessary if, for example, {{createAnswer}} was called when an {{RTCRtpTransceiver}}'s direction was {{RTCRtpTransceiverDirection/"recvonly"}}, but while performing the [= in-parallel steps to create an answer =], the direction was changed to {{RTCRtpTransceiverDirection/"sendrecv"}}, requiring additional inspection of video encoding resources.
  3. Given the information that was obtained from previous inspection and the current state of connection and its {{RTCRtpTransceiver}}s, generate an SDP answer, sdpString, as described in [[!RFC9429]].

    1. Let filteredCodecs be the result of applying the following filter on transceiver.{{RTCRtpTransceiver/[[PreferredCodecs]]}}. The filtering MUST NOT change the order of the codec preferences:

      1. Let kind be transceiver's {{RTCRtpTransceiver/[[Receiver]]}}'s {{RTCRtpReceiver/[[ReceiverTrack]]}}'s {{MediaStreamTrack/kind}}.

      2. If transceiver.{{RTCRtpTransceiver/direction}} is {{RTCRtpTransceiverDirection/"sendonly"}} or {{RTCRtpTransceiverDirection/"sendrecv"}}, exclude any codecs not included in the [=RTCRtpSender/list of implemented send codecs=] for kind, using the [= codec dictionary match =] algorithm with ignoreAsymmetricalParameters set to true.

      3. If transceiver.{{RTCRtpTransceiver/direction}} is {{RTCRtpTransceiverDirection/"recvonly"}} or {{RTCRtpTransceiverDirection/"sendrecv"}}, exclude any codecs not included in the [=list of implemented receive codecs=] for kind, using the [= codec dictionary match =] algorithm with ignoreAsymmetricalParameters set to true.

      The codec preferences of a [= media description =]'s [= associated =] transceiver, transceiver, is said to be the value of filteredCodecs if non-empty and said to be unset otherwise.

    2. If this is an answer to an offer to receive simulcast, then for each media section requesting to receive simulcast, run the following steps:

      1. If the a=simulcast attribute contains comma-separated alternatives for RIDs, remove all but the first ones.

      2. If there are any identically named RIDs in the a=simulcast attribute, remove all but the first one. No RID restrictions are set.

      3. Exclude from the media section in the answer any RID not found in the corresponding transceiver's {{RTCRtpTransceiver/[[Sender]]}}.{{RTCRtpSender/[[SendEncodings]]}}.

      When a {{RTCPeerConnection/setRemoteDescription(offer)}} establishes a sender's [=proposed envelope=], the sender's {{RTCRtpSender/[[SendEncodings]]}} is updated in {{RTCSignalingState/"have-remote-offer"}}, exposing it to rollback. However, once a [=simulcast envelope=] has been established for the sender, subsequent pruning of the sender's {{RTCRtpSender/[[SendEncodings]]}} happen when this answer is set with {{RTCPeerConnection/setLocalDescription}}.

  4. Let answer be a newly created {{RTCSessionDescriptionInit}} dictionary with its {{RTCSessionDescriptionInit/type}} member initialized to the string {{RTCSdpType/"answer"}} and its {{RTCSessionDescriptionInit/sdp}} member initialized to sdpString.

  5. Set the {{RTCPeerConnection/[[LastCreatedAnswer]]}} internal slot to sdpString.

  6. [= Resolve =] p with answer.

setLocalDescription

The {{setLocalDescription}} method instructs the {{RTCPeerConnection}} to apply the supplied {{RTCLocalSessionDescriptionInit}} as the local description.

This API changes the local media state. In order to successfully handle scenarios where the application wants to offer to change from one media format to a different, incompatible format, the {{RTCPeerConnection}} MUST be able to simultaneously support use of both the current and pending local descriptions (e.g. support codecs that exist in both descriptions) until a final answer is received, at which point the {{RTCPeerConnection}} can fully adopt the pending local description, or rollback to the current description if the remote side rejected the change.

Passing in a description is optional. If left out, then {{setLocalDescription}} will implicitly [= create an offer =] or [= create an answer =], as needed. As noted in [[!RFC9429]], if a description with SDP is passed in, that SDP is not allowed to have changed from when it was returned from either {{createOffer}} or {{createAnswer}}.

When the method is invoked, the user agent MUST run the following steps:

  1. Let description be the method's first argument.

  2. Let connection be the {{RTCPeerConnection}} object on which the method was invoked.

  3. Let sdp be description.{{RTCSessionDescriptionInit/sdp}}.

  4. Return the result of [= chaining =] the following steps to connection's [= operations chain =]:

    1. Let type be description.{{RTCSessionDescriptionInit/type}} if [=map/exists|present=], or {{RTCSdpType/"offer"}} if not [=map/exists|present=] and connection.{{RTCPeerConnection/[[SignalingState]]}} is either {{RTCSignalingState/"stable"}}, {{RTCSignalingState/"have-local-offer"}}, or {{RTCSignalingState/"have-remote-pranswer"}}; otherwise {{RTCSdpType/"answer"}}.

    2. If type is {{RTCSdpType/"offer"}}, and sdp is not the empty string and not equal to connection.{{RTCPeerConnection/[[LastCreatedOffer]]}}, then return a promise [= rejected =] with a newly [= exception/created =] {{InvalidModificationError}} and abort these steps.

    3. If type is {{RTCSdpType/"answer"}} or {{RTCSdpType/"pranswer"}}, and sdp is not the empty string and not equal to connection.{{RTCPeerConnection/[[LastCreatedAnswer]]}}, then return a promise [= rejected =] with a newly [= exception/created =] {{InvalidModificationError}} and abort these steps.

    4. If sdp is the empty string, and type is {{RTCSdpType/"offer"}}, then run the following sub steps:

      1. Set sdp to the value of connection.{{RTCPeerConnection/[[LastCreatedOffer]]}}.

      2. If sdp is the empty string, or if it no longer accurately represents the [= offerer's system state =] of connection, then let p be the result of [= creating an offer =] with connection, and return the result of [= promise/reacting =] to p with a fulfillment step that [= set a local session description | sets the local session description =] indicated by its first argument.

    5. If sdp is the empty string, and type is {{RTCSdpType/"answer"}} or {{RTCSdpType/"pranswer"}}, then run the following sub steps:

      1. Set sdp to the value of connection.{{RTCPeerConnection/[[LastCreatedAnswer]]}}.

      2. If sdp is the empty string, or if it no longer accurately represents the [= answerer's system state =] of connection, then let p be the result of [= creating an answer =] with connection, and return the result of [= promise/reacting =] to p with the following fulfillment steps:

        1. Let answer be the first argument to these fulfillment steps.

        2. Return the result of [= setting the local session description =] indicated by {type, answer.{{RTCSessionDescriptionInit/sdp}}}.

    6. Return the result of [= setting the local session description =] indicated by {type, sdp}.

As noted in [[!RFC9429]], calling this method may trigger the ICE candidate gathering process by the [= ICE Agent =].

setRemoteDescription

The {{setRemoteDescription}} method instructs the {{RTCPeerConnection}} to apply the supplied {{RTCSessionDescriptionInit}} as the remote offer or answer. This API changes the local media state.

When the method is invoked, the user agent MUST run the following steps:

  1. Let description be the method's first argument.

  2. Let connection be the {{RTCPeerConnection}} object on which the method was invoked.

  3. Return the result of [= chaining =] the following steps to connection's [= operations chain =]:

    1. If description.{{RTCSessionDescriptionInit/type}} is {{RTCSdpType/"offer"}} and is invalid for the current connection.{{RTCPeerConnection/[[SignalingState]]}} as described in [[!RFC9429]], then run the following sub steps:

      1. Let p be the result of [= setting the local session description =] indicated by {type: {{RTCSdpType/"rollback"}}}.

      2. Return the result of [= promise/reacting =] to p with a fulfillment step that [= set a remote session description | sets the remote session description =] description, and abort these steps.

    2. Return the result of [= setting the remote session description =] description.

addIceCandidate

The {{addIceCandidate}} method provides a remote candidate to the [= ICE Agent =]. This method can also be used to indicate the end of remote candidates when called with an empty string for the {{RTCIceCandidate/candidate}} member. The only members of the argument used by this method are {{RTCIceCandidate/candidate}}, {{RTCIceCandidate/sdpMid}}, {{RTCIceCandidate/sdpMLineIndex}}, and {{RTCIceCandidate/usernameFragment}}; the rest are ignored. When the method is invoked, the user agent MUST run the following steps:

  1. Let candidate be the method's argument.

  2. Let connection be the {{RTCPeerConnection}} object on which the method was invoked.

  3. If candidate.{{RTCIceCandidate/candidate}} is not an empty string and both candidate.{{RTCIceCandidate/sdpMid}} and candidate.{{RTCIceCandidate/sdpMLineIndex}} are null, return a promise [= rejected =] with a newly [= exception/created =] {{TypeError}}.

  4. Return the result of [= chaining =] the following steps to connection's [= operations chain =]:

    1. If {{RTCPeerConnection/remoteDescription}} is null return a promise [= rejected =] with a newly [= exception/created =] {{InvalidStateError}}.

    2. If candidate.{{RTCIceCandidate/sdpMid}} is not null, run the following steps:

      1. If candidate.{{RTCIceCandidate/sdpMid}} is not equal to the mid of any media description in {{RTCPeerConnection/remoteDescription}}, return a promise [= rejected =] with a newly [= exception/created =] {{OperationError}}.

    3. Else, if candidate.{{RTCIceCandidate/sdpMLineIndex}} is not null, run the following steps:

      1. If candidate.{{RTCIceCandidate/sdpMLineIndex}} is equal to or larger than the number of media descriptions in {{RTCPeerConnection/remoteDescription}}, return a promise [= rejected =] with a newly [= exception/created =] {{OperationError}}.

    4. If either candidate.{{RTCIceCandidate/sdpMid}} or candidate.{{RTCIceCandidate/sdpMLineIndex}} indicate a media description in {{RTCPeerConnection/remoteDescription}} whose associated transceiver is {{RTCRtpTransceiver/ stopped}}, return a promise [= resolved =] with undefined.

    5. If candidate.{{RTCIceCandidate/usernameFragment}} is not null, and is not equal to any username fragment present in the corresponding [= media description =] of an applied remote description, return a promise [= rejected =] with a newly [= exception/created =] {{OperationError}}.

    6. Let p be a new promise.

    7. [=In parallel=], if the candidate is not [= administratively prohibited =], add the ICE candidate candidate as described in [[!RFC9429]]. Use candidate.{{RTCIceCandidate/usernameFragment}} to identify the ICE [= generation =]; if {{RTCIceCandidate/usernameFragment}} is null, process the candidate for the most recent ICE [= generation =].

      If candidate.{{RTCIceCandidate/candidate}} is an empty string, process candidate as an end-of-candidates indication for the corresponding [= media description =] and ICE candidate [= generation =]. If both candidate.{{RTCIceCandidate/sdpMid}} and candidate.{{RTCIceCandidate/sdpMLineIndex}} are null, then this end-of-candidates indication applies to all [= media description =]s.

      1. If candidate could not be successfully added the user agent MUST queue a task that runs the following steps:

        1. If connection.{{RTCPeerConnection/[[IsClosed]]}} is true, then abort these steps.

        2. [= Reject =] p with a newly [= exception/created =] {{OperationError}} and abort these steps.

      2. If candidate is applied successfully, or if the candidate was [= administratively prohibited =] the user agent MUST queue a task that runs the following steps:

        1. If connection.{{RTCPeerConnection/[[IsClosed]]}} is true, then abort these steps.

        2. If connection.{{RTCPeerConnection/[[PendingRemoteDescription]]}} is not null, and represents the ICE [= generation =] for which candidate was processed, add candidate to connection.{{RTCPeerConnection/[[PendingRemoteDescription]]}}.sdp.

        3. If connection.{{RTCPeerConnection/[[CurrentRemoteDescription]]}} is not null, and represents the ICE [= generation =] for which candidate was processed, add candidate to connection.{{RTCPeerConnection/[[CurrentRemoteDescription]]}}.sdp.

        4. [= Resolve =] p with undefined.

    8. Return p.

A candidate or a [= gathering source =] can be administratively prohibited. A remote candidate is [= administratively prohibited =] if the UA decides not to allow connection attempts to this address. Local candidates are gathered from a gathering source which can be local (network interface) or remote (remote candidate, STUN server or TURN server). A local gathering source is [= administratively prohibited =] if the UA decides not to use the source network interface for WebRTC traffic. A remote gathering source is [= administratively prohibited =] if the UA decides not to allow connection attempts to the source address. If all candidates are said to be [= administratively prohibited =], the UA MUST NOT allow connection to any remote candidate and MUST NOT gather candidates from any gathering source.

For privacy reasons, there is no indication to the developer about whether or not an address/port is blocked; it behaves exactly as if there was no response from the address.

The UA MUST prohibit connections to addresses on the [[!Fetch]] [= block bad port =] list, and MAY choose to prohibit connections to other addresses.

If the {{RTCConfiguration/iceTransportPolicy}} member of the {{RTCConfiguration}} is {{RTCIceTransportPolicy/relay}}, candidates requiring external resolution, such as mDNS candidates and DNS candidates, MUST be prohibited.

Due to WebIDL processing, {{RTCPeerConnection/addIceCandidate}}(null) is interpreted as a call with the default dictionary present, which, in the above algorithm, indicates end-of-candidates for all media descriptions and ICE candidate generation. This is by design for legacy reasons.

restartIce

The {{restartIce}} method tells the {{RTCPeerConnection}} that ICE should be restarted. Subsequent calls to {{createOffer}} will create descriptions that will restart ICE, as described in section 9.1.1.1 of [[RFC5245]].

When this method is invoked, the user agent MUST run the following steps:

  1. Let connection be the {{RTCPeerConnection}} on which the method was invoked.

  2. Empty connection.{{RTCPeerConnection/[[LocalIceCredentialsToReplace]]}}, and populate it with all ICE credentials (ice-ufrag and ice-pwd as defined in section 15.4 of [[RFC5245]]) found in connection.{{RTCPeerConnection/[[CurrentLocalDescription]]}}, as well as all ICE credentials found in connection.{{RTCPeerConnection/[[PendingLocalDescription]]}}.

  3. [= Update the negotiation-needed flag =] for connection.

getConfiguration

Returns an {{RTCConfiguration}} object representing the current configuration of this {{RTCPeerConnection}} object.

When this method is called, the user agent MUST return the {{RTCConfiguration}} object stored in the {{RTCPeerConnection/[[Configuration]]}} internal slot.

setConfiguration

The {{setConfiguration}} method updates the configuration of this {{RTCPeerConnection}} object. This includes changing the configuration of the [= ICE Agent =]. As noted in [[!RFC9429]], when the ICE configuration changes in a way that requires a new gathering phase, an ICE restart is required.

When the {{setConfiguration}} method is invoked, the user agent MUST run the following steps:

  1. Let connection be the {{RTCPeerConnection}} on which the method was invoked.

  2. If connection.{{RTCPeerConnection/[[IsClosed]]}} is true, [= exception/throw =] an {{InvalidStateError}}.

  3. [= Set the configuration =] specified by configuration.

close

When the {{close}} method is invoked, the user agent MUST run the following steps:

  1. Let connection be the {{RTCPeerConnection}} object on which the method was invoked.

  2. [= close the connection =] with connection and the value false.

The close the connection algorithm given a connection and a disappear boolean, is as follows:

  1. If connection.{{RTCPeerConnection/[[IsClosed]]}} is true, abort these steps.

  2. Set connection.{{RTCPeerConnection/[[IsClosed]]}} to true.

  3. Set connection.{{RTCPeerConnection/[[SignalingState]]}} to {{RTCSignalingState/"closed"}}. This does not fire any event.

  4. Let transceivers be the result of executing the {{CollectTransceivers}} algorithm. For every {{RTCRtpTransceiver}} transceiver in transceivers, run the following steps:

    1. If transceiver.{{RTCRtpTransceiver/[[Stopped]]}} is true, abort these sub steps.

    2. [= Stop the RTCRtpTransceiver =] with transceiver and disappear.

  5. Set the {{RTCDataChannel/[[ReadyState]]}} slot of each of connection's {{RTCDataChannel}}s to {{RTCDataChannelState/"closed"}}.

    The {{RTCDataChannel}}s will be closed abruptly and the closing procedure will not be invoked.
  6. If connection.{{RTCPeerConnection/[[SctpTransport]]}} is not null, tear down the underlying SCTP association by sending an SCTP ABORT chunk and set the {{RTCSctpTransport/[[SctpTransportState]]}} to {{RTCSctpTransportState/"closed"}}.

  7. Set the {{RTCDtlsTransport/[[DtlsTransportState]]}} slot of each of connection's {{RTCDtlsTransport}}s to {{RTCDtlsTransportState/"closed"}}.

  8. Destroy connection's [= ICE Agent =], abruptly ending any active ICE processing and releasing any relevant resources (e.g. TURN permissions).

  9. Set the {{RTCIceTransport/[[IceTransportState]]}} slot of each of connection's {{RTCIceTransport}}s to {{RTCIceTransportState/"closed"}}.

  10. Set connection.{{RTCPeerConnection/[[IceConnectionState]]}} to {{RTCIceConnectionState/"closed"}}. This does not fire any event.

  11. Set connection.{{RTCPeerConnection/[[ConnectionState]]}} to {{RTCPeerConnectionState/"closed"}}. This does not fire any event.

Legacy Interface Extensions

The IDL definition of these methods are documented in the main definition of the {{RTCPeerConnection}} interface since overloaded functions are not allowed to be defined in partial interfaces.

Supporting the methods in this section is optional. However, if these methods are supported it is mandatory to implement according to what is specified here.

The addStream method that used to exist on {{RTCPeerConnection}} is easy to polyfill as:
RTCPeerConnection.prototype.addStream = function(stream) {
  stream.getTracks().forEach((track) => this.addTrack(track, stream));
};

Method extensions

Methods

createOffer

When the createOffer method is called, the user agent MUST run the following steps:

  1. Let successCallback be the method's first argument.

  2. Let failureCallback be the callback indicated by the method's second argument.

  3. Let options be the callback indicated by the method's third argument.

  4. Run the steps specified by {{RTCPeerConnection}}'s {{RTCPeerConnection/createOffer()}} method with options as the sole argument, and let p be the resulting promise.

  5. Upon [= fulfillment =] of p with value offer, invoke successCallback with offer as the argument.

  6. Upon [= rejection =] of p with reason r, invoke failureCallback with r as the argument.

  7. Return a promise [= resolved =] with undefined.

setLocalDescription

When the setLocalDescription method is called, the user agent MUST run the following steps:

  1. Let description be the method's first argument.

  2. Let successCallback be the callback indicated by the method's second argument.

  3. Let failureCallback be the callback indicated by the method's third argument.

  4. Run the steps specified by {{RTCPeerConnection}}'s {{RTCPeerConnection/setLocalDescription}} method with description as the sole argument, and let p be the resulting promise.

  5. Upon [= fulfillment =] of p, invoke successCallback with undefined as the argument.

  6. Upon [= rejection =] of p with reason r, invoke failureCallback with r as the argument.

  7. Return a promise [= resolved =] with undefined.

createAnswer
The legacy createAnswer method does not take an {{RTCAnswerOptions}} parameter, since no known legacy createAnswer implementation ever supported it.

When the createAnswer method is called, the user agent MUST run the following steps:

  1. Let successCallback be the method's first argument.

  2. Let failureCallback be the callback indicated by the method's second argument.

  3. Run the steps specified by {{RTCPeerConnection}}'s {{RTCPeerConnection/createAnswer()}} method with no arguments, and let p be the resulting promise.

  4. Upon [= fulfillment =] of p with value answer, invoke successCallback with answer as the argument.

  5. Upon [= rejection =] of p with reason r, invoke failureCallback with r as the argument.

  6. Return a promise [= resolved =] with undefined.

setRemoteDescription

When the setRemoteDescription method is called, the user agent MUST run the following steps:

  1. Let description be the method's first argument.

  2. Let successCallback be the callback indicated by the method's second argument.

  3. Let failureCallback be the callback indicated by the method's third argument.

  4. Run the steps specified by {{RTCPeerConnection}}'s {{RTCPeerConnection/setRemoteDescription}} method with description as the sole argument, and let p be the resulting promise.

  5. Upon [= fulfillment =] of p, invoke successCallback with undefined as the argument.

  6. Upon [= rejection =] of p with reason r, invoke failureCallback with r as the argument.

  7. Return a promise [= resolved =] with undefined.

addIceCandidate

When the addIceCandidate method is called, the user agent MUST run the following steps:

  1. Let candidate be the method's first argument.

  2. Let successCallback be the callback indicated by the method's second argument.

  3. Let failureCallback be the callback indicated by the method's third argument.

  4. Run the steps specified by {{RTCPeerConnection}}'s {{RTCPeerConnection/addIceCandidate()}} method with candidate as the sole argument, and let p be the resulting promise.

  5. Upon [= fulfillment =] of p, invoke successCallback with undefined as the argument.

  6. Upon [= rejection =] of p with reason r, invoke failureCallback with r as the argument.

  7. Return a promise [= resolved =] with undefined.

Callback Definitions

These callbacks are only used on the legacy APIs.

RTCPeerConnectionErrorCallback

callback RTCPeerConnectionErrorCallback = undefined (DOMException error);

Callback {{RTCPeerConnectionErrorCallback}} Parameters

error of type {{DOMException}}
An error object encapsulating information about what went wrong.

RTCSessionDescriptionCallback

callback RTCSessionDescriptionCallback = undefined (RTCSessionDescriptionInit description);

Callback {{RTCSessionDescriptionCallback}} Parameters

description of type {{RTCSessionDescriptionInit}}
The object containing the SDP [[!SDP]].

Legacy configuration extensions

This section describes a set of legacy extensions that may be used to influence how an offer is created, in addition to the media added to the {{RTCPeerConnection}}. Developers are encouraged to use the {{RTCRtpTransceiver}} API instead.

When {{RTCPeerConnection/createOffer}} is called with any of the legacy options specified in this section, run the followings steps instead of the regular {{RTCPeerConnection/createOffer}} steps:

  1. Let options be the methods first argument.

  2. Let connection be the current {{RTCPeerConnection}} object.

  3. For each offerToReceive<Kind> member in options with kind, kind, run the following steps:

    1. If the value of the dictionary member is false,
      1. For each non-stopped {{RTCRtpTransceiverDirection/"sendrecv"}} transceiver of [=RTCRtpTransceiver/transceiver kind=] kind, set transceiver.{{RTCRtpTransceiver/[[Direction]]}} to {{RTCRtpTransceiverDirection/"sendonly"}}.

      2. For each non-stopped {{RTCRtpTransceiverDirection/"recvonly"}} transceiver of [=RTCRtpTransceiver/transceiver kind=] kind, set transceiver.{{RTCRtpTransceiver/[[Direction]]}} to {{RTCRtpTransceiverDirection/"inactive"}}.

      Continue with the next option, if any.

    2. If connection has any non-stopped {{RTCRtpTransceiverDirection/"sendrecv"}} or {{RTCRtpTransceiverDirection/"recvonly"}} transceivers of [=RTCRtpTransceiver/transceiver kind=] kind, continue with the next option, if any.

    3. Let transceiver be the result of invoking the equivalent of connection.{{RTCPeerConnection/addTransceiver}}(kind), except that this operation MUST NOT [= update the negotiation-needed flag =].

    4. If transceiver is unset because the previous operation threw an error, abort these steps.

    5. Set transceiver.{{RTCRtpTransceiver/[[Direction]]}} to {{RTCRtpTransceiverDirection/"recvonly"}}.

  4. Run the steps specified by {{RTCPeerConnection/createOffer}} to create the offer.

partial dictionary RTCOfferOptions {
  boolean offerToReceiveAudio;
  boolean offerToReceiveVideo;
};
          

Attributes

offerToReceiveAudio of type boolean

This setting provides additional control over the directionality of audio. For example, it can be used to ensure that audio can be received, regardless if audio is sent or not.

offerToReceiveVideo of type boolean

This setting provides additional control over the directionality of video. For example, it can be used to ensure that video can be received, regardless if video is sent or not.

Garbage collection

An {{RTCPeerConnection}} object MUST not be garbage collected as long as any event can cause an event handler to be triggered on the object. When the object's {{RTCPeerConnection/[[IsClosed]]}} internal slot is true, no such event handler can be triggered and it is therefore safe to garbage collect the object.

All {{RTCDataChannel}} and {{MediaStreamTrack}} objects that are connected to an {{RTCPeerConnection}} have a strong reference to the {{RTCPeerConnection}} object.

Error Handling

General Principles

All methods that return promises are governed by the standard error handling rules of promises. Methods that do not return promises may throw exceptions to indicate errors.

Session Description Model

RTCSdpType

The {{RTCSdpType}} enum describes the type of an {{RTCSessionDescriptionInit}}, {{RTCLocalSessionDescriptionInit}}, or {{RTCSessionDescription}} instance.

enum RTCSdpType {
  "offer",
  "pranswer",
  "answer",
  "rollback"
};
{{RTCSdpType}} Enumeration description
Enum valueDescription
offer

An {{RTCSdpType}} of {{RTCSdpType/"offer"}} indicates that a description MUST be treated as an [[!SDP]] offer.

pranswer

An {{RTCSdpType}} of {{RTCSdpType/"pranswer"}} indicates that a description MUST be treated as an [[!SDP]] answer, but not a final answer. A description used as an SDP pranswer may be applied as a response to an SDP offer, or an update to a previously sent SDP pranswer.

answer

An {{RTCSdpType}} of {{RTCSdpType/"answer"}} indicates that a description MUST be treated as an [[!SDP]] final answer, and the offer-answer exchange MUST be considered complete. A description used as an SDP answer may be applied as a response to an SDP offer or as an update to a previously sent SDP pranswer.

rollback

An {{RTCSdpType}} of {{RTCSdpType/"rollback"}} indicates that a description MUST be treated as canceling the current SDP negotiation and moving the SDP [[!SDP]] offer back to what it was in the previous stable state. Note the local or remote SDP descriptions in the previous stable state could be null if there has not yet been a successful offer-answer negotiation. An {{RTCSdpType/"answer"}} or {{RTCSdpType/"pranswer"}} cannot be rolled back.

RTCSessionDescription Class

The {{RTCSessionDescription}} class is used by {{RTCPeerConnection}} to expose local and remote session descriptions.

[Exposed=Window]
interface RTCSessionDescription {
  constructor(RTCSessionDescriptionInit descriptionInitDict);
  readonly attribute RTCSdpType type;
  readonly attribute DOMString sdp;
  [Default] RTCSessionDescriptionInit toJSON();
};

Constructors

constructor()

The {{RTCSessionDescription()}} constructor takes a dictionary argument, description, whose content is used to initialize the new {{RTCSessionDescription}} object. This constructor is deprecated; it exists for legacy compatibility reasons only.

Attributes

type of type {{RTCSdpType}}, readonly
The type of this session description.
sdp of type DOMString, readonly, defaulting to ""
The string representation of the SDP [[!SDP]].

Methods

toJSON()
When called, run [[!WEBIDL]]'s [= default toJSON steps =].
dictionary RTCSessionDescriptionInit {
  required RTCSdpType type;
  DOMString sdp = "";
};

Dictionary RTCSessionDescriptionInit Members

type of type {{RTCSdpType}}, required
The type of this session description.
sdp of type DOMString
The string representation of the SDP [[!SDP]]; if {{RTCSessionDescriptionInit/type}} is {{RTCSdpType/"rollback"}}, this member is unused.
dictionary RTCLocalSessionDescriptionInit {
  RTCSdpType type;
  DOMString sdp = "";
};

Dictionary RTCLocalSessionDescriptionInit Members

type of type {{RTCSdpType}}
The type of this description. If not [=map/exists|present=], then {{RTCPeerConnection/setLocalDescription}} will infer the type based on the {{RTCPeerConnection}}'s {{RTCPeerConnection/[[SignalingState]]}}.
sdp of type DOMString
The string representation of the SDP [[!SDP]]; if {{RTCLocalSessionDescriptionInit/type}} is {{RTCSdpType/"rollback"}}, this member is unused.

Session Negotiation Model

Many changes to state of an {{RTCPeerConnection}} will require communication with the remote side via the signaling channel, in order to have the desired effect. The app can be kept informed as to when it needs to do signaling, by listening to the {{RTCPeerConnection/negotiationneeded}} event. This event is fired according to the state of the connection's negotiation-needed flag, represented by a {{RTCPeerConnection/[[NegotiationNeeded]]}} internal slot.

Setting Negotiation-Needed

If an operation is performed on an {{RTCPeerConnection}} that requires signaling, the connection will be marked as needing negotiation. Examples of such operations include adding or stopping an {{RTCRtpTransceiver}}, or adding the first {{ RTCDataChannel}}.

Internal changes within the implementation can also result in the connection being marked as needing negotiation.

Note that the exact procedures for [= update the negotiation-needed flag | updating the negotiation-needed flag =] are specified below.

Clearing Negotiation-Needed

The [=negotiation-needed flag=] is cleared when a session description of type {{RTCSdpType/"answer"}} [= set a session description | is set =] successfully, and the supplied description matches the state of the {{RTCRtpTransceiver}}s and {{RTCDataChannel}}s that currently exist on the {{RTCPeerConnection}}. Specifically, this means that all non-{{RTCRtpTransceiver/stopped}} transceivers have an [= associated =] section in the local description with matching properties, and, if any data channels have been created, a data section exists in the local description.

Note that the exact procedures for [= update the negotiation-needed flag | updating the negotiation-needed flag =] are specified below.

Updating the Negotiation-Needed flag

The process below occurs where referenced elsewhere in this document. It also may occur as a result of internal changes within the implementation that affect negotiation. If such changes occur, the user agent MUST [= update the negotiation-needed flag =].

To update the negotiation-needed flag for connection, run the following steps:

  1. If the length of connection.{{RTCPeerConnection/[[Operations]]}} is not 0, then set connection.{{RTCPeerConnection/[[UpdateNegotiationNeededFlagOnEmptyChain]]}} to true, and abort these steps.

  2. Queue a task to run the following steps:

    1. If connection.{{RTCPeerConnection/[[IsClosed]]}} is true, abort these steps.

    2. If the length of connection.{{RTCPeerConnection/[[Operations]]}} is not 0, then set connection.{{RTCPeerConnection/[[UpdateNegotiationNeededFlagOnEmptyChain]]}} to true, and abort these steps.

    3. If connection.{{RTCPeerConnection/[[SignalingState]]}} is not {{RTCSignalingState/"stable"}}, abort these steps.

      The [=negotiation-needed flag=] will be updated once the state transitions to {{RTCSignalingState/"stable"}}, as part of the steps for [= setting a session description =].

    4. If the result of [= check if negotiation is needed | checking if negotiation is needed =] is false, clear the negotiation-needed flag by setting connection.{{RTCPeerConnection/[[NegotiationNeeded]]}} to false, and abort these steps.

    5. If connection.{{RTCPeerConnection/[[NegotiationNeeded]]}} is already true, abort these steps.

    6. Set connection.{{RTCPeerConnection/[[NegotiationNeeded]]}} to true.

    7. [= Fire an event =] named {{RTCPeerConnection/negotiationneeded}} at connection.

    The task queueing prevents {{RTCPeerConnection/negotiationneeded}} from firing prematurely, in the common situation where multiple modifications to connection are being made at once.

    Additionally, we avoid racing with negotiation methods by only firing {{RTCPeerConnection/negotiationneeded}} when the [= operations chain =] is empty.

To check if negotiation is needed for connection, perform the following checks:

  1. If any implementation-specific negotiation is required, as described at the start of this section, return true.

  2. If connection.{{RTCPeerConnection/[[LocalIceCredentialsToReplace]]}} is not empty, return true.

  3. Let description be connection.{{RTCPeerConnection/[[CurrentLocalDescription]]}}.

  4. If connection has created any {{RTCDataChannel}}s, and no m= section in description has been negotiated yet for data, return true.

  5. For each transceiver in connection's [= set of transceivers =], perform the following checks:

    1. If transceiver.{{RTCRtpTransceiver/[[Stopping]]}} is true and transceiver.{{RTCRtpTransceiver/[[Stopped]]}} is false, return true.

    2. If transceiver isn't {{RTCRtpTransceiver/ stopped}} and isn't yet [= associated =] with an m= section in description, return true.

    3. If transceiver isn't {{RTCRtpTransceiver/ stopped}} and is [= associated =] with an m= section in description then perform the following checks:

      1. If transceiver.{{RTCRtpTransceiver/[[Direction]]}} is {{RTCRtpTransceiverDirection/"sendrecv"}} or {{RTCRtpTransceiverDirection/"sendonly"}}, and the [= associated =] m= section in description either doesn't contain a single a=msid line, or the number of MSIDs from the a=msid lines in this m= section, or the MSID values themselves, differ from what is in transceiver.sender.{{RTCRtpSender/[[AssociatedMediaStreamIds]]}}, return true.

      2. If description is of type {{RTCSdpType/"offer"}}, and the direction of the [= associated =] m= section in neither connection.{{RTCPeerConnection/[[CurrentLocalDescription]]}} nor connection.{{RTCPeerConnection/[[CurrentRemoteDescription]]}} matches transceiver.{{RTCRtpTransceiver/[[Direction]]}}, return true. In this step, when the direction is compared with a direction found in {{RTCPeerConnection/[[CurrentRemoteDescription]]}}, the description's direction must be reversed to represent the peer's point of view.

      3. If description is of type {{RTCSdpType/"answer"}}, and the direction of the [= associated =] m= section in the description does not match transceiver.{{RTCRtpTransceiver/[[Direction]]}} intersected with the offered direction (as described in [[!RFC9429]]), return true.

    4. If transceiver is {{RTCRtpTransceiver/ stopped}} and is [= associated =] with an m= section, but the associated m= section is not yet rejected in connection.{{RTCPeerConnection/[[CurrentLocalDescription]]}} or connection.{{RTCPeerConnection/[[CurrentRemoteDescription]]}}, return true.

  6. If all the preceding checks were performed and true was not returned, nothing remains to be negotiated; return false.

Interfaces for Interactive Connectivity Establishment

RTCIceCandidate Interface

This interface describes an ICE candidate, described in [[RFC5245]] Section 2. Other than {{RTCIceCandidate/candidate}}, {{RTCIceCandidate/sdpMid}}, {{RTCIceCandidate/sdpMLineIndex}}, {{RTCIceCandidate/usernameFragment}}, {{RTCIceCandidate/relayProtocol}}, and {{RTCIceCandidate/url}}, the remaining attributes are derived from parsing the {{RTCIceCandidateInit/candidate}} member in candidateInitDict, if it is well formed.

[Exposed=Window]
interface RTCIceCandidate {
  constructor(optional RTCLocalIceCandidateInit candidateInitDict = {});
  readonly attribute DOMString candidate;
  readonly attribute DOMString? sdpMid;
  readonly attribute unsigned short? sdpMLineIndex;
  readonly attribute DOMString? foundation;
  readonly attribute RTCIceComponent? component;
  readonly attribute unsigned long? priority;
  readonly attribute DOMString? address;
  readonly attribute RTCIceProtocol? protocol;
  readonly attribute unsigned short? port;
  readonly attribute RTCIceCandidateType? type;
  readonly attribute RTCIceTcpCandidateType? tcpType;
  readonly attribute DOMString? relatedAddress;
  readonly attribute unsigned short? relatedPort;
  readonly attribute DOMString? usernameFragment;
  readonly attribute RTCIceServerTransportProtocol? relayProtocol;
  readonly attribute USVString? url;
  RTCIceCandidateInit toJSON();
};

Constructor

constructor()

The RTCIceCandidate() constructor takes a dictionary argument, candidateInitDict, whose content is used to initialize the new {{RTCIceCandidate}} object.

When invoked, run the following steps:

  1. If both the {{RTCIceCandidateInit/sdpMid}} and {{RTCIceCandidateInit/sdpMLineIndex}} members of candidateInitDict are null, [= exception/throw =] a {{TypeError}}.
  2. Return the result of [= creating an RTCIceCandidate =] with candidateInitDict.

To create an RTCIceCandidate with a candidateInitDict dictionary, run the following steps:

  1. Let iceCandidate be a newly created {{RTCIceCandidate}} object.
  2. Create internal slots for the following attributes of iceCandidate, initilized to null: {{foundation}}, {{component}}, {{priority}}, {{address}}, {{protocol}}, {{port}}, {{type}}, {{tcpType}}, {{relatedAddress}}, and {{relatedPort}}.
  3. Create internal slots for the following attributes of iceCandidate, initilized to their namesakes in candidateInitDict: {{candidate}}, {{sdpMid}}, {{sdpMLineIndex}}, {{usernameFragment}}, {{relayProtocol}}, {{url}}.
  4. Let candidate be the {{RTCIceCandidateInit/candidate}} dictionary member of candidateInitDict. If candidate is not an empty string, run the following steps:
    1. Parse candidate using the [= candidate-attribute =] grammar.
    2. If parsing of [= candidate-attribute =] has failed, abort these steps.
    3. If any field in the parse result represents an invalid value for the corresponding attribute in iceCandidate, abort these steps.
    4. Set the corresponding internal slots in iceCandidate to the field values of the parsed result.
  5. Return iceCandidate.

The constructor for {{RTCIceCandidate}} only does basic parsing and type checking for the dictionary members in candidateInitDict. Detailed validation on the well-formedness of {{RTCIceCandidateInit/candidate}}, {{RTCIceCandidateInit/sdpMid}}, {{RTCIceCandidateInit/sdpMLineIndex}}, {{RTCIceCandidateInit/usernameFragment}} with the corresponding session description is done when passing the {{RTCIceCandidate}} object to {{RTCPeerConnection/addIceCandidate()}}.

To maintain backward compatibility, any error on parsing the candidate attribute is ignored. In such case, the {{candidate}} attribute holds the raw {{RTCIceCandidateInit/candidate}} string given in candidateInitDict, but derivative attributes such as {{foundation}}, {{priority}}, etc are set to null.

Attributes

Most attributes below are defined in section 15.1 of [[RFC5245]].

candidate of type DOMString, readonly
This carries the [= candidate-attribute =] as defined in section 15.1 of [[RFC5245]]. If this {{RTCIceCandidate}} represents an end-of-candidates indication or a peer reflexive remote candidate, {{candidate}} is an empty string.
sdpMid of type DOMString, readonly, nullable
If not null, this contains the media stream "identification-tag" defined in [[!RFC5888]] for the media component this candidate is associated with.
sdpMLineIndex of type unsigned short, readonly, nullable
If not null, this indicates the index (starting at zero) of the [= media description =] in the SDP this candidate is associated with.
foundation of type DOMString, readonly, nullable
A unique identifier that allows ICE to correlate candidates that appear on multiple {{RTCIceTransport}}s.
component of type {{RTCIceComponent}}, readonly, nullable
The assigned network component of the candidate ({{RTCIceComponent/"rtp"}} or {{RTCIceComponent/"rtcp"}}). This corresponds to the component-id field in [= candidate-attribute =], decoded to the string representation as defined in {{RTCIceComponent}}.
priority of type unsigned long, readonly, nullable
The assigned priority of the candidate.
address of type DOMString, readonly, nullable

The address of the candidate, allowing for IPv4 addresses, IPv6 addresses, and fully qualified domain names (FQDNs). This corresponds to the connection-address field in [= candidate-attribute =].

Remote candidates may be exposed, for instance via {{RTCIceTransport/[[SelectedCandidatePair]]}}.{{RTCIceCandidatePair/remote}}. By default, the user agent MUST leave the {{RTCIceCandidate/address}} attribute as null for any exposed remote candidate. Once a {{RTCPeerConnection}} instance learns on an address by the web application using {{RTCPeerConnection/addIceCandidate}}, the user agent can expose the {{address}} attribute value in any {{RTCIceCandidate}} of the {{RTCPeerConnection}} instance representing a remote candidate with that newly learnt address.

The addresses exposed in candidates gathered via ICE and made visibile to the application in {{RTCIceCandidate}} instances can reveal more information about the device and the user (e.g. location, local network topology) than the user might have expected in a non-WebRTC enabled browser.

These addresses are always exposed to the application, and potentially exposed to the communicating party, and can be exposed without any specific user consent (e.g. for peer connections used with data channels, or to receive media only).

These addresses can also be used as temporary or persistent cross-origin states, and thus contribute to the fingerprinting surface of the device.

Applications can avoid exposing addresses to the communicating party, either temporarily or permanently, by forcing the [= ICE Agent =] to report only relay candidates via the {{RTCConfiguration/iceTransportPolicy}} member of {{RTCConfiguration}}.

To limit the addresses exposed to the application itself, browsers can offer their users different policies regarding sharing local addresses, as defined in [[RFC8828]].

protocol of type {{RTCIceProtocol}}, readonly, nullable
The protocol of the candidate ({{RTCIceProtocol/"udp"}}/{{RTCIceProtocol/"tcp"}}). This corresponds to the transport field in [= candidate-attribute =].
port of type unsigned short, readonly, nullable
The port of the candidate.
type of type {{RTCIceCandidateType}}, readonly, nullable
The type of the candidate. This corresponds to the candidate-types field in [= candidate-attribute =].
tcpType of type {{RTCIceTcpCandidateType}}, readonly, nullable
If {{protocol}} is {{RTCIceProtocol/"tcp"}}, {{tcpType}} represents the type of TCP candidate. Otherwise, {{tcpType}} is null. This corresponds to the tcp-type field in [= candidate-attribute =].
relatedAddress of type DOMString, readonly, nullable
For a candidate that is derived from another, such as a relay or reflexive candidate, the {{relatedAddress}} is the IP address of the candidate that it is derived from. For host candidates, the {{relatedAddress}} is null. This corresponds to the rel-address field in [= candidate-attribute =].
relatedPort of type unsigned short, readonly, nullable
For a candidate that is derived from another, such as a relay or reflexive candidate, the {{relatedPort}} is the port of the candidate that it is derived from. For host candidates, the {{relatedPort}} is null. This corresponds to the rel-port field in [= candidate-attribute =].
usernameFragment of type DOMString, readonly, nullable
This carries the ufrag as defined in section 15.4 of [[RFC5245]].
relayProtocol of type RTCIceServerTransportProtocol, readonly, nullable
For local candidates of type {{RTCIceCandidateType/"relay"}} this is the protocol used by the endpoint to communicate with the TURN server. For all other candidates it is `null`.
url of type USVString, readonly, nullable
For local candidates of type {{RTCIceCandidateType/"srflx"}} or type {{RTCIceCandidateType/"relay"}} this is the URL of the ICE server from which the candidate was obtained. For all other candidates it is `null`.

Methods

toJSON()
To invoke the {{toJSON()}} operation of the {{RTCIceCandidate}} interface, run the following steps:
  1. Let json be a new {{RTCIceCandidateInit}} dictionary.
  2. For each attribute identifier attr in «{{candidate}}, {{sdpMid}}, {{sdpMLineIndex}}, {{usernameFragment}}»:
    1. Let value be the result of getting the underlying value of the attribute identified by attr, given this {{RTCIceCandidate}} object.
    2. Set json[attr] to value.
  3. Return json.

{{relayProtocol}} and {{url}} exist for local examination, not signaling, and do not survive stringification.

dictionary RTCIceCandidateInit {
  DOMString candidate = "";
  DOMString? sdpMid = null;
  unsigned short? sdpMLineIndex = null;
  DOMString? usernameFragment = null;
};

Dictionary RTCIceCandidateInit Members

candidate of type DOMString, defaulting to ""
This carries the [= candidate-attribute =] as defined in section 15.1 of [[RFC5245]]. If this represents an end-of-candidates indication, {{candidate}} is an empty string.
sdpMid of type DOMString, nullable, defaulting to null
If not null, this contains the [= media stream "identification-tag" =] defined in [[!RFC5888]] for the media component this candidate is associated with.
sdpMLineIndex of type unsigned short, nullable, defaulting to null
If not null, this indicates the index (starting at zero) of the [= media description =] in the SDP this candidate is associated with.
usernameFragment of type DOMString, nullable, defaulting to null
If not null, this carries the ufrag as defined in section 15.4 of [[RFC5245]].
dictionary RTCLocalIceCandidateInit : RTCIceCandidateInit {
  RTCIceServerTransportProtocol? relayProtocol = null;
  USVString? url = null;
};

Dictionary RTCLocalIceCandidateInit Members

relayProtocol of type RTCIceServerTransportProtocol, nullable, defaulting to null
Initializes the {{RTCIceCandidate/relayProtocol}} attribute.
url of type USVString, nullable, defaulting to null
Initializes the {{RTCIceCandidate/url}} attribute.

candidate-attribute Grammar

The [= candidate-attribute =] grammar is used to parse the {{RTCIceCandidateInit/candidate}} member of candidateInitDict in the {{RTCIceCandidate()}} constructor.

The primary grammar for [= candidate-attribute =] is defined in section 15.1 of [[RFC5245]]. In addition, the browser MUST support the grammar extension for ICE TCP as defined in section 4.5 of [[!RFC6544]].

The browser MAY support other grammar extensions for [= candidate-attribute =] as defined in other RFCs.

RTCIceProtocol Enum

The {{RTCIceProtocol}} represents the protocol of the ICE candidate.

enum RTCIceProtocol {
  "udp",
  "tcp"
};
{{RTCIceProtocol}} Enumeration description
Enum valueDescription
udp A UDP candidate, as described in [[RFC5245]].
tcp A TCP candidate, as described in [[!RFC6544]].

RTCIceTcpCandidateType Enum

The {{RTCIceTcpCandidateType}} represents the type of the ICE TCP candidate, as defined in [[!RFC6544]].

enum RTCIceTcpCandidateType {
  "active",
  "passive",
  "so"
};
{{RTCIceTcpCandidateType}} Enumeration description
Enum valueDescription
active An {{RTCIceTcpCandidateType/"active"}} TCP candidate is one for which the transport will attempt to open an outbound connection but will not receive incoming connection requests.
passive A {{RTCIceTcpCandidateType/"passive"}} TCP candidate is one for which the transport will receive incoming connection attempts but not attempt a connection.
so An {{RTCIceTcpCandidateType/"so"}} candidate is one for which the transport will attempt to open a connection simultaneously with its peer.

The user agent will typically only gather {{RTCIceTcpCandidateType/active}} ICE TCP candidates.

RTCIceCandidateType Enum

The {{RTCIceCandidateType}} represents the type of the ICE candidate, as defined in [[RFC5245]] section 15.1.

enum RTCIceCandidateType {
  "host",
  "srflx",
  "prflx",
  "relay"
};
{{RTCIceCandidateType}} Enumeration description
Enum valueDescription
host A host candidate, as defined in Section 4.1.1.1 of [[RFC5245]].
srflx A server reflexive candidate, as defined in Section 4.1.1.2 of [[RFC5245]].
prflx A peer reflexive candidate, as defined in Section 4.1.1.2 of [[RFC5245]].
relay A relay candidate, as defined in Section 7.1.3.2.1 of [[RFC5245]].

RTCIceServerTransportProtocol Enum

The {{RTCIceServerTransportProtocol}} represents the type of the transport protocol used between the client and the server, as defined in [[RFC8656]] section 3.1.

enum RTCIceServerTransportProtocol {
  "udp",
  "tcp",
  "tls",
};
{{RTCIceServerTransportProtocol}} Enumeration description
Enum valueDescription
udp The TURN client is using UDP as transport to the server.
tcp The TURN client is using TCP as transport to the server.
tls The TURN client is using TLS as transport to the server.

RTCPeerConnectionIceEvent

The {{RTCPeerConnection/icecandidate}} event of the {{RTCPeerConnection}} uses the {{RTCPeerConnectionIceEvent}} interface.

When firing an {{RTCPeerConnectionIceEvent}} event that contains an {{RTCIceCandidate}} object, it MUST include values for both {{RTCIceCandidate/sdpMid}} and {{RTCIceCandidate/sdpMLineIndex}}. If the {{RTCIceCandidate}} is of type {{RTCIceCandidateType/"srflx"}} or type {{RTCIceCandidateType/"relay"}}, the {{RTCPeerConnectionIceEvent/url}} property of the event MUST be set to the URL of the ICE server from which the candidate was obtained.

The {{RTCPeerConnection/icecandidate}} event is used for three different types of indications:
  • A candidate has been gathered. The {{RTCPeerConnectionIceEvent/candidate}} member of the event will be populated normally. It should be signaled to the remote peer and passed into {{RTCPeerConnection/addIceCandidate}}.

  • An {{RTCIceTransport}} has finished gathering a [= generation =] of candidates, and is providing an end-of-candidates indication as defined by Section 8.2 of [[RFC8838]]. This is indicated by {{RTCPeerConnectionIceEvent/candidate}}.{{RTCIceCandidate/candidate}} being set to an empty string. The {{RTCPeerConnectionIceEvent/candidate}} object should be signaled to the remote peer and passed into {{RTCPeerConnection/addIceCandidate}} like a typical ICE candidate, in order to provide the end-of-candidates indication to the remote peer.

  • All {{RTCIceTransport}}s have finished gathering candidates, and the {{RTCPeerConnection}}'s {{RTCIceGatheringState}} has transitioned to {{RTCIceGatheringState/"complete"}}. This is indicated by the {{RTCPeerConnectionIceEvent/candidate}} member of the event being set to null. This only exists for backwards compatibility, and this event does not need to be signaled to the remote peer. It's equivalent to an {{RTCPeerConnection/icegatheringstatechange}} event with the {{RTCIceGatheringState/"complete"}} state.

[Exposed=Window]
interface RTCPeerConnectionIceEvent : Event {
  constructor(DOMString type, optional RTCPeerConnectionIceEventInit eventInitDict = {});
  readonly attribute RTCIceCandidate? candidate;
  readonly attribute USVString? url;
};

Constructors

RTCPeerConnectionIceEvent.constructor()

Attributes

candidate of type {{RTCIceCandidate}}, readonly, nullable

The {{candidate}} attribute is the {{RTCIceCandidate}} object with the new ICE candidate that caused the event.

This attribute is set to null when an event is generated to indicate the end of candidate gathering.

Even where there are multiple media components, only one event containing a null candidate is fired.

url of type USVString, readonly, nullable

The {{url}} attribute is the STUN or TURN URL that identifies the STUN or TURN server used to gather this candidate. If the candidate was not gathered from a STUN or TURN server, this parameter will be set to null.

This attribute is deprecated; it exists for legacy compatibility reasons only. Prefer the candidate {{RTCIceCandidate/url}}.

dictionary RTCPeerConnectionIceEventInit : EventInit {
  RTCIceCandidate? candidate;
  USVString? url;
};

Dictionary RTCPeerConnectionIceEventInit Members

candidate of type {{RTCIceCandidate}}, nullable

See the {{RTCPeerConnectionIceEvent/candidate}} attribute of the {{RTCPeerConnectionIceEvent}} interface.

url of type USVString, nullable
The {{url}} attribute is the STUN or TURN URL that identifies the STUN or TURN server used to gather this candidate.

RTCPeerConnectionIceErrorEvent

The {{RTCPeerConnection/icecandidateerror}} event of the {{RTCPeerConnection}} uses the {{RTCPeerConnectionIceErrorEvent}} interface.

[Exposed=Window]
interface RTCPeerConnectionIceErrorEvent : Event {
  constructor(DOMString type, RTCPeerConnectionIceErrorEventInit eventInitDict);
  readonly attribute DOMString? address;
  readonly attribute unsigned short? port;
  readonly attribute USVString url;
  readonly attribute unsigned short errorCode;
  readonly attribute USVString errorText;
};

Constructors

RTCPeerConnectionIceErrorEvent.constructor()

Attributes

address of type DOMString, readonly, nullable

The {{address}} attribute is the local IP address used to communicate with the STUN or TURN server.

On a multihomed system, multiple interfaces may be used to contact the server, and this attribute allows the application to figure out on which one the failure occurred.

If the local IP address value is not already exposed as part of a local candidate, the {{address}} attribute will be set to null.

port of type unsigned short, readonly, nullable

The {{port}} attribute is the port used to communicate with the STUN or TURN server.

If the {{address}} attribute is null, the {{port}} attribute is also set to null.

url of type USVString, readonly

The {{url}} attribute is the STUN or TURN URL that identifies the STUN or TURN server for which the failure occurred.

errorCode of type unsigned short, readonly

The {{errorCode}} attribute is the numeric STUN error code returned by the STUN or TURN server [[STUN-PARAMETERS]].

If no host candidate can reach the server, {{errorCode}} will be set to the value 701 which is outside the STUN error code range. This error is only fired once per server URL while in the {{RTCIceGatheringState}} of {{RTCIceGatheringState/"gathering"}}.

errorText of type USVString, readonly

The {{errorText}} attribute is the STUN reason text returned by the STUN or TURN server [[STUN-PARAMETERS]].

If the server could not be reached, {{errorText}} will be set to an implementation-specific value providing details about the error.

dictionary RTCPeerConnectionIceErrorEventInit : EventInit {
  DOMString? address;
  unsigned short? port;
  USVString url;
  required unsigned short errorCode;
  USVString errorText;
};

Dictionary RTCPeerConnectionIceErrorEventInit Members

address of type DOMString, nullable

The local address used to communicate with the STUN or TURN server, or null.

port of type unsigned short, nullable

The local port used to communicate with the STUN or TURN server, or null.

url of type USVString

The STUN or TURN URL that identifies the STUN or TURN server for which the failure occurred.

errorCode of type unsigned short, required

The numeric STUN error code returned by the STUN or TURN server.

errorText of type USVString

The STUN reason text returned by the STUN or TURN server.

Certificate Management

The certificates that {{RTCPeerConnection}} instances use to authenticate with peers use the {{RTCCertificate}} interface. These objects can be explicitly generated by applications using the {{RTCPeerConnection/generateCertificate}} method and can be provided in the {{RTCConfiguration}} when constructing a new {{RTCPeerConnection}} instance.

The explicit certificate management functions provided here are optional. If an application does not provide the {{RTCConfiguration/certificates}} configuration option when constructing an {{RTCPeerConnection}} a new set of certificates MUST be generated by the user agent. That set MUST include an ECDSA certificate with a private key on the P-256 curve and a signature with a SHA-256 hash.

partial interface RTCPeerConnection {
  static Promise<RTCCertificate>
      generateCertificate(AlgorithmIdentifier keygenAlgorithm);
};

Methods

generateCertificate, static

The {{generateCertificate}} function causes the user agent to create an X.509 certificate [[!X509V3]] and corresponding private key. A handle to information is provided in the form of the {{RTCCertificate}} interface. The returned {{RTCCertificate}} can be used to control the certificate that is offered in the DTLS sessions established by {{RTCPeerConnection}}.

The keygenAlgorithm argument is used to control how the private key associated with the certificate is generated. The keygenAlgorithm argument uses the WebCrypto [[!WebCryptoAPI]] AlgorithmIdentifier type.

The following values MUST be supported by a user agent: { name: "RSASSA-PKCS1-v1_5", modulusLength: 2048, publicExponent: new Uint8Array([1, 0, 1]), hash: "SHA-256" }, and { name: "ECDSA", namedCurve: "P-256" }.

It is expected that a user agent will have a small or even fixed set of values that it will accept.

The certificate produced by this process also contains a signature. The validity of this signature is only relevant for compatibility reasons. Only the public key and the resulting certificate fingerprint are used by {{RTCPeerConnection}}, but it is more likely that a certificate will be accepted if the certificate is well formed. The browser selects the algorithm used to sign the certificate; a browser SHOULD select SHA-256 [[!FIPS-180-4]] if a hash algorithm is needed.

The resulting certificate MUST NOT include information that can be linked to a user or user agent. Randomized values for distinguished name and serial number SHOULD be used.

When the method is called, the user agent MUST run the following steps:

  1. Let keygenAlgorithm be the first argument to {{generateCertificate}}.

  2. Let expires be a value of 2592000000 (30*24*60*60*1000)

    This means the certificate will by default expire in 30 days from the time of the {{generateCertificate}} call.

  3. If keygenAlgorithm is an object, run the following steps:

    1. Let certificateExpiration be the result of converting the ECMAScript object represented by keygenAlgorithm to an {{RTCCertificateExpiration}} dictionary.

    2. If the conversion fails with an error, return a promise that is [= rejected =] with error.

    3. If certificateExpiration.{{RTCCertificateExpiration/expires}} is not undefined, set expires to certificateExpiration.{{RTCCertificateExpiration/expires}}.

    4. If expires is greater than 31536000000, set expires to 31536000000.

      This means the certificate cannot be valid for longer than 365 days from the time of the {{generateCertificate}} call.

      A user agent MAY further cap the value of expires.

  4. Let normalizedKeygenAlgorithm be the result of normalizing an algorithm with an operation name of generateKey and a supportedAlgorithms value specific to production of certificates for {{RTCPeerConnection}}.

  5. If the above normalization step fails with an error, return a promise that is [= rejected =] with error.

  6. If the normalizedKeygenAlgorithm parameter identifies an algorithm that the user agent cannot or will not use to generate a certificate for {{RTCPeerConnection}}, return a promise that is [= rejected =] with a {{DOMException}} of type {{NotSupportedError}}. In particular, normalizedKeygenAlgorithm MUST be an asymmetric algorithm that can be used to produce a signature used to authenticate DTLS connections.

  7. Let p be a new promise.

  8. Run the following steps [=in parallel=]:

    1. Perform the generate key operation specified by normalizedKeygenAlgorithm using keygenAlgorithm.

    2. Let generatedKeyingMaterial and generatedKeyCertificate be the private keying material and certificate generated by the above step.

    3. Let certificate be a new {{RTCCertificate}} object.

    4. Set certificate.[[\Expires]] to the current time plus expires value.

    5. Set certificate.{{RTCCertificate/[[Origin]]}} to the [= relevant settings object =]'s [=environment settings object/origin=].

    6. Store the generatedKeyingMaterial in a secure module, and let handle be a reference identifier to it.

    7. Set certificate.{{RTCCertificate/[[KeyingMaterialHandle]]}} to handle.

    8. Set certificate.{{RTCCertificate/[[Certificate]]}} to generatedCertificate.

    9. [=Queue a global task=] on the [=networking task source=] given the current realm's [=global object=] as global to [=resolve=] p with certificate.

  9. Return p.

RTCCertificateExpiration Dictionary

{{RTCCertificateExpiration}} is used to set an expiration date on certificates generated by {{RTCPeerConnection/generateCertificate}}.

dictionary RTCCertificateExpiration {
  [EnforceRange] unsigned long long expires;
};
expires, of type unsigned long long

An optional {{expires}} attribute MAY be added to the definition of the algorithm that is passed to {{RTCPeerConnection/generateCertificate}}. If this parameter is [=map/exists|present=] it indicates the maximum time in milliseconds that the {{RTCCertificate}} is valid for, measured from the time the certificate is created.

RTCCertificate Interface

The {{RTCCertificate}} interface represents a certificate used to authenticate WebRTC communications. In addition to the visible properties, internal slots contain a handle to the generated private keying materal ([[\KeyingMaterialHandle]]), a certificate ([[\Certificate]]) that {{RTCPeerConnection}} uses to authenticate with a peer, and the origin ([[\Origin]]) that created the object.

[Exposed=Window, Serializable]
interface RTCCertificate {
  readonly attribute EpochTimeStamp expires;
  sequence<RTCDtlsFingerprint> getFingerprints();
};

Attributes

expires of type {{EpochTimeStamp}}, readonly

The expires attribute indicates the date and time in milliseconds relative to 1970-01-01T00:00:00Z after which the certificate will be considered invalid by the browser. After this time, attempts to construct an {{RTCPeerConnection}} using this certificate fail.

Note that this value might not be reflected in a notAfter parameter in the certificate itself.

Methods

getFingerprints

Returns the list of certificate fingerprints, one of which is computed with the digest algorithm used in the certificate signature.

For the purposes of this API, the {{RTCCertificate/[[Certificate]]}} slot contains unstructured binary data. No mechanism is provided for applications to access the {{RTCCertificate/[[KeyingMaterialHandle]]}} internal slot or the keying material it references. Implementations MUST support applications storing and retrieving {{RTCCertificate}} objects from persistent storage, in a manner that also preserves the keying material referenced by {{RTCCertificate/[[KeyingMaterialHandle]]}}. Implementations SHOULD store the sensitive keying material in a secure module safe from same-process memory attacks. This allows the private key to be stored and used, but not easily read using a memory attack.

{{RTCCertificate}} objects are [= serializable objects =] [[!HTML]]. Their [= serialization steps =], given value and serialized, are:

  1. Set serialized.[[\Expires]] to the value of value.{{RTCCertificate/expires}} attribute.
  2. Set serialized.[[\Certificate]] to a copy of the unstructured binary data in value.{{RTCCertificate/[[Certificate]]}}.
  3. Set serialized.[[\Origin]] to a copy of the unstructured binary data in value.{{RTCCertificate/[[Origin]]}}.
  4. Set serialized.[[\KeyingMaterialHandle]] to a serialization of the handle in value.{{RTCCertificate/[[KeyingMaterialHandle]]}} (not the private keying material itself).

Their deserialization steps, given serialized and value, are:

  1. Initialize value.{{RTCCertificate/expires}} attribute to contain serialized.[[\Expires]].
  2. Set value.{{RTCCertificate/[[Certificate]]}} to a copy of serialized.[[\Certificate]]
  3. Set value.{{RTCCertificate/[[Origin]]}} to a copy of serialized.[[\Origin]]
  4. Set value.{{RTCCertificate/[[KeyingMaterialHandle]]}} to the private keying material handle resulting from deserializing serialized.[[\KeyingMaterialHandle]]

Supporting structured cloning in this manner allows {{RTCCertificate}} instances to be persisted to stores. It also allows instances to be passed to other origins using APIs like {{MessagePort/postMessage(message, options)}} [[html]]. However, the object cannot be used by any other origin than the one that originally created it.

RTP Media API

The RTP media API lets a web application send and receive {{MediaStreamTrack}}s over a peer-to-peer connection. Tracks, when added to an {{RTCPeerConnection}}, result in signaling; when this signaling is forwarded to a remote peer, it causes corresponding tracks to be created on the remote side.

There is not an exact 1:1 correspondence between tracks sent by one {{RTCPeerConnection}} and received by the other. For one, IDs of tracks sent have no mapping to the IDs of tracks received. Also, {{RTCRtpSender/replaceTrack}} changes the track sent by an {{RTCRtpSender}} without creating a new track on the receiver side; the corresponding {{RTCRtpReceiver}} will only have a single track, potentially representing multiple sources of media stitched together. Both {{RTCPeerConnection/addTransceiver}} and {{RTCRtpSender/replaceTrack}} can be used to cause the same track to be sent multiple times, which will be observed on the receiver side as multiple receivers each with its own separate track. Thus it's more accurate to think of a 1:1 relationship between an {{RTCRtpSender}} on one side and an {{RTCRtpReceiver}}'s track on the other side, matching senders and receivers using the {{RTCRtpTransceiver}}'s {{RTCRtpTransceiver/mid}} if necessary.

When sending media, the sender may need to rescale or resample the media to meet various requirements, including the envelope negotiated by SDP, alignment restrictions of the encoder, or even CPU overuse detection or bandwidth estimation.

Following the rules in [[!RFC9429]], the video MAY be downscaled. The media MUST NOT be upscaled to create fake data that did not occur in the input source, the media MUST NOT be cropped except as needed to satisfy constraints on pixel counts, and the aspect ratio MUST NOT be changed.

The WebRTC Working Group is seeking implementation feedback on the need and timeline for a more complex handling of this situation. Some possible designs have been discussed in GitHub issue 1283.

Whenever video is rescaled as a result of {{RTCRtpEncodingParameters/scaleResolutionDownBy}}, situations when the resulting width or height is not an integer may occur. The user agent MUST NOT transmit video larger than the integer part of the scaled width and height from {{RTCRtpEncodingParameters/scaleResolutionDownBy}}, except to respect an encoder's minimum resolution. What to transmit if the integer part of the scaled width or height is zero is [=implementation-defined=].

The actual encoding and transmission of {{MediaStreamTrack}}s is managed through objects called {{RTCRtpSender}}s. Similarly, the reception and decoding of {{MediaStreamTrack}}s is managed through objects called {{RTCRtpReceiver}}s. Each {{RTCRtpSender}} is associated with at most one track, and each track to be received is associated with exactly one {{RTCRtpReceiver}}.

The encoding and transmission of each {{MediaStreamTrack}} SHOULD be made such that its characteristics (width, height and frameRate for video tracks; sampleSize, sampleRate and channelCount for audio tracks) are to a reasonable degree retained by the track created on the remote side. There are situations when this does not apply, there may for example be resource constraints at either endpoint or in the network or there may be {{RTCRtpSender}} settings applied that instruct the implementation to act differently.

An {{RTCPeerConnection}} object contains a set of {{RTCRtpTransceiver}}s, representing the paired senders and receivers with some shared state. This set is initialized to the empty set when the {{RTCPeerConnection}} object is created. {{RTCRtpSender}}s and {{RTCRtpReceiver}}s are always created at the same time as an {{RTCRtpTransceiver}}, which they will remain attached to for their lifetime. {{RTCRtpTransceiver}}s are created implicitly when the application attaches a {{MediaStreamTrack}} to an {{RTCPeerConnection}} via the {{RTCPeerConnection/addTrack()}} method, or explicitly when the application uses the {{RTCPeerConnection/addTransceiver}} method. They are also created when a remote description is applied that includes a new media description. Additionally, when a remote description is applied that indicates the remote endpoint has media to send, the relevant {{MediaStreamTrack}} and {{RTCRtpReceiver}} are surfaced to the application via the {{RTCPeerConnection/track}} event.

In order for an {{RTCRtpTransceiver}} to send and/or receive media with another endpoint this must be negotiated with SDP such that both endpoints have an {{RTCRtpTransceiver}} object that is [= associated =] with the same [= media description =].

When creating an offer, enough media descriptions will be generated to cover all transceivers on that end. When this offer is set as the local description, any disassociated transceivers get associated with media descriptions in the offer.

When an offer is set as the remote description, any media descriptions in it not yet associated with a transceiver get associated with a new or existing transceiver. In this case, only disassociated transceivers that were created via the {{RTCPeerConnection/addTrack()}} method may be associated. Disassociated transceivers created via the {{RTCPeerConnection/addTransceiver()}} method, however, won't get associated even if media descriptions are available in the remote offer. Instead, new transceivers will be created and associated if there aren't enough {{RTCPeerConnection/addTrack()}}-created transceivers. This sets {{RTCPeerConnection/addTrack()}}-created and {{RTCPeerConnection/addTransceiver()}}-created transceivers apart in a critical way that is not observable from inspecting their attributes.

When creating an answer, only media descriptions that were present in the offer may be listed in the answer. As a consequence, any transceivers that were not associated when setting the remote offer remain disassociated after setting the local answer. This can be remedied by the answerer creating a follow-up offer, initiating another offer/answer exchange, or in the case of using {{RTCPeerConnection/addTrack()}}-created transceivers, making sure that enough media descriptions are offered in the initial exchange.

RTCPeerConnection Interface Extensions

The RTP media API extends the {{RTCPeerConnection}} interface as described below.

          partial interface RTCPeerConnection {
  sequence<RTCRtpSender> getSenders();
  sequence<RTCRtpReceiver> getReceivers();
  sequence<RTCRtpTransceiver> getTransceivers();
  RTCRtpSender addTrack(MediaStreamTrack track, MediaStream... streams);
  undefined removeTrack(RTCRtpSender sender);
  RTCRtpTransceiver addTransceiver((MediaStreamTrack or DOMString) trackOrKind,
                                   optional RTCRtpTransceiverInit init = {});
  attribute EventHandler ontrack;
};

Attributes

ontrack of type EventHandler

The event type of this event handler is {{RTCPeerConnection/track}}.

Methods

getSenders

Returns a sequence of {{RTCRtpSender}} objects representing the RTP senders that belong to non-stopped {{RTCRtpTransceiver}} objects currently attached to this {{RTCPeerConnection}} object.

When the {{getSenders}} method is invoked, the user agent MUST return the result of executing the {{CollectSenders}} algorithm.

We define the CollectSenders algorithm as follows:

  1. Let transceivers be the result of executing the {{CollectTransceivers}} algorithm.
  2. Let senders be a new empty sequence.
  3. For each transceiver in transceivers,
    1. If transceiver.{{RTCRtpTransceiver/[[Stopped]]}} is false, add transceiver.{{RTCRtpTransceiver/[[Sender]]}} to senders.
  4. Return senders.
getReceivers

Returns a sequence of {{RTCRtpReceiver}} objects representing the RTP receivers that belong to non-stopped {{RTCRtpTransceiver}} objects currently attached to this {{RTCPeerConnection}} object.

When the {{getReceivers}} method is invoked, the user agent MUST run the following steps:

  1. Let transceivers be the result of executing the {{CollectTransceivers}} algorithm.
  2. Let receivers be a new empty sequence.
  3. For each transceiver in transceivers,
    1. If transceiver.{{RTCRtpTransceiver/[[Stopped]]}} is false, add transceiver.{{RTCRtpTransceiver/[[Receiver]]}} to receivers.
  4. Return receivers.
getTransceivers

Returns a sequence of {{RTCRtpTransceiver}} objects representing the RTP transceivers that are currently attached to this {{RTCPeerConnection}} object.

The {{getTransceivers}} method MUST return the result of executing the {{CollectTransceivers}} algorithm.

We define the CollectTransceivers algorithm as follows:

  1. Let transceivers be a new sequence consisting of all {{RTCRtpTransceiver}} objects in this {{RTCPeerConnection}} object's [= set of transceivers =], in insertion order.
  2. Return transceivers.
addTrack

Adds a new track to the {{RTCPeerConnection}}, and indicates that it is contained in the specified {{MediaStream}}s.

When the {{addTrack}} method is invoked, the user agent MUST run the following steps:

  1. Let connection be the {{RTCPeerConnection}} object on which this method was invoked.

  2. Let track be the {{MediaStreamTrack}} object indicated by the method's first argument.

  3. Let kind be track.kind.

  4. Let streams be a list of {{MediaStream}} objects constructed from the method's remaining arguments, or an empty list if the method was called with a single argument.

  5. If connection.{{RTCPeerConnection/[[IsClosed]]}} is true, [= exception/throw =] an {{InvalidStateError}}.

  6. Let senders be the result of executing the {{CollectSenders}} algorithm. If an {{RTCRtpSender}} for track already exists in senders, [= exception/throw =] an {{InvalidAccessError}}.

  7. The steps below describe how to determine if an existing sender can be reused. Doing so will cause future calls to {{RTCPeerConnection/createOffer}} and {{RTCPeerConnection/createAnswer}} to mark the corresponding [= media description =] as sendrecv or sendonly and add the MSID of the sender's streams, as defined in [[!RFC9429]].

    If any {{RTCRtpSender}} object in senders matches all the following criteria, let sender be that object, or null otherwise:

    • The sender's track is null.

    • The [=RTCRtpTransceiver/transceiver kind=] of the {{RTCRtpTransceiver}}, associated with the sender, matches kind.

    • The {{RTCRtpTransceiver/[[Stopping]]}} slot of the {{RTCRtpTransceiver}} associated with the sender is false.

    • The sender has never been used to send. More precisely, the {{RTCRtpTransceiver/[[CurrentDirection]]}} slot of the {{RTCRtpTransceiver}} associated with the sender has never had a value of {{RTCRtpTransceiverDirection/"sendrecv"}} or {{RTCRtpTransceiverDirection/"sendonly"}}.

  8. If sender is not null, run the following steps to use that sender:

    1. Set sender.{{RTCRtpSender/[[SenderTrack]]}} to track.

    2. Set sender.{{RTCRtpSender/[[AssociatedMediaStreamIds]]}} to an empty set.

    3. For each stream in streams, add stream.id to {{RTCRtpSender/[[AssociatedMediaStreamIds]]}} if it's not already there.

    4. Let transceiver be the {{RTCRtpTransceiver}} associated with sender.

    5. If transceiver.{{RTCRtpTransceiver/[[Direction]]}} is {{RTCRtpTransceiverDirection/"recvonly"}}, set transceiver.{{RTCRtpTransceiver/[[Direction]]}} to {{RTCRtpTransceiverDirection/"sendrecv"}}.

    6. If transceiver.{{RTCRtpTransceiver/[[Direction]]}} is {{RTCRtpTransceiverDirection/"inactive"}}, set transceiver.{{RTCRtpTransceiver/[[Direction]]}} to {{RTCRtpTransceiverDirection/"sendonly"}}.

  9. If sender is null, run the following steps:

    1. Create an RTCRtpSender with track, kind and streams, and let sender be the result.

    2. Create an RTCRtpReceiver with kind, and let receiver be the result.

    3. Create an RTCRtpTransceiver with sender, receiver and an {{RTCRtpTransceiverDirection}} value of {{RTCRtpTransceiverDirection/"sendrecv"}}, and let transceiver be the result.

    4. Add transceiver to connection's [= set of transceivers =].

  10. A track could have contents that are inaccessible to the application. This can be due to anything that would make a track CORS cross-origin. These tracks can be supplied to the {{RTCPeerConnection/addTrack()}} method, and have an {{RTCRtpSender}} created for them, but content MUST NOT be transmitted. Silence (audio), black frames (video) or equivalently absent content is sent in place of track content.

    Note that this property can change over time.

  11. [= Update the negotiation-needed flag =] for connection.

  12. Return sender.

removeTrack

Stops sending media from sender. The {{RTCRtpSender}} will still appear in {{getSenders}}. Doing so will cause future calls to {{createOffer}} to mark the [= media description =] for the corresponding transceiver as {{RTCRtpTransceiverDirection/"recvonly"}} or {{RTCRtpTransceiverDirection/"inactive"}}, as defined in [[!RFC9429]].

When the other peer stops sending a track in this manner, the track is removed from any remote {{MediaStream}}s that were initially revealed in the {{RTCPeerConnection/track}} event, and if the {{MediaStreamTrack}} is not already muted, a mute event is fired at the track.

The same effect as {{removeTrack()}} can be achieved by setting the {{RTCRtpTransceiver}}.{{RTCRtpTransceiver/direction}} attribute of the corresponding transceiver and invoking {{RTCRtpSender}}.{{RTCRtpSender/replaceTrack}}(null) on the sender. One minor difference is that {{RTCRtpSender/replaceTrack()}} is asynchronous and {{removeTrack()}} is synchronous.

When the {{removeTrack}} method is invoked, the user agent MUST run the following steps:

  1. Let sender be the argument to {{removeTrack}}.

  2. Let connection be the {{RTCPeerConnection}} object on which the method was invoked.

  3. If connection.{{RTCPeerConnection/[[IsClosed]]}} is true, [= exception/throw =] an {{InvalidStateError}}.

  4. If sender was not created by connection, [= exception/throw =] an {{InvalidAccessError}}.

  5. Let transceiver be the {{RTCRtpTransceiver}} object corresponding to sender.

  6. If transceiver.{{RTCRtpTransceiver/[[Stopping]]}} is true, abort these steps.

  7. Let senders be the result of executing the {{CollectSenders}} algorithm.

  8. If sender is not in senders (which indicates its transceiver was stopped or removed due to [= setting a session description =] of {{RTCSessionDescriptionInit/type}} {{RTCSdpType/"rollback"}}), then abort these steps.

  9. If sender.{{RTCRtpSender/[[SenderTrack]]}} is null, abort these steps.

  10. Set sender.{{RTCRtpSender/[[SenderTrack]]}} to null.

  11. If transceiver.{{RTCRtpTransceiver/[[Direction]]}} is {{RTCRtpTransceiverDirection/"sendrecv"}}, set transceiver.{{RTCRtpTransceiver/[[Direction]]}} to {{RTCRtpTransceiverDirection/"recvonly"}}.

  12. If transceiver.{{RTCRtpTransceiver/[[Direction]]}} is {{RTCRtpTransceiverDirection/"sendonly"}}, set transceiver.{{RTCRtpTransceiver/[[Direction]]}} to {{RTCRtpTransceiverDirection/"inactive"}}.

  13. [= Update the negotiation-needed flag =] for connection.

addTransceiver

Create a new {{RTCRtpTransceiver}} and add it to the [= set of transceivers =].

Adding a transceiver will cause future calls to {{createOffer}} to add a [= media description =] for the corresponding transceiver, as defined in [[!RFC9429]].

The initial value of {{RTCRtpTransceiver/mid}} is null. [= Setting a session description =] may later change it to a non-null value.

The {{RTCRtpTransceiverInit/sendEncodings}} argument can be used to specify the number of offered simulcast encodings, and optionally their RIDs and encoding parameters.

When this method is invoked, the user agent MUST run the following steps:

  1. Let init be the second argument.

  2. Let streams be init.{{RTCRtpTransceiverInit/streams}}.

  3. Let sendEncodings be init.{{RTCRtpTransceiverInit/sendEncodings}}.

  4. Let direction be init.{{RTCRtpTransceiverInit/direction}}.

  5. If the first argument is a string, let kind be the first argument and run the following steps:

    1. If kind is neither `"audio"` nor `"video"`, [= exception/throw =] a {{TypeError}}.

    2. Let track be null.

  6. If the first argument is a {{MediaStreamTrack}}, let track be the first argument and let kind be track.{{MediaStreamTrack/kind}}.

  7. If connection.{{RTCPeerConnection/[[IsClosed]]}} is true, [= exception/throw =] an {{InvalidStateError}}.

  8. Validate sendEncodings by running the following addTransceiver sendEncodings validation steps, where each {{RTCRtpEncodingParameters}} dictionary in it is an "encoding":

    1. If any of the following conditions are met, [=exception/throw=] a {{TypeError}}:
      • Any encoding [=map/contains=] a {{RTCRtpCodingParameters/rid}} member whose value does not conform to the grammar requirements specified in Section 10 of [[RFC8851]].
      • Some but not all encodings [=map/contain=] a {{RTCRtpCodingParameters/rid}} member.
      • Any encoding [=map/contains=] a {{RTCRtpCodingParameters/rid}} member whose value is the same as that of a {{RTCRtpCodingParameters/rid}} [=map/contains | contained=] in another encoding in sendEncodings.
    2. If any encoding [=map/contains=] a read-only parameter other than {{RTCRtpCodingParameters/rid}}, [= exception/throw =] an {{InvalidAccessError}}.

    3. If any encoding [=map/contains=] a {{RTCRtpEncodingParameters/codec}} member whose value does [= codec dictionary match | not match =] any codec in {{RTCRtpSender.getCapabilities(kind)}}.codecs, [= exception/throw =] an {{OperationError}}.

    4. If the user agent does not support changing codecs without negotiation or does not support setting codecs for individual encodings, return a promise [= rejected =] with a newly [= exception/created =] {{OperationError}}.

    5. If kind is `"audio"`, remove the {{RTCRtpEncodingParameters/scaleResolutionDownBy}} and {{RTCRtpEncodingParameters/maxFramerate}} members from all encodings that [=map/contain=] any of them.

    6. If any encoding [=map/contains=] a {{RTCRtpEncodingParameters/scaleResolutionDownBy}} member whose value is less than `1.0`, [= exception/throw =] a {{RangeError}}.

    7. Verify that the value of each {{RTCRtpEncodingParameters/maxFramerate}} member in sendEncodings that is defined is greater than 0.0. If one of the {{RTCRtpEncodingParameters/maxFramerate}} values does not meet this requirement, [= exception/throw =] a {{RangeError}}.

    8. Let maxN be the maximum number of total simultaneous encodings the user agent may support for this kind, at minimum 1.This should be an optimistic number since the codec to be used is not known yet.

    9. If any encoding [=map/contains=] a {{RTCRtpEncodingParameters/scaleResolutionDownBy}} member, then for each encoding without one, add a {{RTCRtpEncodingParameters/scaleResolutionDownBy}} member with the value `1.0`.

    10. If the number of encodings stored in sendEncodings exceeds maxN, then trim sendEncodings from the tail until its length is maxN.

    11. If kind is `"video"` and none of the encodings [=map/contain=] a {{RTCRtpEncodingParameters/scaleResolutionDownBy}} member, then for each encoding, add a {{RTCRtpEncodingParameters/scaleResolutionDownBy}} member with the value 2^(length of sendEncodings - encoding index - 1). This results in smaller-to-larger resolutions where the last encoding has no scaling applied to it, e.g. 4:2:1 if the length is 3.

    12. If the number of encodings now stored in sendEncodings is 1, then remove any {{RTCRtpCodingParameters/rid}} member from the lone entry.

      Providing a single, default {{RTCRtpEncodingParameters}} in sendEncodings allows the application to subsequently set encoding parameters using {{RTCRtpSender/setParameters}}, even when simulcast isn't used.
  9. Create an RTCRtpSender with track, kind, streams and sendEncodings and let sender be the result.

    If sendEncodings is set, then subsequent calls to {{createOffer}} will be configured to send multiple RTP encodings as defined in [[!RFC9429]]. When {{RTCPeerConnection/setRemoteDescription}} is called with a corresponding remote description that is able to receive multiple RTP encodings as defined in [[!RFC9429]], the {{RTCRtpSender}} may send multiple RTP encodings and the parameters retrieved via the transceiver's {{RTCRtpTransceiver/sender}}.{{RTCRtpSender/getParameters()}} will reflect the encodings negotiated.

  10. Create an RTCRtpReceiver with kind and let receiver be the result.

  11. Create an RTCRtpTransceiver with sender, receiver and direction, and let transceiver be the result.

  12. Add transceiver to connection's [= set of transceivers =].

  13. [= Update the negotiation-needed flag =] for connection.

  14. Return transceiver.

dictionary RTCRtpTransceiverInit {
  RTCRtpTransceiverDirection direction = "sendrecv";
  sequence<MediaStream> streams = [];
  sequence<RTCRtpEncodingParameters> sendEncodings = [];
};

Dictionary RTCRtpTransceiverInit Members

direction of type {{RTCRtpTransceiverDirection}}, defaulting to {{RTCRtpTransceiverDirection/"sendrecv"}}
The direction of the {{RTCRtpTransceiver}}.
streams of type sequence<{{MediaStream}}>

When the remote {{RTCPeerConnection}}'s track event fires corresponding to the {{RTCRtpReceiver}} being added, these are the streams that will be put in the event.

sendEncodings of type sequence<{{RTCRtpEncodingParameters}}>

A sequence containing parameters for sending RTP encodings of media.

enum RTCRtpTransceiverDirection {
  "sendrecv",
  "sendonly",
  "recvonly",
  "inactive",
  "stopped"
};
RTCRtpTransceiverDirection Enumeration description
Enum valueDescription
sendrecv The {{RTCRtpTransceiver}}'s {{RTCRtpSender}} sender will offer to send RTP, and will send RTP if the remote peer accepts and sender.{{RTCRtpSender/getParameters()}}.{{RTCRtpSendParameters/encodings}}[i].{{RTCRtpEncodingParameters/active}} is true for any value of i. The {{RTCRtpTransceiver}}'s {{RTCRtpReceiver}} will offer to receive RTP, and will receive RTP if the remote peer accepts.
sendonly The {{RTCRtpTransceiver}}'s {{RTCRtpSender}} sender will offer to send RTP, and will send RTP if the remote peer accepts and sender.{{RTCRtpSender/getParameters()}}.{{RTCRtpSendParameters/encodings}}[i].{{RTCRtpEncodingParameters/active}} is true for any value of i. The {{RTCRtpTransceiver}}'s {{RTCRtpReceiver}} will not offer to receive RTP, and will not receive RTP.
recvonly The {{RTCRtpTransceiver}}'s {{RTCRtpSender}} will not offer to send RTP, and will not send RTP. The {{RTCRtpTransceiver}}'s {{RTCRtpReceiver}} will offer to receive RTP, and will receive RTP if the remote peer accepts.
inactive The {{RTCRtpTransceiver}}'s {{RTCRtpSender}} will not offer to send RTP, and will not send RTP. The {{RTCRtpTransceiver}}'s {{RTCRtpReceiver}} will not offer to receive RTP, and will not receive RTP.
stopped The {{RTCRtpTransceiver}} will neither send nor receive RTP. It will generate a zero port in the offer. In answers, its {{RTCRtpSender}} will not offer to send RTP, and its {{RTCRtpReceiver}} will not offer to receive RTP. This is a terminal state.

Processing Remote MediaStreamTracks

An application can reject incoming media descriptions by setting the transceiver's direction to either {{RTCRtpTransceiverDirection/"inactive"}} to turn off both directions temporarily, or to {{RTCRtpTransceiverDirection/"sendonly"}} to reject only the incoming side. To permanently reject an m-line in a manner that makes it available for reuse, the application would need to call {{RTCRtpTransceiver}}.{{RTCRtpTransceiver/stop()}} and subsequently initiate negotiation from its end.

To process remote tracks given an {{RTCRtpTransceiver}} transceiver, direction, msids, addList, removeList, and trackEventInits, run the following steps:

  1. Set the associated remote streams with transceiver.{{RTCRtpTransceiver/[[Receiver]]}}, msids, addList, and removeList.

  2. If direction is {{RTCRtpTransceiverDirection/"sendrecv"}} or {{RTCRtpTransceiverDirection/"recvonly"}} and transceiver.{{RTCRtpTransceiver/[[FiredDirection]]}} is neither {{RTCRtpTransceiverDirection/"sendrecv"}} nor {{RTCRtpTransceiverDirection/"recvonly"}}, or the previous step increased the length of addList, process the addition of a remote track with transceiver and trackEventInits.

  3. If direction is {{RTCRtpTransceiverDirection/"sendonly"}} or {{RTCRtpTransceiverDirection/"inactive"}}, set transceiver.{{RTCRtpTransceiver/[[Receptive]]}} to false.

  4. If direction is {{RTCRtpTransceiverDirection/"sendonly"}} or {{RTCRtpTransceiverDirection/"inactive"}}, and transceiver.{{RTCRtpTransceiver/[[FiredDirection]]}} is either {{RTCRtpTransceiverDirection/"sendrecv"}} or {{RTCRtpTransceiverDirection/"recvonly"}}, process the removal of a remote track for the media description, with transceiver and muteTracks.

  5. Set transceiver.{{RTCRtpTransceiver/[[FiredDirection]]}} to direction.

To process the addition of a remote track given an {{RTCRtpTransceiver}} transceiver and trackEventInits, run the following steps:

  1. Let receiver be transceiver.{{RTCRtpTransceiver/[[Receiver]]}}.

  2. Let track be receiver.{{RTCRtpReceiver/[[ReceiverTrack]]}}.

  3. Let streams be receiver.{{RTCRtpReceiver/[[AssociatedRemoteMediaStreams]]}}.

  4. Create a new {{RTCTrackEventInit}} dictionary with receiver, track, streams and transceiver as members and add it to trackEventInits.

To process the removal of a remote track with an {{RTCRtpTransceiver}} transceiver and muteTracks, run the following steps:

  1. Let receiver be transceiver.{{RTCRtpTransceiver/[[Receiver]]}}.

  2. Let track be receiver.{{RTCRtpReceiver/[[ReceiverTrack]]}}.

  3. If track.muted is false, add track to muteTracks.

To set the associated remote streams given {{RTCRtpReceiver}} receiver, msids, addList, and removeList, run the following steps:

  1. Let connection be the {{RTCPeerConnection}} object associated with receiver.

  2. For each MSID in msids, unless a {{MediaStream}} object has previously been created with that id for this connection, create a {{MediaStream}} object with that id.

  3. Let streams be a list of the {{MediaStream}} objects created for this connection with the ids corresponding to msids.

  4. Let track be receiver.{{RTCRtpReceiver/[[ReceiverTrack]]}}.

  5. For each stream in receiver.{{RTCRtpReceiver/[[AssociatedRemoteMediaStreams]]}} that is not present in streams, add stream and track as a pair to removeList.

  6. For each stream in streams that is not present in receiver.{{RTCRtpReceiver/[[AssociatedRemoteMediaStreams]]}}, add stream and track as a pair to addList.

  7. Set receiver.{{RTCRtpReceiver/[[AssociatedRemoteMediaStreams]]}} to streams.

RTCRtpSender Interface

The {{RTCRtpSender}} interface allows an application to control how a given {{MediaStreamTrack}} is encoded and transmitted to a remote peer. When {{RTCRtpSender/setParameters}} is called on an {{RTCRtpSender}} object, the encoding is changed appropriately.

To create an RTCRtpSender with a {{MediaStreamTrack}}, track, a string, kind, a list of {{MediaStream}} objects, streams, and optionally a list of {{RTCRtpEncodingParameters}} objects, sendEncodings, run the following steps:

  1. Let sender be a new {{RTCRtpSender}} object.

  2. Let sender have a [[\SenderTrack]] internal slot initialized to track.

  3. Let sender have a [[\SenderTransport]] internal slot initialized to null.

  4. Let sender have a [[\LastStableStateSenderTransport]] internal slot initialized to null.

  5. Let sender have a [[\Dtmf]] internal slot initialized to null.

  6. If kind is "audio" then create an RTCDTMFSender dtmf and set the {{RTCRtpSender/[[Dtmf]]}} internal slot to dtmf.

  7. Let sender have an [[\AssociatedMediaStreamIds]] internal slot, representing a list of Ids of {{MediaStream}} objects that this sender is to be associated with. The {{RTCRtpSender/[[AssociatedMediaStreamIds]]}} slot is used when sender is represented in SDP as described in [[!RFC9429]].

  8. Set sender.{{RTCRtpSender/[[AssociatedMediaStreamIds]]}} to an empty set.

  9. For each stream in streams, add stream.id to {{RTCRtpSender/[[AssociatedMediaStreamIds]]}} if it's not already there.

  10. Let sender have a [[\SendEncodings]] internal slot, representing a list of {{RTCRtpEncodingParameters}} dictionaries.

  11. If sendEncodings is given as input to this algorithm, and is non-empty, set the {{RTCRtpSender/[[SendEncodings]]}} slot to sendEncodings. Otherwise, set it to a list containing a single new {{RTCRtpEncodingParameters}} dictionary, and if kind is `"video"`, add a {{RTCRtpEncodingParameters/scaleResolutionDownBy}} member with the value `1.0` to that dictionary.

    {{RTCRtpEncodingParameters}} dictionaries contain {{RTCRtpEncodingParameters/active}} members whose values are true by default.

  12. Let sender have a [[\LastStableRidlessSendEncodings]] internal slot initialized to null.

  13. Let sender have a [[\SendCodecs]] internal slot, representing a list of {{RTCRtpCodecParameters}} dictionaries, and initialized to an empty list.

  14. Let sender have a [[\LastReturnedParameters]] internal slot, which will be used to match {{RTCRtpSender/getParameters}} and {{RTCRtpSender/setParameters}} transactions.

  15. Return sender.

[Exposed=Window]
interface RTCRtpSender {
  readonly attribute MediaStreamTrack? track;
  readonly attribute RTCDtlsTransport? transport;
  static RTCRtpCapabilities? getCapabilities(DOMString kind);
  Promise<undefined> setParameters(RTCRtpSendParameters parameters,
      optional RTCSetParameterOptions setParameterOptions = {});
  RTCRtpSendParameters getParameters();
  Promise<undefined> replaceTrack(MediaStreamTrack? withTrack);
  undefined setStreams(MediaStream... streams);
  Promise<RTCStatsReport> getStats();
};

Attributes

track of type {{MediaStreamTrack}}, readonly, nullable

The {{track}} attribute is the track that is associated with this {{RTCRtpSender}} object. If {{track}} is ended, or if the track's output is disabled, i.e. the track is disabled and/or muted, the {{RTCRtpSender}} MUST send black frames (video) and MUST NOT send (audio). In the case of video, the {{RTCRtpSender}} SHOULD send one black frame per second. If {{track}} is null then the {{RTCRtpSender}} does not send. On getting, the attribute MUST return the value of the {{RTCRtpSender/[[SenderTrack]]}} slot.

transport of type {{RTCDtlsTransport}}, readonly, nullable

The {{transport}} attribute is the transport over which media from {{track}} is sent in the form of RTP packets. Prior to construction of the {{RTCDtlsTransport}} object, the {{transport}} attribute will be null. When bundling is used, multiple {{RTCRtpSender}} objects will share one {{transport}} and will all send RTP and RTCP over the same transport.

On getting, the attribute MUST return the value of the {{RTCRtpSender/[[SenderTransport]]}} slot.

Methods

getCapabilities, static

The static {{RTCRtpSender}}.{{getCapabilities()}} method provides a way to discover the types of capabilities the user agent supports for sending media of the given kind, without reserving any resources, ports, or other state.

When the {{getCapabilities}} method is called, the user agent MUST run the following steps:

  1. Let kind be the method's first argument.

  2. If kind is neither `"video"` nor `"audio"` return `null`.

  3. Return a new {{RTCRtpCapabilities}} dictionary, with its {{RTCRtpCapabilities/codecs}} member initialized to the [=RTCRtpSender/list of implemented send codecs=] for kind, and its {{RTCRtpCapabilities/headerExtensions}} member initialized to the [=list of implemented header extensions for sending=] with kind.

The list of implemented send codecs, given kind, is an [=implementation-defined=] list of {{RTCRtpCodec}} dictionaries representing the most optimistic view of the codecs the user agent supports for sending media of the given kind (video or audio).

The list of implemented header extensions for sending, given kind, is an [=implementation-defined=] list of {{RTCRtpHeaderExtensionCapability}} dictionaries representing the most optimistic view of the header extensions the user agent supports for sending media of the given kind (video or audio).

These capabilities provide generally persistent cross-origin information on the device and thus increases the fingerprinting surface of the application. In privacy-sensitive contexts, user agents MAY consider mitigations such as reporting only a common subset of the capabilities.

The codec capabilities returned affect the {{RTCRtpTransceiver/setCodecPreferences()}} algorithm and what inputs it throws {{InvalidModificationError}} on, and should also be consistent with information revealed by {{RTCPeerConnection/createOffer()}} and {{RTCPeerConnection/createAnswer()}} about codecs negotiated for sending, to ensure any privacy mitigations are effective.

setParameters

The {{setParameters}} method updates how {{track}} is encoded and transmitted to a remote peer.

When the {{setParameters}} method is called, the user agent MUST run the following steps:

  1. Let parameters be the method's first argument.
  2. Let sender be the {{RTCRtpSender}} object on which {{setParameters}} is invoked.
  3. Let transceiver be the {{RTCRtpTransceiver}} object associated with sender (i.e. sender is transceiver.{{RTCRtpTransceiver/[[Sender]]}}).
  4. If transceiver.{{RTCRtpTransceiver/[[Stopping]]}} is true, return a promise [= rejected =] with a newly [= exception/created =] {{InvalidStateError}}.
  5. If sender.{{RTCRtpSender/[[LastReturnedParameters]]}} is null, return a promise [= rejected =] with a newly [= exception/created =] {{InvalidStateError}}.
  6. Validate parameters by running the following setParameters validation steps:
    1. Let encodings be parameters.{{RTCRtpSendParameters/encodings}}.
    2. Let codecs be parameters.{{RTCRtpParameters/codecs}}.
    3. Let choosableCodecs be codecs.

    4. If choosableCodecs is an empty list, set choosableCodecs to the [=RTCRtpSender/list of implemented send codecs=] for transceiver's kind.

    5. Let N be the number of {{RTCRtpEncodingParameters}} stored in sender.{{RTCRtpSender/[[SendEncodings]]}}.
    6. If any of the following conditions are met, return a promise [= rejected =] with a newly [= exception/created =] {{InvalidModificationError}}:
      • encodings.length is different from N.
      • encodings has been re-ordered.
      • Any parameter in parameters is marked as a Read-only parameter (such as RID) and has a value that is different from the corresponding parameter value in sender.{{RTCRtpSender/[[LastReturnedParameters]]}}. Note that this also applies to transactionId.
      • Any encoding in encodings [=map/exists|contains=] a codec not found in choosableCodecs, using the [= codec dictionary match =] algorithm with ignoreAsymmetricalParameters set to true.
    7. If [=RTCRtpTransceiver/transceiver kind=] is `"audio"`, remove the {{RTCRtpEncodingParameters/scaleResolutionDownBy}} and {{RTCRtpEncodingParameters/maxFramerate}} members from all encodings that [=map/contain=] any of them.

    8. If [=RTCRtpTransceiver/transceiver kind=] is `"video"`, then for each encoding in encodings that doesn't [=map/contain=] a {{RTCRtpEncodingParameters/scaleResolutionDownBy}} member, add a {{RTCRtpEncodingParameters/scaleResolutionDownBy}} member with the value `1.0`.

    9. If [=RTCRtpTransceiver/transceiver kind=] is `"video"`, and any encoding in encodings [=map/contains=] a {{RTCRtpEncodingParameters/scaleResolutionDownBy}} member whose value is less than `1.0`, return a promise [= rejected =] with a newly [= exception/created =] {{RangeError}}.

    10. Verify that each encoding in encodings has a {{RTCRtpEncodingParameters/maxFramerate}} member whose value is greater than or equal to 0.0. If one of the {{RTCRtpEncodingParameters/maxFramerate}} values does not meet this requirement, return a promise [= rejected =] with a newly [= exception/created =] {{RangeError}}.

    11. If the user agent does not support setting the codec for any encoding or mixing different codec values on the different encodings, return a promise [= rejected =] with a newly [= exception/created =] {{OperationError}}.

  7. Let p be a new promise.
  8. [=In parallel=], configure the media stack to use parameters to transmit sender.{{RTCRtpSender/[[SenderTrack]]}}.
    1. If the media stack is successfully configured with parameters, queue a task to run the following steps:
      1. Set sender.{{RTCRtpSender/[[LastReturnedParameters]]}} to null.
      2. Set sender.{{RTCRtpSender/[[SendEncodings]]}} to parameters.{{RTCRtpSendParameters/encodings}}.
      3. [= Resolve =] p with undefined.
    2. If any error occurred while configuring the media stack, queue a task to run the following steps:
      1. If an error occurred due to hardware resources not being available, [= reject =] p with a newly created {{RTCError}} whose {{RTCError/errorDetail}} is set to {{RTCErrorDetailType/"hardware-encoder-not-available"}} and abort these steps.
      2. If an error occurred due to a hardware encoder not supporting parameters, [= reject =] p with a newly created {{RTCError}} whose {{RTCError/errorDetail}} is set to {{RTCErrorDetailType/"hardware-encoder-error"}} and abort these steps.
      3. For all other errors, [= reject =] p with a newly [= exception/created =] {{OperationError}}.
  9. Return p.

{{setParameters}} does not cause SDP renegotiation and can only be used to change what the media stack is sending or receiving within the envelope negotiated by Offer/Answer. The attributes in the {{RTCRtpSendParameters}} dictionary are designed to not enable this, so attributes like {{RTCRtcpParameters/cname}} that cannot be changed are read-only. Other things, like bitrate, are controlled using limits such as {{RTCRtpEncodingParameters/maxBitrate}}, where the user agent needs to ensure it does not exceed the maximum bitrate specified by {{RTCRtpEncodingParameters/maxBitrate}}, while at the same time making sure it satisfies constraints on bitrate specified in other places such as the SDP.

getParameters

The {{getParameters()}} method returns the {{RTCRtpSender}} object's current parameters for how {{track}} is encoded and transmitted to a remote {{RTCRtpReceiver}}.

When {{getParameters}} is called, the user agent MUST run the following steps:

  1. Let sender be the {{RTCRtpSender}} object on which the getter was invoked.

  2. If sender.{{RTCRtpSender/[[LastReturnedParameters]]}} is not null, return sender.{{RTCRtpSender/[[LastReturnedParameters]]}}, and abort these steps.

  3. Let result be a new {{RTCRtpSendParameters}} dictionary constructed as follows:

    • {{RTCRtpSendParameters/transactionId}} is set to a new unique identifier.
    • {{RTCRtpSendParameters/encodings}} is set to the value of the {{RTCRtpSender/[[SendEncodings]]}} internal slot.
    • The {{RTCRtpParameters/headerExtensions}} sequence is populated based on the header extensions that have been negotiated for sending.
    • {{RTCRtpParameters/codecs}} is set to the value of the {{RTCRtpSender/[[SendCodecs]]}} internal slot.
    • {{RTCRtpParameters/rtcp}}.{{RTCRtcpParameters/cname}} is set to the CNAME of the associated {{RTCPeerConnection}}. {{RTCRtpParameters/rtcp}}.{{RTCRtcpParameters/reducedSize}} is set to true if reduced-size RTCP has been negotiated for sending, and false otherwise.
  4. Set sender.{{RTCRtpSender/[[LastReturnedParameters]]}} to result.

  5. Queue a task that sets sender.{{RTCRtpSender/[[LastReturnedParameters]]}} to null.

  6. Return result.

{{getParameters}} may be used with {{setParameters}} to change the parameters in the following way:

async function updateParameters() {
  try {
    const params = sender.getParameters();
    // ... make changes to parameters
    params.encodings[0].active = false;
    await sender.setParameters(params);
  } catch (err) {
    console.error(err);
  }
}
              

After a completed call to {{setParameters}}, subsequent calls to {{getParameters}} will return the modified set of parameters.

replaceTrack

Attempts to replace the {{RTCRtpSender}}'s current {{track}} with another track provided (or with a null track), without renegotiation.

When the {{replaceTrack}} method is invoked, the user agent MUST run the following steps:

  1. Let sender be the {{RTCRtpSender}} object on which {{replaceTrack}} is invoked.

  2. Let transceiver be the {{RTCRtpTransceiver}} object associated with sender.

  3. Let connection be the {{RTCPeerConnection}} object associated with sender.

  4. Let withTrack be the argument to this method.

  5. If withTrack is non-null and withTrack.kind differs from the [=RTCRtpTransceiver/transceiver kind=] of transceiver, return a promise [= rejected =] with a newly [= exception/created =] {{TypeError}}.

  6. Return the result of [= chaining =] the following steps to connection's [= operations chain =]:

    1. If transceiver.{{RTCRtpTransceiver/[[Stopping]]}} is true, return a promise [= rejected =] with a newly [= exception/created =] {{InvalidStateError}}.

    2. Let p be a new promise.

    3. Let sending be true if transceiver.{{RTCRtpTransceiver/[[CurrentDirection]]}} is {{RTCRtpTransceiverDirection/"sendrecv"}} or {{RTCRtpTransceiverDirection/"sendonly"}}, and false otherwise.

    4. Run the following steps [=in parallel=]:

      1. If sending is true, and withTrack is null, have the sender stop sending.

      2. If sending is true, and withTrack is not null, determine if withTrack can be sent immediately by the sender without violating the sender's already-negotiated envelope, and if it cannot, then:

        1. [=Queue a global task=] on the [=networking task source=] given the current realm's [=global object=] as global to [=reject=] p with a newly [=exception/created=] {{InvalidModificationError}}.
        2. Abort these steps.
      3. If sending is true, and withTrack is not null, have the sender switch seamlessly to transmitting withTrack instead of the sender's existing track.

      4. Queue a task that runs the following steps:

        1. If connection.{{RTCPeerConnection/[[IsClosed]]}} is true, abort these steps.

        2. Set sender.{{RTCRtpSender/[[SenderTrack]]}} to withTrack.

        3. [=Queue a global task=] on the [=networking task source=] given the current realm's [=global object=] as global to [=resolve=] p with undefined.

    5. Return p.

Changing dimensions and/or frame rates might not require negotiation. Cases that may require negotiation include:

  1. Changing a resolution to a value outside of the negotiated imageattr bounds, as described in [[RFC6236]].
  2. Changing a frame rate to a value that causes the block rate for the codec to be exceeded.
  3. A video track differing in raw vs. pre-encoded format.
  4. An audio track having a different number of channels.
  5. Sources that also encode (typically hardware encoders) might be unable to produce the negotiated codec; similarly, software sources might not implement the codec that was negotiated for an encoding source.
setStreams

Sets the {{MediaStream}}s to be associated with this sender's track.

When the {{setStreams}} method is invoked, the user agent MUST run the following steps:

  1. Let sender be the {{RTCRtpSender}} object on which this method was invoked.

  2. Let connection be the {{RTCPeerConnection}} object on which this method was invoked.

  3. If connection.{{RTCPeerConnection/[[IsClosed]]}} is true, [= exception/throw =] an {{InvalidStateError}}.

  4. Let streams be a list of {{MediaStream}} objects constructed from the method's arguments, or an empty list if the method was called without arguments.

  5. Set sender.{{RTCRtpSender/[[AssociatedMediaStreamIds]]}} to an empty set.

  6. For each stream in streams, add stream.id to {{RTCRtpSender/[[AssociatedMediaStreamIds]]}} if it's not already there.

  7. [= Update the negotiation-needed flag =] for connection.

getStats

Gathers stats for this sender only and reports the result asynchronously.

When the {{getStats()}} method is invoked, the user agent MUST run the following steps:

  1. Let selector be the {{RTCRtpSender}} object on which the method was invoked.

  2. Let p be a new promise, and run the following steps [=in parallel=]:

    1. Gather the stats indicated by selector according to the [= stats selection algorithm =].

    2. [=Queue a global task=] on the [=networking task source=] given the current realm's [=global object=] as global to [=resolve=] p with the resulting {{RTCStatsReport}} object, containing the gathered stats.

  3. Return p.

RTCRtpParameters Dictionary

dictionary RTCRtpParameters {
  required sequence<RTCRtpHeaderExtensionParameters> headerExtensions;
  required RTCRtcpParameters rtcp;
  required sequence<RTCRtpCodecParameters> codecs;
};

Dictionary {{RTCRtpParameters}} Members

headerExtensions of type sequence<{{RTCRtpHeaderExtensionParameters}}>, required

A sequence containing parameters for RTP header extensions. Read-only parameter.

rtcp of type {{RTCRtcpParameters}}, required

Parameters used for RTCP. Read-only parameter.

codecs of type sequence<{{RTCRtpCodecParameters}}>, required

A sequence containing the media codecs that an {{RTCRtpSender}} will choose from, as well as entries for RTX, RED and FEC mechanisms. Corresponding to each media codec where retransmission via RTX is enabled, there will be an entry in {{codecs}} with a {{RTCRtpCodec/mimeType}} attribute indicating retransmission via audio/rtx or video/rtx, and an {{RTCRtpCodec/sdpFmtpLine}} attribute (providing the "apt" and "rtx-time" parameters). Read-only parameter.

RTCRtpSendParameters Dictionary

              dictionary RTCRtpSendParameters : RTCRtpParameters {
                required DOMString transactionId;
                required sequence<RTCRtpEncodingParameters> encodings;
              };
            

Dictionary {{RTCRtpSendParameters}} Members

transactionId of type DOMString, required

A unique identifier for the last set of parameters applied. Ensures that {{RTCRtpSender/setParameters}} can only be called based on a previous {{RTCRtpSender/getParameters}}, and that there are no intervening changes. [= Read-only parameter =].

encodings of type sequence<{{RTCRtpEncodingParameters}}>, required

A sequence containing parameters for RTP encodings of media.

RTCRtpReceiveParameters Dictionary

dictionary RTCRtpReceiveParameters : RTCRtpParameters {
};

RTCRtpCodingParameters Dictionary

dictionary RTCRtpCodingParameters {
  DOMString rid;
};

Dictionary {{RTCRtpCodingParameters}} Members

rid of type DOMString

If set, this RTP encoding will be sent with the RID header extension as defined by [[!RFC9429]]. The RID is not modifiable via {{RTCRtpSender/setParameters}}. It can only be set or modified in {{RTCPeerConnection/addTransceiver}} on the sending side. Read-only parameter.

RTCRtpEncodingParameters Dictionary

dictionary RTCRtpEncodingParameters : RTCRtpCodingParameters {
  boolean active = true;
  RTCRtpCodec codec;
  unsigned long maxBitrate;
  double maxFramerate;
  double scaleResolutionDownBy;
};

Dictionary {{RTCRtpEncodingParameters}} Members

active of type boolean, defaulting to true

Indicates that this encoding is actively being sent. Setting it to false causes this encoding to no longer be sent. Setting it to true causes this encoding to be sent. Since setting the value to false does not cause the SSRC to be removed, an RTCP BYE is not sent.

codec of type RTCRtpCodec

Optional value selecting which codec is used for this encoding's RTP stream. If [=map/exists|absent=], the user agent can choose to use any codec negotiated for sending.

When {{codec}} is set and {{RTCRtpSender/[[SendCodecs]]}} have been negotiated, the user agent SHOULD use the first {{RTCRtpSender/[[SendCodecs]]}} matching {{codec}} for sending, according to the [= codec dictionary match =] algorithm with ignoreAsymmetricalParameters set to true.

maxBitrate of type unsigned long

When [=map/exists|present=], indicates the maximum bitrate that can be used to send this encoding. The user agent is free to allocate bandwidth between the encodings, as long as the {{maxBitrate}} value is not exceeded. The encoding may also be further constrained by other limits (such as per-transport or per-session bandwidth limits) below the maximum specified here. {{maxBitrate}} is computed the same way as the Transport Independent Application Specific Maximum (TIAS) bandwidth defined in [[RFC3890]] Section 6.2.2, which is the maximum bandwidth needed without counting IP or other transport layers like TCP or UDP. The unit of {{maxBitrate}} is bits per second.

How the bitrate is achieved is media and encoding dependent. For video, a frame will always be sent as fast as possible, but frames may be dropped until bitrate is low enough. Thus, even a bitrate of zero will allow sending one frame. For audio, it might be necessary to stop playing if the bitrate does not allow the chosen encoding enough bandwidth to be sent.

maxFramerate of type double

This member can only be [=map/exists|present=] if the sender's kind is "video". When [=map/exists|present=], indicates the maximum frame rate that can be used to send this encoding, in frames per second. The user agent is free to allocate bandwidth between the encodings, as long as the {{maxFramerate}} value is not exceeded.

If changed with {{RTCRtpSender/setParameters()}}, the new frame rate takes effect after the current picture is completed; setting the max frame rate to zero thus has the effect of freezing the video on the next frame.

scaleResolutionDownBy of type double

This member is only [=map/exists|present=] if the sender's kind is "video". The video's resolution will be scaled down in each dimension by the given value before sending. For example, if the value is 2.0, the video will be scaled down by a factor of 2 in each dimension, resulting in sending a video of one quarter the size. If the value is 1.0, the video will not be affected. The value must be greater than or equal to 1.0. By default, scaling is applied in reverse order by a factor of two, to produce an order of smaller to higher resolutions, e.g. 4:2:1. If there is only one layer, the sender will by default not apply any scaling, (i.e. {{RTCRtpEncodingParameters/scaleResolutionDownBy}} will be 1.0).

RTCRtcpParameters Dictionary

dictionary RTCRtcpParameters {
  DOMString cname;
  boolean reducedSize;
};

Dictionary {{RTCRtcpParameters}} Members

cname of type DOMString

The Canonical Name (CNAME) used by RTCP (e.g. in SDES messages). Read-only parameter.

reducedSize of type boolean

Whether reduced size RTCP [[RFC5506]] is configured (if true) or compound RTCP as specified in [[RFC3550]] (if false). Read-only parameter.

RTCRtpHeaderExtensionParameters Dictionary

dictionary RTCRtpHeaderExtensionParameters {
  required DOMString uri;
  required unsigned short id;
  boolean encrypted = false;
};

Dictionary {{RTCRtpHeaderExtensionParameters}} Members

uri of type DOMString, required

The URI of the RTP header extension, as defined in [[RFC5285]]. Read-only parameter.

id of type unsigned short, required

The value put in the RTP packet to identify the header extension. Read-only parameter.

encrypted of type boolean

Whether the header extension is encrypted or not. Read-only parameter.

The {{RTCRtpHeaderExtensionParameters}} dictionary enables an application to determine whether a header extension is configured for use within an {{RTCRtpSender}} or {{RTCRtpReceiver}}. For an {{RTCRtpTransceiver}} transceiver, an application can determine the "direction" parameter (defined in Section 5 of [[RFC5285]]) of a header extension as follows without having to parse SDP:

  1. sendonly: The header extension is only included in transceiver.{{RTCRtpTransceiver/sender}}.{{RTCRtpSender/getParameters()}}.{{RTCRtpParameters/headerExtensions}}.
  2. recvonly: The header extension is only included in transceiver.{{RTCRtpTransceiver/receiver}}.{{RTCRtpReceiver/getParameters()}}.{{RTCRtpParameters/headerExtensions}}.
  3. sendrecv: The header extension is included in both transceiver.{{RTCRtpTransceiver/sender}}.{{RTCRtpSender/getParameters()}}.{{RTCRtpParameters/headerExtensions}} and transceiver.{{RTCRtpTransceiver/receiver}}.{{RTCRtpReceiver/getParameters()}}.{{RTCRtpParameters/headerExtensions}}.
  4. inactive: The header extension is included in neither transceiver.{{RTCRtpTransceiver/sender}}.{{RTCRtpSender/getParameters()}}.{{RTCRtpParameters/headerExtensions}} nor transceiver.{{RTCRtpTransceiver/receiver}}.{{RTCRtpReceiver/getParameters()}}.{{RTCRtpParameters/headerExtensions}}.

RTCRtpCodec Dictionary

dictionary RTCRtpCodec {
  required DOMString mimeType;
  required unsigned long clockRate;
  unsigned short channels;
  DOMString sdpFmtpLine;
};

Dictionary {{RTCRtpCodec}} Members

The {{RTCRtpCodec}} dictionary provides information about codec objects.

mimeType of type DOMString, required

The codec MIME media type/subtype. Valid media types and subtypes are listed in [[IANA-RTP-2]].

clockRate of type unsigned long, required

The codec clock rate expressed in Hertz.

channels of type unsigned short

If [=map/exists|present=], indicates the maximum number of channels (mono=1, stereo=2).

sdpFmtpLine of type DOMString

The "format specific parameters" field from the a=fmtp line in the SDP corresponding to the codec, if one exists, as defined by [[!RFC9429]].

RTCRtpCodecParameters Dictionary

dictionary RTCRtpCodecParameters : RTCRtpCodec {
  required octet payloadType;
};

Dictionary {{RTCRtpCodecParameters}} Members

The {{RTCRtpCodecParameters}} dictionary provides information about the negotiated codecs. The fields inherited from {{RTCRtpCodec}} MUST all be Read-only parameters.

For an {{RTCRtpSender}}, the {{RTCRtpCodec/sdpFmtpLine}} parameters come from the {{RTCPeerConnection/[[CurrentRemoteDescription]]}}, and for an {{RTCRtpReceiver}}, they come from the local description (which is {{RTCPeerConnection/[[PendingLocalDescription]]}} if not `null`, and {{RTCPeerConnection/[[CurrentLocalDescription]]}} otherwise).

payloadType of type octet, required

The RTP payload type used to identify this codec. Read-only parameter.

RTCRtpCapabilities Dictionary

dictionary RTCRtpCapabilities {
  required sequence<RTCRtpCodec> codecs;
  required sequence<RTCRtpHeaderExtensionCapability> headerExtensions;
};

Dictionary {{RTCRtpCapabilities}} Members

codecs of type sequence<{{RTCRtpCodec}}>, required

Supported media codecs as well as entries for RTX, RED and FEC mechanisms. Only combinations that would utilize distinct payload types in a generated SDP offer are to be provided. For example:

  1. Two H.264/AVC codecs, one for each of two supported packetization-mode values.
  2. Two CN codecs with different clock rates.

There MUST only be a single entry in {{codecs}} for retransmission via RTX, with {{RTCRtpCodec/sdpFmtpLine}} not [=map/exists|present=].

headerExtensions of type sequence<{{RTCRtpHeaderExtensionCapability}}>, required

Supported RTP header extensions.

RTCRtpHeaderExtensionCapability Dictionary

dictionary RTCRtpHeaderExtensionCapability {
  required DOMString uri;
};

Dictionary {{RTCRtpHeaderExtensionCapability}} Members

uri of type DOMString, required

The URI of the RTP header extension, as defined in [[RFC5285]].

RTCSetParameterOptions Dictionary

dictionary RTCSetParameterOptions {
};

Dictionary {{RTCSetParameterOptions}} Members

RTCSetParameterOptions is defined as an empty dictionary to allow for extensibility.

RTCRtpReceiver Interface

The {{RTCRtpReceiver}} interface allows an application to inspect the receipt of a {{MediaStreamTrack}}.

To create an RTCRtpReceiver with a string, kind, run the following steps:

  1. Let receiver be a new {{RTCRtpReceiver}} object.

  2. Let track be a new {{MediaStreamTrack}} object [[!GETUSERMEDIA]]. The source of track is a remote source provided by receiver. Note that the track.id is generated by the user agent and does not map to any track IDs on the remote side.

  3. Initialize track.kind to kind.

  4. Initialize track.label to the result of concatenating the string "remote " with kind.

  5. Initialize track.readyState to live.

  6. Initialize track.muted to true. See the MediaStreamTrack section about how the muted attribute reflects if a {{MediaStreamTrack}} is receiving media data or not.

  7. Let receiver have a [[\ReceiverTrack]] internal slot initialized to track.

  8. Let receiver have a [[\ReceiverTransport]] internal slot initialized to null.

  9. Let receiver have a [[\LastStableStateReceiverTransport]] internal slot initialized to null.

  10. Let receiver have an [[\AssociatedRemoteMediaStreams]] internal slot, representing a list of {{MediaStream}} objects that the {{MediaStreamTrack}} object of this receiver is associated with, and initialized to an empty list.

  11. Let receiver have a [[\LastStableStateAssociatedRemoteMediaStreams]] internal slot and initialize it to an empty list.

  12. Let receiver have a [[\ReceiveCodecs]] internal slot, representing a list of {{RTCRtpCodecParameters}} dictionaries, and initialized to an empty list.

  13. Let receiver have a [[\LastStableStateReceiveCodecs]] internal slot and initialize it to an empty list.

  14. Let receiver have a [[\JitterBufferTarget]] internal slot initialized to null.

  15. Return receiver.

[Exposed=Window]
interface RTCRtpReceiver {
  readonly attribute MediaStreamTrack track;
  readonly attribute RTCDtlsTransport? transport;
  static RTCRtpCapabilities? getCapabilities(DOMString kind);
  RTCRtpReceiveParameters getParameters();
  sequence<RTCRtpContributingSource> getContributingSources();
  sequence<RTCRtpSynchronizationSource> getSynchronizationSources();
  Promise<RTCStatsReport> getStats();
  attribute DOMHighResTimeStamp? jitterBufferTarget;
};

Attributes

track of type {{MediaStreamTrack}}, readonly

The {{track}} attribute is the track that is associated with this {{RTCRtpReceiver}} object receiver.

Note that {{track}}.stop() is final, although clones are not affected. Since receiver.{{track}}.stop() does not implicitly stop receiver, Receiver Reports continue to be sent. On getting, the attribute MUST return the value of the {{RTCRtpReceiver/[[ReceiverTrack]]}} slot.

transport of type {{RTCDtlsTransport}}, readonly, nullable

The {{transport}} attribute is the transport over which media for the receiver's {{RTCRtpReceiver/track}} is received in the form of RTP packets. Prior to construction of the {{RTCDtlsTransport}} object, the {{transport}} attribute will be null. When bundling is used, multiple {{RTCRtpReceiver}} objects will share one {{transport}} and will all receive RTP and RTCP over the same transport.

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

jitterBufferTarget of type {{DOMHighResTimeStamp}}, nullable

This attribute allows the application to specify a target duration of time in milliseconds of media for the {{RTCRtpReceiver}}'s jitter buffer to hold. This influences the amount of buffering done by the user agent, which in turn affects retransmissions and packet loss recovery. Altering the target value allows applications to control the tradeoff between playout delay and the risk of running out of audio or video frames due to network jitter.

The user agent MUST have a minimum allowed target and a maximum allowed target reflecting what the user agent is able or willing to provide based on network conditions and memory constraints, which can change at any time.

This is a target value. The resulting change in delay can be gradually observed over time. The receiver's average jitter buffer delay can be measured as the delta {{RTCInboundRtpStreamStats/jitterBufferDelay}} divided by the delta {{RTCInboundRtpStreamStats/jitterBufferEmittedCount}}.

An average delay is expected even if DTX is used. For example, if DTX is used and packets start flowing after silence, larger targets can influence the user agent to buffer these packets rather than playing them out.

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

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

  1. Let receiver be the {{RTCRtpReceiver}} object on which the setter is invoked.

  2. Let target be the argument to the setter.

  3. If target is negative or larger than 4000 milliseconds, then

    [Page truncated to keep GeezerVison snappy.]

You are visitor 01402520 — GeezerVison does not store the pages you look up.
Best viewed with Netscape Navigator 4.7 or Internet Explorer 6 at 800×600. No cookies required.