WebRTC 1.0: Real-time Communication Between Browsers W3C Editor's Draft 17 October 2011 This version: http://dev.w3.org/2011/webrtc/editor/webrtc-20111017.html Latest published version: http://www.w3.org/TR/webrtc/ Latest editor's draft: http://dev.w3.org/2011/webrtc/editor/webrtc.html Previous version: http://dev.w3.org/2011/webrtc/editor/webrtc-20111004.html Editors: Adam Bergkvist , Ericsson Daniel C. Burnett , Voxeo Cullen Jennings , Cisco Anant Narayanan , Mozilla

This document defines a set of ECMAScript APIs that allow local media in WebIDL to be requested from a platform, allow media and generic application data to be sent over the network to another browser or device implementing the WEBRTC protocols, and media received from another browser or device to be processed and displayed locally. Status of This Document This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current W3C publications and implementing the latest revision appropriate set of this technical report can be found in the W3C technical reports index at http://www.w3.org/TR/. real-time protocols. This document was published by the Web Real-Time Communications Working Group as an Editor's Draft. If you wish to make comments regarding this document, please send them to public-webrtc@w3.org@w3.org ( subscribe , archives ). All feedback specification is welcome. Publication as being developed in conjunction with a Editor's Draft does not imply endorsement protocol specification developed by the W3C Membership. This is a draft document IETF RTCWEB group and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate an API specification to cite this document as other than work in progress. get access to local media devices.

This document was produced by a group operating under includes Candidate Amendments to the 5 February 2004 current W3C Patent Policy Recommendation dated January 26, 2021 . W3C maintains a public list of any patent disclosures

Its associated test suite made in connection with the deliverables of the group; that page also includes instructions for disclosing a patent. An individual who has actual knowledge of a patent which the individual believes contains Essential Claim(s) been used to build an implementation report must disclose the information in accordance with section 6 of the W3C Patent Policy . Table of Contents 1. Introduction 2. Obtaining local multimedia content 2.1 Definition 2.1.1 NavigatorUserMedia 2.1.1.1 Methods 2.1.2 NavigatorUserMediaSuccessCallback 2.1.2.1 Methods 2.1.3 NavigatorUserMediaError and NavigatorUserMediaErrorCallback 2.1.3.1 Attributes 2.1.3.2 Constants 2.1.3.3 Methods 2.2 Examples 3. Stream API 3.1 Introduction 3.2 Interface definitions 3.2.1 MediaStream 3.2.1.1 Attributes 3.2.1.2 Methods 3.2.1.3 Constants 3.2.2 LocalMediaStream 3.2.2.1 Methods 3.2.3 MediaStreamTrack 3.2.3.1 Attributes 3.2.4 MediaStreamRecorder 3.2.4.1 Methods 3.2.5 BlobCallback 3.2.5.1 Methods 3.2.6 URL 3.2.6.1 Methods 3.3 Examples 4. Peer-to-peer connections 4.1 PeerConnection 4.1.1 Attributes 4.1.2 Methods 4.1.3 Constants 4.2 SignalingCallback 4.2.1 Methods 4.3 Examples 5. The data stream 6. Garbage collection 7. Event definitions 7.1 MediaStreamEvent 7.1.1 Attributes 7.1.2 Methods 8. Event summary 9. application/html-peer-connection-data 10. Change Log A. Acknowledgements B. References B.1 Normative references B.2 Informative references at the time of its initial publication as a Recommendation.

1. Introduction

This section is non-normative.

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

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. Obtaining local multimedia content

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

2.1 Definition 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

2.1.1 NavigatorUserMedia RTCConfiguration Dictionary

] interface { };

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;
};

2.1.1.1 Methods

Dictionary {{RTCConfiguration}} Members

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

Prompts An array of objects describing servers available to be used by ICE, such as STUN and TURN servers. If the user for permission 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 their Web cam or other video or audio input. when gathering ICE candidates.

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

The options argument is a string Indicates which rtcp-mux policy to use when gathering ICE candidates.

certificates of comma-separated values, each 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 itself used for a space-separated list given connection; how certificates are selected is outside the scope of tokens, this specification.

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

If this value is absent, then a default set of which certificates is from 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 following list: cost of key generation.

" audio

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 provided media needs {{RTCIceServer}} dictionary is used to include audio data. describe the STUN and TURN servers that can be used by the [= ICE Agent =] to establish a connection with a peer.

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

Dictionary {{RTCIceServer}} Members

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

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

" video "
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 value Description
relay

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

This can be used to include 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 value Description
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 data. 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 token only value defined in this spec is {{RTCRtcpMuxPolicy/"require"}}.

              enum RTCRtcpMuxPolicy {
                "require"
              };
{{RTCRtcpMuxPolicy}} Enumeration description
Enum value Description
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 followed by used to control the tokens " user 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 " environment " 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 indicate {{RTCIceConnectionState/"failed"}}. An application may additionally choose to listen for the preferred cameras {{RTCPeerConnection/iceConnectionState}} transition to use. {{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.

If The RTCAnswerOptions dictionary describe options specific to session description of type {{RTCSdpType/"answer"}} (none in this version of the user accepts, 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 value Description
stable There is no offer/answer exchange in progress. This is also the successCallback 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 invoked, with 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 value Description
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 value Description
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 value Description
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 suitable 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 LocalMediaStream new {{RTCPeerConnection}}( configuration ) object 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 its argument. a STUN server for the purposes of gathering server reflexive candidates.

If 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 declines, agent when the errorCallback 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 (if any) be document 's [=relevant global object=].

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

Constructor

When the getUserMedia() method RTCPeerConnection.constructor() is called, invoked, the user agent must 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 options 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. Let successCallback be 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 callback indicated by value of {{RTCConfiguration/certificates}} remains undefined for the method's second argument. 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 errorCallback connection be have a [[\Configuration]] internal slot, initialized to null . [= Set the callback indicated configuration =] specified by the method's third argument, if any, or 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 otherwise. .

  12. If successCallback Let connection is null, abort these steps. have a [[\DataChannels]] internal slot, initialized to an empty [=ordered set=].

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  27. 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 false. the {{RTCPeerConnection}} object.

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

  3. Let camera preference operation be the empty set. operation to be chained.

  4. Split options Let p be a new promise.

  5. Append operation on commas to obtain list {{RTCPeerConnection/[[Operations]]}}.

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

  7. For each string option in list Upon [= fulfillment =] or [= rejection =] of options the promise returned by the operation , run the following substeps: steps:

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

    2. If the promise returned by operation on spaces to obtain list 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 suboptions . 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 token in list element of suboptions {{RTCPeerConnection/[[Operations]]}}, and abort these steps.

      4. If connection .{{RTCPeerConnection/[[UpdateNegotiationNeededFlagOnEmptyChain]]}} is a case-sensitive match false , abort these steps.

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

      6. Update the negotiation-needed flag for connection .

  8. Return p .

Update the string " audio ", let audio 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 true. 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 first token in list value of suboptions 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 case-sensitive match for local session description description on an {{RTCPeerConnection}} object connection , [= set a session description | set the string " video ", 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 subsubsteps: steps.

  3. Let video jsepSetOfTransceivers be true. 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. If list Use jsepSetOfTransceivers as the source of suboptions truth with regard to what "RtpTransceivers" exist, and their {{RTCRtpTransceiver/[[JsepMid]]}} internal slot as their "mid property".

    2. If remote contains a token is false and this triggers the ICE candidate gathering process in [[!RFC9429]] , the [= ICE Agent =] MUST NOT gather candidates that would be [= administratively prohibited =].

    3. If remote is a case-sensitive match 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. If the string " user ", add process to apply description fails for any cameras that face towards 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 content of description is not valid SDP syntax, then [= reject =] p with an {{RTCError}} (with {{RTCError/errorDetail}} set to {{RTCErrorDetailType/"sdp-syntax-error"}} and the camera preference {{RTCError/sdpLineNumber}} attribute set to the line number in the SDP where the syntax error was detected) and abort these steps.

      4. If remote set. 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 list 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 content of suboptions description contains is invalid, then [= reject =] p with a token that newly [= exception/created =] {{InvalidAccessError}} and abort these steps.

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

    6. If description is applied successfully, the user agent MUST queue a case-sensitive match for task that runs the string " environment following steps:

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

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

      3. If any promises from {{RTCRtpSender/setParameters}} methods on {{RTCRtpSender}}s associated with connection set. 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 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 both audio 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 video [= release early candidates =].

        2. If description are still false, is of type {{RTCSdpType/"answer"}}, then throw 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 NOT_SUPPORTED_ERR exception null . Set both connection .{{RTCPeerConnection/[[LastCreatedOffer]]}} and abort these steps. 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. Return, 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 remaining steps asynchronously. 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. Optionally, e.g. based on If description is of type {{RTCSdpType/"answer"}}, then this completes an offer answer negotiation. Set connection .{{RTCPeerConnection/[[CurrentRemoteDescription]]}} to a previously-established user preference, for security reasons, or due new {{RTCSessionDescription}} object constructed from description , and set connection .{{RTCPeerConnection/[[CurrentLocalDescription]]}} to platform limitations, jump 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 step labeled failure below. 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. Prompt If description is of type {{RTCSdpType/"answer"}}, and it initiates the user closure of an existing SCTP association, as defined in [[RFC8841]], Sections 10.3 and 10.4, set the value of connection .{{RTCPeerConnection/[[SctpTransport]]}} to null .

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

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

        1. If description initiates the establishment of a user-agent-specific manner for permission new SCTP association, as defined in [[RFC8841]], Sections 10.3 and 10.4, [= create an RTCSctpTransport =] with an initial state of {{RTCSctpTransportState/"connecting"}} and assign the result to provide the entry script's origin {{RTCPeerConnection/[[SctpTransport]]}} slot. Otherwise, if an SCTP association is established, but the max-message-size SDP attribute is updated, [= 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 LocalMediaStream null object representing a media stream. {{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 .
      10. If audio description is true, not of type {{RTCSdpType/"rollback"}}, then run the provided media should include an audio track. following steps:

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

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

            1. If video Let transceiver is true, then be the provided {{RTCRtpTransceiver}} used to create the [= media should include a video track. description =].

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

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

            4. If the provided [= media must not include 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 video track. newly created {{RTCDtlsTransport}} object with a new underlying {{RTCIceTransport}}.

            6. User agents are encouraged Set transceiver .{{RTCRtpTransceiver/[[Sender]]}}.{{RTCRtpSender/[[SenderTransport]]}} to default transport .

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

          2. Let transceiver be the user's primary {{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 system default camera and/or microphone (as appropriate) {{RTCRtpTransceiverDirection/"recvonly"}}, set transceiver .{{RTCRtpTransceiver/[[Receptive]]}} to generate true , otherwise set it to false .

          6. For each of the media stream. User agents may allow users codecs that description negotiates for receiving, execute the following steps:

            1. Locate the matching codec description in transceiver .{{RTCRtpTransceiver/[[Receiver]]}}.{{RTCRtpReceiver/[[ReceiveCodecs]]}}.
            2. If the matching codec description is not found, abort these steps.
            3. Set the "enabled" flag in the matching codec description to use any media source, including pre-recorded media files. "true".

            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 video description is true, of type {{RTCSdpType/"answer"}} or {{RTCSdpType/"pranswer"}}, then run the user agent should encourage following steps:

            1. If transceiver . {{RTCRtpTransceiver/[[Sender]]}}.{{RTCRtpSender/[[SendEncodings]]}} .length is greater than 1 , then run the user 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 provide a camera the missing layers from transceiver .{{RTCRtpTransceiver/[[Sender]]}}.{{RTCRtpSender/[[SendEncodings]]}}.

            2. For each of the camera preference codecs that description set. negotiates for sending, execute the following steps:

              1. Locate the matching codec description in transceiver .{{RTCRtpTransceiver/[[Sender]]}}.{{RTCRtpSender/[[SendCodecs]]}}.
              2. If the matching codec description is not found, abort these steps.
              3. Set the "enabled" flag in the matching codec description to "true".
            3. Set transceiver .{{RTCRtpTransceiver/[[Sender]]}}.{{RTCRtpSender/[[LastReturnedParameters]]}} to null .

            4. User agents may wish to offer If direction is {{RTCRtpTransceiverDirection/"sendonly"}} or {{RTCRtpTransceiverDirection/"inactive"}}, and transceiver .{{RTCRtpTransceiver/[[FiredDirection]]}} is either {{RTCRtpTransceiverDirection/"sendrecv"}} or {{RTCRtpTransceiverDirection/"recvonly"}}, then run the user more control over following steps:

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

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

            5. Set transceiver .{{RTCRtpTransceiver/[[CurrentDirection]]}} and transceiver .{{RTCRtpTransceiver/[[FiredDirection]]}} to enable 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 camera light or flash, or request to change settings such as receive simulcast, use the frame rate or shutter speed. 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 user grants permission 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 use local recording devices, user agents are encouraged 2^(length of proposedSendEncodings - encoding index - 1) .
          5. As described by [[!RFC9429]] , attempt to include find an existing {{RTCRtpTransceiver}} object, transceiver , to represent the [= media description =].

          6. If a prominent indicator that suitable transceiver was found ( transceiver is set), and proposedSendEncodings is non-empty, run the devices are "hot" (i.e. 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 "on-air" 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 "recording" indicator). {{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 user denies permission, jump to previously negotiated layers, then remove all dictionaries in transceiver .{{RTCRtpTransceiver/[[Sender]]}}.{{RTCRtpSender/[[SendEncodings]]}} except the step labeled failure below. first one and abort these sub steps.

            2. If description is missing any of the user never responds, this algorithm stalls on this step. 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 stream direction be an {{RTCRtpTransceiverDirection}} value representing the LocalMediaStream object for which direction from the user granted permission. [= 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. Queue If direction is {{RTCRtpTransceiverDirection/"sendrecv"}} or {{RTCRtpTransceiverDirection/"recvonly"}}, let msids be a task list of the MSIDs that the media description indicates transceiver .{{RTCRtpTransceiver/[[Receiver]]}}.{{RTCRtpReceiver/[[ReceiverTrack]]}} is to invoke successCallback be associated with. Otherwise, let msids with stream be an empty list.

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

          13. Abort For each of the codecs that description negotiates for receiving, execute the following steps:

            1. Locate the matching codec description in transceiver .{{RTCRtpTransceiver/[[Receiver]]}}.{{RTCRtpReceiver/[[ReceiveCodecs]]}}.
            2. If the matching codec description is not found, abort these steps.
            3. Set the "enabled" flag in the matching codec description to "true".

            Failure :

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

            1. For each of the codecs that description negotiates for sending, execute the following steps:

              1. Locate the matching codec description in transceiver .{{RTCRtpTransceiver/[[Sender]]}}.{{RTCRtpSender/[[SendCodecs]]}}.
              2. If the matching codec description is not found, abort these steps.
              3. Set the "enabled" flag in the matching codec description to "true".

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

            3. Let error transport be a new NavigatorUserMediaError the {{RTCDtlsTransport}} object whose code attribute has representing the numeric value 1 ( PERMISSION_DENIED ). RTP/RTCP component of the [= media transport =] used by transceiver 's [= associated =] [= media description =], according to [[RFC8843]].

            4. Queue 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 task local offer, set it to invoke errorCallback {{RTCIceRole/controlling}}.
              • If description with error is a remote offer, and contains a=ice-lite , set {{RTCIceTransport/[[IceRole]]}} to {{RTCIceRole/controlling}}.
              • If description as its argument. 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 .

      11. The task source for these tasks Otherwise, (if description is of type {{RTCSdpType/"rollback"}}) run the user interaction task source. following steps:

        Parameter Type Nullable Optional Description options DOMString ✘ ✘ successCallback NavigatorUserMediaSuccessCallback ✔ ✘ errorCallback
        1. Let pendingDescription be either connection .{{RTCPeerConnection/[[PendingLocalDescription]]}} or connection .{{RTCPeerConnection/[[PendingRemoteDescription]]}}, whichever one is not NavigatorUserMediaErrorCallback ✔ ✔ No exceptions. Return type: null .

        2. 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 void 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 id s of all {{MediaStream}} objects in transceiver .{{RTCRtpTransceiver/[[Receiver]]}}.{{RTCRtpReceiver/[[LastStableStateAssociatedRemoteMediaStreams]]}}, or an empty list if there are none.

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

          7. All instances of 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 =].

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

      12. 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 =].

      13. 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 defined 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. [= Clear the negotiation-needed flag =] and [= update the negotiation-needed flag =].

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

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

      16. For each track in muteTracks , [= set the NavigatorUserMedia interface. 2.1.2 NavigatorUserMediaSuccessCallback ] interface { }; 2.1.2.1 Methods handleEvent (Explanation muted state =] of handleEvent TBD) Parameter Type Nullable Optional Description stream track to the value true .

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

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

      19. 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.

      20. [= Resolve =] p with LocalMediaStream ✘ ✘ No exceptions. undefined .

  5. Return type: 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 void 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 following steps:

      1. Let parsedURL be the result of 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/fragment=] is non-null
        • 2.1.3 NavigatorUserMediaError parsedURL 's' [=url/scheme=] is `"stun"` or `"stuns"`, and NavigatorUserMediaErrorCallback ] interface { }; 2.1.3.1 Attributes code 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 type unsigned short parsing , readonly Returns the current error's error code. At concatenation of `"https://"` and parsedURL 's [=url/path=].

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

        For "stun" and "stuns" schemes, this time, validates [[!RFC7064]] section 3.1.
        For "turn" and "turns" schemes, this will always be 1, for which and the constant PERMISSION_DENIED steps below validate [[!RFC7065]] section 3.1.

      6. If parsedURL 's [=url/query=] is defined. No exceptions. 2.1.3.2 Constants non-null, run the following sub-steps:

        1. TODO: validate ?transport=udp|tcp

      7. If parsedURL 's' [=url/scheme=] is PERMISSION_DENIED "turn" or "turns" , and either of type unsigned short The user denied server .{{RTCIceServer/username}} or server .{{RTCIceServer/credential}} do [=map/exist|not exist=], then [= exception/throw =] an {{InvalidAccessError}}.

  7. Set the page permission [= ICE Agent =]'s ICE transports setting to use the user's media devices. ] interface { }; 2.1.3.3 Methods handleEvent (Explanation value of handleEvent TBD) Parameter Type Nullable Optional Description error NavigatorUserMediaError ✘ ✘ No exceptions. Return type: void 2.2 Examples A voice chat feature 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 game could attempt script wants this to get access 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 user's microphone by calling value of configuration .{{RTCConfiguration/iceCandidatePoolSize}}. If the API 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 follows: defined in [[!RFC9429]] .

    <script> navigator.getUserMedia('audio', gotAudio); function gotAudio(stream) { // ... use 'stream' ... } </script>
  9. A video-conferencing system would ask for both audio 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 video: new candidates will be gathered from the new servers.

    <script> function beginCall() { navigator.getUserMedia('audio,video user', gotStream); } function gotStream(stream) { // ... use 'stream' ... } </script> 3. Stream API
  10. Store configuration in the {{RTCPeerConnection/[[Configuration]]}} internal slot.

3.1 Introduction Interface Definition

The MediaStream RTCPeerConnection interface presented in this section is used extended by several partial interfaces throughout this specification. Notably, the [= RTP Media API =] section, which adds the APIs to represent streams 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 media data, typically (but type {{RTCSessionDescription}} , readonly, nullable

The {{localDescription}} attribute MUST return {{RTCPeerConnection/[[PendingLocalDescription]]}} if it is not necessarily) null and otherwise it MUST return {{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 audio and/or video content, e.g. from a type {{RTCSessionDescription}} , readonly, nullable

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

It represents the local camera 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 a remote site. answer was created.

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

The data from {{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 MediaStream object does null .

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

The {{remoteDescription}} attribute MUST return {{RTCPeerConnection/[[PendingRemoteDescription]]}} if it is not necessarily have a canonical binary form; for example, null and otherwise it could just MUST return {{RTCPeerConnection/[[CurrentRemoteDescription]]}}.

Note that {{RTCPeerConnection/[[CurrentRemoteDescription]]}}.{{RTCSessionDescription/sdp}} and {{RTCPeerConnection/[[PendingRemoteDescription]]}}.{{RTCSessionDescription/sdp}} need not be "the video currently coming from string-wise identical to the user's video camera". This allows user agents {{RTCSessionDescriptionInit/sdp}} value passed to manipulate media streams in whatever fashion is most suitable on the user's platform. 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]]}}.

Each MediaStream object can represent zero 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 more tracks, in particular audio and video tracks. Tracks can contain multiple channels answer was created.

pendingRemoteDescription of parallel data; for example type {{RTCSessionDescription}} , readonly, nullable

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

It represents a single audio track could remote description that is in the process of being negotiated, complete with any remote candidates that have nine channels 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 audio data to represent a 7.2 surround sound audio track. type {{RTCSignalingState}} , readonly

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

iceGatheringState of type {{RTCIceGatheringState}} , readonly

Each track represented by a MediaStream object has 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 corresponding remote description indicates support for trickle ICE, as defined in [[!RFC9429]] . Prior to the completion of {{RTCPeerConnection/setRemoteDescription}}, this value is MediaStreamTrack object. 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

A MediaStream object has The {{createOffer}} method generates a blob of SDP that contains an input 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 an output. parameters of the [= ICE agent =] and the DTLS connection. The input depends on how options parameter may be supplied to provide additional control over the object was created: offer generated.

If a LocalMediaStream object generated by system has limited resources (e.g. a getUserMedia() call, 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 instance, might take its input from generating an offer described in [[!RFC9429]], except the user's local camera, while user agent MUST treat a MediaStream created {{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 PeerConnection object specific negotiated subset to use). In the event {{createOffer}} is called after the session is established, {{createOffer}} will take 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 input addition or removal of tracks. If no changes have been made, the data received from 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 remote peer. set of certificate fingerprints. These certificate fingerprints are used in the construction of SDP.

The output process of generating an SDP exposes a subset of the object controls how media capabilities of the object is used, e.g. what is saved if underlying system, which provides generally persistent cross-origin information on the object is written to 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 file, what common subset of the capabilities.

When the method is displayed if 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 used in a video element, or indeed what 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 transmitted 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 remote peer if 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 object is used 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 PeerConnection object. true , then abort these steps.

  2. Each track If connection was modified in such a MediaStream object can be disabled, meaning way that it additional inspection of the [= offerer's system state =] is muted necessary, then in parallel begin the object's output. All tracks are initially enabled. [= in-parallel steps to create an offer =] again, given connection and p , and abort these steps.

    A MediaStream can
    This may be finished , indicating 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 inputs have forever stopped providing data. When {{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 MediaStream object 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 finished, all its tracks are muted regardless the offerer tagged m= section without having to parse the SDP.

    2. The codec preferences of whether they are enabled a [= media description =]'s [= associated =] transceiver, transceiver , is said to be the value of transceiver .{{RTCRtpTransceiver/[[PreferredCodecs]]}} with the following filtering applied (or said not to be set if transceiver .{{RTCRtpTransceiver/[[PreferredCodecs]]}} is empty):

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

      2. If transceiver .{{RTCRtpTransceiver/direction}} is {{RTCRtpTransceiverDirection/"sendonly"}} or disabled. {{RTCRtpTransceiverDirection/"sendrecv"}}, include all codecs in the transceiver 's {{RTCRtpTransceiver/[[Sender]]}}'s {{RTCRtpSender/[[SendCodecs]]}} for which the "enabled" flag is "true". kind .

      3. If transceiver .{{RTCRtpTransceiver/direction}} is {{RTCRtpTransceiverDirection/"recvonly"}} or {{RTCRtpTransceiverDirection/"sendrecv"}}, include all codecs in the transceiver 's {{RTCRtpTransceiver/[[Receiver]]}}'s {{RTCRtpReceiver/[[ReceiveCodecs]]}} for which the "enabled" flag is "true".

      The output filtering MUST NOT change the order of a MediaStream the codec preferences.

    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 object must correspond line to the tracks corresponding media section, and add an a=simulcast:send line giving the RIDs in its input. Muted audio tracks must 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 replaced a newly created {{RTCSessionDescriptionInit}} dictionary with silence. Muted video tracks must be replaced 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 blackness. offer .

createAnswer

A new MediaStream object can 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 created from 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 list specific codec/RTP/RTCP configuration that, along with the corresponding offer, specifies how the media plane should be established. The generation of MediaStreamTrack objects using the MediaStream() constructor. SDP MUST follow the appropriate process for generating an answer described in [[!RFC9429]].

The list 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 MediaStreamTrack objects 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 track list of another stream, {{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 subset promise [= rejected =] with a newly [= exception/created =] {{InvalidStateError}}.

  3. Return the result of [= chaining =] the track list 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 stream or promise [= rejected =] with a composition 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 MediaStreamTrack objects from different MediaStream objects. 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 ability final steps to duplicate create an answer given a promise p are as follows:

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

  2. If connection was modified in such a new MediaStream object from the track list way that additional inspection of the [= answerer's system state =] is necessary, then in parallel begin the [= in-parallel steps to create an existing stream, allows for greater control since separate MediaStream instances can be manipulated answer =] again given connection and consumed individually. p , and abort these steps.

    This can may be used, necessary if, for instance, in a video-conferencing scenario example, {{createAnswer}} was called when an {{RTCRtpTransceiver}}'s direction was {{RTCRtpTransceiverDirection/"recvonly"}}, but while performing the [= in-parallel steps to display create an answer =], the local 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 user's camera current state of connection and microphone its {{RTCRtpTransceiver}}s, generate an SDP answer, sdpString , as described in a local monitor, while only transmitting [[!RFC9429]] .

    1. The codec preferences of an m= section's [= associated =] transceiver, transceiver , is said to be the audio value of transceiver .{{RTCRtpTransceiver/[[PreferredCodecs]]}} with the following filtering applied (or said not to be set if transceiver .{{RTCRtpTransceiver/[[PreferredCodecs]]}} is empty):

      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 remote peer (e.g. [=RTCRtpSender/list of implemented send codecs=] for kind .

      3. If transceiver .{{RTCRtpTransceiver/direction}} is {{RTCRtpTransceiverDirection/"recvonly"}} or {{RTCRtpTransceiverDirection/"sendrecv"}}, exclude any codecs not included in response the [=list of implemented receive codecs=] for kind .

      The filtering MUST NOT change the order of the codec preferences.

    2. If this is an answer to an offer to receive simulcast, then for each media section requesting to receive simulcast, run the user using a "video mute" feature). Combining tracks from different MediaStream following steps:

      1. If the a=simulcast objects into a new MediaStream 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 makes it possible to, e.g., record selected tracks 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 conversation involving several MediaStream objects {{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 single MediaStreamRecorder . newly created {{RTCSessionDescriptionInit}} dictionary with its {{RTCSessionDescriptionInit/type}} member initialized to the string {{RTCSdpType/"answer"}} and its {{RTCSessionDescriptionInit/sdp}} member initialized to sdpString .

  5. The LocalMediaStream interface is used when Set the user agent is generating {{RTCPeerConnection/[[LastCreatedAnswer]]}} internal slot to sdpString .

  6. [= Resolve =] p with answer .

setLocalDescription

The {{setLocalDescription}} method instructs the stream's data (e.g. from a camera or streaming it from a local video file). It allows authors {{RTCPeerConnection}} to control individual tracks during apply the generation of supplied {{RTCLocalSessionDescriptionInit}} as the content, e.g. local description.

This API changes the local media state. In order to allow successfully handle scenarios where the user application wants to offer to change from one media format to temporarily disable a different, incompatible format, the {{RTCPeerConnection}} MUST be able to simultaneously support use of both the current and pending local camera during descriptions (e.g. support codecs that exist in both descriptions) until a video-conference chat. 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.

When Passing in a LocalMediaStream object description is being generated from optional. If left out, then {{setLocalDescription}} will implicitly [= create an offer =] or [= create an answer =], as needed. As noted in [[!RFC9429]] , if a local file (as opposed description with SDP is passed in, that SDP is not allowed to a live audio/video source), have changed from when it was returned from either {{createOffer}} or {{createAnswer}}.

When the method is invoked, the user agent should stream MUST run the data from following steps:

  1. Let description be the file in real time, not all at once. This reduces method's first argument.

  2. Let connection be the ease with which pages can distinguish live video from pre-recorded video, {{RTCPeerConnection}} object on which can help protect the user's privacy. method was invoked.

    3.2 Interface definitions 3.2.1 MediaStream
  3. The MediaStream( trackList Let sdp ) constructor must 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 present, or {{RTCSdpType/"offer"}} if not 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 new MediaStream object promise [= rejected =] with a newly generated label. A new MediaStreamTrack object [= exception/created =] {{InvalidModificationError}} and abort these steps.

    3. If type is created for every unique underlying media source in trackList {{RTCSdpType/"answer"}} or {{RTCSdpType/"pranswer"}}, and sdp is not the empty string and appended 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 new MediaStream object's track list according empty string, and type is {{RTCSdpType/"offer"}}, then run the following sub steps:

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

      2. A MediaStream object If sdp is said to end when the user agent learns 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 more data will ever longer accurately represents the [= answerer's system state =] of connection , then let p be forthcoming for 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 stream. 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 a MediaStream object ends for any reason (e.g. because the method is invoked, the user rescinds agent MUST run the permission for following steps:

  1. Let description be the page 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 use 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 camera, or because session description =] indicated by {type: {{RTCSdpType/"rollback"}}} .

      2. Return the data comes from result of [= promise/reacting =] to p with a finite file 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 file's end has been reached 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 has not requested that it agent MUST run the following steps:

  1. Let candidate be looped, 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 because larger than the stream comes from number of media descriptions in {{RTCPeerConnection/remoteDescription}}, return a remote peer 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 peer has permanently stopped sending data, it 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 said not [= administratively prohibited =], add the ICE candidate candidate as described in [[!RFC9429]] . Use candidate .{{RTCIceCandidate/usernameFragment}} to be finished . When this happens identify the ICE [= generation =]; if {{RTCIceCandidate/usernameFragment}} is null , process the candidate for any reason other than the stop() method being invoked, 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 MUST queue a task that runs the following steps:

        1. If the object's readyState attribute has the value ENDED (2) already, connection .{{RTCPeerConnection/[[IsClosed]]}} is true , then abort these steps. (The stop() method was probably called just before

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

      2. If candidate is applied successfully, or if the stream stopped for other reasons, e.g. candidate was [= administratively prohibited =] the user clicked an in-page stop button and then agent MUST queue a task that runs the user-agent-provided stop button.) following steps:

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

        2. Set If connection .{{RTCPeerConnection/[[PendingRemoteDescription]]}} is not null , and represents the object's readyState attribute ICE [= generation =] for which candidate was processed, add candidate to ENDED (2). connection .{{RTCPeerConnection/[[PendingRemoteDescription]]}}.sdp.

        3. Fire a simple event named ended at If connection .{{RTCPeerConnection/[[CurrentRemoteDescription]]}} is not null , and represents the object. ICE [= generation =] for which candidate was processed, add candidate to connection .{{RTCPeerConnection/[[CurrentRemoteDescription]]}}.sdp.

        4. As soon as a [= Resolve =] p with MediaStream object undefined .

    8. Return p .

A candidate is finished , administratively prohibited if the stream's tracks start outputting only silence and/or blackness, as appropriate, UA has decided not to allow connection attempts to this address.

For privacy reasons, there is no indication to the developer about whether or not an address/port is blocked; it behaves exactly as defined earlier . 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 end {{RTCConfiguration/iceTransportPolicy}} member of the stream was reached due {{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 user request, call with the task source 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 task method is invoked, the user interaction task source. Otherwise agent MUST run the task source 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 task {{RTCPeerConnection}} object.

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

] interface { }; 3.2.1.1 Attributes label
setConfiguration

The {{setConfiguration}} method updates the configuration of type DOMString this {{RTCPeerConnection}} object. This includes changing the configuration of the [= ICE Agent =]. As noted in [[!RFC9429]] , readonly Returns when the ICE configuration changes in a label way that requires a new gathering phase, an ICE restart is unique to this stream, so that streams can required.

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

  1. Let connection be recognized after they are sent through the {{RTCPeerConnection}} on which the method was invoked.

  2. If connection .{{RTCPeerConnection/[[IsClosed]]}} is PeerConnection API. No exceptions. onended of type Function , nullable 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 event handler, does not fire any event.

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

    1. If transceiver .{{RTCRtpTransceiver/[[Stopped]]}} is true , must 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 supported by all objects implementing closed abruptly and the MediaStream interface. No exceptions. closing procedure will not be invoked.
  6. If connection .{{RTCPeerConnection/[[SctpTransport]]}} is not readyState 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 type unsigned short 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 , readonly 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 readyState 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 attribute represents

When the state of createOffer method is called, the stream. It must return 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 to which 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 last set it (as defined below). It can have MUST run the following values: LIVE or ENDED . steps:

  1. When 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 MediaStream undefined .

createAnswer
The legacy createAnswer object is created, its readyState method does not take an {{RTCAnswerOptions}} parameter, since no known legacy createAnswer attribute must be set to LIVE implementation ever supported it.

When the createAnswer (1), unless it method is being created using called, the MediaStream() 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 constructor whose argument method is a list 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 MediaStreamTrack undefined objects whose underlying media sources will never produce any more data, in which case as the argument.

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

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

addIceCandidate

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

  1. Let candidate be created 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 its readyState attribute set to ENDED (2). candidate as the sole argument, and let p be the resulting promise.

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

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

  7. Returns Return a promise [= resolved =] with MediaStreamTrackList 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 representing encapsulating information about what went wrong.

RTCSessionDescriptionCallback


callback
RTCSessionDescriptionCallback
=
undefined
(RTCSessionDescriptionInit
description);

Callback {{RTCSessionDescriptionCallback}} Parameters

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

Legacy configuration extensions

This section describes a set of legacy extensions that can may be enabled and disabled. 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.

A 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 MediaStream offerToReceive <Kind> can have multiple audio and video sources (e.g. because member in options with kind, kind , run the user has multiple microphones, or because following steps:

    1. If the real source value of the stream dictionary member is a media resource 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 many media tracks). The stream represented by a MediaStream thus the next option, if any.

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

    3. The tracks attribute must return 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 array host object 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 for objects

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 MediaStreamTrack 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 fixed length and read only . The same sent or not.

Garbage collection

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

The array must contain the MediaStreamTrack All {{RTCDataChannel}} and {{MediaStreamTrack}} objects that correspond 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 tracks standard error handling rules of the stream. promises. Methods that do not return promises may throw exceptions to indicate errors.

Session Description Model

RTCSdpType

The relative order {{RTCSdpType}} enum describes the type of all tracks in an {{RTCSessionDescriptionInit}}, {{RTCLocalSessionDescriptionInit}}, or {{RTCSessionDescription}} instance.

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

An {{RTCSdpType}} of {{RTCSdpType/"offer"}} indicates that a user agent must description MUST be stable. All audio tracks must precede all video tracks. Tracks treated as an [[!SDP]] offer.

pranswer

An {{RTCSdpType}} of {{RTCSdpType/"pranswer"}} indicates that come from a media resource whose format defines description MUST be treated as an order must [[!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 order defined by previous stable state. Note the format; tracks that come from local or remote SDP descriptions in the previous stable state could be null if there has not yet been a media resource 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] object toJSON();
};

Constructors

constructor()

The {{RTCSessionDescription()}} constructor takes a dictionary argument, description , whose format does 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 define 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 must 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 relative order 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 which the tracks 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 declared 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 media resource . Within these constraints, affect negotiation. If such changes occur, the order 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 user-agent defined. not 0 , then set connection .{{RTCPeerConnection/[[UpdateNegotiationNeededFlagOnEmptyChain]]}} to true , and abort these steps.

    No exceptions. 3.2.1.2 Methods
  2. Queue a task to run the following steps:

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

    2. Begins recording If the stream. The returned length of connection .{{RTCPeerConnection/[[Operations]]}} is not MediaStreamRecorder object provides access 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 recorded data. steps for [= setting a session description =].

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

    5. If connection .{{RTCPeerConnection/[[NegotiationNeeded]]}} is invoked, the user agent must return a new already MediaStreamRecorder object associated 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 stream. [= operations chain =] is empty.

    No parameters.
    No exceptions. Return type:

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 MediaStreamRecorder 3.2.1.3 Constants 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 ENDED true .

  5. For each transceiver in connection 's [= set of type unsigned short The stream has finished (the user agent transceivers =], perform the following checks:

    1. If transceiver .{{RTCRtpTransceiver/[[Stopping]]}} is no longer receiving 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 generating data, {{RTCRtpTransceiverDirection/"sendonly"}}, and will never receive the [= associated =] m= section in description either doesn't contain a single a=msid line, or generate more data for the number of MSIDs from the a=msid lines in this stream). LIVE m= section, or the MSID values themselves, differ from what is in transceiver .sender.{{RTCRtpSender/[[AssociatedMediaStreamIds]]}}, return true .

      2. If description is of type unsigned short The stream is active (the user agent {{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 making compared with a best-effort attempt direction found in {{RTCPeerConnection/[[CurrentRemoteDescription]]}}, the description's direction must be reversed to receive or generate data represent the peer's point of view.

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

    4. All instances of 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 MediaStream true type are defined was not returned, nothing remains to also implement the EventTarget interface. be negotiated; return false .

Interfaces for Interactive Connectivity Establishment

3.2.2 LocalMediaStream RTCIceCandidate Interface

{ };

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

[Exposed=Window]
interface RTCIceCandidate {
  constructor(optional RTCIceCandidateInit 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 DOMString? url;
  RTCIceCandidateInit toJSON();
};

3.2.2.1 Methods stop

Constructor

constructor()

When a LocalMediaStream object's The stop() RTCIceCandidate() method constructor takes a dictionary argument, candidateInitDict , whose content is used to initialize the new {{RTCIceCandidate}} object.

When invoked, run the user agent must queue following steps:

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

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

  1. If Let iceCandidate be a newly created {{RTCIceCandidate}} object.
  2. Create internal slots for the object's readyState attribute 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}}.
  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 ENDED (2) state, then 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 .

Permanently stop The constructor for {{RTCIceCandidate}} only does basic parsing and type checking for the generation dictionary members in candidateInitDict . Detailed validation on the well-formedness of data {{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 stream. media component this candidate is associated with.
sdpMLineIndex of type unsigned short , readonly, nullable
If not null , this indicates the data index (starting at zero) of the [= media description =] in the SDP this candidate is being generated from a live source (e.g. a microphone 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 camera), {{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 no other stream is being generated from 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 live source, then {{RTCPeerConnection}} instance learns on an address by the web application using {{RTCPeerConnection/addIceCandidate}}, the user agent should remove can expose the {{address}} attribute value in any active "on-air" indicator. If {{RTCIceCandidate}} of the data is being generated from {{RTCPeerConnection}} instance representing a prerecorded source 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 video file), 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 remaining content 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 file is ignored. candidate ({{RTCIceProtocol/"udp"}}/{{RTCIceProtocol/"tcp"}}). This corresponds to the transport field in [= candidate-attribute =].
port of type unsigned short , readonly, nullable
The stream is finished . port of the candidate.
type of type {{RTCIceCandidateType}} , readonly, nullable
The stream's tracks start outputting only silence and/or blackness, 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 appropriate, 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 earlier . 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 DOMString , 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. Set Let value be the result of getting the underlying value of the object's readyState attribute to ENDED (2). identified by attr , given this {{RTCIceCandidate}} object.
    2. Fire a simple event named ended Set json [ attr ] to value .
  3. Return json .
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 object. [= 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]].

candidate-attribute Grammar

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

The task source primary grammar for [= candidate-attribute =] is defined in section 15.1 of [[RFC5245]]. In addition, the tasks queued 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 stop() method is protocol of the DOM manipulation task source. ICE candidate.

No parameters.
enum RTCIceProtocol {
  "udp",
  "tcp"
};
{{RTCIceProtocol}} Enumeration description
Enum value Description
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]].

No exceptions.
enum RTCIceTcpCandidateType {
  "active",
  "passive",
  "so"
};
{{RTCIceTcpCandidateType}} Enumeration description
Enum value Description
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.

Return type: void
enum RTCIceCandidateType {
  "host",
  "srflx",
  "prflx",
  "relay"
};
{{RTCIceCandidateType}} Enumeration description
Enum value Description
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]].

3.2.3 MediaStreamTrack RTCIceServerTransportProtocol Enum

typedef MediaStreamTrack [] MediaStreamTrackList ;

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",
};

Throughout this specification,
{{RTCIceServerTransportProtocol}} Enumeration description
Enum value Description
udp The TURN client is using UDP as transport to the identifier MediaStreamTrackList 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 refer 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 array 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 MediaStreamTrack type. 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 DOMString? url;
};

Constructors

RTCPeerConnectionIceEvent.constructor()
3.2.3.1

Attributes enabled

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

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

This attribute is set to MediaStreamTrack.enabled 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 attribute, on getting, must return of type DOMString , readonly, nullable

The {{url}} attribute is the last value STUN or TURN URL that identifies the STUN or TURN server used to which it gather this candidate. If the candidate was set. On setting, it must 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 new value, and then, if candidate {{RTCIceCandidate/url}}.

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

Dictionary RTCPeerConnectionIceEventInit Members

candidate of type {{RTCIceCandidate}} , nullable

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

url of type DOMString , 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 DOMString url;
  readonly attribute unsigned short errorCode;
  readonly attribute USVString errorText;
};

Constructors

RTCPeerConnectionIceErrorEvent.constructor()
object

Attributes

address of type DOMString , readonly, nullable

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

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

If the local IP address value is true, and disable it otherwise. Thus, after not already exposed as part of a local candidate, the {{address}} attribute will be set to MediaStreamTrack is disassociated from its track, its enabled null .

port of type unsigned short , readonly, nullable

The {{port}} attribute still changes value when set, it just doesn't do anything is the port used to communicate with that new value. the STUN or TURN server.

No exceptions.

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

url of type DOMString , readonly

The MediaStreamTrack.kind {{url}} attribute must return is the string " audio " if STUN or TURN URL that identifies the object's corresponding track 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 was an audio track, " video " if TURN server [[STUN-PARAMETERS]].

If no host candidate can reach the corresponding track 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 was a video track, and a user-agent defined string otherwise. TURN server [[STUN-PARAMETERS]].

No exceptions.

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;
  DOMString 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 label null .

port of type unsigned short , nullable

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

url of type DOMString

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

errorCode of type unsigned short , readonly required

When 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 LocalMediaStream object is created, 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 must generate . That set MUST include an ECDSA certificate with a globally unique identifier string, private key on the P-256 curve and must initialize a signature with a SHA-256 hash.

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

Methods

generateCertificate , static

The {{generateCertificate}} function causes the object's label user agent attribute to that string. Such strings must only use characters create an X.509 certificate [[!X509V3]] and corresponding private key. A handle to information is provided in the ranges U+0021, U+0023 to U+0027, U+002A to U+002B, U+002D form of the {{RTCCertificate}} interface. The returned {{RTCCertificate}} can be used to U+002E, U+0030 control the certificate that is offered in the DTLS sessions established by {{RTCPeerConnection}}.

The keygenAlgorithm argument is used to U+0039, U+0041 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 U+005A, U+005E 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 U+007E, a user or user agent . Randomized values for distinguished name and must serial number SHOULD be 36 characters long. used.

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

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

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

    This means the certificate will by default expire in 30 days from a remote peer, the label attribute time of the {{generateCertificate}} call.

  3. If keygenAlgorithm is initialized from information provided by an object, run the remote source. following steps:

    1. When 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 MediaStream undefined , set expires to certificateExpiration .{{RTCCertificateExpiration/expires}}.

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

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

      A user agent constructor, MAY further cap the value of expires .

  4. Let normalizedKeygenAlgorithm be the result of normalizing an algorithm with an operation name of label generateKey attribute 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 initialized [= rejected =] with error .

  6. If the normalizedKeygenAlgorithm parameter identifies an algorithm that the user agent cannot or will not use to generate a newly 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. The label 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. 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 must return MAY be added to the value definition of the algorithm that is passed to which {{RTCPeerConnection/generateCertificate}}. If this parameter is present it was initialized when indicates the object was maximum time in milliseconds that the {{RTCCertificate}} is valid for, measured from the time the certificate is created.

RTCCertificate Interface

The label of {{RTCCertificate}} interface represents a MediaStream object is unique certificate used to authenticate WebRTC communications. In addition to the source 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 stream, but 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 does this value might not mean it be reflected in a notAfter parameter in the certificate itself.

Methods

getFingerprints

Returns the list of certificate fingerprints, one of which is not possible to end up computed with duplicates. the digest algorithm used in the certificate signature.

For example, 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 locally generated stream could 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 sent 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 user 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 using PeerConnection , 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 then received by the other. For one, IDs of tracks sent back have no mapping to the original user in IDs of tracks received. Also, {{RTCRtpSender/replaceTrack}} changes the same manner, in which case track sent by an {{RTCRtpSender}} without creating a new track on the original user receiver side; the corresponding {{RTCRtpReceiver}} will only have a single track, potentially representing multiple streams with sources of media stitched together. Both {{RTCPeerConnection/addTransceiver}} and {{RTCRtpSender/replaceTrack}} can be used to cause the same label (the locally-generated 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 one received from other side, matching senders and receivers using the remote peer). {{RTCRtpTransceiver}}'s {{RTCRtpTransceiver/mid}} if necessary.

User agents When sending media, the sender may label audio 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 sources (e.g. "Internal microphone" is rescaled as a result of {{RTCRtpEncodingParameters/scaleResolutionDownBy}}, situations when the resulting width or "External USB Webcam"). height is not an integer may occur. The MediaStreamTrack.label attribute must return user agent MUST NOT transmit video larger than the label integer part of the object's corresponding track, scaled width and height from {{RTCRtpEncodingParameters/scaleResolutionDownBy}}, except to respect an encoder's minimum resolution. What to transmit if any. If the corresponding 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 has 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 had no label, in the attribute must instead return network or there may be {{RTCRtpSender}} settings applied that instruct the empty string. implementation to act differently.

Thus

An {{RTCPeerConnection}} object contains a set of {{RTCRtpTransceiver}}s , representing the kind paired senders and label attributes do 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 change value, 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 MediaStreamTrack object 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 disassociated not observable from its corresponding track. 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.

No exceptions. 3.2.4 MediaStreamRecorder { };
          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;
};

3.2.4.1

Attributes

ontrack of type EventHandler

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

Methods getRecordedData

getSenders

Creates Returns a Blob sequence of {{RTCRtpSender}} objects representing the recorded data, and invokes the provided callback with RTP senders that Blob . 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 getRecordedData() 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 called, invoked, the user agent must 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 callback 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 callback {{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. If callback Let kind is null, abort these steps. be track.kind .

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

  5. If connection .{{RTCPeerConnection/[[IsClosed]]}} is MediaStream 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 from which in senders matches all the following criteria, let sender be that object, or MediaStreamRecorder null was created since otherwise:

    • The sender's track is null.

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

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

    • Return, and 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 remaining following steps asynchronously. to use that sender:

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

    2. Generate a file that containing data Set sender .{{RTCRtpSender/[[AssociatedMediaStreamIds]]}} to an empty set.

    3. For each stream in a format supported by the user agent for use in audio and video elements. streams , add stream.id to {{RTCRtpSender/[[AssociatedMediaStreamIds]]}} if it's not already there.

    4. Let blob transceiver be a 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 Blob object representing null , run the contents of following steps:

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

    2. Create an RTCRtpReceiver with kind , and let receiver be the previous step. [ FILE-API result.

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

    4. Queue a task to invoke callback Add transceiver with blob to connection as its argument. 's [= set of transceivers =].

    The getRecordedData() method
  10. A track could have contents that are inaccessible to the application. This can be called multiple times on one MediaStreamRecorder object; each time, it will create due to anything that would make a new file 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 if {{RTCRtpTransceiverDirection/"recvonly"}} or {{RTCRtpTransceiverDirection/"inactive"}}, as defined in [[!RFC9429]] .

When the other peer stops sending a track in this was manner, the first time track is removed from any remote {{MediaStream}}s that were initially revealed in the method was being called. In particular, {{RTCPeerConnection/track}} event, and if the method does {{MediaStreamTrack}} is not stop or reset already muted, a mute event is fired at the recording when 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 called. invoked, the user agent MUST run the following steps:

Parameter Type Nullable Optional Description callback BlobCallback ✔ ✘ No exceptions. Return type: voice 3.2.5 BlobCallback ] interface { }; 3.2.5.1 Methods handleEvent Def TBD Parameter Type Nullable Optional Description blob
  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 Blob ✘ ✘ No exceptions. Return type: 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 void 3.2.6 URL true , abort these steps.

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

  8. If sender is actually only a partial interface, but ReSpec does not yet support that. 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.

    { }; 3.2.6.1 Methods createObjectURL
  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

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

Adding a transceiver will cause future calls to {{createOffer}} to add a [= media description =] for the given MediaStream . 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 the createObjectURL() this method is called with a MediaStream argument, invoked, the user agent must return 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 unique Blob URL for string, let kind be the given first argument and run the following steps:

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

    2. Let track be MediaStream null . [ FILE-API ]

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

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

  8. Validate sendEncodings by running the data exposed on 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 stream must be of a {{RTCRtpCodingParameters/rid}} [=map/contains | contained=] in another encoding in sendEncodings .
    2. If any encoding [=map/contains=] a format supported by read-only parameter other than {{RTCRtpCodingParameters/rid}}, [= exception/throw =] an {{InvalidAccessError}}.

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

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

    5. 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}}.

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

    7. 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`.

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

    9. 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 video elements. A Blob URL 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.

    10. If the same as what number of encodings now stored in sendEncodings is 1 , then remove any {{RTCRtpCodingParameters/rid}} member from the File API specification calls lone entry.

      Providing a Blob URI, except that anything single, default {{RTCRtpEncodingParameters}} in sendEncodings allows the definition of that feature that refers application to File subsequently set encoding parameters using {{RTCRtpSender/setParameters}}, even when simulcast isn't used.
  9. Create an RTCRtpSender with track , kind , streams and Blob objects sendEncodings and let sender be the result.

    If sendEncodings is hereby extended set, then subsequent calls to also apply {{createOffer}} will be configured to MediaStream 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 LocalMediaStream let receiver be the result.

  11. Create an RTCRtpTransceiver objects. 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"
};
Parameter Type stream
RTCRtpTransceiverDirection Enumeration description
Nullable Optional Enum value Description
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 MediaStream true ✘ ✘ No exceptions. Return type: 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 static DOMString 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.
3.3 Examples

Processing Remote MediaStreamTracks

This sample code exposes 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 button. When clicked, manner that makes it available for reuse, the button 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 disabled {{RTCRtpTransceiverDirection/"sendrecv"}} or {{RTCRtpTransceiverDirection/"recvonly"}} and transceiver .{{RTCRtpTransceiver/[[FiredDirection]]}} is neither {{RTCRtpTransceiverDirection/"sendrecv"}} nor {{RTCRtpTransceiverDirection/"recvonly"}}, or the user previous step increased the length of addList , process the addition of a remote track with transceiver and trackEventInits .

  3. If direction is prompted {{RTCRtpTransceiverDirection/"sendonly"}} or {{RTCRtpTransceiverDirection/"inactive"}}, set transceiver .{{RTCRtpTransceiver/[[Receptive]]}} to offer 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 stream. The user can cause remote track for the button 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 re-enabled by providing transceiver .{{RTCRtpTransceiver/[[Receiver]]}}.

  2. Let track be receiver .{{RTCRtpReceiver/[[ReceiverTrack]]}}.

  3. Let streams be receiver .{{RTCRtpReceiver/[[AssociatedRemoteMediaStreams]]}}.

  4. Create a stream (e.g. giving new {{RTCTrackEventInit}} dictionary with receiver , track , streams and transceiver as members and add it to trackEventInits .

To process the page access 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 local camera) associated remote streams given {{RTCRtpReceiver}} receiver , msids , addList , and then disabling 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 id s corresponding to msids .

  4. Let track be receiver .{{RTCRtpReceiver/[[ReceiverTrack]]}}.

  5. For each stream (e.g. revoking in receiver .{{RTCRtpReceiver/[[AssociatedRemoteMediaStreams]]}} that access). is not present in streams , add stream and track as a pair to removeList .

    <input type="button" value="Start" onclick="start()" id="startBtn"> <script> var startBtn = document.getElementById('startBtn'); function start() { navigator.getUserMedia('audio,video', gotStream); startBtn.disabled = true; } function gotStream(stream) { stream.onended = function () { startBtn.disabled = false; } } </script>
  6. This example 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 people an application to record control how a short audio message given {{MediaStreamTrack}} is encoded and upload it transmitted to a remote peer. When {{RTCRtpSender/setParameters}} is called on an {{RTCRtpSender}} object, the server. This example even shows rudimentary error handling. encoding is changed appropriately.

<input type="button" value="⚫" onclick="msgRecord()" id="recBtn"> <input type="button" value="◼" onclick="msgStop()" id="stopBtn" disabled> <p id="status">To start recording, press the ⚫ button.</p> <script> var recBtn = document.getElementById('recBtn'); var stopBtn = document.getElementById('stopBtn'); function report(s) { document.getElementById('status').textContent = s; } function msgRecord() { report('Attempting to access microphone...'); navigator.getUserMedia('audio', gotStream, noStream); recBtn.disabled = true; } var msgStream, msgStreamRecorder; function gotStream(stream) { report('Recording... To stop, press to ◼ button.'); msgStream = stream; msgStreamRecorder = stream.record(); stopBtn.disabled = false; stream.onended = function () { msgStop(); } } function msgStop() { report('Creating file...'); stopBtn.disabled = true; msgStream.onended = null; msgStream.stop(); msgStreamRecorder.getRecordedData(msgSave); } function msgSave(blob) { report('Uploading file...'); var x = new XMLHttpRequest(); x.open('POST', 'uploadMessage'); x.send(blob); x.onload = function () { report('Done! To record a new message, press the ⚫ button.'); recBtn.disabled = false; }; x.onerror = function () { report('Failed to upload message. To try recording a message again, press the ⚫ button.'); recBtn.disabled = false; }; } function noStream() { report('Could not obtain access to your microphone. To try again, press the ⚫ button.'); recBtn.disabled = false; } </script>

This example allows people to take photos To create an RTCRtpSender with a {{MediaStreamTrack}}, track , a string, kind , a list of themselves from {{MediaStream}} objects, streams , and optionally a list of {{RTCRtpEncodingParameters}} objects, sendEncodings , run the local video camera. following steps:

<article> <style scoped> video { transform: scaleX(-1); } p { text-align: center; } </style> <h1>Snapshot Kiosk</h1> <section id="splash"> <p id="errorMessage">Loading...</p> </section> <section id="app" hidden> <p><video id="monitor" autoplay></video> <canvas id="photo"></canvas> <p><input type=button value="&#x1F4F7;" onclick="snapshot()"> </section> <script> navigator.getUserMedia('video user', gotStream, noStream); var video = document.getElementById('monitor'); var canvas = document.getElementById('photo'); function gotStream(stream) { video.src = URL.getObjectURL(stream); video.onerror = function () { stream.stop(); }; stream.onended = noStream; video.onloadedmetadata = function () { canvas.width = video.videoWidth; canvas.height = video.videoHeight; document.getElementById('splash').hidden = true; document.getElementById('app').hidden = false; }; } function noStream() { document.getElementById('errorMessage').textContent = 'No camera available.'; } function snapshot() { canvas.getContext('2d').drawImage(video, 0, 0); } </script> </article> 4. Peer-to-peer connections
  1. A 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 PeerConnection allows two users null .

  4. Let sender have a [[\LastStableStateSenderTransport]] internal slot initialized to communicate directly, browser-to-browser. Communications are coordinated via null .

  5. Let sender have a signaling channel provided by script in the page via the server, e.g. using [[\Dtmf]] internal slot initialized to XMLHttpRequest null .

  6. Calling "new PeerConnection If kind is "audio" ( configuration 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 , signalingCallback add stream.id )" creates 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 PeerConnection true object. by default.

  12. Let sender have a [[\LastStableRidlessSendEncodings]] internal slot initialized to null .

  13. The configuration Let sender string gives have a [[\SendCodecs]] internal slot, representing a list of [=tuple=]s, each containing an {{RTCRtpCodecParameters}} dictionary and an "enabled" boolean, and initialized to the address [=RTCRtpSender/list of implemented send codecs=], with the "enabled" flag set in an implementation defined manner.

  14. Let sender have a STUN or TURN server to use [[\LastReturnedParameters]] internal slot, which will be used to establish the connection. [STUN] [TURN] match {{RTCRtpSender/getParameters}} and {{RTCRtpSender/setParameters}} transactions.

  15. The allowed formats for this string are: 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

" TYPE 203.0.113.2:3478 " track of type {{MediaStreamTrack}} , readonly, nullable

Indicates a specific IP address 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 port for MUST NOT send (audio). In the server. 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.

" TYPE relay.example.net:3478 ""
transport of type {{RTCDtlsTransport}} , readonly, nullable

Indicates a specific host 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 port 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 server; given kind, without reserving any resources, ports, or other state.

When the {{getCapabilities}} method is called, the user agent will look up MUST run the IP address in DNS. following steps:

" TYPE
  1. Let kind example.net "" be the method's first argument.

  2. Indicates If kind is neither `"video"` nor `"audio"` return `null`.

  3. Return a specific domain 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 server; [=list of implemented header extensions for sending=] with kind .

The list of implemented send codecs , given kind , is an [=implementation-defined=] list of {{RTCRtpCodecCapability}} dictionaries representing the most optimistic view of the codecs the user agent will look up supports for sending media of the IP address given kind (video or audio).

This conceptual list contains every combination of parameters that the user agent is capable of processing. In practice, this would be implemented as a piece of code that parses the parameters and port in DNS. determines whether they are acceptable or not, but this is highly codec dependent, so for the purpose of specification, we work with a conceptual list containing all acceptable parameter combinations.

The " TYPE " list of implemented header extensions for sending , given kind , is one of: 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).

STUN Indicates

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 STUN server 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.

STUNS
setParameters
Indicates a STUN server that

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 contacted using 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 TLS session. TURN Indicates promise [= rejected =] with a TURN server 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 N be the number of {{RTCRtpEncodingParameters}} stored in sender .{{RTCRtpSender/[[SendEncodings]]}}.
    4. If any of the following conditions are met, return a promise [= rejected =] with a newly [= exception/created =] {{InvalidModificationError}}:
      • TURNS encodings .length Indicates is different from N .
      • encodings has been re-ordered.
      • Any parameter in parameters is marked as a TURN server 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 be contacted using transactionId .
    5. If [=RTCRtpTransceiver/transceiver kind=] is `"audio"`, remove the {{RTCRtpEncodingParameters/scaleResolutionDownBy}} and {{RTCRtpEncodingParameters/maxFramerate}} members from all encodings that [=map/contain=] any of them.

    6. If [=RTCRtpTransceiver/transceiver kind=] is `"video"`, then for each encoding in encodings that doesn't [=map/contain=] a TLS session. {{RTCRtpEncodingParameters/scaleResolutionDownBy}} member, add a {{RTCRtpEncodingParameters/scaleResolutionDownBy}} member with the value `1.0`.

    7. The signalingCallback If [=RTCRtpTransceiver/transceiver kind=] is `"video"`, and any encoding in encodings argument [=map/contains=] a {{RTCRtpEncodingParameters/scaleResolutionDownBy}} member whose value is less than `1.0`, return a method promise [= rejected =] with a newly [= exception/created =] {{RangeError}}.

    8. Verify that will 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}}.

  7. Let p be invoked when a new promise.
  8. In parallel, configure the user agent needs media stack to send use parameters to transmit sender .{{RTCRtpSender/[[SenderTrack]]}}.
    1. If the media stack is successfully configured with parameters , queue a message task to run the other host over 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 signaling channel. When media stack, queue a task to run the callback 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 invoked, convey its first argument (a string) set to the other peer using whatever method {{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 being 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 Web application {{RTCRtpSendParameters}} dictionary are designed to relay signaling messages. (Messages returned from 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 peer are provided back 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 using MUST run the processSignalingMessage() method.) following steps:

  1. A PeerConnection Let sender be the {{RTCRtpSender}} object has an 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 codecs from the {{RTCRtpSender/[[SendCodecs]]}} internal slot where the "enabled" flag is true.
    • {{RTCRtpParameters/rtcp}}.{{RTCRtcpParameters/cname}} is set to the CNAME of the associated {{RTCPeerConnection}}. {{RTCRtpParameters/rtcp}}.{{RTCRtcpParameters/reducedSize}} is set to PeerConnection true signaling callback , a if reduced-size RTCP has been negotiated for sending, and PeerConnection false ICE Agent , otherwise.
  4. Set sender .{{RTCRtpSender/[[LastReturnedParameters]]}} to result .

  5. Queue a task that sets sender .{{RTCRtpSender/[[LastReturnedParameters]]}} to PeerConnection readiness state and an SDP Agent . These are initialized when null .

  6. Return result .

{{getParameters}} may be used with {{setParameters}} to change the object is created. 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);
  }
}

When 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 PeerConnection() null constructor track), without renegotiation.

When the {{replaceTrack}} method is invoked, the user agent must MUST run the following steps. This algorithm has a synchronous section (which is triggered as part of the event loop algorithm). Steps in the synchronous section are marked with ⌛. steps:

  1. Let serverConfiguration sender be the constructor's first argument. {{RTCRtpSender}} object on which {{replaceTrack}} is invoked.

  2. Let signalingCallback transceiver be the constructor's second argument. {{RTCRtpTransceiver}} object associated with sender .

  3. Let connection be a newly created the {{RTCPeerConnection}} object associated with sender .

  4. Let withTrack be the argument to this method.

  5. If withTrack is non-null and PeerConnection withTrack .kind object. differs from the [=RTCRtpTransceiver/transceiver kind=] of transceiver , return a promise [= rejected =] with a newly [= exception/created =] {{TypeError}}.

  6. Create an ICE Agent and let Return the result of [= chaining =] the following steps to connection 's [= operations chain =]:

    1. If transceiver .{{RTCRtpTransceiver/[[Stopping]]}} is PeerConnection ICE Agent true , return a promise [= rejected =] with a newly [= exception/created =] {{InvalidStateError}}.

    2. Let p be that ICE Agent. [ICE] 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 serverConfiguration sending contains a U+000A LINE FEED (LF) character or a U+000D CARRIAGE RETURN (CR) character (or both), remove all characters from serverConfiguration is true , and withTrack after is null , have the first such character. sender stop sending.

      2. Split serverConfiguration If sending on spaces to obtain configuration components . 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 [= reject =] p with a newly [= exception/created =] {{InvalidModificationError}}, and abort these steps.

      3. If configuration components sending has two or more components, is true , and the first component withTrack is a case-sensitive match for one 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 strings: steps:

        1. " STUN "

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

        2. Set sender .{{RTCRtpSender/[[SenderTrack]]}} to withTrack .

        3. " STUNS "

          [= Resolve =] p with undefined .

    5. Return p .

Changing dimensions and/or frame rates might not require negotiation. Cases that may require negotiation include:

  1. " TURN " Changing a resolution to a value outside of the negotiated imageattr bounds, as described in [[RFC6236]].
  2. " TURNS " Changing a frame rate to a value that causes the block rate for the codec to be exceeded.
  3. ...then
  4. A video track differing in raw vs. pre-encoded format.
  5. An audio track having a different number of channels.
  6. 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 substeps: steps:

  1. Let server type sender be STUN if the first component of configuration components is ' STUN ' or ' STUNS ', and TURN otherwise (the first component of configuration components {{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 " TURN " or " TURNS "). true , [= exception/throw =] an {{InvalidStateError}}.

  4. Let secure streams be true a list of {{MediaStream}} objects constructed from the method's arguments, or an empty list if the first component of configuration components method was called without arguments.

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

  6. For each stream is " STUNS " or " TURNS ", 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 false otherwise. 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 host p be a new promise, and run the contents of following steps in parallel:

    1. Gather the second component of configuration components stats indicated by selector up according to the character before the first U+003A COLON character (:), if any, or the entire string otherwise. [= stats selection algorithm =].

    2. Let port [= 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 contents "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 second component last set of configuration components from 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 character after 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 first U+003A COLON character (:) up sending side. Read-only parameter .

RTCRtpEncodingParameters Dictionary

dictionary RTCRtpEncodingParameters : RTCRtpCodingParameters {
  boolean active = true;
  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 end, if any, value to false does not cause the SSRC to be removed, an RTCP BYE is not sent.

maxBitrate of type unsigned long

When 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 empty string otherwise. 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

Configure This member can only be present if the PeerConnection sender's kind ICE Agent is "video" . When present, indicates the maximum frame rate that can be used to send this encoding, in frames per second. The user agent 's STUN or TURN server is free to allocate bandwidth between the encodings, as follows: long as the {{maxFramerate}} value is not exceeded.

If server 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 STUN, only present if the server 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 STUN server. Otherwise, server 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 TURN and 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 server 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 TURN server. 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. If secure recvonly: The header extension is true, the server 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 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 contacted using TLS-over-TCP, otherwise, it 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<RTCRtpCodecCapability> codecs;
  required sequence<RTCRtpHeaderExtensionCapability> headerExtensions;
};

Dictionary {{RTCRtpCapabilities}} Members

codecs of type sequence<{{RTCRtpCodecCapability}}> , required

Supported media codecs as well as entries for RTX, RED and FEC mechanisms. There will only be contacted using UDP. a single entry in {{codecs}} for retransmission via RTX, with {{RTCRtpCodec/sdpFmtpLine}} not present.

headerExtensions of type sequence<{{RTCRtpHeaderExtensionCapability}}> , required

Supported RTP header extensions.

RTCRtpCodecCapability Dictionary

dictionary RTCRtpCodecCapability : RTCRtpCodec {
};

The {{RTCRtpCodecCapability}} dictionary provides information about codec capabilities. Only capability combinations that would utilize distinct payload types in a generated SDP offer are 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.

RTCRtpHeaderExtensionCapability Dictionary

dictionary RTCRtpHeaderExtensionCapability {
  required DOMString uri;
};

Dictionary {{RTCRtpHeaderExtensionCapability}} Members

uri of type DOMString , required

The IP address, host name, or domain name URI of the server RTP header extension, as defined in [[RFC5285]].

RTCSetParameterOptions Dictionary

dictionary RTCSetParameterOptions {
};

Dictionary {{RTCSetParameterOptions}} Members

RTCSetParameterOptions is host . 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 port 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 use 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 port receiving media data or not.

  7. Let receiver have a [[\ReceiverTrack]] internal slot initialized to track . If

  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 [=tuple=]s, each containing a {{RTCRtpCodecParameters}} dictionaries, and initialized to an list containing all the codecs in the list of implemented receive codecs for kind , and with the "enabled" flag set in an implementation defined manner.

  13. Let receiver have a [[\LastStableStateReceiveCodecs]] internal slot and initialize it to an empty string, then only list.

  14. Let receiver have a domain name [[\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 configured (and the ICE Agent will use DNS SRV requests 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 determine be sent. On getting, the IP address and port). attribute MUST return the value of the {{RTCRtpReceiver/[[ReceiverTrack]]}} slot.

transport of type {{RTCDtlsTransport}} , readonly, nullable

The long-term username {{transport}} attribute is the transport over which media for the STUN or TURN server receiver's {{RTCRtpReceiver/track}} is received in the ASCII serialization form of RTP packets. Prior to construction of the entry script's origin; {{RTCDtlsTransport}} object, the long-term password {{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 empty string. same transport.

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

jitterBufferTarget of type {{DOMHighResTimeStamp}}, nullable

If This attribute allows the given IP address, host name, domain name, 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 port are invalid, then 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 must act 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 no STUN or TURN server DTX is configured. 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 the connection receiver 's PeerConnection signaling callback be signalingCallback . the {{RTCRtpReceiver}} object on which the setter is invoked.

  2. Set connection Let target 's PeerConnection readiness state be the argument to NEW (0). the setter.

  3. Set connection If target 's PeerConnection ice state to NEW (0). is negative or larger than 4000 milliseconds, then [=exception/throw=] a {{RangeError}}.

  4. Set connection receiver 's PeerConnection sdp state {{RTCRtpReceiver/[[JitterBufferTarget]]}} to NEW (0). target .

  5. Let connection track 's localStreams attribute be an empty read-only MediaStream array. [ WEBIDL ] receiver 's {{RTCRtpReceiver/[[ReceiverTrack]]}}.

  6. Let connection In parallel, begin executing the following steps:

    1. Update the underlying system about the new target , or that there is no application preference if target 's remoteStreams attribute be an empty read-only is MediaStream null .

      If track is synchronized with another {{RTCRtpReceiver}}'s track for audio/video synchronization , then the user agent array. [ WEBIDL SHOULD use the larger of the two receivers' {{RTCRtpReceiver/[[JitterBufferTarget]]}} for both receivers.

      When the underlying system is applying a jitter buffer target, it will continuously make sure that the actual jitter buffer target is clamped within the minimum allowed target and maximum allowed target .

      If the user agent ends up using a target different from the requested one (e.g. due to network conditions or physical memory constraints), this is not reflected in the {{RTCRtpReceiver/[[JitterBufferTarget]]}} internal slot.

      ]

    2. Return connection , but continue these steps asynchronously. Modifying the jitter buffer target of the underlying system SHOULD affect the internal audio or video buffering gradually in order not to hurt user experience. Audio samples or video frames SHOULD be accelerated or decelerated before playout, similarly to how it is done for audio/video synchronization or in response to congestion control.

      Await a stable state. The synchronous section consists of acceleration or deceleration rate may vary depending on network conditions or the remaining steps type of this algorithm. (Steps in synchronous sections audio received (e.g. speech or background noise). It MAY take several seconds to achieve 1 second of buffering but SHOULD not take more than 30 seconds assuming packets are marked being received. The speed MAY be different for audio and video.

      For audio, acceleration and deceleration can be measured with ⌛.) {{RTCInboundRtpStreamStats/insertedSamplesForDeceleration}} and {{RTCInboundRtpStreamStats/removedSamplesForAcceleration}}. For video, this may result in the same frame being rendered multiple times or frames may be dropped.

Methods

getCapabilities , static

The static {{RTCRtpReceiver}}.{{getCapabilities()}} method provides a way to discover the types of capabilities the user agent supports for receiving media of the given kind, without reserving any resources, ports, or other state.

⌛ If When the ice state {{getCapabilities}} method is set to NEW, it must queue 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 task new {{RTCRtpCapabilities}} dictionary, with its {{RTCRtpCapabilities/codecs}} member initialized to start gathering ICE address and set the ice state [=list of implemented receive codecs=] for kind , and its {{RTCRtpCapabilities/headerExtensions}} member initialized to ICEGATHERING. the [=list of implemented header extensions for receiving=] for kind .

⌛ Once The list of implemented receive codecs , given kind , is an [=implementation-defined=] list of {{RTCRtpCodecCapability}} dictionaries representing the ICE address gathering most optimistic view of the codecs the user agent supports for receiving media of the given kind (video or audio).

This conceptual list contains every combination of parameters that the user agent is complete, if there capable of processing. In practice, this would be implemented as a piece of code that parses the parameters and determines whether they are any streams in localStreams, acceptable or not, but this is highly codec dependent, so for the SDP Agent will send purpose of specification, we work with a conceptual list containing all acceptable parameter combinations.

The list of implemented header extensions for receiving , given kind , is an [=implementation-defined=] list of {{RTCRtpHeaderExtensionCapability}} dictionaries representing an optimistic view of the initial header extensions the SDP offer. user agent supports for receiving 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 initial SDP offer must contain both codec capabilities returned affect the ICE candidate {{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 reception, to ensure any privacy mitigations are effective.

getParameters

The {{getParameters()}} method returns the {{RTCRtpReceiver}} object's current parameters for how {{track}} is decoded.

When {{getParameters}} is called, the {{RTCRtpReceiveParameters}} dictionary is constructed as well follows:

  • The {{RTCRtpParameters/headerExtensions}} sequence is populated based on the header extensions that the receiver is currently prepared to receive.
  • {{RTCRtpParameters/codecs}} is set to the value of the "enabled" codecs from the {{RTCRtpReceiver/[[ReceiveCodecs]]}} internal slot.

    Both the local and remote description may affect this list of codecs. For example, if three codecs are offered, the receiver will be prepared to receive each of them and will return them all from {{getParameters}}. But if the remote endpoint only answers with two, the absent codec will no longer be returned by {{getParameters}} as the SDP receiver no longer needs to represent be prepared to receive it.
  • {{RTCRtpParameters/rtcp}}.{{RTCRtcpParameters/reducedSize}} is set to true if the media descriptions receiver is currently prepared to receive reduced-size RTCP packets, and false otherwise. {{RTCRtpParameters/rtcp}}.{{RTCRtcpParameters/cname}} is left out.
getContributingSources

Returns an {{RTCRtpContributingSource}} for all each unique CSRC identifier received by this {{RTCRtpReceiver}} in the streams last 10 seconds, in localStreams. descending {{RTCRtpContributingSource/timestamp}} order.

getSynchronizationSources

Returns an {{RTCRtpSynchronizationSource}} for each unique SSRC identifier received by this {{RTCRtpReceiver}} in the last 10 seconds, in descending {{RTCRtpContributingSource/timestamp}} order.

getStats

During Gathers stats for this receiver only and reports the lifetime of result asynchronously.

When the peerConnection object, {{getStats()}} method is invoked, the user agent MUST run the following procedures are followed: steps:

  1. Let selector be the {{RTCRtpReceiver}} object on which the method was invoked.

  2. If Let p be a local media stream has been added new promise, and run the following steps in parallel:

    1. Gather the stats indicated by selector according to the [= stats selection algorithm =].

    2. [= Resolve =] p with the resulting {{RTCStatsReport}} object, containing the gathered stats.

  3. Return p .

The RTCRtpContributingSource and RTCRtpSynchronizationSource dictionaries contain information about a given contributing source (CSRC) or synchronization source (SSRC) respectively. When an SDP offer needs audio or video frame from one or more RTP packets is delivered to be sent, the {{RTCRtpReceiver}}'s {{MediaStreamTrack}}, the user agent MUST queue a task to update the relevant information for the {{RTCRtpContributingSource}} and {{RTCRtpSynchronizationSource}} dictionaries based on the ICE state content of those packets. The information relevant to the {{RTCRtpSynchronizationSource}} dictionary corresponding to the SSRC identifier, is not NEW or ICEGATHERING, updated each time, and if an RTP packet contains CSRC identifiers, then the SDP Agent state information relevant to the {{RTCRtpContributingSource}} dictionaries corresponding to those CSRC identifiers is NEW or SDPIDLE, then send also updated. The user agent MUST process RTP packets in order of ascending RTP timestamps. The user agent MUST keep information from RTP packets delivered to the {{RTCRtpReceiver}}'s {{MediaStreamTrack}} in the previous 10 seconds.

Even if the {{MediaStreamTrack}} is not attached to any sink for playout, {{RTCRtpReceiver/getSynchronizationSources}} and {{RTCRtpReceiver/getContributingSources}} returns up-to-date information as long as the track is not ended; sinks are not a prerequisite for decoding RTP packets.
As stated in the conformance section , requirements phrased as algorithms may be implemented in any manner so long as the end result is equivalent. So, an implementation does not need to literally queue a task to send for every frame, as long as the end result is that within a single event loop task execution, all returned {{RTCRtpSynchronizationSource}} and {{RTCRtpContributingSource}} dictionaries for a particular {{RTCRtpReceiver}} contain information from a single point in the RTP stream.
dictionary RTCRtpContributingSource {
  required DOMHighResTimeStamp timestamp;
  required unsigned long source;
  double audioLevel;
  required unsigned long rtpTimestamp;
};

Dictionary RTCRtpContributingSource Members

timestamp of type {{DOMHighResTimeStamp}}, required

The {{timestamp}} indicating the most recent time a frame from an SDP offer RTP packet, originating from this source, was delivered to the {{RTCRtpReceiver}}'s {{MediaStreamTrack}}. The {{timestamp}} is defined as {{Performance.timeOrigin}} + {{Performance.now()}} at that time.

source of type unsigned long , required

The CSRC or SSRC identifier of the contributing or synchronization source.

audioLevel of type double

Only present for audio receivers. This is a value between 0..1 (linear), where 1.0 represents 0 dBov, 0 represents silence, and 0.5 represents approximately 6 dBSPL change in the SPD state to SDP Waiting. sound pressure level from 0 dBov.

For CSRCs, this MUST be converted from the level value defined in [[!RFC6465]] if the RFC 6465 header extension is present, otherwise this member MUST be absent.

For SSRCs, this MUST be converted from the level value defined in [[!RFC6464]]. If an SDP offer has been received, and the SDP state RFC 6464 header extension is NEW not present in the received packets (such as if the other endpoint is not a user agent or SDPIDLE, pass is a legacy endpoint), this value SHOULD be absent.

Both RFCs define the ICE candidates level as an integral value from 0 to 127 representing the SDP offer audio level in negative decibels relative to the ICE Agent loudest signal that the system could possibly encode. Thus, 0 represents the loudest signal the system could possibly encode, and change it state 127 represents silence.

To convert these values to ICECHECKING. Construct the linear 0..1 range, a value of 127 is converted to 0, and all other values are converted using the equation: 10^(-rfc_level/20) .

rtpTimestamp of type unsigned long , required

The RTP timestamp, as defined in [[!RFC3550]] Section 5.1, of the media played out at timestamp .

            dictionary RTCRtpSynchronizationSource : RTCRtpContributingSource {};

The {{RTCRtpSynchronizationSource}} dictionary is expected to serve as an appropriate SDP answer, update extension point for the remote streams, queue specification to surface data only available in SSRCs.

RTCRtpTransceiver Interface

The {{RTCRtpTransceiver}} interface represents a task combination of an {{RTCRtpSender}} and an {{RTCRtpReceiver}} that share a common [= media stream "identification-tag" =]. As defined in [[!RFC9429]] , an {{RTCRtpTransceiver}} is said to send be associated with a [= media description =] if its "mid" property is non-null and matches a [= media stream "identification-tag" =] in the SDP offer, [= media description =]; otherwise it is said to be disassociated with that [= media description =].

A {{RTCRtpTransceiver}} may become associated with a new pending description in RFC9429 while still being disassociated with the current description. This may happen in [= check if negotiation is needed =].

The transceiver kind of an {{RTCRtpTransceiver}} is defined by the kind of the associated {{RTCRtpReceiver}}'s {{MediaStreamTrack}} object.

To create an RTCRtpTransceiver with an {{RTCRtpReceiver}} object, receiver , {{RTCRtpSender}} object, sender , and set an {{RTCRtpTransceiverDirection}} value, direction , run the SDPAgent state following steps:

  1. Let transceiver be a new {{RTCRtpTransceiver}} object.

  2. Let transceiver have a [[\Sender]] internal slot, initialized to SDPIDLE. sender .

  3. Let transceiver have a [[\Receiver]] internal slot, initialized to receiver .

  4. Let transceiver have a [[\Stopping]] internal slot, initialized to false .

  5. Let transceiver have a [[\Stopped]] internal slot, initialized to false .

  6. Let transceiver have a [[\Direction]] internal slot, initialized to direction .

  7. Let transceiver have a [[\Receptive]] internal slot, initialized to false .

  8. Let transceiver have a [[\CurrentDirection]] internal slot, initialized to null .

  9. Let transceiver have a [[\FiredDirection]] internal slot, initialized to null .

  10. At the point the sdpState changes from NEW Let transceiver have a [[\PreferredCodecs]] internal slot, initialized to some other state, an empty list.

  11. Let transceiver have a [[\JsepMid]] internal slot, initialized to null . This is the readyState changes "RtpTransceiver mid property" defined in [[!RFC9429]] , and is only modified there.

  12. Let transceiver have a [[\Mid]] internal slot, initialized to NEGOTIATING. null .

  13. If Return transceiver .

Creating a transceiver does not create the ICE Agent finds underlying {{RTCDtlsTransport}} and {{RTCIceTransport}} objects. This will only occur as part of the process of [= set the session description | setting a candidates session description =].
[Exposed=Window]
interface RTCRtpTransceiver {
  readonly attribute DOMString? mid;
  [SameObject] readonly attribute RTCRtpSender sender;
  [SameObject] readonly attribute RTCRtpReceiver receiver;
  attribute RTCRtpTransceiverDirection direction;
  readonly attribute RTCRtpTransceiverDirection? currentDirection;
  undefined stop();
  undefined setCodecPreferences(sequence<RTCRtpCodec> codecs);
};

Attributes

mid of type DOMString , readonly, nullable

The {{mid}} attribute is the [= media stream "identification-tag" =] negotiated and present in the local and remote descriptions. On getting, the attribute MUST return the value of the {{RTCRtpTransceiver/[[Mid]]}} slot.

sender of type {{RTCRtpSender}} , readonly

The {{sender}} attribute exposes the {{RTCRtpSender}} corresponding to the RTP media that froms a valid connection, may be sent with mid = {{RTCRtpTransceiver/[[Mid]]}}. On getting, the ICE state attribute MUST return the value of the {{RTCRtpTransceiver/[[Sender]]}} slot.

receiver of type {{RTCRtpReceiver}} , readonly

The {{receiver}} attribute is changed the {{RTCRtpReceiver}} corresponding to ICECONNECTED the RTP media that may be received with mid = {{RTCRtpTransceiver/[[Mid]]}}. On getting the attribute MUST return the value of the {{RTCRtpTransceiver/[[Receiver]]}} slot.

direction of type {{RTCRtpTransceiverDirection}}

As defined in [[!RFC9429]] , the direction attribute indicates the preferred direction of this transceiver, which will be used in calls to {{RTCPeerConnection/createOffer}} and {{RTCPeerConnection/createAnswer}}. An update of directionality does not take effect immediately. Instead, future calls to {{RTCPeerConnection/createOffer}} and {{RTCPeerConnection/createAnswer}} mark the corresponding [= media description =] as sendrecv , sendonly , recvonly or inactive as defined in [[!RFC9429]]

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

  1. Let transceiver be the {{RTCRtpTransceiver}} object on which the getter is invoked.

  2. If transceiver .{{RTCRtpTransceiver/[[Stopping]]}} is true , return {{RTCRtpTransceiverDirection/"stopped"}}.

  3. Otherwise, return the ICE Agent finishes checking all candidates, if a value of the {{RTCRtpTransceiver/[[Direction]]}} slot.

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

  1. Let transceiver be the {{RTCRtpTransceiver}} object on which the setter is invoked.

  2. Let connection has been found, be the ice state {{RTCPeerConnection}} object associated with transceiver .

  3. If transceiver .{{RTCRtpTransceiver/[[Stopping]]}} is changed true , [= exception/throw =] an {{InvalidStateError}}.

  4. Let newDirection be the argument to ICECOMPLETED and if not connection has been found it the setter.

  5. If newDirection is changed equal to ICEFAILED. transceiver .{{RTCRtpTransceiver/[[Direction]]}}, abort these steps.

  6. If newDirection is equal to {{RTCRtpTransceiverDirection/"stopped"}}, [= exception/throw =] a {{TypeError}}.

  7. Set transceiver .{{RTCRtpTransceiver/[[Direction]]}} to newDirection .

  8. Update the negotiation-needed flag for connection .

currentDirection of type {{RTCRtpTransceiverDirection}} , readonly, nullable

As defined in [[!RFC9429]] , the currentDirection attribute indicates the current direction negotiated for this transceiver. The value of currentDirection is independent of the value of {{RTCRtpEncodingParameters}}.{{RTCRtpEncodingParameters/active}} since one cannot be deduced from the other. If this transceiver has never been represented in an offer/answer exchange, the iceState value is ICECONNECTED or ICECOMPLETED and null . If the SDP stat transceiver is SDPIDLE, {{stopped}}, the readyState value is set to ACTIVE. {{RTCRtpTransceiverDirection/"stopped"}}.

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

  1. Let transceiver be the {{RTCRtpTransceiver}} object on which the getter is invoked.

  2. If transceiver .{{RTCRtpTransceiver/[[Stopped]]}} is true , return {{RTCRtpTransceiverDirection/"stopped"}}.

  3. Otherwise, return the iceState value of the {{RTCRtpTransceiver/[[CurrentDirection]]}} slot.

Methods

stop

Irreversibly marks the transceiver as {{stopping}}, unless it is ICEFAILED, already {{stopped}}. This will immediately cause the transceiver's sender to no longer send, and its receiver to no longer receive. Calling {{stop()}} also [= update the negotiation-needed flag | updates the negotiation-needed flag =] for the {{RTCRtpTransceiver}}'s associated {{RTCPeerConnection}}.

A stopping transceiver will cause future calls to {{RTCPeerConnection/createOffer}} to generate a task is queued zero port in the [= media description =] for the corresponding transceiver, as defined in [[!RFC9429]] (The user agent MUST treat a {{stopping}} transceiver as {{stopped}} for the purposes of RFC9429 only in this case). However, to avoid problems with [[RFC8843]], a transceiver that is {{stopping}}, but not {{stopped}}, will not affect {{RTCPeerConnection/createAnswer}}.

A stopped transceiver will cause future calls to {{RTCPeerConnection/createOffer}} or {{RTCPeerConnection/createAnswer}} to generate a zero port in the close method. [= media description =] for the corresponding transceiver, as defined in [[!RFC9429]] .

The close method transceiver will remain in the {{stopping}} state, unless it becomes {{stopped}} by {{RTCPeerConnection/setRemoteDescription}} processing a rejected m-line in a remote offer or answer.

A transceiver that is {{stopping}} but not {{stopped}} will always need negotiation. In practice, this means that calling {{stop()}} on a transceiver will cause the system transceiver to wait until become {{stopped}} eventually, provided negotiation is allowed to complete on both ends.

When the sdpStat {{stop}} method is SDPIDLE then it will send invoked, the user agent MUST run the following steps:

  1. Let transceiver be the {{RTCRtpTransceiver}} object on which the method is invoked.

  2. Let connection be the {{RTCPeerConnection}} object associated with transceiver .

  3. If connection .{{RTCPeerConnection/[[IsClosed]]}} is true , [= exception/throw =] an SDP offer terminating all media {{InvalidStateError}}.

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

  5. [= Stop sending and change receiving =] with transceiver .

  6. Update the readyState negotiation-needed flag for connection .

The stop sending and receiving algorithm given a transceiver and, optionally, a disappear boolean defaulting to CLOSING false , is as well follows:

  1. Let sender be transceiver .{{RTCRtpTransceiver/[[Sender]]}}.

  2. Let receiver be transceiver .{{RTCRtpTransceiver/[[Receiver]]}}.

  3. Stop sending media with sender .

  4. Send an RTCP BYE for each RTP stream that was being sent by sender , as specified in [[!RFC3550]].

  5. Stop receiving media with receiver .

  6. If disappear is false , execute the steps for receiver .{{RTCRtpReceiver/[[ReceiverTrack]]}} to be ended . This fires an event.

  7. Set transceiver .{{RTCRtpTransceiver/[[Direction]]}} to {{RTCRtpTransceiverDirection/"inactive"}}.

  8. Set transceiver .{{RTCRtpTransceiver/[[Stopping]]}} to true .

The stop all ICE process the RTCRtpTransceiver algorithm given a transceiver and, optionally, a disappear boolean defaulting to false , is as follows:

  1. If transceiver .{{RTCRtpTransceiver/[[Stopping]]}} is false , [= stop sending and change receiving =] with transceiver and disappear .

  2. Set transceiver .{{RTCRtpTransceiver/[[Stopped]]}} to true .

  3. Set transceiver .{{RTCRtpTransceiver/[[Receptive]]}} to false .

  4. Set transceiver .{{RTCRtpTransceiver/[[CurrentDirection]]}} to null .

setCodecPreferences

The {{setCodecPreferences}} method overrides the iceState default receive codec preferences used by the user agent . When generating a session description using either {{RTCPeerConnection/createOffer}} or {{RTCPeerConnection/createAnswer}}, the user agent MUST use the indicated codecs, in the order specified in the codecs argument, for the media section corresponding to ICE_CLOSED. Once this {{RTCRtpTransceiver}}.

This method allows applications to disable the negotiation of specific codecs (including RTX/RED/FEC). It also allows an SDP anser application to cause a remote peer to prefer the codec that appears first in the list for sending.

Codec preferences remain in effect for all calls to {{RTCPeerConnection/createOffer}} and {{RTCPeerConnection/createAnswer}} that include this offer {{RTCRtpTransceiver}} until this method is received, called again. Setting codecs to an empty sequence resets codec preferences to any default value.

Codecs have their payload types listed under each m= section in the readyState SDP, defining the mapping between payload types and codecs. These payload types are referenced by the m=video or m=audio lines in the order of preference, and codecs that are not negotiated do not appear in this list as defined in section 5.2.1 of [[!RFC9429]]. A previously negotiated codec that is subsequently removed disappears from the m=video or m=audio line, and while its codec payload type is not to be reused in future offers or answers, its payload type may also be removed from the mapping of payload types in the SDP.

{{setCodecPreferences}} will reject attempts to set codecs [= codec dictionary match | not matching =] codecs found in {{RTCRtpReceiver}}.{{RTCRtpReceiver/getCapabilities}}( kind ), where kind is the kind of the {{RTCRtpTransceiver}} on which the method is called.

When {{setCodecPreferences()}} is invoked, the user agent MUST run the following steps:

  1. Let transceiver be changed the {{RTCRtpTransceiver}} object this method was invoked on.

  2. Let codecs be the first argument.

  3. If codecs is an empty list, set transceiver .{{RTCRtpTransceiver/[[PreferredCodecs]]}} to CLOSED. codecs and abort these steps.

  4. User agents may negotiate Remove any [= codec dictionary match | duplicate =] values in codecs , ensuring that the first occurrence of each value remains in place.

  5. Let kind be the transceiver 's [=RTCRtpTransceiver/transceiver kind=].

  6. Let codecCapabilities be {{RTCRtpReceiver}}.{{RTCRtpReceiver/getCapabilities}}( kind ).{{RTCRtpParameters/codecs}}.

  7. For each codec in codecs ,

    1. If codec does [= codec dictionary match | not match =] any codec in codecCapabilities , throw {{InvalidModificationError}}.

  8. If codecs only contains entries for RTX, RED, FEC or Comfort Noise or is an empty set, throw {{InvalidModificationError}}. This ensures that we always have something to offer, regardless of transceiver .{{RTCRtpTransceiver/direction}}.

  9. Set transceiver .{{RTCRtpTransceiver/[[PreferredCodecs]]}} to codecs .

The codec dictionary match algorithm given two {{RTCRtpCodec}} dictionaries first and second is as follows:

  1. If first .{{RTCRtpCodec/mimeType}} is different from second .{{RTCRtpCodec/mimeType}}, return false .

  2. If first .{{RTCRtpCodec/clockRate}} is different from second .{{RTCRtpCodec/clockRate}}, return false .

  3. If either (but not both) of first .{{RTCRtpCodec/channels}} and second .{{RTCRtpCodec/channels}} are [= map/exist | missing =], or if they both [= map/exist =] and first .{{RTCRtpCodec/channels}} is different from second .{{RTCRtpCodec/channels}}, return false .

  4. If either (but not both) of first .{{RTCRtpCodec/sdpFmtpLine}} and second .{{RTCRtpCodec/sdpFmtpLine}} are [= map/exist | missing =], or if they both [=map/exist=] and first .{{RTCRtpCodec/sdpFmtpLine}} is different from second .{{RTCRtpCodec/sdpFmtpLine}}, return false .

  5. Return true .

If set, the offerer's receive codec preferences will decide the order of the codecs in the offer. If the answerer does not have any resolution, bitrate, codec preferences then the same order will be used in the answer. However, if the answerer also has codec preferences, these preferences override the order in the answer. In this case, the offerer's preferences would affect which codecs were on offer but not the final order.

Simulcast functionality

Simulcast sending functionality is enabled by the {{RTCPeerConnection/addTransceiver}} method via its {{RTCRtpTransceiverInit/sendEncodings}} argument, or other quality metric. User agents the {{RTCPeerConnection/setRemoteDescription}} method with a remote offer to receive simulcast, which are encouraged both methods on the {{RTCPeerConnection}} object. Additionally, the {{RTCRtpSender/setParameters}} method on each {{RTCRtpSender}} object can be used to initially negotiate for inspect and modify the native resolution functionality.

An {{RTCRtpSender}}'s simulcast envelope is established in the first successful negotiation that involves it sending simulcast instead of unicast, and includes the stream. For maximum number of simulcast streams that can be sent, as well as the ordering of its {{RTCRtpSendParameters/encodings}}. This [= simulcast envelope =] may be narrowed (reducing the number of layers) in subsequent renegotiation, but cannot be reexpanded. Characteristics of individual simulcast streams can be modified using the {{RTCRtpSender/setParameters}} method, but the [= simulcast envelope =] itself cannot be changed by that method.

One way to configure simulcast is with the {{RTCRtpTransceiverInit/sendEncodings}} option to {{RTCPeerConnection/addTransceiver()}}. While the {{RTCPeerConnection/addTrack()}} method lacks the {{RTCRtpTransceiverInit/sendEncodings}} argument necessary to configure simulcast, senders can be promoted to simulcast when the user agent is the answerer. Upon calling the {{RTCPeerConnection/setRemoteDescription}} method with a remote offer to receive simulcast, a proposed envelope is configured on an {{RTCRtpSender}} to contain the layers described in the specified session description. As long as this description isn't rolled back, the [=proposed envelope=] becomes the {{RTCRtpSender}}'s [=simulcast envelope=] when negotiation completes. As above, this [=simulcast envelope=] may be narrowed in subsequent renegotiation, but not reexpanded.

While {{RTCRtpSender/setParameters}} cannot modify the [= simulcast envelope =], it is still possible to control the number of streams that are sent and the characteristics of those streams. Using {{RTCRtpSender/setParameters}}, simulcast streams can be made inactive by setting the {{RTCRtpEncodingParameters/active}} member to false , or can be reactivated by setting the {{RTCRtpEncodingParameters/active}} member to true . [[?RFC7728]] (RTP Pause/Resume) is not supported, nor is signaling of pause/resume via SDP Offer/Answer. Using {{RTCRtpSender/setParameters}}, stream characteristics can be changed by modifying attributes such as {{RTCRtpEncodingParameters/maxBitrate}}.

Simulcast is frequently used to send multiple encodings to an SFU, which will then rendered (using forward one of the simulcast streams to the end user. The user agent is therefore expected to allocate bandwidth between encodings in such a video element), way that all simulcast streams are usable on their own; for instance, if two simulcast streams have the same {{RTCRtpEncodingParameters/maxBitrate}}, one would expect to see a similar bitrate on both streams. If bandwidth does not permit all simulcast streams to be sent in an usable form, the user agents agent is expected to stop sending some of the simulcast streams.

As defined in [[!RFC9429]] , an offer from a user-agent will only contain a "send" description and no "recv" description on the a=simulcast line. Alternatives and restrictions (described in [[RFC8853]]) are encouraged not supported.

This specification does not define how to renegotiate for configure reception of multiple RTP encodings using {{RTCPeerConnection/createOffer}}, {{RTCPeerConnection/createAnswer}} or {{RTCPeerConnection/addTransceiver}}. However when {{RTCPeerConnection/setRemoteDescription}} is called with a resolution corresponding remote description that matches is able to send multiple RTP encodings as defined in [[!RFC9429]], and the rendered display size. browser supports receiving multiple RTP encodings, the {{RTCRtpReceiver}} may receive multiple RTP encodings and the parameters retrieved via the transceiver's {{RTCRtpTransceiver/receiver}}.{{RTCRtpReceiver/getParameters()}} will reflect the encodings negotiated.

Starting An {{RTCRtpReceiver}} can receive multiple RTP streams in a scenario where a Selective Forwarding Unit (SFU) switches between simulcast streams it receives from user agents. If the SFU does not rewrite RTP headers so as to arrange the switched streams into a single RTP stream prior to forwarding, the {{RTCRtpReceiver}} will receive packets from distinct RTP streams, each with their own SSRC and sequence number space. While the native resolution means that if SFU may only forward a single RTP stream at any given time, packets from multiple RTP streams can become intermingled at the Web application notifies its peer receiver due to reordering. An {{RTCRtpReceiver}} equipped to receive multiple RTP streams will therefore need to be able to correctly order the received packets, recognize potential loss events and react to them. Correct operation in this scenario is non-trivial and therefore is optional for implementations of this specification.

Encoding Parameter Examples

Examples of simulcast scenarios implemented with encoding parameters:


// Example of 3-layer spatial simulcast with all but the lowest resolution layer disabled
var encodings = [
  {rid: 'q', active: true, scaleResolutionDownBy: 4.0}
  {rid: 'h', active: false, scaleResolutionDownBy: 2.0},
  {rid: 'f', active: false},
];

"Hold" functionality

Together, the native resolution as it starts sending data, {{RTCRtpTransceiver/direction}} attribute and the {{RTCRtpSender/replaceTrack}} method enable developers to implement "hold" scenarios.

To send music to a peer prepares its video element accordingly, there and cease rendering received audio (music-on-hold):

async function playMusicOnHold() {
  try {
    // Assume we have an audio transceiver and a music track named musicTrack
    await audio.sender.replaceTrack(musicTrack);
    // Mute received audio
    audio.receiver.track.enabled = false;
    // Set the direction to send-only (requires negotiation)
    audio.direction = 'sendonly';
  } catch (err) {
    console.error(err);
  }
}

To respond to a remote peer's "sendonly" offer:

async function handleSendonlyOffer() {
  try {
    // Apply the sendonly offer first,
    // to ensure the receiver is ready for ICE candidates.
    await pc.setRemoteDescription(sendonlyOffer);
    // Stop sending audio
    await audio.sender.replaceTrack(null);
    // Align our direction to avoid further negotiation
    audio.direction = 'recvonly';
    // Call createAnswer and send a recvonly answer
    await doAnswer();
  } catch (err) {
    // handle signaling error
  }
}

To stop sending music and send audio captured from a microphone, as well to render received audio:

async function stopOnHoldMusic() {
  // Assume we have an audio transceiver and a microphone track named micTrack
  await audio.sender.replaceTrack(micTrack);
  // Unmute received audio
  audio.receiver.track.enabled = true;
  // Set the direction to sendrecv (requires negotiation)
  audio.direction = 'sendrecv';
}

To respond to being taken off hold by a remote peer:

async function onOffHold() {
  try {
    // Apply the sendrecv offer first, to ensure receiver is ready for ICE candidates.
    await pc.setRemoteDescription(sendrecvOffer);
    // Start sending audio
    await audio.sender.replaceTrack(micTrack);
    // Set the direction sendrecv (just in time for the answer)
    audio.direction = 'sendrecv';
    // Call createAnswer and send a sendrecv answer
    await doAnswer();
  } catch (err) {
    // handle signaling error
  }
}

RTCDtlsTransport Interface

The {{RTCDtlsTransport}} interface allows an application access to information about the Datagram Transport Layer Security (DTLS) transport over which RTP and RTCP packets are sent and received by {{RTCRtpSender}} and {{RTCRtpReceiver}} objects, as well other data such as SCTP packets sent and received by data channels. In particular, DTLS adds security to an underlying transport, and the {{RTCDtlsTransport}} interface allows access to information about the underlying transport and the security added. {{RTCDtlsTransport}} objects are constructed as a result of calls to {{RTCPeerConnection/setLocalDescription()}} and {{RTCPeerConnection/setRemoteDescription()}}. Each {{RTCDtlsTransport}} object represents the DTLS transport layer for the RTP or RTCP {{RTCIceTransport/component}} of a specific {{RTCRtpTransceiver}}, or a group of {{RTCRtpTransceiver}}s if such a group has been negotiated via [[RFC8843]].

A new DTLS association for an existing {{RTCRtpTransceiver}} will be no need for represented by an existing {{RTCDtlsTransport}} object, whose {{RTCDtlsTransport/state}} will be updated accordingly, as opposed to being represented by a renegotiation once new object.

An {{RTCDtlsTransport}} has a [[\DtlsTransportState]] internal slot initialized to {{RTCDtlsTransportState/"new"}} and a [[\RemoteCertificates]] slot initialized to an empty list.

When the stream underlying DTLS transport experiences an error, such as a certificate validation failure, or a fatal alert (see [[RFC5246]] section 7.2), the user agent MUST queue a task that runs the following steps:

  1. Let transport be the {{RTCDtlsTransport}} object to receive the state update and error notification.

  2. If the state of transport is flowing. already {{RTCDtlsTransportState/"failed"}}, abort these steps.

  3. All SDP media descriptions Set transport .{{RTCDtlsTransport/[[DtlsTransportState]]}} to {{RTCDtlsTransportState/"failed"}}.

  4. [= Fire an event =] named {{RTCDtlsTransport/error}} using the {{RTCErrorEvent}} interface with its errorDetail attribute set to either {{RTCErrorDetailType/"dtls-failure"}} or {{RTCErrorDetailType/"fingerprint-failure"}}, as appropriate, and other fields set as described under the {{RTCErrorDetailType}} enum description, at transport .

  5. [= Fire an event =] named {{RTCDtlsTransport/statechange}} at transport .

When the underlying DTLS transport needs to update the state of the corresponding {{RTCDtlsTransport}} object for streams represented by MediaStream objects must include any other reason, the user agent MUST queue a label task that runs the following steps:

  1. Let transport be the {{RTCDtlsTransport}} object to receive the state update.

  2. Let newState be the new state.

  3. Set transport .{{RTCDtlsTransport/[[DtlsTransportState]]}} to newState .

  4. If newState is {{RTCDtlsTransportState/connected}} then let newRemoteCertificates be the certificate chain in use by the remote side, with each certificate encoded in binary Distinguished Encoding Rules (DER) [[!X690]], and set transport .{{RTCDtlsTransport/[[RemoteCertificates]]}} to newRemoteCertificates .

  5. [= Fire an event =] named {{RTCDtlsTransport/statechange}} at transport .

[Exposed=Window]
interface RTCDtlsTransport : EventTarget {
  [SameObject] readonly attribute RTCIceTransport iceTransport;
  readonly attribute RTCDtlsTransportState state;
  sequence<ArrayBuffer> getRemoteCertificates();
  attribute EventHandler onstatechange;
  attribute EventHandler onerror;
};

Attributes

iceTransport of type {{RTCIceTransport}} , readonly

The {{iceTransport}} attribute (" a=label: ") whose value is the underlying transport that is used to send and receive packets. The underlying transport may not be shared between multiple active {{RTCDtlsTransport}} objects.

state of type {{RTCDtlsTransportState}} , readonly

The {{state}} attribute MUST, on getting, return the value of the MediaStream object's label attribute. [SDP] [SDPLABEL] {{RTCDtlsTransport/[[DtlsTransportState]]}} slot.

onstatechange of type EventHandler
The event type of this event handler is {{RTCDtlsTransport/statechange}}.
onerror of type EventHandler
The event type of this event handler is {{RTCDtlsTransport/error}}.

Methods

getRemoteCertificates

PeerConnection s must not generate any candidates for media streams whose media descriptions do Returns the value of {{RTCDtlsTransport/[[RemoteCertificates]]}}.

RTCDtlsTransportState Enum

enum RTCDtlsTransportState {
  "new",
  "connecting",
  "connected",
  "closed",
  "failed"
};
{{RTCDtlsTransportState}} Enumeration description
Enum value Description
new DTLS has not have started negotiating yet.
connecting DTLS is in the process of negotiating a label attribute (" a=label: "). [ICE] [SDP] [SDPLABEL] secure connection and verifying the remote fingerprint.
connected DTLS has completed negotiation of a secure connection and verified the remote fingerprint.
closed The transport has been closed intentionally as the result of receipt of a close_notify alert, or calling {{RTCPeerConnection/close()}}.
failed The transport has failed as the result of an error (such as receipt of an error alert or failure to validate the remote fingerprint).

RTCDtlsFingerprint Dictionary

The {{RTCDtlsFingerprint}} dictionary includes the hash function algorithm and certificate fingerprint as described in [[!RFC4572]].

dictionary RTCDtlsFingerprint {
  DOMString algorithm;
  DOMString value;
};

Dictionary RTCDtlsFingerprint Members

algorithm of type DOMString

When One of the the hash function algorithms defined in the 'Hash function Textual Names' registry [[!IANA-HASH-FUNCTION]].

value of type DOMString

The value of the certificate fingerprint in lowercase hex string as expressed utilizing the syntax of 'fingerprint' in [[!RFC4572]] Section 5.

RTCIceTransport Interface

The {{RTCIceTransport}} interface allows an application access to information about the ICE transport over which packets are sent and received. In particular, ICE manages peer-to-peer connections which involve state which the application may want to access. {{RTCIceTransport}} objects are constructed as a result of calls to {{RTCPeerConnection/setLocalDescription()}} and {{RTCPeerConnection/setRemoteDescription()}}. The underlying ICE state is managed by the ICE agent ; as such, the state of an {{RTCIceTransport}} changes when the [= ICE Agent =] provides indications to the user agent starts receiving media as described below. Each {{RTCIceTransport}} object represents the ICE transport layer for the RTP or RTCP {{RTCIceTransport/component}} of a component and specific {{RTCRtpTransceiver}}, or a candidate was provided group of {{RTCRtpTransceiver}}s if such a group has been negotiated via [[RFC8843]].

An ICE restart for that component an existing {{RTCRtpTransceiver}} will be represented by an existing {{RTCIceTransport}} object, whose {{RTCIceTransport/state}} will be updated accordingly, as opposed to being represented by a PeerConnection , new object.

When the [= ICE Agent =] indicates that it began gathering a [= generation =] of candidates for an {{RTCIceTransport}} transport associated with an {{RTCPeerConnection}} connection , the user agent must follow these MUST queue a task that runs the following steps:

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

  2. Set transport .{{RTCIceTransport/[[IceGathererState]]}} to {{RTCIceGathererState/gathering}}.

  3. Set connection .{{RTCPeerConnection/[[IceGatheringState]]}} to the value of deriving a new state value as described by the {{RTCIceGatheringState}} enum.

  4. Let connectionIceGatheringStateChanged be the PeerConnection true expecting if connection .{{RTCPeerConnection/[[IceGatheringState]]}} changed in the previous step, otherwise false .

  5. Do not read or modify state beyond this media. point.

  6. [= Fire an event =] named {{RTCIceTransport/gatheringstatechange}} at transport .

  7. If there connectionIceGatheringStateChanged is already a MediaStream object true , [= fire an event =] named {{RTCPeerConnection/icegatheringstatechange}} at connection .

When the [= ICE Agent =] is finished gathering a [= generation =] of candidates for an {{RTCIceTransport}} transport associated with an {{RTCPeerConnection}} connection , and those candidates have been surfaced to the media stream application, the user agent MUST queue a task to which this component belongs, then associate run the component with that media stream and following steps:

  1. If connection .{{RTCPeerConnection/[[IsClosed]]}} is true , abort these steps. (Some media streams have multiple components; this API does

  2. If connection .{{RTCPeerConnection/[[PendingLocalDescription]]}} is not expose null , and represents the role of these individual components in ICE.) ICE [= generation =] for which gathering finished, add `a=end-of-candidates` to connection .{{RTCPeerConnection/[[PendingLocalDescription]]}}.sdp.

  3. Create a If connection .{{RTCPeerConnection/[[CurrentLocalDescription]]}} is not MediaStream object null , and represents the ICE [= generation =] for which gathering finished, add `a=end-of-candidates` to represent connection .{{RTCPeerConnection/[[CurrentLocalDescription]]}}.sdp.

  4. Let endOfGatheringCandidate be the media stream. Set its label attribute result of [= creating an RTCIceCandidate =] with a new dictionary whose {{RTCIceCandidateInit/sdpMid}} and {{RTCIceCandidateInit/sdpMLineIndex}} are set to the value values associated with this {{RTCIceTransport}}, {{RTCIceCandidateInit/usernameFragment}} is set to the username fragment of the SDP Label attribute [= generation =] of candidates for that component's media stream. which gathering finished, and {{RTCIceCandidateInit/candidate}} is set to `""`.

  5. Queue [= Fire an event =] named {{RTCPeerConnection/icecandidate}} using the {{RTCPeerConnectionIceEvent}} interface with the candidate attribute set to endOfGatheringCandidate at connection .

When the [= ICE Agent =] has queued the above task, and no other [= generation | generations =] of candidates is being gathered, the user agent MUST also queue a second task to run the following substeps: steps:

Other [= generation | generations =] of candidates might still be gathering if an ICE restart was initiated while the ICE agent is still gathering the previous [= generation =] of candidates.
  1. If the connection 's PeerConnection readiness state .{{RTCPeerConnection/[[IsClosed]]}} is CLOSED (3), true , abort these steps.

  2. Add the newly created MediaStream object Set transport .{{RTCIceTransport/[[IceGathererState]]}} to {{RTCIceGathererState/complete}}.

  3. Set connection .{{RTCPeerConnection/[[IceGatheringState]]}} to the end value of connection deriving a new state value as described by the {{RTCIceGatheringState}} enum.

  4. Let connectionIceGatheringStateChanged 's remoteStreams be true array. if connection .{{RTCPeerConnection/[[IceGatheringState]]}} changed in the previous step, otherwise false .

  5. Do not read or modify state beyond this point.

  6. [= Fire a stream an event =] named addstream {{RTCIceTransport/gatheringstatechange}} at transport .

  7. If connectionIceGatheringStateChanged is true , [= fire an event =] named {{RTCPeerConnection/icegatheringstatechange}} at connection .

  8. [= Fire an event =] named {{RTCPeerConnection/icecandidate}} using the {{RTCPeerConnectionIceEvent}} interface with the newly created candidate attribute set to MediaStream null object at the connection object. .

    The null candidate event is fired to ensure legacy compatibility. New code should monitor the gathering state of {{RTCIceTransport}} and/or {{RTCPeerConnection}}.

When a PeerConnection finds the [= ICE Agent =] indicates that a stream new ICE candidate is available for an {{RTCIceTransport}}, either by taking one from the remote peer has been removed (its port has been set to zero in a media description sent on the signaling channel), [= ICE candidate pool size | ICE candidate pool =] or gathering it from scratch, the user agent must follow these MUST queue a task that runs the following steps:

  1. Let connection candidate be the PeerConnection associated with the stream being removed. available ICE candidate.

  2. Let stream connection be the MediaStream {{RTCPeerConnection}} object that represents the media stream being removed, if any. associated with this [= ICE Agent =].

  3. If there isn't one, then connection .{{RTCPeerConnection/[[IsClosed]]}} is true , abort these steps.

  4. By definition, stream If either connection .{{RTCPeerConnection/[[PendingLocalDescription]]}} or connection .{{RTCPeerConnection/[[CurrentLocalDescription]]}} are not null , and represent the ICE [= generation =] for which candidate is now finished . was gathered, [= surface the candidate =] with candidate and connection , and abort these steps.

    A
  5. Otherwise, append candidate to connection .{{RTCPeerConnection/[[EarlyCandidates]]}}.

When the [= ICE Agent =] signals that the ICE role has changed due to an ICE binding request with a role collision per [[RFC8445]] section 7.3.1.1, the UA will queue a task is thus queued to update stream set the value of {{RTCIceTransport/[[IceRole]]}} to the new value.

To release early candidates of a connection , run the following steps:

  1. For each candidate, candidate , in connection .{{RTCPeerConnection/[[EarlyCandidates]]}}, queue a task to [= surface the candidate =] with candidate and fire an event. connection .

  2. Queue a task Set connection .{{RTCPeerConnection/[[EarlyCandidates]]}} to an empty list.

To surface a candidate with candidate and connection , run the following substeps: steps:

  1. If the connection 's PeerConnection readiness state .{{RTCPeerConnection/[[IsClosed]]}} is CLOSED (3), true , abort these steps.

  2. Let transport be the {{RTCIceTransport}} for which candidate is being made available.

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

  4. Remove stream If connection .{{RTCPeerConnection/[[CurrentLocalDescription]]}} is not null , and represents the ICE [= generation =] for which candidate from was gathered, add candidate to connection .{{RTCPeerConnection/[[CurrentLocalDescription]]}}.sdp.

  5. Let newCandidate 's remoteStreams array. be the result of [= creating an RTCIceCandidate =] with a new dictionary whose {{RTCIceCandidateInit/sdpMid}} and {{RTCIceCandidateInit/sdpMLineIndex}} are set to the values associated with this {{RTCIceTransport}}, {{RTCIceCandidateInit/usernameFragment}} is set to the username fragment of the candidate, and {{RTCIceCandidateInit/candidate}} is set to a string encoded using the [= candidate-attribute =] grammar to represent candidate .

  6. Add newCandidate to transport 's set of local candidates.

  7. [= Fire a stream an event =] named removestream {{RTCPeerConnection/icecandidate}} using the {{RTCPeerConnectionIceEvent}} interface with stream the candidate attribute set to newCandidate at the connection object. .

The task source for {{RTCIceTransportState}} of an {{RTCIceTransport}} may change because a candidate pair with a usable connection was found and selected or it may change without the tasks listed selected candidate pair changing. The selected pair and {{RTCIceTransportState}} are related and are handled in the same task.

When the [= ICE Agent =] indicates that an {{RTCIceTransport}} has changed either the selected candidate pair, the {{RTCIceTransportState}} or both, the user agent MUST queue a task that runs the steps to change the selected candidate pair and state :

  1. Let connection be the {{RTCPeerConnection}} object associated with this section [= ICE Agent =].

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

  3. Let transport be the networking task source. {{RTCIceTransport}} whose state is changing.

    To prevent network sniffing from allowing
  4. Let selectedCandidatePairChanged be false .

  5. Let transportIceConnectionStateChanged be false .

  6. Let connectionIceConnectionStateChanged be false .

  7. Let connectionStateChanged be false .

  8. If transport 's selected candidate pair was changed, run the following steps:

    1. Let newCandidatePair be a fourth party newly created {{RTCIceCandidatePair}} representing the indicated pair if one is selected, and null otherwise.

    2. Set transport .{{RTCIceTransport/[[SelectedCandidatePair]]}} to establish a newCandidatePair .

    3. Set selectedCandidatePairChanged to true .

  9. If transport 's {{RTCIceTransportState}} was changed, run the following steps:

    1. Set transport .{{RTCIceTransport/[[IceTransportState]]}} to the new indicated {{RTCIceTransportState}}.

    2. Set transportIceConnectionStateChanged to true .

    3. Set connection .{{RTCPeerConnection/[[IceConnectionState]]}} to the value of deriving a peer using new state value as described by the information sent out-of-band {{RTCIceConnectionState}} enum.

    4. If connection .{{RTCPeerConnection/[[IceConnectionState]]}} changed in the previous step, set connectionIceConnectionStateChanged to true .

    5. Set connection .{{RTCPeerConnection/[[ConnectionState]]}} to the other peer and thus spoofing value of deriving a new state value as described by the client, {{RTCPeerConnectionState}} enum.

    6. If connection .{{RTCPeerConnection/[[ConnectionState]]}} changed in the configuration information should always be transmitted using previous step, set connectionStateChanged to true .

  10. If selectedCandidatePairChanged is true , [= fire an encrypted connection. event =] named {{RTCIceTransport/selectedcandidatepairchange}} at transport .

    4.1 PeerConnection ] interface { }; 4.1.1 Attributes
  11. If transportIceConnectionStateChanged is iceState true , [= fire an event =] named {{RTCIceTransport/statechange}} at transport .

  12. If connectionIceConnectionStateChanged is true , [= fire an event =] named {{RTCPeerConnection/iceconnectionstatechange}} at connection .

  13. If connectionStateChanged is true , [= fire an event =] named {{RTCPeerConnection/connectionstatechange}} at connection .

An {{RTCIceTransport}} object has the following internal slots:

[Exposed=Window]
interface RTCIceTransport : EventTarget {
  readonly attribute RTCIceRole role;
  readonly attribute RTCIceComponent component;
  readonly attribute RTCIceTransportState state;
  readonly attribute RTCIceGathererState gatheringState;
  sequence<RTCIceCandidate> getLocalCandidates();
  sequence<RTCIceCandidate> getRemoteCandidates();
  RTCIceCandidatePair? getSelectedCandidatePair();
  RTCIceParameters? getLocalParameters();
  RTCIceParameters? getRemoteParameters();
  attribute EventHandler onstatechange;
  attribute EventHandler ongatheringstatechange;
  attribute EventHandler onselectedcandidatepairchange;
};

Attributes

role of type unsigned short {{RTCIceRole}} , readonly

The iceState {{role}} attribute MUST, on getting, return the value of the [[\IceRole]] internal slot.

component of type {{RTCIceComponent}} , readonly

The {{component}} attribute must MUST return the ICE component of the transport. When RTCP mux is used, a single {{RTCIceTransport}} transports both RTP and RTCP and {{component}} is set to {{RTCIceComponent/"rtp"}}.

state of type {{RTCIceTransportState}} , readonly

The {{state}} attribute MUST, on getting, return the value of the {{RTCIceTransport/[[IceTransportState]]}} slot.

gatheringState of type {{RTCIceGathererState}} , readonly

The {{gatheringState}} attribute MUST, on getting, return the value of the {{RTCIceTransport/[[IceGathererState]]}} slot.

onstatechange of type EventHandler
This event handler, of event handler event type {{statechange}}, MUST be fired any time the {{RTCIceTransport}} {{RTCIceTransport/state}} changes.
ongatheringstatechange of type EventHandler
This event handler, of event handler event type {{gatheringstatechange}}, MUST be fired any time the {{RTCIceTransport}}'s {{RTCIceTransport/[[IceGathererState]]}} changes.
onselectedcandidatepairchange of type EventHandler
This event handler, of event handler event type {{RTCIceTransport/selectedcandidatepairchange}}, MUST be fired any time the {{RTCIceTransport}}'s selected candidate pair changes.

Methods

getLocalCandidates

Returns a sequence describing the local ICE candidates gathered for this {{RTCIceTransport}} and sent in {{RTCPeerConnection/onicecandidate}}.

getRemoteCandidates

Returns a sequence describing the remote ICE candidates received by this {{RTCIceTransport}} via {{RTCPeerConnection/addIceCandidate()}}.

{{getRemoteCandidates}} will not expose peer reflexive candidates since they are not received via {{RTCPeerConnection/addIceCandidate()}}.
getSelectedCandidatePair

Returns the selected candidate pair on which packets are sent. This method MUST return the value of the {{RTCIceTransport/[[SelectedCandidatePair]]}} slot. When {{RTCIceTransport}}.{{RTCIceTransport/state}} is {{RTCIceTransportState/"new"}} or {{RTCIceTransportState/"closed"}} {{getSelectedCandidatePair}} returns PeerConnection null .

getLocalParameters

Returns the local ICE Agent parameters received by this {{RTCIceTransport}} via {{RTCPeerConnection/setLocalDescription}}, or PeerConnection null if the parameters have not yet been received.

getRemoteParameters

Returns the remote ICE state , represented parameters received by a number from this {{RTCIceTransport}} via {{RTCPeerConnection/setRemoteDescription}} or null if the following list: parameters have not yet been received.

RTCIceParameters Dictionary

dictionary RTCIceParameters {
  DOMString usernameFragment;
  DOMString password;
};

Dictionary {{RTCIceParameters}} Members

PeerConnection . NEW (0) usernameFragment of type DOMString

The object was just created, and no networking has yet occurred. ICE username fragment as defined in [[RFC5245]], Section 7.1.2.3.

PeerConnection . ICE_GATHERING (0x100) password of type DOMString

The ICE Agent is attempting to establish a gather addresses. password as defined in [[RFC5245]], Section 7.1.2.3.

RTCIceCandidatePair Dictionary

dictionary RTCIceCandidatePair {
  required RTCIceCandidate local;
  required RTCIceCandidate remote;
};

Dictionary {{RTCIceCandidatePair}} Members

PeerConnection . ICE_WAITING (0x200) local of type {{RTCIceCandidate}}

The local ICE Agent is waiting for candidates from the other side before it can start checking. candidate.

PeerConnection . ICE_CHECKING (0x300) remote of type {{RTCIceCandidate}}

The remote ICE Agent candidate.

RTCIceGathererState Enum

enum RTCIceGathererState {
  "new",
  "gathering",
  "complete"
};
{{RTCIceGathererState}} Enumeration description
Enum value Description
new The {{RTCIceTransport}} was just created, and has not started gathering candidates yet.
gathering The {{RTCIceTransport}} is in the process of gathering candidates.
complete The {{RTCIceTransport}} has completed gathering and the end-of-candidates indication for this transport has been sent. It will not gather candidates again until an ICE restart causes it to restart.

RTCIceTransportState Enum

enum RTCIceTransportState {
  "closed",
  "failed",
  "disconnected",
  "new",
  "checking",
  "completed",
  "connected"
};
{{RTCIceTransportState}} Enumeration description
Enum value Description
closed The {{RTCIceTransport}} has shut down and is no longer responding to STUN requests.
failed
The {{RTCIceTransport}} has finished gathering, received an indication that there are no more remote candidates, finished checking all candidate pairs, and all pairs have either failed connectivity checks or lost consent, and either zero local candidates but were gathered or the PAC timer has not yet found expired [[RFC8863]]. This is a connection. PeerConnection . ICE_CONNECTED (0x400) terminal state until ICE is restarted. Since an ICE restart may cause connectivity to resume, entering the {{RTCIceTransportState/"failed"}} state does not cause DTLS transports, SCTP associations or the data channels that run over them to close, or tracks to mute.
disconnected The [= ICE Agent =] has determined that connectivity is currently lost for this {{RTCIceTransport}}. This is a transient state that may trigger intermittently (and resolve itself without action) on a flaky network. The way this state is determined is implementation dependent. Examples include:
  • Losing the network interface for the connection in use.
  • Repeatedly failing to receive a response to STUN requests.
Alternatively, the {{RTCIceTransport}} has finished checking all existing candidates pairs and not found a connection (or consent checks [[!RFC7675]] once successful, have now failed), but it is still checking other gathering and/or waiting for additional remote candidates.
new The {{RTCIceTransport}} is gathering candidates and/or waiting for remote candidates to see if there be supplied, and has not yet started checking.
checking The {{RTCIceTransport}} has received at least one remote candidate (by means of {{RTCPeerConnection/addIceCandidate()}} or discovered as a peer-reflexive candidate when receiving a STUN binding request) and is checking candidate pairs and has either not yet found a better connection. PeerConnection . ICE_COMPLETED (0x500) connection or consent checks [[!RFC7675]] have failed on all previously successful candidate pairs. In addition to checking, it may also still be gathering.
completed The ICE Agent {{RTCIceTransport}} has finished gathering, received an indication that there are no more remote candidates, finished checking all candidate pairs and found a connection. PeerConnection . ICE_FAILED (0x600) If consent checks [[!RFC7675]] subsequently fail on all successful candidate pairs, the state transitions to {{RTCIceTransportState/"failed"}}.
connected The ICE Agent {{RTCIceTransport}} has found a usable connection, but is finished still checking all candidates and failed other candidate pairs to find see if there is a better connection. PeerConnection . ICE_CLOSED (0x700) The ICE Agent has shut down It may also still be gathering and/or waiting for additional remote candidates. If consent checks [[!RFC7675]] fail on the connection in use, and is there are no longer responding other successful candidate pairs available, then the state transitions to STUN requests. No exceptions. {{RTCIceTransportState/"checking"}} (if there are candidate pairs remaining to be checked) or {{RTCIceTransportState/"disconnected"}} (if there are no candidate pairs to check, but the peer is still gathering and/or waiting for additional remote candidates).
localStreams of type array of MediaStream , readonly Returns

The most common transitions for a live array containing successful call will be new -> checking -> connected -> completed, but under specific circumstances (only the streams that last checked candidate succeeds, and gathering and the user agent is currently attempting to transmit no-more candidates indication both occur prior to success), the remote peer (those that were added with addStream() ). state can transition directly from {{RTCIceTransportState/"checking"}} to {{RTCIceTransportState/"completed"}}.

Specifically, it must return An ICE restart causes candidate gathering and connectivity checks to begin anew, causing a transition to {{RTCIceTransportState/"connected"}} if begun in the read-only MediaStream array that {{RTCIceTransportState/"completed"}} state. If begun in the attribute transient {{RTCIceTransportState/"disconnected"}} state, it causes a transition to {{RTCIceTransportState/"checking"}}, effectively forgetting that connectivity was previously lost.

The {{RTCIceTransportState/"failed"}} and {{RTCIceTransportState/"completed"}} states require an indication that there are no additional remote candidates. This can be indicated by calling {{RTCPeerConnection/addIceCandidate}} with a candidate value whose {{RTCIceCandidate/candidate}} property is set to an empty string or by {{RTCPeerConnection/canTrickleIceCandidates}} being set to when the PeerConnection 's constructor ran. false .

Some example state transitions are:

  • ({{RTCIceTransport}} first created, as a result of {{RTCPeerConnection/setLocalDescription}} or {{RTCPeerConnection/setRemoteDescription}}): {{RTCIceTransportState/"new"}}
  • ({{RTCIceTransportState/"new"}}, remote candidates received): {{RTCIceTransportState/"checking"}}
  • ({{RTCIceTransportState/"checking"}}, found usable connection): {{RTCIceTransportState/"connected"}}
  • ({{RTCIceTransportState/"checking"}}, checks fail but gathering still in progress): {{RTCIceTransportState/"disconnected"}}
  • ({{RTCIceTransportState/"checking"}}, gave up): {{RTCIceTransportState/"failed"}}
  • ({{RTCIceTransportState/"disconnected"}}, new local candidates): {{RTCIceTransportState/"checking"}}
  • ({{RTCIceTransportState/"connected"}}, finished all checks): {{RTCIceTransportState/"completed"}}
  • ({{RTCIceTransportState/"completed"}}, lost connectivity): {{RTCIceTransportState/"disconnected"}}
  • ({{RTCIceTransportState/"disconnected"}} or {{RTCIceTransportState/"failed"}}, ICE restart occurs): {{RTCIceTransportState/"checking"}}
  • ({{RTCIceTransportState/"completed"}}, ICE restart occurs): {{RTCIceTransportState/"connected"}}
  • {{RTCPeerConnection}}.{{RTCPeerConnection/close()}}: {{RTCIceTransportState/"closed"}}
ICE transport state transition diagram
Non-normative ICE transport state transition diagram

RTCIceRole Enum

No exceptions.
enum RTCIceRole {
  "unknown",
  "controlling",
  "controlled"
};
{{RTCIceRole}} Enumeration description
Enum value Description
unknown An agent whose role as defined by [[RFC5245]], Section 3, has not yet been determined.
controlling A controlling agent as defined by [[RFC5245]], Section 3.
controlled A controlled agent as defined by [[RFC5245]], Section 3.

RTCIceComponent Enum

enum RTCIceComponent {
  "rtp",
  "rtcp"
};
{{RTCIceComponent}} Enumeration description
Enum value Description
rtp The ICE Transport is used for RTP (or RTCP multiplexing), as defined in [[RFC5245]], Section 4.1.1.1. Protocols multiplexed with RTP (e.g. data channel) share its component ID. This represents the component-id value onaddstream 1 of type Function , nullable This event handler, of event handler event type addstream , must be supported when encoded in [= candidate-attribute =].
rtcp The ICE Transport is used for RTCP as defined by all objects implementing [[RFC5245]], Section 4.1.1.1. This represents the component-id value PeerConnection 2 when encoded in [= candidate-attribute =].

RTCTrackEvent

The {{RTCPeerConnection/track}} event uses the {{RTCTrackEvent}} interface.

[Exposed=Window]
interface RTCTrackEvent : Event {
  constructor(DOMString type, RTCTrackEventInit eventInitDict);
  readonly attribute RTCRtpReceiver receiver;
  readonly attribute MediaStreamTrack track;
  [SameObject] readonly attribute FrozenArray<MediaStream> streams;
  readonly attribute RTCRtpTransceiver transceiver;
};

Constructors

RTCTrackEvent.constructor()
No exceptions. onconnecting

Attributes

receiver of type Function {{RTCRtpReceiver}} , nullable readonly
This event handler,

The {{receiver}} attribute represents the {{RTCRtpReceiver}} object associated with the event.

track of event handler event type connecting , must be supported by all objects implementing {{MediaStreamTrack}} , readonly

The {{track}} attribute represents the PeerConnection interface. No exceptions. onopen {{MediaStreamTrack}} object that is associated with the {{RTCRtpReceiver}} identified by {{receiver}}.

streams of type Function FrozenArray<{{MediaStream}}> , nullable readonly
This event handler,

The {{streams}} attribute returns an array of event handler event type open , must be supported by all {{MediaStream}} objects implementing representing the PeerConnection interface. No exceptions. onremovestream {{MediaStream}}s that this event's {{track}} is a part of.

transceiver of type Function {{RTCRtpTransceiver}} , nullable readonly
This event handler, of event handler event type removestream , must be supported by all objects implementing

The {{transceiver}} attribute represents the PeerConnection interface. No exceptions. {{RTCRtpTransceiver}} object associated with the event.

onstatechange
dictionary RTCTrackEventInit : EventInit {
  required RTCRtpReceiver receiver;
  required MediaStreamTrack track;
  sequence<MediaStream> streams = [];
  required RTCRtpTransceiver transceiver;
};

Dictionary RTCTrackEventInit Members

receiver of type Function {{RTCRtpReceiver}} , nullable required
This event handler,

The {{receiver}} member represents the {{RTCRtpReceiver}} object associated with the event.

track of event handler event type open , must be supported by all objects implementing {{MediaStreamTrack}} , required

The {{track}} member represents the PeerConnection interface. It {{MediaStreamTrack}} object that is called any time associated with the readyState, iceState, or sdpState changes. No exceptions. {{RTCRtpReceiver}} identified by {{RTCTrackEventInit/receiver}}.

streams of type sequence<{{MediaStream}}> , defaulting to readyState []

The {{streams}} member is an array of {{MediaStream}} objects representing the {{MediaStream}}s that this event's {{track}} is a part of.

transceiver of type unsigned short {{RTCRtpTransceiver}} , readonly required

The readyState {{transceiver}} attribute must return represents the PeerConnection object's PeerConnection readiness state , represented by {{RTCRtpTransceiver}} object associated with the event.

Peer-to-peer Data API

The Peer-to-peer Data API lets a number from web application send and receive generic application data peer-to-peer. The API for sending and receiving data models the following list: behavior of Web Sockets .

PeerConnection . NEW (0)

RTCPeerConnection Interface Extensions

The Peer-to-peer data API extends the {{RTCPeerConnection}} interface as described below.

          partial interface RTCPeerConnection {
  readonly attribute RTCSctpTransport? sctp;
  RTCDataChannel createDataChannel(USVString label,
                                   optional RTCDataChannelInit dataChannelDict = {});
  attribute EventHandler ondatachannel;
};

Attributes

sctp of type {{RTCSctpTransport}} , readonly, nullable

The object was just created, SCTP transport over which SCTP data is sent and no networking received. If SCTP has yet occurred. not been negotiated, the value is null. This attribute MUST return the {{RTCSctpTransport}} object stored in the {{RTCPeerConnection/[[SctpTransport]]}} internal slot.

PeerConnection . NEGOTIATING (1)
ondatachannel of type EventHandler
The user agent event type of this event handler is attempting to establish an connection with the ICE Agent and to negotiate codecs with the SDP Agent. {{RTCPeerConnection/datachannel}}.

Methods

PeerConnection . ACTIVE (2) createDataChannel
The ICE Agent has found

Creates a new {{RTCDataChannel}} object with the given label. The {{RTCDataChannelInit}} dictionary can be used to configure properties of the underlying channel such as data reliability.

When the {{createDataChannel}} method is invoked, the user agent MUST run the following steps.

  1. Let connection be the SDP Agent has performed {{RTCPeerConnection}} object on which the method is invoked.

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

  3. [= Create an RTCDataChannel =], channel .

  4. Initialize channel .{{RTCDataChannel/[[DataChannelLabel]]}} to the value of the first argument.

  5. If the UTF-8 representation of {{RTCDataChannel/[[DataChannelLabel]]}} is longer than 65535 bytes, [= exception/throw =] a round {{TypeError}}.

  6. Let options be the second argument.

  7. Initialize channel .{{RTCDataChannel/[[MaxPacketLifeTime]]}} to option .{{RTCDataChannelInit/maxPacketLifeTime}}, if present, otherwise null .

  8. Initialize channel .{{RTCDataChannel/[[MaxRetransmits]]}} to option .{{RTCDataChannelInit/maxRetransmits}}, if present, otherwise null .

  9. Initialize channel .{{RTCDataChannel/[[Ordered]]}} to option .{{RTCDataChannelInit/ordered}}.

  10. Initialize channel .{{RTCDataChannel/[[DataChannelProtocol]]}} to option .{{RTCDataChannelInit/protocol}}.

  11. If the UTF-8 representation of codec negotiation. It {{RTCDataChannel/[[DataChannelProtocol]]}} is possible for whatever media was negotiated longer than 65535 bytes, [= exception/throw =] a {{TypeError}}.

  12. Initialize channel .{{RTCDataChannel/[[Negotiated]]}} to flow. option .{{RTCDataChannelInit/negotiated}}.

  13. Initialize channel .{{RTCDataChannel/[[DataChannelId]]}} to the value of option .{{RTCDataChannelInit/id}}, if it is present and {{RTCDataChannel/[[Negotiated]]}} is true, otherwise PeerConnection . CLOSING (4) The null .

    This means the {{RTCDataChannelInit/id}} member will be ignored if the data channel is negotiated in-band; this is intentional. Data channels negotiated in-band should have IDs selected based on the DTLS role, as specified in [[RFC8832]].
  14. If {{RTCDataChannel/[[Negotiated]]}} is PeerConnection true object and {{RTCDataChannel/[[DataChannelId]]}} is terminating all media null , [= exception/throw =] a {{TypeError}}.

  15. If both {{RTCDataChannel/[[MaxPacketLifeTime]]}} and {{RTCDataChannel/[[MaxRetransmits]]}} attributes are set (not null), [= exception/throw =] a {{TypeError}}.

  16. If a setting, either {{RTCDataChannel/[[MaxPacketLifeTime]]}} or {{RTCDataChannel/[[MaxRetransmits]]}}, has been set to indicate unreliable mode, and that value exceeds the maximum value supported by the user agent, the value MUST be set to the user agents maximum value.

  17. If {{RTCDataChannel/[[DataChannelId]]}} is in equal to 65535, which is greater than the process maximum allowed ID of closing 65534 but still qualifies as an unsigned short , [= exception/throw =] a {{TypeError}}.

  18. If the Ice Agent and SDP Agent. {{RTCDataChannel/[[DataChannelId]]}} slot is PeerConnection null . CLOSED (due to no ID being passed into {{createDataChannel}}, or {{RTCDataChannel/[[Negotiated]]}} being false), and the DTLS role of the SCTP transport has already been negotiated, then initialize {{RTCDataChannel/[[DataChannelId]]}} to a value generated by the user agent, according to [[RFC8832]], and skip to the next step. If no available ID could be generated, or if the value of the {{RTCDataChannel/[[DataChannelId]]}} slot is being used by an existing {{RTCDataChannel}}, [= exception/throw =] an {{OperationError}} exception.

    If the {{RTCDataChannel/[[DataChannelId]]}} slot is null (3) The after this step, it will be populated during the [= RTCSctpTransport connected =] procedure.
  19. Let transport be connection .{{RTCPeerConnection/[[SctpTransport]]}}.

    If the {{RTCDataChannel/[[DataChannelId]]}} slot is closed. not null , transport is in the {{RTCSctpTransportState/"connected"}} state and {{RTCDataChannel/[[DataChannelId]]}} is greater or equal to transport .{{RTCSctpTransport/[[MaxChannels]]}}, [= exception/throw =] an {{OperationError}}.

  20. If channel is the first {{RTCDataChannel}} created on connection , [= update the negotiation-needed flag =] for connection .

  21. [=list/Append=] channel to connection .{{RTCPeerConnection/[[DataChannels]]}}.

  22. Return channel and continue the following steps in parallel.

  23. Create channel 's associated [= underlying data transport =] and configure it according to the relevant properties of channel .

No exceptions.

RTCSctpTransport Interface

The {{RTCSctpTransport}} interface allows an application access to information about the SCTP data channels tied to a particular SCTP association.

Create an instance

To create an {{RTCSctpTransport}} with an initial state, initialState , run the following steps:

  1. Let transport be a new {{RTCSctpTransport}} object.

  2. Let transport have a [[\SctpTransportState]] internal slot initialized to initialState .

  3. Let transport have a [[\MaxMessageSize]] internal slot and run the steps labeled [= update the data max message size =] to initialize it.

  4. Let transport have a [[\MaxChannels]] internal slot initialized to remoteStreams of type array null .

  5. Return transport .

Update max message size

To update the data max message size of MediaStream , readonly an {{RTCSctpTransport}} run the following steps:

  1. Returns a live array containing Let transport be the streams that {{RTCSctpTransport}} object to be updated.

  2. Let remoteMaxMessageSize be the user agent is currently receiving value of the max-message-size SDP attribute read from the remote peer. description, as described in [[RFC8841]] (section 6), or 65536 if the attribute is missing.

  3. Specifically, it must return Let canSendSize be the read-only MediaStream array number of bytes that this client can send (i.e. the attribute was size of the local send buffer) or 0 if the implementation can handle messages of any size.

  4. If both remoteMaxMessageSize and canSendSize are 0, set {{RTCSctpTransport/[[MaxMessageSize]]}} to when the PeerConnection positive Infinity value.

  5. Else, if either remoteMaxMessageSize or canSendSize is 0, set {{RTCSctpTransport/[[MaxMessageSize]]}} to the larger of the two.

  6. Else, set {{RTCSctpTransport/[[MaxMessageSize]]}} to the smaller of remoteMaxMessageSize or canSendSize .

Connected procedure

Once an SCTP transport is connected , meaning the SCTP association of an {{ RTCSctpTransport}} has been established, run the following steps:

  1. Let transport be the {{RTCSctpTransport}} object.

  2. Let connection be the {{RTCPeerConnection}} object associated with transport .

  3. Set {{RTCSctpTransport/[[MaxChannels]]}} to the minimum of the negotiated amount of incoming and outgoing SCTP streams.

  4. For each of connection 's constructor ran. {{RTCDataChannel}}:

    1. Let channel be the {{RTCDataChannel}} object.

    2. If channel .{{RTCDataChannel/[[DataChannelId]]}} is null , initialize {{RTCDataChannel/[[DataChannelId]]}} to the value generated by the underlying sctp data channel, according to [[RFC8832]].

    3. If channel .{{RTCDataChannel/[[DataChannelId]]}} is greater or equal to transport .{{RTCSctpTransport/[[MaxChannels]]}}, or the previous step failed to assign an id, [= unable to create an RTCDataChannel | close =] the channel due to a failure. Otherwise, [= announce the rtcdatachannel as open | announce the channel as open =].

  5. [= Fire an event =] named {{RTCSctpTransport/statechange}} at transport .

    This array event is updated when addstream and removestream fired before the {{RTCDataChannel/open}} events fired by [= announce the rtcdatachannel as open | announcing the channel as open =]; the {{RTCDataChannel/open}} events are fired. fired from a queued task.

No exceptions. sdpState
[Exposed=Window]
interface RTCSctpTransport : EventTarget {
  readonly attribute RTCDtlsTransport transport;
  readonly attribute RTCSctpTransportState state;
  readonly attribute unrestricted double maxMessageSize;
  readonly attribute unsigned short? maxChannels;
  attribute EventHandler onstatechange;
};

Attributes

transport of type unsigned short {{RTCDtlsTransport}} , readonly

The sdpState transport over which all SCTP packets for data channels will be sent and received.

state of type {{RTCSctpTransportState}} , readonly

The current state of the SCTP transport. On getting, this attribute must MUST return the state value of the PeerConnection SDP Agent , represented by a number from the following list: {{RTCSctpTransport/[[SctpTransportState]]}} slot.

PeerConnection . NEW (0)
maxMessageSize of type unrestricted double , readonly

The object was just created, and no networking has yet occurred. maximum size of data that can be passed to {{RTCDataChannel}}'s {{RTCDataChannel/send()}} method. The attribute MUST, on getting, return the value of the {{RTCSctpTransport/[[MaxMessageSize]]}} slot.

maxChannels of type unsigned short , readonly, nullable

The maximum amount of {{RTCDataChannel}}'s that can be used simultaneously. The attribute MUST, on getting, return the value of the {{RTCSctpTransport/[[MaxChannels]]}} slot.

This attribute's value will be PeerConnection . SDP_IDLE null (0x1000) until the SCTP transport goes into the {{RTCSctpTransportState/"connected"}} state.
onstatechange of type EventHandler
At least one SDP offer

The event type of this event handler is {{RTCSctpTransport/statechange}}.

RTCSctpTransportState Enum

{{RTCSctpTransportState}} indicates the state of the SCTP transport.

enum RTCSctpTransportState {
  "connecting",
  "connected",
  "closed"
};
{{RTCSctpTransportState}} Enumeration description
Enum value Description
connecting

The {{RTCSctpTransport}} is in the process of negotiating an association. This is the initial state of the [[\SctpTransportState]] slot when an {{RTCSctpTransport}} is created.

connected

When the negotiation of an association is completed, a task is queued to update the [[\SctpTransportState]] slot to {{RTCSctpTransportState/"connected"}}.

closed

A task is queued to update the [[\SctpTransportState]] slot to {{RTCSctpTransportState/"closed"}} when:

  • a SHUTDOWN or answer ABORT chunk is received.
  • the SCTP association has been exchange and closed intentionally, such as by closing the SDP Agent peer connection or applying a remote description that rejects data or changes the SCTP port.
  • the underlying DTLS association has transitioned to {{RTCDtlsTransportState/"closed"}} state.

Note that the last transition is ready logical due to send the fact that an SDP offer or receive SCTP association requires an SDP answer. PeerConnection . SDP_WAITING (0x2000) established DTLS connection - [[RFC8261]] section 6.1 specifies that SCTP over DTLS is single-homed - and that no way of of switching to an alternate transport is defined in this API.

RTCDataChannel

The SDP Agent has {{RTCDataChannel}} interface represents a bi-directional data channel between two peers. An {{RTCDataChannel}} is created via a factory method on an {{RTCPeerConnection}} object. The messages sent between the browsers are described in [[RFC8831]] and offer and is waiting for [[RFC8832]].

There are two ways to establish a answer. PeerConnection . SDP_GLARE (0x3000) connection with {{RTCDataChannel}}. The SDP Agent received first way is to simply create an offer while waiting for {{RTCDataChannel}} at one of the peers with the {{RTCDataChannelInit/negotiated}} {{RTCDataChannelInit}} dictionary member unset or set to its default value false. This will announce the new channel in-band and trigger an answer {{RTCDataChannelEvent}} with the corresponding {{RTCDataChannel}} object at the other peer. The second way is to let the application negotiate the {{RTCDataChannel}}. To do this, create an {{RTCDataChannel}} object with the {{RTCDataChannelInit/negotiated}} {{RTCDataChannelInit}} dictionary member set to true, and now much wait signal out-of-band (e.g. via a rondom amount of time before retrying web server) to send the offer. No exceptions. 4.1.2 Methods addStream Attempts other side that it SHOULD create a corresponding {{RTCDataChannel}} with the {{RTCDataChannelInit/negotiated}} {{RTCDataChannelInit}} dictionary member set to starting sending true and the given stream same {{RTCDataChannel/id}}. This will connect the two separately created {{RTCDataChannel}} objects. The second way makes it possible to create channels with asymmetric properties and to create channels in a declarative way by specifying matching {{RTCDataChannelInit/id}}s.

Each {{RTCDataChannel}} has an associated underlying data transport that is used to transport actual data to the remote other peer. In the case of SCTP data channels utilizing an {{RTCSctpTransport}} (which represents the state of the SCTP association), the underlying data transport is the SCTP stream pair. The transport properties of the [= underlying data transport =], such as in order delivery settings and reliability mode, are configured by the peer as the channel is created. The properties of a channel cannot change after the channel has been created. The actual wire protocol between the peers is specified by the WebRTC DataChannel Protocol specification [[RFC8831]].

When An {{RTCDataChannel}} can be configured to operate in different reliability modes. A reliable channel ensures that the data is delivered at the other peer starts sending through retransmissions. An unreliable channel is configured to either limit the number of retransmissions ( {{RTCDataChannelInit/maxRetransmits}} ) or set a stream time during which transmissions (including retransmissions) are allowed ( {{RTCDataChannelInit/maxPacketLifeTime}} ). These properties can not be used simultaneously and an attempt to do so will result in this manner, an addstream event error. Not setting any of these properties results in a reliable channel.

An {{RTCDataChannel}}, created with {{RTCPeerConnection/createDataChannel}} or dispatched via an {{RTCDataChannelEvent}}, MUST initially be in the {{RTCDataChannelState/"connecting"}} state. When the {{RTCDataChannel}} object's [= underlying data transport =] is fired at ready, the PeerConnection user agent MUST [= announce the RTCDataChannel as open =].

Creating a data channel

To create an {{RTCDataChannel}} , run the following steps:

  1. Let channel be a newly created {{RTCDataChannel}} object.

  2. Let channel have a [[\ReadyState]] internal slot initialized to {{RTCDataChannelState/"connecting"}}.

  3. Let channel have a [[\BufferedAmount]] internal slot initialized to 0 .

  4. Let channel have internal slots named [[\DataChannelLabel]] , [[\Ordered]] , [[\MaxPacketLifeTime]] , [[\MaxRetransmits]] , [[\DataChannelProtocol]] , [[\Negotiated]] , and [[\DataChannelId]] .

  5. Return channel .

Announcing a data channel as open

When the addStream() method user agent is invoked, to announce an {{RTCDataChannel}} as open , the user agent must MUST queue a task to run the following steps:

  1. If the associated {{RTCPeerConnection}} object's {{RTCPeerConnection/[[IsClosed]]}} slot is true , abort these steps.

  2. Let stream channel be the method's argument. {{RTCDataChannel}} object to be announced.

  3. If the PeerConnection object's PeerConnection readiness state channel .{{RTCDataChannel/[[ReadyState]]}} is CLOSED (3), throw an INVALID_STATE_ERR exception. {{RTCDataChannelState/"closing"}} or {{RTCDataChannelState/"closed"}}, abort these steps.

  4. If stream Set channel .{{RTCDataChannel/[[ReadyState]]}} to {{RTCDataChannelState/"open"}}.

  5. [= Fire an event =] named {{RTCDataChannel/open}} at channel .

Announcing a data channel instance

When an [= underlying data transport =] is already in to be announced (the other peer created a channel with {{RTCDataChannelInit/negotiated}} unset or set to false), the user agent of the peer that did not initiate the creation process MUST queue a task to run the following steps:

  1. Let connection be the {{RTCPeerConnection}} object associated with the [= underlying data transport =].

  2. If connection .{{RTCPeerConnection/[[IsClosed]]}} is PeerConnection object's localStreams object, then true , abort these steps.

  3. Add stream [= Create an RTCDataChannel =], channel .

  4. Let configuration to be an information bundle received from the end other peer as a part of the process to establish the [= underlying data transport =] described by the WebRTC DataChannel Protocol specification [[RFC8832]].

  5. Initialize channel .{{RTCDataChannel/[[DataChannelLabel]]}}, {{RTCDataChannel/[[Ordered]]}}, {{RTCDataChannel/[[MaxPacketLifeTime]]}}, {{RTCDataChannel/[[MaxRetransmits]]}}, {{RTCDataChannel/[[DataChannelProtocol]]}}, and {{RTCDataChannel/[[DataChannelId]]}} internal slots to the corresponding values in configuration .

  6. Initialize channel .{{RTCDataChannel/[[Negotiated]]}} to PeerConnection false .

  7. [=list/Append=] channel to connection .{{RTCPeerConnection/[[DataChannels]]}}.

  8. Set channel .{{RTCDataChannel/[[ReadyState]]}} to {{RTCDataChannelState/"open"}} (but do not fire the {{RTCDataChannel/open}} event, yet).

    This allows to start sending messages inside of the {{RTCPeerConnection/datachannel}} event handler prior to the {{RTCDataChannel/open}} event being fired.
  9. [= Fire an event =] named {{RTCPeerConnection/datachannel}} using the {{RTCDataChannelEvent}} interface with the {{RTCDataChannelEvent/channel}} attribute set to channel at connection .

  10. [= announce the rtcdatachannel as open | Announce the data channel as open =].

Closing procedure

An {{RTCDataChannel}} object's localStreams object. [= underlying data transport =] may be torn down in a non-abrupt manner by running the closing procedure . When that happens the user agent MUST queue a task to run the following steps:

  1. Let channel be the {{RTCDataChannel}} object whose [= underlying data transport =] was closed.

  2. Let connection be the {{RTCPeerConnection}} object associated with channel .

  3. Return [=list/Remove=] channel from connection .{{RTCPeerConnection/[[DataChannels]]}}.

  4. Unless the method. procedure was initiated by channel .{{RTCDataChannel/close}}, set channel .{{RTCDataChannel/[[ReadyState]]}} to {{RTCDataChannelState/"closing"}} and [= fire an event =] named {{RTCDataChannel/closing}} at channel .

  5. Have Run the PeerConnection add a media stream following steps in parallel:

    1. Finish sending all currently pending messages of the channel .

    2. Follow the closing procedure defined for stream the channel 's [= underlying data transport =] :

      1. In the next time case of an SCTP-based [= underlying data transport | transport =], follow [[RFC8831]], section 6.7.

    3. [= RTCDataChannel underlying data transport/closed | Close=] the channel 's [= data transport =] by following the associated procedure.

Announcing a data channel as closed

When an {{RTCDataChannel}} object's [= underlying data transport =] has been closed , the user agent provides MUST queue a stable state . Any other pending stream additions and removals must task to run the following steps:

  1. Let channel be processed at the same time. {{RTCDataChannel}} object whose [= underlying data transport =] was closed.

  2. Parameter Type Nullable Optional Description stream MediaStream ✘ ✘ No exceptions. Return type: void
  3. If channel .{{RTCDataChannel/[[ReadyState]]}} is {{RTCDataChannelState/"closed"}}, abort these steps.
  4. Set channel .{{RTCDataChannel/[[ReadyState]]}} to {{RTCDataChannelState/"closed"}}.

  5. [=list/Remove=] channel from connection .{{RTCPeerConnection/[[DataChannels]]}} if it is still there.

  6. If the [= underlying data transport | transport =] was closed with an error , [= fire an event =] named {{RTCDataChannel/error}} using the {{RTCErrorEvent}} interface with its {{RTCError/errorDetail}} attribute set to {{RTCErrorDetailType/"sctp-failure"}} at channel .

  7. [= Fire an event =] named close at channel .

Error on creating data channels

When In some cases, the close() user agent may be unable to create an {{RTCDataChannel}} method is invoked, 's [= underlying data transport =]. For example, the data channel's {{RTCDataChannel/id}} may be outside the range negotiated by the [[RFC8831]] implementations in the SCTP handshake. When the user agent must determines that an {{RTCDataChannel}}'s [= underlying data transport =] cannot be created, the user agent MUST queue a task to run the following steps:

  1. Let channel be the {{RTCDataChannel}} object for which the user agent could not create an [= underlying data transport =].

  2. If Set channel .{{RTCDataChannel/[[ReadyState]]}} to {{RTCDataChannelState/"closed"}}.

  3. [= Fire an event =] named {{RTCDataChannel/error}} using the PeerConnection object's PeerConnection readiness state is CLOSED {{RTCErrorEvent}} interface with the {{RTCError/errorDetail}} attribute set to {{RTCErrorDetailType/"data-channel-failure"}} at channel .

  4. [= Fire an event =] named close (3), throw at channel .

Receiving messages on a data channel

When an INVALID_STATE_ERR exception. {{RTCDataChannel}} message has been received via the [= underlying data transport =] with type type and data rawData , the user agent MUST queue a task to run the following steps:

  1. Let channel be the {{RTCDataChannel}} object for which the user agent has received a message.

  2. Let connection be the {{RTCPeerConnection}} object associated with channel .

  3. Destroy If channel .{{RTCDataChannel/[[ReadyState]]}} is not {{RTCDataChannelState/"open"}}, abort these steps and discard rawData .

  4. Execute the PeerConnection ICE Agent , abruptly ending any active ICE processing sub step by switching on type and any active streaming, channel .{{RTCDataChannel/binaryType}}:

    • If type indicates that rawData is a string :

      Let data be a DOMString that represents the result of decoding rawData as UTF-8.

    • If type indicates that rawData is binary and releasing any relevant resources (e.g. TURN permissions). {{RTCDataChannel/binaryType}} is "blob" :

      Let data be a new {{Blob}} object containing rawData as its raw data source.

    • Set If type indicates that rawData is binary and {{RTCDataChannel/binaryType}} is "arraybuffer" :

      Let data be a new {{ArrayBuffer}} object containing rawData as its raw data source.

  5. [= Fire an event =] named {{RTCDataChannel/message}} using the object's PeerConnection {{MessageEvent}} interface with its origin readiness state attribute initialized to CLOSED the serialization of an origin of connection .{{RTCPeerConnection/[[DocumentOrigin]]}}, and the data (3). attribute initialized to data at channel .

[Exposed=Window]
interface RTCDataChannel : EventTarget {
  readonly attribute USVString label;
  readonly attribute boolean ordered;
  readonly attribute unsigned short? maxPacketLifeTime;
  readonly attribute unsigned short? maxRetransmits;
  readonly attribute USVString protocol;
  readonly attribute boolean negotiated;
  readonly attribute unsigned short? id;
  readonly attribute RTCDataChannelState readyState;
  readonly attribute unsigned long bufferedAmount;
  [EnforceRange] attribute unsigned long bufferedAmountLowThreshold;
  attribute EventHandler onopen;
  attribute EventHandler onbufferedamountlow;
  attribute EventHandler onerror;
  attribute EventHandler onclosing;
  attribute EventHandler onclose;
  undefined close();
  attribute EventHandler onmessage;
  attribute BinaryType binaryType;
  undefined send(USVString data);
  undefined send(Blob data);
  undefined send(ArrayBuffer data);
  undefined send(ArrayBufferView data);
};

Attributes

label of type USVString , readonly

The localStreams and remoteStreams {{label}} attribute represents a label that can be used to distinguish this {{RTCDataChannel}} object from other {{RTCDataChannel}} objects. Scripts are allowed to create multiple {{RTCDataChannel}} objects remain with the same label. On getting, the attribute MUST return the value of the {{RTCDataChannel/[[DataChannelLabel]]}} slot.

ordered of type boolean , readonly

The {{ordered}} attribute returns true if the {{RTCDataChannel}} is ordered, and false if out of order delivery is allowed. On getting, the attribute MUST return the value of the {{RTCDataChannel/[[Ordered]]}} slot.

maxPacketLifeTime of type unsigned short , readonly, nullable

The {{maxPacketLifeTime}} attribute returns the length of the time window (in milliseconds) during which transmissions and retransmissions may occur in unreliable mode. On getting, the state they were attribute MUST return the value of the {{RTCDataChannel/[[MaxPacketLifeTime]]}} slot.

maxRetransmits of type unsigned short , readonly, nullable

The {{maxRetransmits}} attribute returns the maximum number of retransmissions that are attempted in when unreliable mode. On getting, the object was closed. attribute MUST return the value of the {{RTCDataChannel/[[MaxRetransmits]]}} slot.

No parameters. No exceptions. Return type: void processSignalingMessage
protocol of type USVString , readonly

When a message is relayed from The {{protocol}} attribute returns the remote peer over name of the signaling channel is received sub-protocol used with this {{RTCDataChannel}}. On getting, the attribute MUST return the value of the {{RTCDataChannel/[[DataChannelProtocol]]}} slot.

negotiated of type boolean , readonly

The {{negotiated}} attribute returns true if this {{RTCDataChannel}} was negotiated by the Web application, pass or false otherwise. On getting, the attribute MUST return the value of the {{RTCDataChannel/[[Negotiated]]}} slot.

id of type unsigned short , readonly, nullable

The {{id}} attribute returns the ID for this {{RTCDataChannel}}. The value is initially null, which is what will be returned if the ID was not provided at channel creation time, and the DTLS role of the SCTP transport has not yet been negotiated. Otherwise, it to will return the ID that was either selected by the script or generated by the user agent by calling according to [[RFC8832]]. After the processSignalingMessage() method. ID is set to a non-null value, it will not change. On getting, the attribute MUST return the value of the {{RTCDataChannel/[[DataChannelId]]}} slot.

readyState of type {{RTCDataChannelState}} , readonly

The order {{readyState}} attribute represents the state of messages is important. Passing messages to the user agent {{RTCDataChannel}} object. On getting, the attribute MUST return the value of the {{RTCDataChannel/[[ReadyState]]}} slot.

bufferedAmount of type unsigned long , readonly

The {{bufferedAmount}} attribute MUST, on getting, return the value of the {{RTCDataChannel/[[BufferedAmount]]}} slot. The attribute exposes the number of bytes of application data (UTF-8 text and binary data) that have been queued using {{RTCDataChannel/send()}}. Even though the data transmission can occur in a different order than they were generated parallel, the returned value MUST NOT be decreased before the current task yielded back to the event loop to prevent race conditions. The value does not include framing overhead incurred by the remote peer's protocol, or buffering done by the operating system or network hardware. The value of the {{RTCDataChannel/[[BufferedAmount]]}} slot will only increase with each call to the {{RTCDataChannel/send()}} method as long as the {{RTCDataChannel/[[ReadyState]]}} slot is {{RTCDataChannelState/"open"}}; however, the slot does not reset to zero once the channel closes. When the [= underlying data transport =] sends data from its queue, the user agent can prevent MUST queue a successful connection task that reduces {{RTCDataChannel/[[BufferedAmount]]}} with the number of bytes that was sent.

bufferedAmountLowThreshold of type unsigned long

The {{bufferedAmountLowThreshold}} attribute sets the threshold at which the {{RTCDataChannel/bufferedAmount}} is considered to be low. When the {{RTCDataChannel/bufferedAmount}} decreases from being established above this threshold to equal or degrade below it, the connection's quality if one {{bufferedamountlow}} event fires. The {{RTCDataChannel/bufferedAmountLowThreshold}} is established. initially zero on each new {{RTCDataChannel}}, but the application may change its value at any time.

onopen of type EventHandler
The event type of this event handler is {{RTCDataChannel/open}}.
onbufferedamountlow of type EventHandler
The event type of this event handler is {{bufferedamountlow}}.
onerror of type EventHandler

The event type of this event handler is {{RTCErrorEvent}}. {{RTCError/errorDetail}} contains "sctp-failure", {{RTCError/sctpCauseCode}} contains the SCTP Cause Code value, and {{DOMException/message}} contains the SCTP Cause-Specific-Information, possibly with additional text.

onclosing of type EventHandler

The event type of this event handler is {{RTCDataChannel/closing}}.

onclose of type EventHandler

The event type of this event handler is close .

onmessage of type EventHandler

The event type of this event handler is {{RTCDataChannel/message}}.

binaryType of type BinaryType

The {{binaryType}} attribute returns the value to which it was last set. When an {{RTCDataChannel}} object is created, the processSignalingMessage() {{binaryType}} attribute MUST be initialized to the string {{BinaryType/"arraybuffer"}}.

This attribute controls how binary data is exposed to scripts. See Web Socket's {{WebSocket/binaryType}}.

Methods

close()

Closes the {{RTCDataChannel}}. It may be called regardless of whether the {{RTCDataChannel}} object was created by this peer or the remote peer.

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

  1. Let message channel be the method's argument. {{RTCDataChannel}} object which is about to be closed.

  2. If channel .{{RTCDataChannel/[[ReadyState]]}} is {{RTCDataChannelState/"closing"}} or {{RTCDataChannelState/"closed"}}, then abort these steps.

  3. Set channel .{{RTCDataChannel/[[ReadyState]]}} to {{RTCDataChannelState/"closing"}}.

  4. If the [= closing procedure =] has not started yet, start it.

send

Run the steps described by the [= send() algorithm =] with argument type string object.

send

Run the steps described by the [= send() algorithm =] with argument type {{Blob}} object.

send

Run the steps described by the [= send() algorithm =] with argument type {{ArrayBuffer}} object.

send

Run the steps described by the [= send() algorithm =] with argument type {{ArrayBufferView}} object.

The send() method is overloaded to handle different data argument types. When any version of the method is called, the user agent MUST run the following steps :

  1. Let connection channel be the PeerConnection {{RTCDataChannel}} object on which the method was invoked. data is to be sent.

  2. If connection 's PeerConnection readiness state channel .{{RTCDataChannel/[[ReadyState]]}} is CLOSED (3), throw not {{RTCDataChannelState/"open"}}, [= exception/throw =] an INVALID_STATE_ERR exception. {{InvalidStateError}}.

  3. If Execute the first four characters sub step that corresponds to the type of message are not " SDP the methods argument:

    • string " followed object:

      Let data be a byte buffer that represents the result of encoding the method's argument as UTF-8.

    • {{Blob}} object:

      Let data be the raw data represented by the {{Blob}} object.

      Although the actual retrieval of data from a U+000A LINE FEED (LF) character, then abort these steps. (This indicates an error in {{Blob}} object can happen asynchronously, the signaling channel implementation. User agents may report such errors user agent will make sure to their developer consoles queue the data on the channel 's [= underlying data transport =] in the same order as the send method is called. The byte size of data needs to aid debugging.) be known synchronously.
    • {{ArrayBuffer}} object:

      Future extensions to

      Let data be the PeerConnection interface might use other prefix values to implement additional features. data stored in the buffer described by the {{ArrayBuffer}} object.

    • {{ArrayBufferView}} object:

      Let sdp data be the string consisting of all but data stored in the first four characters section of message . the buffer described by the {{ArrayBuffer}} object that the {{ArrayBufferView}} object references.

    Any data argument type this method has not been overloaded with will result in a {{TypeError}}. This includes null and undefined .
  4. Pass If the sdp byte size of data to exceeds the PeerConnection SDP Agent as value of {{RTCSctpTransport/maxMessageSize}} on channel 's associated {{RTCSctpTransport}}, [= exception/throw =] a subsequent offer or answer, {{TypeError}}.

  5. Queue data for transmission on channel 's [= underlying data transport =]. If queuing data is not possible because not enough buffer space is available, [= exception/throw =] an {{OperationError}}.

    The actual transmission of data occurs in parallel. If sending data leads to an SCTP-level error, the application will be interpreted as appropriate given notified asynchronously through {{RTCDataChannel/onerror}}.
  6. Increase the current state value of the SDP Agent. [ICE] {{RTCDataChannel/[[BufferedAmount]]}} slot by the byte size of data .

When a
dictionary RTCDataChannelInit {
  boolean ordered = true;
  [EnforceRange] unsigned short maxPacketLifeTime;
  [EnforceRange] unsigned short maxRetransmits;
  USVString protocol = "";
  boolean negotiated = false;
  [EnforceRange] unsigned short id;
};

Dictionary RTCDataChannelInit Members

ordered of type boolean , defaulting to PeerConnection true ICE Agent forms a connection

If set to false, data is allowed to be delivered out of order. The default value of true, guarantees that data will be delivered in order.

maxPacketLifeTime of type unsigned short

Limits the time (in milliseconds) during which the far side and enters channel will transmit or retransmit data if not acknowledged. This value may be clamped if it exceeds the state ICECONNECTED, maximum value supported by the user agent must queue agent.

maxRetransmits of type unsigned short

Limits the number of times a task that sets channel will retransmit data if not successfully delivered. This value may be clamped if it exceeds the maximum value supported by the user agent.

protocol of type USVString , defaulting to PeerConnection "" object's

Subprotocol name used for this channel.

negotiated of type boolean , defaulting to PeerConnection false readiness state

The default value of false tells the user agent to ACTIVE (2) announce the channel in-band and then fires instruct the other peer to dispatch a simple event named open corresponding {{RTCDataChannel}} object. If set to true, it is up to the application to negotiate the channel and create an {{RTCDataChannel}} object with the same {{RTCDataChannel/id}} at the PeerConnection object. other peer.

If set to true, the application must also take care to not send a message until the other peer has created a data channel to receive it. Receiving a message on an SCTP stream with no associated data channel is undefined behavior, and it may be silently dropped. This will not be possible as long as both endpoints create their data channel before the first offer/answer exchange is complete.
id of type unsigned short

Sets the channel ID when {{RTCDataChannelInit/negotiated}} is true. Ignored when {{RTCDataChannelInit/negotiated}} is false.

enum RTCDataChannelState {
  "connecting",
  "open",
  "closing",
  "closed"
};
message DOMString ✘ ✘
RTCDataChannelState Enumeration description
Parameter Type Nullable Optional Enum value Description
connecting

The user agent is attempting to establish the [= underlying data transport =]. This is the initial state of an {{RTCDataChannel}} object, whether created with {{RTCPeerConnection/createDataChannel}}, or dispatched as a part of an {{RTCDataChannelEvent}}.

open

The [= underlying data transport =] is established and communication is possible.

closing

The [= closing procedure | procedure =] to close down the [= underlying data transport =] has started.

closed

The [= underlying data transport =] has been {{closed}} or could not be established.

RTCDataChannelEvent

The {{RTCPeerConnection/datachannel}} event uses the {{RTCDataChannelEvent}} interface.

[Exposed=Window]
interface RTCDataChannelEvent : Event {
  constructor(DOMString type, RTCDataChannelEventInit eventInitDict);
  readonly attribute RTCDataChannel channel;
};

Constructors

RTCDataChannelEvent.constructor()
No exceptions.

Attributes

channel of type {{RTCDataChannel}} , readonly

The {{channel}} attribute represents the {{RTCDataChannel}} object associated with the event.

Return type: void
dictionary RTCDataChannelEventInit : EventInit {
  required RTCDataChannel channel;
};

Dictionary RTCDataChannelEventInit Members

channel of type {{RTCDataChannel}} , required

The {{RTCDataChannel}} object to be announced by the event.

Garbage Collection

An {{RTCDataChannel}} object MUST not be garbage collected if its

Peer-to-peer DTMF

This section describes an interface on {{RTCRtpSender}} to send DTMF (phone keypad) values across an {{RTCPeerConnection}}. Details of how DTMF is sent to the other peer are described in [[RFC7874]].

RTCRtpSender Interface Extensions

The Peer-to-peer DTMF API extends the {{RTCRtpSender}} interface as described below.

          partial interface RTCRtpSender {
  readonly attribute RTCDTMFSender? dtmf;
};

Attributes

dtmf of type {{RTCDTMFSender}} , readonly, nullable

On getting, the {{dtmf}} attribute returns the value of the {{RTCRtpSender/[[Dtmf]]}} internal slot, which represents a {{RTCDTMFSender}} which can be used to send DTMF, or removeStream null if unset. The {{RTCRtpSender/[[Dtmf]]}} internal slot is set when the kind of an {{RTCRtpSender}}'s {{RTCRtpSender/[[SenderTrack]]}} is "audio" .

RTCDTMFSender

To create an RTCDTMFSender , the user agent MUST run the following steps:

  1. Let dtmf be a newly created {{RTCDTMFSender}} object.

  2. Let dtmf have a [[\Duration]] internal slot.

  3. Let dtmf have a [[\InterToneGap]] internal slot.

  4. Let dtmf have a [[\ToneBuffer]] internal slot.

[Exposed=Window]
interface RTCDTMFSender : EventTarget {
  undefined insertDTMF(DOMString tones, optional unsigned long duration = 100, optional unsigned long interToneGap = 70);
  attribute EventHandler ontonechange;
  readonly attribute boolean canInsertDTMF;
  readonly attribute DOMString toneBuffer;
};

Attributes

ontonechange of type EventHandler

Stops The event type of this event handler is {{RTCDTMFSender/tonechange}}.

canInsertDTMF of type boolean , readonly

Whether the {{RTCDTMFSender}} dtmfSender is capable of sending DTMF. On getting, the given stream user agent MUST return the result of running [= determine if DTMF can be sent =] for dtmfSender .

toneBuffer of type DOMString , readonly

The {{toneBuffer}} attribute MUST return a list of the tones remaining to be played out. For the remote peer. syntax, content, and interpretation of this list, see {{insertDTMF}}.

Methods

insertDTMF

When An {{RTCDTMFSender}} object's {{insertDTMF}} method is used to send DTMF tones.

The tones parameter is treated as a series of characters. The characters 0 through 9, A through D, #, and * generate the other peer stops sending associated DTMF tones. The characters a stream to d MUST be normalized to uppercase on entry and are equivalent to A to D. As noted in this manner, [[RTCWEB-AUDIO]] Section 3, support for the characters 0 through 9, A through D, #, and * are required. The character ',' MUST be supported, and indicates a removestream event delay of 2 seconds before processing the next character in the tones parameter. All other characters (and only those other characters) MUST be considered unrecognized .

The duration parameter indicates the duration in ms to use for each character passed in the tones parameters. The duration cannot be more than 6000 ms or less than 40 ms. The default duration is fired 100 ms for each tone.

The interToneGap parameter indicates the gap between tones in ms. The user agent clamps it to at least 30 ms and at most 6000 ms. The default value is 70 ms.

The browser MAY increase the PeerConnection object. duration and interToneGap times to cause the times that DTMF start and stop to align with the boundaries of RTP packets but it MUST not increase either of them by more than the duration of a single RTP audio packet.

When the removeStream() {{insertDTMF()}} method is invoked, the user agent must MUST run the following steps:

  1. Let sender be the {{RTCRtpSender}} used to send DTMF.
  2. Let stream transceiver be the method's argument. {{RTCRtpTransceiver}} object associated with sender .

  3. Let dtmf be the {{RTCDTMFSender}} associated with sender .
  4. If the [= determine if DTMF can be sent =] for dtmf returns PeerConnection false , [= exception/throw =] an {{InvalidStateError}}.
  5. Let tones be the method's first argument.
  6. Let duration be the method's second argument.
  7. Let interToneGap be the method's third argument.
  8. If tones contains any {{unrecognized}} characters, [= exception/throw =] an {{InvalidCharacterError}}.
  9. Set the object's PeerConnection readiness state {{RTCDTMFSender/[[ToneBuffer]]}} slot to tones .
  10. Set dtmf .{{RTCDTMFSender/[[Duration]]}} to the value of duration .
  11. Set dtmf .{{RTCDTMFSender/[[InterToneGap]]}} to the value of interToneGap .
  12. If the value of duration is CLOSED less than 40 ms, set dtmf .{{RTCDTMFSender/[[Duration]]}} to 40 ms.
  13. If the value of duration parameter is greater than 6000 ms, set dtmf .{{RTCDTMFSender/[[Duration]]}} to 6000 ms.
  14. If the value of interToneGap is less than 30 ms, set dtmf .{{RTCDTMFSender/[[InterToneGap]]}} to 30 ms.
  15. If the value of interToneGap is greater than 6000 ms, set dtmf .{{RTCDTMFSender/[[InterToneGap]]}} to 6000 ms.
  16. If [[\ToneBuffer]] (3), throw slot is an INVALID_STATE_ERR exception. empty string, abort these steps.
  17. If stream a task to run the [=DTMF playout task steps=] is not in scheduled to be run, abort these steps; otherwise queue a task that runs the following DTMF playout task steps :
    1. If [=determine if DTMF can be sent=] for dtmf returns PeerConnection object's localStreams object, then false , abort these steps.
    2. If the {{RTCDTMFSender/[[ToneBuffer]]}} slot contains the empty string, [= fire an event =] named {{RTCDTMFSender/tonechange}} using the {{RTCDTMFToneChangeEvent}} interface with the {{RTCDTMFToneChangeEvent/tone}} attribute set to an empty string at the {{RTCDTMFSender}} object and abort these steps.
    3. Remove stream the first character from the {{RTCDTMFSender/[[ToneBuffer]]}} slot and let that character be tone .
    4. If tone is PeerConnection "," object's localStreams delay sending tones for 2000 object. Return ms on the associated RTP media stream, and queue a task to be executed in 2000 ms from now that runs the method. [=DTMF playout task steps=].
    5. Have the If tone is not PeerConnection "," remove start playout of tone for {{RTCDTMFSender/[[Duration]]}} ms on the associated RTP media stream for stream stream, using the appropriate codec, then queue a task to be executed in {{RTCDTMFSender/[[Duration]]}} + {{RTCDTMFSender/[[InterToneGap]]}} ms from now that runs the [=DTMF playout task steps=].
    6. [= Fire an event =] named {{RTCDTMFSender/tonechange}} using the {{RTCDTMFToneChangeEvent}} interface with the {{RTCDTMFToneChangeEvent/tone}} attribute set to tone at the next time {{RTCDTMFSender}} object.

Since {{insertDTMF}} replaces the user agent provides tone buffer, in order to add to the DTMF tones being played, it is necessary to call {{insertDTMF}} with a stable state . Any other pending stream additions string containing both the remaining tones (stored in the {{RTCDTMFSender/[[ToneBuffer]]}} slot) and removals must the new tones appended together. Calling {{insertDTMF}} with an empty tones parameter can be processed at used to cancel all tones queued to play after the same time. currently playing tone.

canInsertDTMF algorithm

To determine if DTMF can be sent for an {{RTCDTMFSender}} instance dtmfSender , the user agent MUST run the following steps:

  1. Let sender be the {{RTCRtpSender}} associated with dtmfSender .
  2. Parameter Type Nullable Optional Description stream
  3. Let transceiver be the {{RTCRtpTransceiver}} associated with sender .
  4. Let connection be the {{RTCPeerConnection}} associated with transceiver .
  5. If connection 's {{RTCPeerConnectionState}} is not {{RTCPeerConnectionState/"connected"}} return false .
  6. If transceiver .{{RTCRtpTransceiver/[[Stopping]]}} is MediaStream true return false .
  7. If sender .{{RTCRtpSender/[[SenderTrack]]}} is null ✘ ✘ No exceptions. Return type: return void false .
  8. If transceiver .{{RTCRtpTransceiver/[[CurrentDirection]]}} is neither {{RTCRtpTransceiverDirection/"sendrecv"}} nor {{RTCRtpTransceiverDirection/"sendonly"}} return false .
  9. If sender .{{RTCRtpSender/[[SendEncodings]]}} [0] .{{RTCRtpEncodingParameters/active}} is false 4.1.3 Constants return ACTIVE false .
  10. If no codec with mimetype "audio/telephone-event" of type unsigned short A connection has been formed and if any media streams were successfully negotiated, any relevant media can be streaming. negotiated for sending with this sender , return CLOSED false .
  11. Otherwise, return true .

RTCDTMFToneChangeEvent

The {{RTCDTMFSender/tonechange}} event uses the {{RTCDTMFToneChangeEvent}} interface.

[Exposed=Window]
interface RTCDTMFToneChangeEvent : Event {
  constructor(DOMString type, optional RTCDTMFToneChangeEventInit eventInitDict = {});
  readonly attribute DOMString tone;
};

Constructors

RTCDTMFToneChangeEvent.constructor()

Attributes

tone of type unsigned short DOMString , readonly

The close() method has been invoked. {{tone}} attribute contains the character for the tone (including CLOSING "," ) that has just begun playout (see {{RTCDTMFSender/insertDTMF}} ). If the value is the empty string, it indicates that the {{RTCDTMFSender/[[ToneBuffer]]}} slot is an empty string and that the previous tones have completed playback.

          dictionary RTCDTMFToneChangeEventInit : EventInit {
  DOMString tone = "";
};

Dictionary RTCDTMFToneChangeEventInit Members

tone of type unsigned short DOMString , defaulting to ""

The object is starting to shut down after {{tone}} attribute contains the close() method has been invoked. character for the tone (including ICE_CHECKING "," of type unsigned short ) that has just begun playout (see {{RTCDTMFSender/insertDTMF}} ). If the value is the empty string, it indicates that the {{RTCDTMFSender/[[ToneBuffer]]}} slot is an empty string and that the previous tones have completed playback.

Statistics Model

Introduction

The ICE Agent basic statistics model is checking candidates but has not yet found a connection that works. ICE_CLOSED the browser maintains a set of type unsigned short statistics for [= monitored object =]s, in the form of [= stats object =]s.

A group of related objects may be referenced by a selector . The ICE Agent selector may, for example, be a {{MediaStreamTrack}}. For a track to be a valid selector, it MUST be a {{MediaStreamTrack}} that is terminating sent or received by the {{RTCPeerConnection}} object on which the stats request was issued. The calling Web application provides the selector to the {{RTCPeerConnection/getStats()}} method and will no longer repined the browser emits (in the JavaScript) a set of statistics that are relevant to STUN connectivity checks. ICE_COMPLETED the selector, according to the [= stats selection algorithm =]. Note that that algorithm takes the sender or receiver of type unsigned short a selector.

The ICE Agent has finished checking all candidates statistics returned in [= stats object =]s are designed in such a way that repeated queries can be linked by the {{RTCStats}} {{RTCStats/id}} dictionary member. Thus, a Web application can make measurements over a given time period by requesting measurements at the beginning and end of that period.

With a connection has been formed. ICE_CONNECTED few exceptions, [= monitored object =]s, once created, exist for the duration of type unsigned short their associated {{RTCPeerConnection}}. This ensures statistics from them are available in the result from {{RTCPeerConnection/getStats()}} even past the associated peer connection being {{RTCPeerConnection/close}}d.

Only a few monitored objects have shorter lifetimes . Statistics from these objects are no longer available in subsequent getStats() results. The object descriptions in [[!WEBRTC-STATS]] describe when these monitored objects are deleted.

RTCPeerConnection Interface Extensions

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

          partial interface RTCPeerConnection {
  Promise<RTCStatsReport> getStats(optional MediaStreamTrack? selector = null);
};

Methods

getStats

Gathers stats for the given [= selector =] and reports the result asynchronously.

When the {{getStats()}} method is invoked, the user agent MUST run the following steps:

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

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

  3. If selectorArg is null , let selector be null .

  4. If selectorArg is a {{MediaStreamTrack}} let selector be an {{RTCRtpSender}} or {{RTCRtpReceiver}} on connection which {{RTCRtpSender/track}} attribute matches selectorArg . If no such sender or receiver exists, or if more than one sender or receiver fit this criteria, return a promise [= rejected =] with a newly [= exception/created =] {{InvalidAccessError}}.

  5. Let p be a new promise.

  6. Run the following steps in parallel:

    1. Gather the stats indicated by selector according to the [= stats selection algorithm =].

    2. [= Resolve =] p with the resulting {{RTCStatsReport}} object, containing the gathered stats.

  7. Return p .

RTCStatsReport Object

The ICE Agent has found at least {{RTCPeerConnection/getStats()}} method delivers a successful result in the form of an {{RTCStatsReport}} object. An {{RTCStatsReport}} object is a map between strings that identify the inspected objects ({{RTCStats/id}} attribute in {{RTCStats}} instances), and their corresponding {{RTCStats}}-derived dictionaries.

An {{RTCStatsReport}} may be composed of several {{RTCStats}}-derived dictionaries, each reporting stats for one candidate underlying object that works but the implementation thinks is still checking. ICE_FAILED relevant for the [= selector =]. One achieves the total for the [= selector =] by summing over all the stats of type unsigned short a certain type; for instance, if an {{RTCRtpSender}} uses multiple SSRCs to carry its track over the network, the {{RTCStatsReport}} may contain one {{RTCStats}}-derived dictionary per SSRC (which can be distinguished by the value of the {{RTCRtpStreamStats/ssrc}} stats attribute).

[Exposed=Window]
interface RTCStatsReport {
  readonly maplike<DOMString, object>;
};

Use these to retrieve the various dictionaries descended from {{RTCStats}} that this stats report is composed of. The ICE Agent has finished checking set of supported property names [[!WEBIDL]] is defined as the ids of all candidates the {{RTCStats}}-derived dictionaries that have been generated for this stats report.

RTCStats Dictionary

An {{RTCStats}} dictionary represents the [= stats object =] constructed by inspecting a specific [= monitored object =]. The {{RTCStats}} dictionary is a base type that specifies as set of default attributes, such as {{RTCStats/timestamp}} and no connection was worked. ICE_GATHERING {{RTCStats/type}}. Specific stats are added by extending the {{RTCStats}} dictionary.

Note that while stats names are standardized, any given implementation may be using experimental values or values not yet known to the Web application. Thus, applications MUST be prepared to deal with unknown stats.

Statistics need to be synchronized with each other in order to yield reasonable values in computation; for instance, if {{RTCSentRtpStreamStats/bytesSent}} and {{RTCSentRtpStreamStats/packetsSent}} are both reported, they both need to be reported over the same interval, so that "average packet size" can be computed as "bytes / packets" - if the intervals are different, this will yield errors. Thus implementations MUST return synchronized values for all stats in an {{RTCStats}}-derived dictionary.

dictionary RTCStats {
  required DOMHighResTimeStamp timestamp;
  required RTCStatsType type;
  required DOMString id;
};

Dictionary {{RTCStats}} Members

timestamp of type unsigned short DOMHighResTimeStamp

The ICE Agent {{timestamp}}, of type {{DOMHighResTimeStamp}}, associated with this object. The time is gather addresses relative to the UNIX epoch (Jan 1, 1970, UTC). For statistics that came from a remote source (e.g., from received RTCP packets), {{timestamp}} represents the time at which the information arrived at the local endpoint. The remote timestamp can be used. ICE_WAITING found in an additional field in an {{RTCStats}}-derived dictionary, if applicable.

type of type unsigned short {{RTCStatsType}}
THE ICE Agent has complete gathering addresses and is waiting for candidates

The type of this object.

The {{type}} attribute MUST be initialized to start checking. NEGOTIATING the name of the most specific type unsigned short this {{RTCStats}} dictionary represents.

id of type DOMString
The peerConenction object

A unique {{id}} that is attempting associated with the object that was inspected to get produce this {{RTCStats}} object. Two {{RTCStats}} objects, extracted from two different {{RTCStatsReport}} objects, MUST have the same id if they were produced by inspecting the same underlying object.

Stats ids MUST NOT be predictable by an application. This prevents applications from depending on a particular user agent's way of generating ids, since this prevents an application from getting stats objects by their id unless they have already read the id of that specific stats object.

User agents are free to pick any format for the point wehre media id as long as it meets the requirements above.

A user agent can flow. NEW turn a predictably generated string into an unpredictable string using a hash function, as long as it uses a salt that is unique to the peer connection. This allows an implementation to have predictable ids internally, which may make it easier to guarantee that stats objects have stable ids across getStats() calls.

The set of type unsigned short valid values for {{RTCStatsType}}, and the dictionaries derived from RTCStats that they indicate, are documented in [[!WEBRTC-STATS]].

The object was just created stats selection algorithm

The stats selection algorithm is as follows:

  1. Let result be an empty {{RTCStatsReport}}.
  2. If selector is null , gather stats for the whole connection , add them to result , return result , and its ICE abort these steps.
  3. If selector is an {{RTCRtpSender}}, gather stats for and SDP Agent add the following objects to result :
    • All {{RTCOutboundRtpStreamStats}} objects representing RTP streams being sent by selector .
    • All stats objects referenced directly or indirectly by the {{RTCOutboundRtpStreamStats}} objects added.
  4. If selector is an {{RTCRtpReceiver}}, gather stats for and add the following objects to result :
    • All {{RTCInboundRtpStreamStats}} objects representing RTP streams being received by selector .
    • All stats objects referenced directly or indirectly by the {{RTCInboundRtpStreamStats}} added.
  5. Return result .

Mandatory To Implement Stats

The stats listed in [[WEBRTC-STATS]] are intended to cover a wide range of use cases. Not all of them have to be implemented by every WebRTC implementation.

An implementation MUST support generating statistics of the following {{RTCStats/type}}s when the corresponding objects exist on a {{RTCPeerConnection}}, with the fields that are listed when they are valid for that object in addition to the generic fields defined in the {{RTCStats}} dictionary:

{{RTCStatsType}} Dictionary Fields
{{RTCStatsType/"codec"}} {{RTCCodecStats}} {{RTCCodecStats/payloadType}}, {{RTCCodecStats/mimeType}}, {{RTCCodecStats/clockRate}}, {{RTCCodecStats/channels}}, {{RTCCodecStats/sdpFmtpLine}}
{{RTCStatsType/"inbound-rtp"}} {{RTCRtpStreamStats}} {{RTCRtpStreamStats/ssrc}}, {{RTCRtpStreamStats/kind}}, {{RTCRtpStreamStats/transportId}}, {{RTCRtpStreamStats/codecId}}
{{RTCReceivedRtpStreamStats}} {{RTCReceivedRtpStreamStats/packetsReceived}}, {{RTCReceivedRtpStreamStats/packetsLost}}, {{RTCReceivedRtpStreamStats/jitter}},
{{RTCInboundRtpStreamStats}} {{RTCInboundRtpStreamStats/trackIdentifier}}, {{RTCInboundRtpStreamStats/remoteId}}, {{RTCInboundRtpStreamStats/framesDecoded}}, {{RTCInboundRtpStreamStats/framesDropped}} {{RTCInboundRtpStreamStats/nackCount}}, {{RTCInboundRtpStreamStats/framesReceived}}, {{RTCInboundRtpStreamStats/bytesReceived}}, {{RTCInboundRtpStreamStats/totalAudioEnergy}}, {{RTCInboundRtpStreamStats/totalSamplesDuration}} {{RTCInboundRtpStreamStats/packetsDiscarded}},
{{RTCStatsType/"outbound-rtp"}} {{RTCRtpStreamStats}} {{RTCRtpStreamStats/ssrc}}, {{RTCRtpStreamStats/kind}}, {{RTCRtpStreamStats/transportId}}, {{RTCRtpStreamStats/codecId}}
{{RTCSentRtpStreamStats}} {{RTCSentRtpStreamStats/packetsSent}}, {{RTCSentRtpStreamStats/bytesSent}}
{{RTCOutboundRtpStreamStats}} {{RTCOutboundRtpStreamStats/remoteId}}, {{RTCOutboundRtpStreamStats/framesEncoded}}, {{RTCOutboundRtpStreamStats/nackCount}}, {{RTCOutboundRtpStreamStats/framesSent}}
{{RTCStatsType/"remote-inbound-rtp"}} {{RTCRtpStreamStats}} {{RTCRtpStreamStats/ssrc}}, {{RTCRtpStreamStats/kind}}, {{RTCRtpStreamStats/transportId}}, {{RTCRtpStreamStats/codecId}}
{{RTCReceivedRtpStreamStats}} {{RTCReceivedRtpStreamStats/packetsReceived}}, {{RTCReceivedRtpStreamStats/packetsLost}}, {{RTCReceivedRtpStreamStats/jitter}}
{{RTCRemoteInboundRtpStreamStats}} {{RTCRemoteInboundRtpStreamStats/localId}}, {{RTCRemoteInboundRtpStreamStats/roundTripTime}}
{{RTCStatsType/"remote-outbound-rtp"}} {{RTCRtpStreamStats}} {{RTCRtpStreamStats/ssrc}}, {{RTCRtpStreamStats/kind}}, {{RTCRtpStreamStats/transportId}}, {{RTCRtpStreamStats/codecId}}
{{RTCSentRtpStreamStats}} {{RTCSentRtpStreamStats/packetsSent}}, {{RTCSentRtpStreamStats/bytesSent}}
{{RTCRemoteOutboundRtpStreamStats}} {{RTCRemoteOutboundRtpStreamStats/localId}}, {{RTCRemoteOutboundRtpStreamStats/remoteTimestamp}}
{{RTCStatsType/"media-source"}} {{RTCMediaSourceStats}} {{RTCMediaSourceStats/trackIdentifier}}, {{RTCMediaSourceStats/kind}}
{{RTCAudioSourceStats}} {{RTCAudioSourceStats/totalAudioEnergy}}, {{RTCAudioSourceStats/totalSamplesDuration}} (for audio tracks attached to senders)
{{RTCVideoSourceStats}} {{RTCVideoSourceStats/width}}, {{RTCVideoSourceStats/height}}, {{RTCVideoSourceStats/framesPerSecond}} (for video tracks attached to senders)
{{RTCStatsType/"peer-connection"}} {{RTCPeerConnectionStats}} {{RTCPeerConnectionStats/dataChannelsOpened}}, {{RTCPeerConnectionStats/dataChannelsClosed}}
{{RTCStatsType/"data-channel"}} {{RTCDataChannelStats}} {{RTCDataChannelStats/label}} , {{RTCDataChannelStats/protocol}}, {{RTCDataChannelStats/dataChannelIdentifier}}, {{RTCDataChannelStats/state}}, {{RTCDataChannelStats/messagesSent}}, {{RTCDataChannelStats/bytesSent}}, {{RTCDataChannelStats/messagesReceived}}, {{RTCDataChannelStats/bytesReceived}}
{{RTCStatsType/"transport"}} {{RTCTransportStats}} {{RTCTransportStats/bytesSent}}, {{RTCTransportStats/bytesReceived}}, {{RTCTransportStats/selectedCandidatePairId}}, {{RTCTransportStats/localCertificateId}}, {{RTCTransportStats/remoteCertificateId}}
{{RTCStatsType/"candidate-pair"}} {{RTCIceCandidatePairStats}} {{RTCIceCandidatePairStats/transportId}}, {{RTCIceCandidatePairStats/localCandidateId}}, {{RTCIceCandidatePairStats/remoteCandidateId}}, {{RTCIceCandidatePairStats/state}}, {{RTCIceCandidatePairStats/nominated}}, {{RTCIceCandidatePairStats/bytesSent}}, {{RTCIceCandidatePairStats/bytesReceived}}, {{RTCIceCandidatePairStats/totalRoundTripTime}}, {{RTCIceCandidatePairStats/responsesReceived}}, {{RTCIceCandidatePairStats/currentRoundTripTime}}
{{RTCStatsType/"local-candidate"}} {{RTCIceCandidateStats}} {{RTCIceCandidateStats/address}}, {{RTCIceCandidateStats/port}}, {{RTCIceCandidateStats/protocol}}, {{RTCIceCandidateStats/candidateType}}, {{RTCIceCandidateStats/url}}
{{RTCStatsType/"remote-candidate"}}
{{RTCStatsType/"certificate"}} {{RTCCertificateStats}} {{RTCCertificateStats/fingerprint}}, {{RTCCertificateStats/fingerprintAlgorithm}}, {{RTCCertificateStats/base64Certificate}}, {{RTCCertificateStats/issuerCertificateId}}

An implementation MAY support generating any other statistic defined in [[!WEBRTC-STATS]], and MAY generate statistics that are not yet been started. SDP_GLARE documented.

GetStats Example

Consider the case where the user is experiencing bad sound and the application wants to determine if the cause of type it is packet loss. The following example code might be used:

async function gatherStats(pc) {
  try {
    const [sender] = pc.getSenders();
    const baselineReport = await sender.getStats();
    await new Promise(resolve => setTimeout(resolve, aBit)); // wait a bit
    const currentReport = await sender.getStats();

unsigned
short

    // compare the elements from the current report with the baseline
    for (const now of currentReport.values()) {
      if (now.type != 'outbound-rtp') continue;

      // get the corresponding stats from the baseline report
      const base = baselineReport.get(now.id);
      if (!base) continue;

Both
side

      const remoteNow = currentReport.get(now.remoteId);
      const remoteBase = baselineReport.get(base.remoteId);
      const packetsSent = now.packetsSent - base.packetsSent;
      const packetsReceived = remoteNow.packetsReceived -
                              remoteBase.packetsReceived;
      const fractionLost = (packetsSent - packetsReceived) / packetsSent;
      if (fractionLost > 0.3) {
        // if fractionLost is > 0.3, we have probably found the culprit
      }
    }
  } catch (err) {
    console.error(err);
  }
}

Media Stream API Extensions for Network Use

Introduction

The {{MediaStreamTrack}} interface, as defined in the [[!GETUSERMEDIA]] specification, typically represents a stream of data of audio or video. One or more {{MediaStreamTrack}}s can be collected in a {{MediaStream}} (strictly speaking, a {{MediaStream}} as defined in [[!GETUSERMEDIA]] may contain zero or more {{MediaStreamTrack}} objects).

A {{MediaStreamTrack}} may be extended to represent a media flow that either comes from or is sent SDP offers at to a remote peer (and not just the same time local camera, for instance). The extensions required to enable this capability on the {{MediaStreamTrack}} object will be described in this section. How the media is transmitted to the peer is described in [[RFC8834]], [[RFC7874]], and [[RFC8835]].

A {{MediaStreamTrack}} sent to another peer will appear as one and only one {{MediaStreamTrack}} to the SDP Agent recipient. A peer is waiting defined as a user agent that supports this specification. In addition, the sending side application can indicate what {{MediaStream}} object(s) the {{MediaStreamTrack}} is a member of. The corresponding {{MediaStream}} object(s) on the receiver side will be created (if not already present) and populated accordingly.

As also described earlier in this document, the objects {{RTCRtpSender}} and {{RTCRtpReceiver}} can be used by the application to get more fine grained control over the transmission and reception of {{MediaStreamTrack}}s.

Channels are the smallest unit considered in the Media Capture and Streams specification. Channels are intended to be encoded together for transmission as, for instance, an RTP payload type. All of the channels that a codec needs to encode jointly MUST be in the same {{MediaStreamTrack}} and the codecs SHOULD be able to retransmit encode, or discard, all the SDP offer. SDP_IDLE channels in the track.

The concepts of type unsigned short an input and output to a given {{MediaStreamTrack}} apply in the case of {{MediaStreamTrack}} objects transmitted over the network as well. A valid offer anser pair has been exchanged {{MediaStreamTrack}} created by an {{RTCPeerConnection}} object (as described previously in this document) will take as input the data received from a remote peer. Similarly, a {{MediaStreamTrack}} from a local source, for instance a camera via [[!GETUSERMEDIA]], will have an output that represents what is transmitted to a remote peer if the object is used with an {{RTCPeerConnection}} object.

The concept of duplicating {{MediaStream}} and {{MediaStreamTrack}} objects as described in [[!GETUSERMEDIA]] is also applicable here. This feature can be used, for instance, in a video-conferencing scenario to display the SDP Agent local video from the user's camera and microphone in a local monitor, while only transmitting the audio to the remote peer (e.g. in response to the user using a "video mute" feature). Combining different {{MediaStreamTrack}} objects into new {{MediaStream}} objects is waiting useful in certain situations.

In this document, we only specify aspects of the following objects that are relevant when used along with an {{RTCPeerConnection}}. Please refer to the original definitions of the objects in the [[!GETUSERMEDIA]] document for general information on using {{MediaStream}} and {{MediaStreamTrack}}.

MediaStream

id

The {{MediaStream/id}} attribute specified in {{MediaStream}} returns an id that is unique to this stream, so that streams can be recognized at the next SDP transaction. SDP_WAITING remote end of type unsigned short the {{RTCPeerConnection}} API.

When a {{MediaStream}} is created to represent a stream obtained from a remote peer, the {{MediaStream/id}} attribute is initialized from information provided by the remote source.

The SDP Agent has {{MediaStream/id}} of a {{MediaStream}} object is unique to the source of the stream, but that does not mean it is not possible to end up with duplicates. For example, the tracks of a locally generated stream could be sent an SDP offer from one user agent to a remote peer using {{RTCPeerConnection}} and then sent back to the original user agent in the same manner, in which case the original user agent will have multiple streams with the same id (the locally-generated one and the one received from the remote peer).

MediaStreamTrack

A {{MediaStreamTrack}} object's reference to its {{MediaStream}} in the non-local media source case (an RTP source, as is waiting the case for each {{MediaStreamTrack}} associated with an {{RTCRtpReceiver}}) is always strong.

Whenever an {{RTCRtpReceiver}} receives data on an RTP source whose corresponding {{MediaStreamTrack}} is muted, but not ended, and the {{RTCRtpTransceiver/[[Receptive]]}} slot of the {{RTCRtpTransceiver}} object the {{RTCRtpReceiver}} is a response. member of is PeerConnection implements EventTarget ; All instances true , it MUST queue a task to [= set the muted state =] of the corresponding {{MediaStreamTrack}} to false .

When one of the SSRCs for RTP source media streams received by an {{RTCRtpReceiver}} is removed either due to reception of a BYE or via timeout, it MUST queue a task to [= set the muted state =] of the corresponding {{MediaStreamTrack}} to PeerConnection true . Note that {{RTCPeerConnection/setRemoteDescription}} can also lead to [= set the muted state | the setting of the muted state =] of the {{RTCRtpReceiver/track}} to the value true .

The procedures add a track , remove a track and set a track's muted state are specified in [[!GETUSERMEDIA]].

When a {{MediaStreamTrack}} track produced by an {{RTCRtpReceiver}} receiver has ended [[!GETUSERMEDIA]] (such as via a call to receiver .{{RTCRtpReceiver/track}}. stop type are defined ), the user agent MAY choose to also implement free resources allocated for the EventTarget interface. 4.2 SignalingCallback ] interface { }; incoming stream, by for instance turning off the decoder of receiver .

4.2.1 Methods MediaTrackSupportedConstraints, MediaTrackCapabilities, MediaTrackConstraints and MediaTrackSettings

handleEvent

The concept of constraints and constrainable properties, including {{MediaTrackConstraints}} ({{MediaStreamTrack}}. getConstraints() , {{MediaStreamTrack}}. applyConstraints() Def TBD Parameter Type Nullable Optional Description message DOMString ), and {{MediaTrackSettings}} ({{MediaStreamTrack}}. getSettings() ✘ ✘ ) are outlined in [[!GETUSERMEDIA]]. However, the constrainable properties of tracks sourced from a peer connection are different than those sourced by getUserMedia() ; the constraints and settings applicable to {{MediaStreamTrack}}s sourced from a [= remote source PeerConnection =] are defined here. The settings of a remote track represent the latest frame received.

{{MediaStreamTrack}}. getCapabilities() MUST always return the empty set and {{MediaStreamTrack}}. applyConstraints() ✘ ✘ No exceptions. Return type: void MUST always reject with OverconstrainedError 4.3 on remote tracks for constraints defined here.

The following constrainable properties are defined to apply to video {{MediaStreamTrack}}s sourced from a [= remote source =]:

Property Name Values Notes
width {{ConstrainULong}} As a setting, this is the width, in pixels, of the latest frame received.
height {{ConstrainULong}} As a setting, this is the height, in pixels, of the latest frame received.
frameRate {{ConstrainDouble}} As a setting, this is an estimate of the frame rate based on recently received frames.
aspectRatio {{ConstrainDouble}} As a setting, this is the aspect ratio of the latest frame; this is the width in pixels divided by height in pixels as a double rounded to the tenth decimal place.

This document does not define any constrainable properties to apply to audio {{MediaStreamTrack}}s sourced from a [= remote source =].

Examples and Call Flows

Simple Peer-to-peer Example

When two peers decide they are going to set up a connection to each other, they both go through these steps. The STUN/TURN server configuration describes a server they can use to get things like their public IP address or to set up NAT traversal. They also have to send data for the signaling channel to each other using the same out-of-band mechanism they used to establish that they were going to communicate in the first place.

// the first argument describes the STUN/TURN server configuration var local = new PeerConnection('TURNS example.net', sendSignalingChannel); local.signalingChannel(...); // if we have a message from the other side, pass it along here
const signaling = new SignalingChannel(); // handles JSON.stringify/parse
const constraints = {audio: true, video: true};
const configuration = {iceServers: [{urls: 'stun:stun.example.org'}]};
const pc = new RTCPeerConnection(configuration);

// (aLocalStream is some LocalMediaStream object)
local.addStream(aLocalStream); // start sending video

// send any ice candidates to the other peer
pc.onicecandidate = ({candidate}) => signaling.send({candidate});

function sendSignalingChannel(message) {
  ... // send message to the other side via the signaling channel

// let the "negotiationneeded" event trigger offer generation
pc.onnegotiationneeded = async () => {
  try {
    await pc.setLocalDescription();
    // send the offer to the other peer
    signaling.send({description: pc.localDescription});
  } catch (err) {
    console.error(err);
  }
};
pc.ontrack = ({track, streams}) => {
  // once media for a remote track arrives, show it in the remote video element
  track.onunmute = () => {
    // don't set srcObject again if it is already set.
    if (remoteView.srcObject) return;
    remoteView.srcObject = streams[0];
  };
};
// call start() to initiate
function start() {
  addCameraMic();

}
function receiveSignalingChannel (message) {
  // call this whenever we get a message on the signaling channel
  local.signalingChannel(message);

// add camera and microphone to connection
async function addCameraMic() {
  try {
    // get a local stream, show it in a self-view and add it to be sent
    const stream = await navigator.mediaDevices.getUserMedia(constraints);
    for (const track of stream.getTracks()) {
      pc.addTrack(track, stream);
    }
    selfView.srcObject = stream;
  } catch (err) {
    console.error(err);
  }

}
local.onaddstream = function (event) {
  // (videoElement is some <video> element)
  videoElement.src = URL.getObjectURL(event.stream);

signaling.onmessage = async ({data: {description, candidate}}) => {
  try {
    if (description) {
      await pc.setRemoteDescription(description);
      // if we got an offer, we need to reply with an answer
      if (description.type == 'offer') {
        if (!selfView.srcObject) {
          // blocks negotiation on permission (not recommended in production code)
          await addCameraMic();
        }
        await pc.setLocalDescription();
        signaling.send({description: pc.localDescription});
      }
    } else if (candidate) {
      await pc.addIceCandidate(candidate);
    }
  } catch (err) {
    console.error(err);
  }

};
5. The data stream Although progress is being made, there is currently not enough agreement on

Advanced Peer-to-peer Example with Warm-up

When two peers decide they are going to set up a connection to each other and want to have the data channel ICE, DTLS, and media connections "warmed up" such that they are ready to write it up. This section will be filled in as rough consensus is reached. send and receive media immediately, they both go through these steps.

const signaling = new SignalingChannel(); // handles JSON.stringify/parse
const constraints = {audio: true, video: true};
const configuration = {iceServers: [{urls: 'stun:stun.example.org'}]};
let pc;
let audio;
let video;
let started = false;

6.
Garbage
collection

// Call warmup() before media is ready, to warm-up ICE, DTLS, and media.
async function warmup(isAnswerer) {
  pc = new RTCPeerConnection(configuration);
  if (!isAnswerer) {
    audio = pc.addTransceiver('audio');
    video = pc.addTransceiver('video');
  }
  // send any ice candidates to the other peer
  pc.onicecandidate = ({candidate}) => signaling.send({candidate});
  // let the "negotiationneeded" event trigger offer generation
  pc.onnegotiationneeded = async () => {
    try {
      await pc.setLocalDescription();
      // send the offer to the other peer
      signaling.send({description: pc.localDescription});
    } catch (err) {
      console.error(err);
    }
  };
  pc.ontrack = async ({track, transceiver}) => {
    try {
      // once media for the remote track arrives, show it in the video element
      event.track.onunmute = () => {
        // don't set srcObject again if it is already set.
        if (!remoteView.srcObject) {
          remoteView.srcObject = new MediaStream();
        }
        remoteView.srcObject.addTrack(track);
      }
      if (isAnswerer) {
        if (track.kind == 'audio') {
          audio = transceiver;
        } else if (track.kind == 'video') {
          video = transceiver;
        }
        if (started) await addCameraMicWarmedUp();
      }
    } catch (err) {
      console.error(err);
    }
  };
  try {
    // get a local stream, show it in a self-view and add it to be sent
    selfView.srcObject = await navigator.mediaDevices.getUserMedia(constraints);
    if (started) await addCameraMicWarmedUp();
  } catch (err) {
    console.error(err);
  }
}
// call start() after warmup() to begin transmitting media from both ends
function start() {
  signaling.send({start: true});
  signaling.onmessage({data: {start: true}});
}
// add camera and microphone to already warmed-up connection
async function addCameraMicWarmedUp() {
  const stream = selfView.srcObject;
  if (audio && video && stream) {
    await Promise.all([
      audio.sender.replaceTrack(stream.getAudioTracks()[0]),
      video.sender.replaceTrack(stream.getVideoTracks()[0]),
    ]);
  }
}
signaling.onmessage = async ({data: {start, description, candidate}}) => {
  if (!pc) warmup(true);
  try {
    if (start) {
      started = true;
      await addCameraMicWarmedUp();
    } else if (description) {
      await pc.setRemoteDescription(description);
      // if we got an offer, we need to reply with an answer
      if (description.type == 'offer') {
        await pc.setLocalDescription();
        signaling.send({description: pc.localDescription});
      }
    } else {
      await pc.addIceCandidate(candidate);
    }
  } catch (err) {
    console.error(err);
  }
};

Simulcast Example

A Window object has a strong reference client wants to any send multiple RTP encodings (simulcast) to a server.

const signaling = new SignalingChannel(); // handles JSON.stringify/parse
const constraints = {audio: true, video: true};
const configuration = {'iceServers': [{'urls': 'stun:stun.example.org'}]};
let pc;

PeerConnection

// call start() to initiate
async function start() {
  pc = new RTCPeerConnection(configuration);

objects
created
from
the
constructor
whose
global

  // let the "negotiationneeded" event trigger offer generation
  pc.onnegotiationneeded = async () => {
    try {
      await pc.setLocalDescription();
      // send the offer to the other peer
      signaling.send({description: pc.localDescription});
    } catch (err) {
      console.error(err);
    }
  };
  try {
    // get a local stream, show it in a self-view and add it to be sent
    const stream = await navigator.mediaDevices.getUserMedia(constraints);
    selfView.srcObject = stream;
    pc.addTransceiver(stream.getAudioTracks()[0], {direction: 'sendonly'});
    pc.addTransceiver(stream.getVideoTracks()[0], {
      direction: 'sendonly',
      sendEncodings: [
        {rid: 'q', scaleResolutionDownBy: 4.0}
        {rid: 'h', scaleResolutionDownBy: 2.0},
        {rid: 'f'},
      ]
    });
  } catch (err) {
    console.error(err);
  }
}
signaling.onmessage = async ({data: {description, candidate}}) => {
  try {
    if (description) {
      await pc.setRemoteDescription(description);
      // if we got an offer, we need to reply with an answer
      if (description.type == 'offer') {
        await pc.setLocalDescription();
        signaling.send({description: pc.localDescription});
      }
    } else if (candidate) {
      await pc.addIceCandidate(candidate);
    }
  } catch (err) {
    console.error(err);
  }
};

Peer-to-peer Data Example

This example shows how to create an {{RTCDataChannel}} object and perform the offer/answer exchange required to connect the channel to the other peer. The {{RTCDataChannel}} is that used in the context of a simple chat application using an Window input object. field for user input.

const signaling = new SignalingChannel(); // handles JSON.stringify/parse
const configuration = {iceServers: [{urls: 'stun:stun.example.org'}]};
let pc, channel;

7.
Event
definitions
The

// call start() to initiate
function start() {
  pc = new RTCPeerConnection(configuration);

addstream

  // send any ice candidates to the other peer
  pc.onicecandidate = ({candidate}) => signaling.send({candidate});

and

  // let the "negotiationneeded" event trigger offer generation
  pc.onnegotiationneeded = async () => {
    try {
      await pc.setLocalDescription();
      // send the offer to the other peer
      signaling.send({description: pc.localDescription});
    } catch (err) {
      console.error(err);
    }
  };

removestream

  // create data channel and setup chat using "negotiated" pattern
  channel = pc.createDataChannel('chat', {negotiated: true, id: 0});
  channel.onopen = () => input.disabled = false;
  channel.onmessage = ({data}) => showChatMessage(data);

events
use
the

  input.onkeydown = ({key}) => {
    if (key != 'Enter') return;
    channel.send(input.value);
  }
}

MediaStreamEvent

signaling.onmessage = async ({data: {description, candidate}}) => {
  if (!pc) start();

interface:

  try {
    if (description) {
      await pc.setRemoteDescription(description);
      // if we got an offer, we need to reply with an answer
      if (description.type == 'offer') {
        await pc.setLocalDescription();
        signaling.send({description: pc.localDescription});
      }
    } else if (candidate) {
      await pc.addIceCandidate(candidate);
    }
  } catch (err) {
    console.error(err);
  }
};

Call Flow Browser to Browser

This shows an example of one possible call flow between two browsers. This does not show the procedure to get access to local media or every callback that gets fired but instead tries to reduce it down to only show the key events and messages.

A message sequence chart detailing a call flow between two browsers

7.1 MediaStreamEvent DTMF Example

Firing a stream event named e with a MediaStream stream means Examples assume that sender is an event {{RTCRtpSender}}.

Sending the DTMF signal "1234" with 500 ms duration per tone:

if (sender.dtmf.canInsertDTMF) {
  const duration = 500;
  sender.dtmf.insertDTMF('1234', duration);
} else {
  console.log('DTMF function not available');
}

Send the name e , which does not bubble (except where otherwise stated) DTMF signal "123" and is not cancelable (except where otherwise stated), abort after sending "2".

async function sendDTMF() {
  if (sender.dtmf.canInsertDTMF) {
    sender.dtmf.insertDTMF('123');
    await new Promise(r => sender.dtmf.ontonechange = e => e.tone == '2' && r());
    // empty the buffer to not play any tone after "2"
    sender.dtmf.insertDTMF('');
  } else {
    console.log('DTMF function not available');
  }
}

Send the DTMF signal "1234", and which uses light up the MediaStreamEvent active key using lightKey(key) interface with while the tone is playing (assuming that lightKey("") will darken all the keys):

const wait = ms => new Promise(resolve => setTimeout(resolve, ms));
stream

if (sender.dtmf.canInsertDTMF) {
  const duration = 500; // ms
  sender.dtmf.insertDTMF(sender.dtmf.toneBuffer + '1234', duration);
  sender.dtmf.ontonechange = async ({tone}) => {
    if (!tone) return;
    lightKey(tone); // light up the key when playout starts
    await wait(duration);
    lightKey(''); // turn off the light after tone duration
  };
} else {
  console.log('DTMF function not available');
}

It is always safe to append to the tone buffer. This example appends before any tone playout has started as well as during playout.

if (sender.dtmf.canInsertDTMF) {
  sender.dtmf.insertDTMF('123');
  // append more tones to the tone buffer before playout has begun
  sender.dtmf.insertDTMF(sender.dtmf.toneBuffer + '456');

attribute
set

  sender.dtmf.ontonechange = ({tone}) => {
    // append more tones when playout has begun
    if (tone != '1') return;
    sender.dtmf.insertDTMF(sender.dtmf.toneBuffer + '789');
  };
} else {
  console.log('DTMF function not available');
}

Send a 1-second "1" tone followed by a 2-second "2" tone:

if (sender.dtmf.canInsertDTMF) {
  sender.dtmf.ontonechange = ({tone}) => {
    if (tone == '1') {
      sender.dtmf.insertDTMF(sender.dtmf.toneBuffer + '2', 2000);
    }
  };
  sender.dtmf.insertDTMF(sender.dtmf.toneBuffer + '1', 1000);
} else {
  console.log('DTMF function not available');
}

Perfect Negotiation Example

Perfect negotiation is a recommended pattern to stream , must be created manage negotiation transparently, abstracting this asymmetric task away from the rest of an application. This pattern has advantages over one side always being the offerer, as it lets applications operate on both peer connection objects simultaneously without risk of glare (an offer coming in outside of {{RTCSignalingState/"stable"}} state). The rest of the application may use any and dispatched at all modification methods and attributes, without worrying about signaling state races.

It designates different roles to the given target. two peers, with behavior to resolve signaling collisions between them:

{ };
  1. The polite peer uses rollback to avoid collision with an incoming offer.

  2. The impolite peer ignores an incoming offer when this would collide with its own.

Together, they manage signaling for the rest of the application in a manner that doesn't deadlock. The example assumes a polite boolean variable indicating the designated role:

const signaling = new SignalingChannel(); // handles JSON.stringify/parse
const constraints = {audio: true, video: true};
const configuration = {iceServers: [{urls: 'stun:stun.example.org'}]};
const pc = new RTCPeerConnection(configuration);

7.1.1
Attributes

// call start() anytime on either end to add camera and microphone to connection
async function start() {
  try {
    const stream = await navigator.mediaDevices.getUserMedia(constraints);
    for (const track of stream.getTracks()) {
      pc.addTrack(track, stream);
    }
    selfView.srcObject = stream;
  } catch (err) {
    console.error(err);
  }
}

pc.ontrack = ({track, streams}) => {
  // once media for a remote track arrives, show it in the remote video element
  track.onunmute = () => {
    // don't set srcObject again if it is already set.
    if (remoteView.srcObject) return;
    remoteView.srcObject = streams[0];
  };
};

// - The perfect negotiation logic, separated from the rest of the application ---

stream
of
type

// keep track of some negotiation state to prevent races and errors
let makingOffer = false;
let ignoreOffer = false;
let isSettingRemoteAnswerPending = false;

// send any ice candidates to the other peer
pc.onicecandidate = ({candidate}) => signaling.send({candidate});

MediaStream

// let the "negotiationneeded" event trigger offer generation
pc.onnegotiationneeded = async () => {
  try {
    makingOffer = true;
    await pc.setLocalDescription();
    signaling.send({description: pc.localDescription});
  } catch (err) {
     console.error(err);
  } finally {
    makingOffer = false;
  }
};

signaling.onmessage = async ({data: {description, candidate}}) => {
  try {
    if (description) {
      // An offer may come in while we are busy processing SRD(answer).
      // In this case, we will be in "stable" by the time the offer is processed
      // so it is safe to chain it on our Operations Chain now.
      const readyForOffer =
          !makingOffer &&
          (pc.signalingState == "stable" || isSettingRemoteAnswerPending);
      const offerCollision = description.type == "offer" && !readyForOffer;

,
readonly,
nullable

      ignoreOffer = !polite && offerCollision;
      if (ignoreOffer) {
        return;
      }
      isSettingRemoteAnswerPending = description.type == "answer";
      await pc.setRemoteDescription(description); // SRD rolls back as needed
      isSettingRemoteAnswerPending = false;
      if (description.type == "offer") {
        await pc.setLocalDescription();
        signaling.send({description: pc.localDescription});
      }
    } else if (candidate) {
      try {
        await pc.addIceCandidate(candidate);
      } catch (err) {
        if (!ignoreOffer) throw err; // Suppress ignored offer's candidates
      }
    }
  } catch (err) {
    console.error(err);
  }
}

Note that this is timing sensitive, and deliberately uses versions of {{RTCPeerConnection/setLocalDescription}} (without arguments) and {{RTCPeerConnection/setRemoteDescription}} (with implicit rollback) to avoid races with other signaling messages being serviced.

The stream attribute represents ignoreOffer variable is needed, because the MediaStream {{RTCPeerConnection}} object associated with on the event. impolite side is never told about ignored offers. We must therefore suppress errors from incoming candidates belonging to such offers.

Error Handling

Some operations throw or fire {{RTCError}}. This is an extension of {{DOMException}} that carries additional WebRTC-specific information.

RTCError Interface

No exceptions.
[Exposed=Window]
interface RTCError : DOMException {
  constructor(RTCErrorInit init, optional DOMString message = "");
  readonly attribute RTCErrorDetailType errorDetail;
  readonly attribute long? sdpLineNumber;
  readonly attribute long? sctpCauseCode;
  readonly attribute unsigned long? receivedAlert;
  readonly attribute unsigned long? sentAlert;
};
7.1.2 Methods

Constructors

constructor()

Run the following steps:

  1. Let init be the constructor's first argument.

  2. Let message be the constructor's second argument.

  3. Let e be a new {{RTCError}} object.

  4. Invoke the {{DOMException}} constructor of e with the {{DOMException/message}} argument set to message and the {{DOMException/name}} argument set to initMediaStreamEvent "OperationError" .

    This name does not have a mapping to a legacy code so e .{{DOMException/code}} will return 0.

  5. Set all {{RTCError}} attributes of e to the value of the corresponding attribute in init if it is present, otherwise set it to null .

  6. Return e .

Attributes

errorDetail of type RTCErrorDetailType , readonly

The initMediaStreamEvent() WebRTC-specific error code for the type of error that occurred.

sdpLineNumber method must initialize of type long , readonly, nullable

If {{RTCError/errorDetail}} is {{RTCErrorDetailType/"sdp-syntax-error"}} this is the event in line number where the error was detected (the first line has line number 1).

sctpCauseCode of type long , readonly, nullable

If {{RTCError/errorDetail}} is {{RTCErrorDetailType/"sctp-failure"}} this is the SCTP cause code of the failed SCTP negotiation.

receivedAlert of type unsigned long , readonly, nullable

If {{RTCError/errorDetail}} is {{RTCErrorDetailType/"dtls-failure"}} and a manner analogous to fatal DTLS alert was received, this is the similarly-named method value of the DTLS alert received.

sentAlert of type unsigned long , readonly, nullable

If {{RTCError/errorDetail}} is {{RTCErrorDetailType/"dtls-failure"}} and a fatal DTLS alert was sent, this is the value of the DTLS alert sent.

All attributes defined in {{RTCError}} are marked at risk due to lack of implementation ({{errorDetail}}, {{sdpLineNumber}}, {{sctpCauseCode}}, {{receivedAlert}} and {{sentAlert}}). This does not include attributes inherited from {{DOMException}}.

RTCErrorInit Dictionary

dictionary RTCErrorInit {
  required RTCErrorDetailType errorDetail;
  long sdpLineNumber;
  long sctpCauseCode;
  unsigned long receivedAlert;
  unsigned long sentAlert;
};

The errorDetail , sdpLineNumber , sctpCauseCode , receivedAlert and sentAlert members of {{RTCErrorInit}} have the DOM Events interfaces. [ DOM-LEVEL-3-EVENTS ] same definitions as the attributes of the same name of {{RTCError}}.

RTCErrorDetailType Enum

enum RTCErrorDetailType {
  "data-channel-failure",
  "dtls-failure",
  "fingerprint-failure",
  "sctp-failure",
  "sdp-syntax-error",
  "hardware-encoder-not-available",
  "hardware-encoder-error"
};
typeArg DOMString ✘ ✘ canBubbleArg boolean ✘ ✘ cancelableArg boolean ✘ ✘ streamArg MediaStream ✔ ✘
{{RTCErrorDetailType}} Enumeration description
Parameter Type Nullable Optional Enum value Description
data-channel-failure The data channel has failed.
dtls-failure The DTLS negotiation has failed or the connection has been terminated with a fatal error. The {{DOMException/message}} contains information relating to the nature of error. If a fatal DTLS alert was received, the {{RTCError/receivedAlert}} attribute is set to the value of the DTLS alert received. If a fatal DTLS alert was sent, the {{RTCError/sentAlert}} attribute is set to the value of the DTLS alert sent.
fingerprint-failure The {{RTCDtlsTransport}}'s remote certificate did not match any of the fingerprints provided in the SDP. If the remote peer cannot match the local certificate against the provided fingerprints, this error is not generated. Instead a "bad_certificate" (42) DTLS alert might be received from the remote peer, resulting in a {{RTCErrorDetailType/"dtls-failure"}}.
sctp-failure The SCTP negotiation has failed or the connection has been terminated with a fatal error. The {{RTCError/sctpCauseCode}} attribute is set to the SCTP cause code.
sdp-syntax-error The SDP syntax is not valid. The {{RTCError/sdpLineNumber}} attribute is set to the line number in the SDP where the syntax error was detected.
hardware-encoder-not-available The hardware encoder resources required for the requested operation are not available.
hardware-encoder-error The hardware encoder does not support the provided parameters.
No exceptions.

RTCErrorEvent Interface

The {{RTCErrorEvent}} interface is defined for cases when an {{RTCError}} is raised as an event:

Return type: void
[Exposed=Window]
interface RTCErrorEvent : Event {
  constructor(DOMString type, RTCErrorEventInit eventInitDict);
  [SameObject] readonly attribute RTCError error;
};

Constructors

constructor()

Constructs a new {{RTCErrorEvent}}.

Attributes

error of type {{RTCError}} , readonly

The {{RTCError}} describing the error that triggered the event.

RTCErrorEventInit Dictionary

          dictionary RTCErrorEventInit : EventInit {
  required RTCError error;
};

8. Dictionary RTCErrorEventInit Members

error of type {{RTCError}}

The {{RTCError}} describing the error associated with the event (if any).

Event summary

This section is non-normative.

The following event fires events fire on MediaStream {{RTCDataChannel}} objects:

Event name Interface Fired when...
ended open Event {{Event}} The MediaStream object will no longer stream any data, either because the user revoked the permissions, or because the source device {{RTCDataChannel}} object's [= underlying data transport =] has been ejected, established (or re-established).
message {{MessageEvent}} [[html]] A message was successfully received.
bufferedamountlow {{Event}} The {{RTCDataChannel}} object's {{RTCDataChannel/bufferedAmount}} decreases from above its {{RTCDataChannel/bufferedAmountLowThreshold}} to less than or because equal to its {{RTCDataChannel/bufferedAmountLowThreshold}}.
error {{RTCErrorEvent}} An error occurred on the remote peer stopped sending data, or because data channel.
closing {{Event}} The {{RTCDataChannel}} object transitions to the stop() method was invoked. {{RTCDataChannelState/"closing"}} state
close {{Event}} The {{RTCDataChannel}} object's [= underlying data transport =] has been closed.

The following events fire on PeerConnection {{RTCPeerConnection}} objects:

Event name Interface Fired when...
connecting track Event {{RTCTrackEvent}} The ICE Agent New incoming media has begun negotiating with been negotiated for a specific {{RTCRtpReceiver}}, and that receiver's {{RTCRtpReceiver/track}} has been added to any associated remote {{MediaStream}}s.
negotiationneeded {{Event}} The browser wishes to inform the peer. application that session negotiation needs to be done (i.e. a createOffer call followed by setLocalDescription).
signalingstatechange {{Event}} The connection's {{RTCPeerConnection/[[SignalingState]]}} has changed. This can happen multiple times during state change is the lifetime result of the PeerConnection object. either {{RTCPeerConnection/setLocalDescription}} or {{RTCPeerConnection/setRemoteDescription}} being invoked.
open iceconnectionstatechange Event {{Event}} The ICE Agent {{RTCPeerConnection}}'s {{RTCPeerConnection/[[IceConnectionState]]}} has finished negotiating with the peer. changed.
message icegatheringstatechange MessageEvent {{Event}} A data UDP media stream message was received. The {{RTCPeerConnection}}'s {{RTCPeerConnection/[[IceGatheringState]]}} has changed.
addstream icecandidate MediaStreamEvent {{RTCPeerConnectionIceEvent}} A new stream has been added {{RTCIceCandidate}} is made available to the remoteStreams array. script.
removestream connectionstatechange MediaStreamEvent {{Event}} The {{RTCPeerConnection}}.{{RTCPeerConnection/connectionState}} has changed.
icecandidateerror {{RTCPeerConnectionIceErrorEvent}} A stream failure occured when gathering ICE candidates.
datachannel {{RTCDataChannelEvent}} A new {{RTCDataChannel}} is dispatched to the script in response to the other peer creating a channel.

The following events fire on {{RTCDTMFSender}} objects:

Event name Interface Fired when...
tonechange {{RTCDTMFToneChangeEvent}} The {{RTCDTMFSender}} object has been removed from either just begun playout of a tone (returned as the remoteStreams array. {{RTCDTMFToneChangeEvent/tone}} attribute) or just ended the playout of tones in the {{RTCDTMFSender/toneBuffer}} (returned as an empty value in the {{RTCDTMFToneChangeEvent/tone}} attribute).

The following events fire on {{RTCIceTransport}} objects:

Event name Interface Fired when...
statechange {{Event}} The {{RTCIceTransport}} state changes.
gatheringstatechange {{Event}} The {{RTCIceTransport}} gathering state changes.
selectedcandidatepairchange {{Event}} The {{RTCIceTransport}}'s selected candidate pair changes.

The following events fire on {{RTCDtlsTransport}} objects:

Event name Interface Fired when...
statechange {{Event}} The {{RTCDtlsTransport}} state changes.
error {{RTCErrorEvent}} An error occurred on the {{RTCDtlsTransport}} (either {{RTCErrorDetailType/"dtls-failure"}} or {{RTCErrorDetailType/"fingerprint-failure"}}).

The following events fire on {{RTCSctpTransport}} objects:

Event name Interface Fired when...
statechange {{Event}} The {{RTCSctpTransport}} state changes.

9. application/html-peer-connection-data Privacy and Security Considerations

This registration section is for community review and will be submitted to non-normative; it specifies no new behaviour, but instead summarizes information already present in other parts of the IESG for review, approval, specification. The overall security considerations of the general set of APIs and registration with IANA. protocols used in WebRTC are described in [[?RFC8827]].

Type name: application Subtype name: html-peer-connection-data Required parameters: No required parameters Optional parameters: No optional parameters Encoding considerations:

Impact on same origin policy

This MIME type defines a binary protocol format which uses UTF-8 for text encoding. Security considerations: document extends the Web platform with the ability to set up real-time, direct communication between browsers and other devices, including other browsers.

This format means that data and media can be shared between applications running in different browsers, or between an application running in the same browser and something that is used not a browser, something that is an extension to the usual barriers in the Web model against sending data between entities with different origins.

The WebRTC specification provides no user prompts or chrome indicators for encoding UDP packets transmitted by potentially hostile communication; it assumes that once the Web page content via a trusted user agent has been allowed to access media, it is free to share that media with other entities as it chooses. Peer-to-peer exchanges of data view WebRTC datachannels can thus occur without any user explicit consent or involvement, similarly as a destination selected by server-mediated exchange (e.g. via Web Sockets) could occur without user involvement.

Revealing IP addresses

Even without WebRTC, the Web server providing a potentially hostile remote server. To prevent this mechanism from being abused for cross-protocol attacks, all Web application will know the data in these packets public IP address to which the application is masked so as delivered. Setting up communications exposes additional information about the browser’s network context to appear the web application, and may include the set of (possibly private) IP addresses available to be random noise. The intent the browser for WebRTC use. Some of this masking is information has to be passed to reduce the potential attack scenarios corresponding party to those already possible previously. enable the establishment of a communication session.

However, Revealing IP addresses can leak location and means of connection; this feature still allows random data to can be sent to destinations sensitive. Depending on the network environment, it can also increase the fingerprinting surface and create persistent cross-origin state that might cannot easily be cleared by the user.

A connection will always reveal the IP addresses proposed for communication to the corresponding party. The application can limit this exposure by choosing not to use certain addresses using the settings exposed by the {{RTCIceTransportPolicy}} dictionary, and by using relays (for instance TURN servers) rather than direct connections between participants. One will normally have been able assume that the IP address of TURN servers is not sensitive information. These choices can for instance be made by the application based on whether the user has indicated consent to receive them, such as start a media connection with the other party.

Mitigating the exposure of IP addresses to hosts within the victim's intranet. If a service within such an intranet cannot handle receiving UDP packets containing random noise, it might application itself requires limiting the IP addresses that can be vulnerable used, which will impact the ability to attack from this feature. Interoperability considerations: Rules communicate on the most direct path between endpoints. Browsers are encouraged to provide appropriate controls for processing both conforming and non-conforming content deciding which IP addresses are defined made available to applications, based on the security posture desired by the user. The choice of which addresses to expose is controlled by local policy (see [[RFC8828]] for details).

Impact on local network

Since the browser is an active platform executing in this specification. Published specification: This document a trusted network environment (inside the firewall), it is important to limit the relevant specification. Applications damage that use this media type: This type is only intended for use with SDP. [SDP] Additional information: Magic number(s): No sequence of bytes the browser can uniquely identify data in this format, as all data in this format do to other elements on the local network, and it is intentionally masked important to avoid cross-protocol attacks. File extension(s): protect data from interception, manipulation and modification by untrusted participants.

Mitigations include:

Fragment identifiers These measures are specified in the relevant IETF documents.

Confidentiality of Communications

The fact that communication is taking place cannot be used with application/html-peer-connection-data hidden from adversaries that can observe the network, so this has to be regarded as URLs cannot public information.

Communication certificates may be used opaquely shared using {{MessagePort/postMessage(message, options)}} in anticipation of future needs. User agents are strongly encouraged to identify streams isolate the private keying material these objects hold a handle to, from the processes that use this format. have access to the {{RTCCertificate}} objects, to reduce memory attack surface.

10. Change Log Persistent information exposed by WebRTC

This section will As described above, the list of IP addresses exposed by the WebRTC API can be removed before publication. used as a persistent cross-origin state.

To Do Items

Need a way to indicate Beyond IP addresses, the type WebRTC API exposes information about the underlying media system via the {{RTCRtpSender}}.{{RTCRtpSender/getCapabilities}} and {{RTCRtpReceiver}}.{{RTCRtpReceiver/getCapabilities}} methods, including detailed and ordered information about the codecs that the system is able to produce and consume. A subset of that information is likely to be represented in the SDP when passing SDP strings. session descriptions generated, exposed and transmitted during session negotiation . That information is in most cases persistent across time and origins, and increases the fingerprint surface of a given device.

Changes since 23 August 2011 Separated

When establishing DTLS connections, the WebRTC API can generate certificates that can be persisted by the application (e.g. in IndexedDB). These certificates are not shared across origins, and get cleared when persistent storage is cleared for the origin.

Setting SDP from remote endpoints

{{RTCPeerConnection/setRemoteDescription}} guards against malformed and ICE Agent into separate agents invalid SDP by throwing exceptions, but makes no attempt to guard against SDP that might be unexpected by the application. Setting the remote description can cause significant resources to be allocated (including image buffers and added explicit state attributes network ports), media to start flowing (which may have privacy and bandwidth implications) among other things. An application that does not guard against malicious SDP could be at risk of resource deprivation, unintentionally allowing incoming media or at risk of not having certain events fire like {{RTCPeerConnection/ontrack}} if the other endpoint does not negotiate sending. Applications need to be on guard against malevolent SDP.

Accessibility Considerations

The WebRTC 1.0 specification exposes an API to control protocols (defined within the IETF) necessary to establish real-time audio, video and data exchange.

The Telecommunications Device for each. Removed the send method Deaf (TDD/TTY) enables individuals who are hearing or speech impaired (among others) to communicate over telephone lines. Real-Time Text, defined in [[RFC4103]], utilizes T.140 encapsulated in RTP to enable the transition from PeerConenction TDD/TTY devices to IP-based communications, including emergency communication with Public Safety Access Points (PSAP) .

Since Real-Time Text requires the ability to send and associated callback function. Modified MediaStream() constructor receive data in near real time, it can be best supported via the WebRTC 1.0 data channel API. As defined by the IETF, the data channel protocol utilizes the SCTP/DTLS/UDP protocol stack, which supports both reliable and unreliable data channels. The IETF chose to take standardize SCTP/DTLS/UDP over proposals for an RTP data channel which relied on SRTP key management and were focused on unreliable communications.

Since the IETF chose a list different approach than the RTP data channel as part of MediaStreamTrack objects instead the WebRTC suite of protocols, as of the time of this publication there is no standardized way for the WebRTC APIs to directly support Real-Time Text as defined at IETF and implemented in U.S. (FCC) regulations. The WebRTC working Group will evaluate whether the developing IETF protocols in this space warrant direct exposure in the browser APIs and is looking for input from the relevant user communities on this potential gap.

Within the IETF MMUSIC Working Group , work is ongoing to enable Real-time text to be sent over the WebRTC data channel , allowing gateways to be deployed to translate between the SCTP data channel protocol and RFC 4103 Real-Time Text. This work, once completed, is expected to enable a MediaStream. Removed unified and interoperable approach for integrating real-time text about MediaStream parent in WebRTC user-agents (including browsers) - through a gateway or otherwise.

At the time of this publication, gateways that enable effective RTT support in WebRTC clients can be developed e.g. through a custom WebRTC data channel. This is deemed sufficient until such time as future standardized gateways are enabled via IETF protocols such as the SCTP data channel protocol and child relationship. Added abstract. RFC 4103 Real-Time Text. This will need to be defined at IETF in conjunction with related work at W3C groups to effectively and consistently standardise RTT support internationally.

Candidate Amendments

Since its publication as a W3C Recommendation in January 2021 , the following candidate amendments have been integrated in this document.

A. Acknowledgements

The editors wish to thank the Working Group chairs, Harald Alvestrand chairs and Team Contact, Harald Alvestrand, Stefan Håkansson, Erik Lagerway and Dominique Hazaël-Massieux, for their support. B. References B.1 Normative references [DOM-LEVEL-3-EVENTS] Björn Höhrmann; Tom Pixley; Philippe Le Hégaret. Document Object Model (DOM) Level 3 Events Specification. 31 May 2011. W3C Working Draft. (Work Substantial text in progress.) URL: http://www.w3.org/TR/2011/WD-DOM-Level-3-Events-20110531/ [FILE-API] Arun Ranganathan. File API. 17 November 2009. W3C Working Draft. (Work this specification was provided by many people including Martin Thomson, Harald Alvestrand, Justin Uberti, Eric Rescorla, Peter Thatcher, Jan-Ivar Bruaroey and Peter Saint-Andre. Dan Burnett would like to acknowledge the significant support received from Voxeo and Aspect during the development of this specification.

The {{RTCRtpSender}} and {{RTCRtpReceiver}} objects were initially described in progress.) URL: http://www.w3.org/TR/2009/WD-FileAPI-20091117/ [WEBIDL] Cameron McCormack. Web IDL. 19 December 2008. the W3C Working Draft. (Work ORTC CG , and have been adapted for use in progress.) URL: http://www.w3.org/TR/2008/WD-WebIDL-20081219 B.2 Informative references No informative references. this specification.