This document defines a set of ECMAScript APIs in WebIDL to allow media
and generic application data to be sent to and received from another
browser or device implementing the appropriate set of real-time
protocols. This specification is being developed in conjunction with a
protocol specification developed by the IETF RTCWEB group and an API
specification to get access to local media devices.
Its associated
test suite has been used to build an implementation
report of the API at the time of its initial publication as a Recommendation. That test suite has been updated to integrate proposed and candidates amendments identified since then, and an updated implementation report focused on the implementation status of these amendments has been used to select features with double implementation as proposed amendments, now fully incorporated in this version of the Recommendation.
Introduction
There are a number of facets to peer-to-peer communications and
video-conferencing in HTML covered by this specification:
Connecting to remote peers using NAT-traversal technologies such as
ICE, STUN, and TURN.
Sending the locally-produced tracks to remote peers and receiving
tracks from remote peers.
Sending arbitrary data directly to remote peers.
This document defines the APIs used for these features. This
specification is being developed in conjunction with a protocol
specification developed by the IETF RTCWEB group and an
API specification to get access to local media devices [[GETUSERMEDIA]]
developed by the WebRTC Working Group. An overview of the system can be
found in [[RFC8825]] and [[RFC8826]].
This specification defines conformance criteria that apply to a single
product: the user agent that implements the interfaces that
it contains.
Conformance requirements phrased as algorithms or specific steps may be
implemented in any manner, so long as the end result is equivalent. (In
particular, the algorithms defined in this specification are intended
to be easy to follow, and not intended to be performant.)
Implementations that use ECMAScript to implement the APIs defined in
this specification MUST implement them in a manner consistent with the
ECMAScript Bindings defined in the Web IDL specification [[!WEBIDL]],
as this specification uses that specification and terminology.
Terminology
The {{EventHandler}} interface, representing a callback used for event
handlers, is defined in [[!HTML]].
The concepts [= queue a task =] and [= networking task source =] are
defined in [[!HTML]].
The concept [= fire an event =] is defined in [[!DOM]].
The terms [= event =], [= event handlers =] and [= event handler event
types =] are defined in [[!HTML]].
{{Performance.timeOrigin}} and {{Performance.now()}} are defined in
[[!hr-time]].
The terms serializable objects, [= serialization steps =], and [=
deserialization steps =] are defined in [[!HTML]].
The terms {{MediaStream}}, {{MediaStreamTrack}}, and
{{MediaStreamConstraints}} are defined in [[!GETUSERMEDIA]]. Note that
{{MediaStream}} is extended in
in this document while {{MediaStreamTrack}} is extended in in this document.
The term {{Blob}} is defined in [[!FILEAPI]].
The term media description is defined in [[!RFC4566]].
The term media transport is defined in [[!RFC7656]].
The term generation is defined in [[RFC8838]] Section
2.
The terms stats
object and monitored object are defined
in [[!WEBRTC-STATS]].
When referring to exceptions, the terms [= exception/throw =] and [=
exception/created =] are defined in [[!WEBIDL]].
The callback {{VoidFunction}} is defined in [[!WEBIDL]].
The term "throw" is used as specified in [[!INFRA]]: it terminates the
current processing steps.
The terms fulfilled,
rejected, resolved, and
settled used in the context of Promises are defined in
[[!ECMASCRIPT-6.0]].
The AlgorithmIdentifier is
defined in [[!WebCryptoAPI]].
The general principles for Javascript APIs apply, including the
principle of run-to-completion
and no-data-races as defined in [[API-DESIGN-PRINCIPLES]]. That is,
while a task is running, external events do not influence what's
visible to the Javascript application. For example, the amount of data
buffered on a data channel will increase due to "send" calls while
Javascript is executing, and the decrease due to packets being sent
will be visible after a task checkpoint.
It is the responsibility of the user agent to make sure the set of
values presented to the application is consistent - for instance that
getContributingSources() (which is synchronous) returns values for all
sources measured at the same time.
Peer-to-peer connections
Introduction
An {{RTCPeerConnection}} instance allows an application to establish
peer-to-peer communications with another {{RTCPeerConnection}}
instance in another browser, or to another endpoint implementing the
required protocols. Communications are coordinated by the exchange of
control messages (called a signaling protocol) over a signaling
channel which is provided by unspecified means, but generally by a
script in the page via the server, e.g. using {{WebSocket}} or
{{XMLHttpRequest}}.
Configuration
RTCConfiguration Dictionary
The {{RTCConfiguration}} defines a set of parameters to configure
how the peer-to-peer communication established via
{{RTCPeerConnection}} is established or re-established.
iceServers of type sequence<{{RTCIceServer}}>,
defaulting to [].
An array of objects describing servers available to be used
by ICE, such as STUN and TURN servers.
If the number of ICE servers exceeds an
implementation-defined limit, ignore the ICE servers above
the threshold. This implementation defined limit MUST be
at least 32.
iceTransportPolicy of type
{{RTCIceTransportPolicy}},
defaulting to "all".
Indicates which candidates the [= ICE Agent =] is allowed
to use.
bundlePolicy of type {{RTCBundlePolicy}}, defaulting to
"balanced".
Indicates which media-bundling policy to use when gathering ICE candidates.
rtcpMuxPolicy of type {{RTCRtcpMuxPolicy}}, defaulting to
"require".
Indicates which rtcp-mux policy to use when gathering ICE candidates.
certificates of type sequence<{{RTCCertificate}}>,
defaulting to [].
A set of certificates that the {{RTCPeerConnection}} uses
to authenticate.
Valid values for this parameter are created through calls
to the {{RTCPeerConnection/generateCertificate()}}
function.
Although any given DTLS connection will use only one
certificate, this attribute allows the caller to provide
multiple certificates that support different algorithms.
The final certificate will be selected based on the DTLS
handshake, which establishes which certificates are
allowed. The {{RTCPeerConnection}} implementation selects
which of the certificates is used for a given connection;
how certificates are selected is outside the scope of this
specification.
Existing implementations only utilize the first certificate
provided; the others are ignored.
If this value is [=map/exists|absent=], then a default set of certificates
is generated for each {{RTCPeerConnection}} instance.
This option allows applications to establish key
continuity. An {{RTCCertificate}} can be persisted in
[[?INDEXEDDB]] and reused. Persistence and reuse also
avoids the cost of key generation.
The value for this configuration option cannot change after
its value is initially selected.
iceCandidatePoolSize of type
octet, defaulting to
0
Size of the prefetched ICE pool as defined in
[[!RFC9429]].
RTCIceServer Dictionary
The {{RTCIceServer}} dictionary is used to describe the STUN and
TURN servers that can be used by the [= ICE Agent =] to establish a
connection with a peer.
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 [= ICE Agent =] uses only media relay candidates such
as candidates passing through a TURN server.
This can be used to prevent the remote endpoint from
learning the user's IP addresses, which may be desired in
certain use cases. For example, in a "call"-based
application, the application may want to prevent an
unknown caller from learning the callee's IP addresses
until the callee has consented in some way.
all
The [= ICE Agent =] can use any type of candidate when
this value is specified.
The implementation can still use its own candidate
filtering policy in order to limit the IP addresses
exposed to the application, as noted in the description
of {{RTCIceCandidate}}.{{RTCIceCandidate/address}}.
RTCBundlePolicy Enum
As described in [[!RFC9429]],
bundle policy affects which media tracks are negotiated if the
remote endpoint is not bundle-aware, and what ICE candidates are
gathered. If the remote endpoint is bundle-aware, all media tracks
and data channels are bundled onto the same transport.
Gather ICE candidates for each media type in use (audio,
video, and data). If the remote endpoint is not
bundle-aware, negotiate only one audio and video track on
separate transports.
max-compat
Gather ICE candidates for each track. If the remote
endpoint is not bundle-aware, negotiate all media tracks on
separate transports.
max-bundle
Gather ICE candidates for only one track. If the remote
endpoint is not bundle-aware, negotiate only one media
track.
RTCRtcpMuxPolicy Enum
As described in [[!RFC9429]], the
{{RTCRtcpMuxPolicy}} affects what ICE candidates are gathered to
support non-multiplexed RTCP. The only value defined in this spec
is {{RTCRtcpMuxPolicy/"require"}}.
enum RTCRtcpMuxPolicy {
"require"
};
{{RTCRtcpMuxPolicy}} Enumeration description
Enum 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 used to control
the offer/answer creation process.
When the value of this dictionary member is
true, or the relevant {{RTCPeerConnection}}
object's {{RTCPeerConnection/[[LocalIceCredentialsToReplace]]}} slot is
not empty, then the generated description will have ICE
credentials that are different from the current credentials
(as visible in the
{{RTCPeerConnection/currentLocalDescription}} attribute's
SDP). Applying the generated description will restart ICE,
as described in section 9.1.1.1 of [[RFC5245]].
When the value of this dictionary member is
false, and the relevant {{RTCPeerConnection}}
object's {{RTCPeerConnection/[[LocalIceCredentialsToReplace]]}} slot is
empty, and the
{{RTCPeerConnection/currentLocalDescription}} attribute has
valid ICE credentials, then the generated description will
have the same ICE credentials as the current value from the
{{RTCPeerConnection/currentLocalDescription}} attribute.
Performing an ICE restart is recommended when
{{RTCPeerConnection/iceConnectionState}} transitions to
{{RTCIceConnectionState/"failed"}}. An application may
additionally choose to listen for the
{{RTCPeerConnection/iceConnectionState}} transition to
{{RTCIceConnectionState/"disconnected"}} and then use other
sources of information (such as using
{{RTCPeerConnection/getStats}} to measure if the number of
bytes sent or received over the next couple of seconds
increases) to determine whether an ICE restart is
advisable.
The RTCAnswerOptions dictionary describe options
specific to session description of type {{RTCSdpType/"answer"}}
(none in this version of the specification).
There is no offer/answer exchange in progress. This is also
the initial state, in which case the local and remote
descriptions are empty.
have-local-offer
A local description, of type {{RTCSdpType/"offer"}}, has
been successfully applied.
have-remote-offer
A remote description, of type {{RTCSdpType/"offer"}}, has
been successfully applied.
have-local-pranswer
A remote description of type {{RTCSdpType/"offer"}} has
been successfully applied and a local description of type
{{RTCSdpType/"pranswer"}} has been successfully applied.
have-remote-pranswer
A local description of type {{RTCSdpType/"offer"}} has been
successfully applied and a remote description of type
{{RTCSdpType/"pranswer"}} has been successfully applied.
closed
The {{RTCPeerConnection}} has been closed; its
{{RTCPeerConnection/[[IsClosed]]}} slot is true.
Non-normative signaling state transitions diagram. Method calls
abbreviated.
An example set of transitions might be:
Caller transition:
new RTCPeerConnection(): {{RTCSignalingState/"stable"}}
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.
{{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.
The {{RTCPeerConnection}} object's {{RTCPeerConnection/[[IsClosed]]}}
slot is true.
failed
The previous state doesn't apply and any
{{RTCIceTransport}}s are in the
{{RTCIceTransportState/"failed"}} state.
disconnected
None of the previous states apply and any
{{RTCIceTransport}}s are in the
{{RTCIceTransportState/"disconnected"}} state.
new
None of the previous states apply and all
{{RTCIceTransport}}s are in the
{{RTCIceTransportState/"new"}} or
{{RTCIceTransportState/"closed"}} state, or there are no
transports.
checking
None of the previous states apply and any
{{RTCIceTransport}}s are in the
{{RTCIceTransportState/"new"}} or
{{RTCIceTransportState/"checking"}} state.
completed
None of the previous states apply and all
{{RTCIceTransport}}s are in the
{{RTCIceTransportState/"completed"}} or
{{RTCIceTransportState/"closed"}} state.
connected
None of the previous states apply and all
{{RTCIceTransport}}s are in the
{{RTCIceTransportState/"connected"}},
{{RTCIceTransportState/"completed"}} or
{{RTCIceTransportState/"closed"}} state.
The set of transports considered is the one
presently referenced by the {{RTCPeerConnection}}'s
[= set of transceivers =] and the {{RTCPeerConnection}}'s
{{RTCPeerConnection/[[SctpTransport]]}}
internal slot if not null.
Note that if an {{RTCIceTransport}} is discarded as a result of
signaling (e.g. RTCP mux or bundling), or created as a result of
signaling (e.g. adding a new [= media description =]), the state
may advance directly from one state to another.
RTCPeerConnection Interface
The [[!RFC9429]] specification, as a whole, describes the details of how
the {{RTCPeerConnection}} operates. References to specific
subsections of [[!RFC9429]] are provided as appropriate.
Operation
Calling new
{{RTCPeerConnection}}(configuration) creates an
{{RTCPeerConnection}} object.
configuration.{{RTCConfiguration/iceServers}} contains
information used to find and access the servers used by ICE. The
application can supply multiple servers of each type, and any TURN
server MAY also be used as a STUN server for the purposes of
gathering server reflexive candidates.
An {{RTCPeerConnection}} object has a
{{RTCPeerConnection/[[SignalingState]]}}, and the aggregated states
{{RTCPeerConnection/[[ConnectionState]]}},
{{RTCPeerConnection/[[IceGatheringState]]}}, and
{{RTCPeerConnection/[[IceConnectionState]]}}.
These are initialized when the object is created.
The ICE protocol implementation of an {{RTCPeerConnection}} is
represented by an ICE agent [[RFC5245]]. Certain
{{RTCPeerConnection}} methods involve interactions with the [= ICE
Agent =], namely {{addIceCandidate}}, {{setConfiguration}},
{{setLocalDescription}}, {{setRemoteDescription}} and {{close}}.
These interactions are described in the relevant sections in this
document and in [[!RFC9429]]. The [= ICE Agent =] also provides
indications to the user agent when the state of its internal
representation of an {{RTCIceTransport}} changes, as described in
.
The task source for the tasks listed in this section is the [=
networking task source =].
The state of the SDP negotiation is represented by the internal variables
{{RTCPeerConnection/[[SignalingState]]}},
{{RTCPeerConnection/[[CurrentLocalDescription]]}},
{{RTCPeerConnection/[[CurrentRemoteDescription]]}},
{{RTCPeerConnection/[[PendingLocalDescription]]}} and
{{RTCPeerConnection/[[PendingRemoteDescription]]}}. These are only set inside the
{{setLocalDescription}} and {{setRemoteDescription}} operations,
and modified by the {{addIceCandidate}} operation and the [=
surface a candidate =] procedure. In each case, all the
modifications to all the five variables are completed before the
procedures fire any events or invoke any callbacks, so the
modifications are made visible at a single point in time.
As one of the unloading document cleanup steps, run the
following steps:
Let window be document's [=relevant global object=].
For each {{RTCPeerConnection}} object connection
whose [=relevant global object=] is window, [= close the connection
=] with connection and the value true.
Constructor
When the RTCPeerConnection.constructor() is
invoked, the user agent MUST run the following steps:
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.
Let connection be a newly created
{{RTCPeerConnection}} object.
Let connection have a
[[\DocumentOrigin]] internal slot, initialized to
the [= relevant settings object =]'s
[=environment settings object/origin=].
Let configuration be the
method's first argument.
If the {{RTCConfiguration/certificates}} value in
configuration is non-empty, run the following
steps for each certificate in certificates:
If the value of
certificate.{{RTCCertificate/expires}} is less
than the current time, [= exception/throw =] an
{{InvalidAccessError}}.
If certificate.{{RTCCertificate/[[Origin]]}} is not
same origin with
connection.{{RTCPeerConnection/[[DocumentOrigin]]}}, [=
exception/throw =] an {{InvalidAccessError}}.
Store certificate.
Else, generate one or more new {{RTCCertificate}} instances
with this {{RTCPeerConnection}} instance and store them. This
MAY happen asynchronously and the value of
{{RTCConfiguration/certificates}} remains
undefined for the subsequent steps. As noted in
Section 4.3.2.3 of [[RFC8826]], WebRTC utilizes
self-signed rather than Public Key Infrastructure (PKI)
certificates, so that the expiration check is to ensure that
keys are not used indefinitely and additional certificate
checks are unnecessary.
Initialize connection's [= ICE Agent =].
Let connection have a
[[\Configuration]]
internal slot, initialized to null.
[= Set the configuration =] specified by configuration.
Let connection have an [[\IsClosed]]
internal slot, initialized to false.
Let connection have a
[[\NegotiationNeeded]] internal slot, initialized
to false.
Let connection have an
[[\SctpTransport]] internal slot,
initialized to null.
Let connection have an
[[\LastStableStateSctpTransport]] internal slot,
initialized to null.
Let connection have a
[[\DataChannels]] internal slot, initialized to
an empty [=ordered set=].
Let connection have an [[\Operations]]
internal slot, representing an [= operations chain =],
initialized to an empty list.
Let connection have a
[[\UpdateNegotiationNeededFlagOnEmptyChain]]
internal slot, initialized to false.
Let connection have an
[[\LastCreatedOffer]] internal slot, initialized
to "".
Let connection have an
[[\LastCreatedAnswer]] internal slot, initialized
to "".
Let connection have an
[[\EarlyCandidates]] internal slot, initialized to
an empty list.
Let connection have an
[[\SignalingState]]
internal slot, initialized to {{RTCSignalingState/"stable"}}.
Let connection have an
[[\IceConnectionState]]
internal slot, initialized to {{RTCIceConnectionState/"new"}}.
Let connection have an
[[\IceGatheringState]]
internal slot, initialized to {{RTCIceGatheringState/"new"}}.
Let connection have an
[[\ConnectionState]]
internal slot, initialized to {{RTCPeerConnectionState/"new"}}.
Let connection have a
[[\PendingLocalDescription]] internal slot,
initialized to null.
Let connection have a
[[\CurrentLocalDescription]] internal slot,
initialized to null.
Let connection have a
[[\PendingRemoteDescription]] internal slot,
initialized to null.
Let connection have a
[[\CurrentRemoteDescription]] internal slot,
initialized to null.
Let connection have a
[[\LocalIceCredentialsToReplace]] internal slot,
initialized to an empty set.
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:
Let connection be the {{RTCPeerConnection}}
object.
If connection.{{RTCPeerConnection/[[IsClosed]]}} is
true, return a promise [= rejected =] with a
newly [= exception/created =] {{InvalidStateError}}.
Let operation be the operation to be chained.
Let p be a new promise.
Append operation to {{RTCPeerConnection/[[Operations]]}}.
If the length of {{RTCPeerConnection/[[Operations]]}} is exactly 1, execute
operation.
Upon [= fulfillment =] or [= rejection =] of the promise
returned by the operation, run the following
steps:
If connection.{{RTCPeerConnection/[[IsClosed]]}} is
true, abort these steps.
If the promise returned by operation was [=
fulfilled =] with a value, [= fulfill =] p
with that value.
If the promise returned by operation was [=
rejected =] with a value, [= reject =] p with
that value.
Upon [= fulfillment =] or [= rejection =] of
p, execute the following steps:
If connection.{{RTCPeerConnection/[[IsClosed]]}} is
true, abort these steps.
Remove the first element of {{RTCPeerConnection/[[Operations]]}}.
If {{RTCPeerConnection/[[Operations]]}} is non-empty, execute the
operation represented by the first element of
{{RTCPeerConnection/[[Operations]]}}, and abort these steps.
If
connection.{{RTCPeerConnection/[[UpdateNegotiationNeededFlagOnEmptyChain]]}}
is false, abort these steps.
Set
connection.{{RTCPeerConnection/[[UpdateNegotiationNeededFlagOnEmptyChain]]}}
to false.
Update the negotiation-needed flag for
connection.
Return p.
Update the connection state
An {{RTCPeerConnection}} object has an aggregated
{{RTCPeerConnection/[[ConnectionState]]}}.
Whenever the state of an {{RTCDtlsTransport}} changes,
the user agent MUST queue a task that runs the following steps:
Let connection be this {{RTCPeerConnection}}
object associated with the {{RTCDtlsTransport}} object whose state changed.
If connection.{{RTCPeerConnection/[[IsClosed]]}} is
true, abort these steps.
Let newState be the value of deriving a new state
value as described by the {{RTCPeerConnectionState}} enum.
If connection.{{RTCPeerConnection/[[ConnectionState]]}} is equal to
newState, abort these steps.
Set connection.{{RTCPeerConnection/[[ConnectionState]]}} to
newState.
[= Fire an event =] named {{RTCPeerConnection/connectionstatechange}} at
connection.
Set the session description
To
set a local session description description on
an {{RTCPeerConnection}} object connection, [=
set a session description | set the session description =]
description on connection with the additional
value false.
To
set a remote session description description
on an {{RTCPeerConnection}} object connection, [=
set a session description | set the session description =]
description on connection with the additional
value true.
To set
a session description description on an
{{RTCPeerConnection}} object connection, given a
remote boolean, run the following steps:
Let p be a new promise.
If description.{{RTCSessionDescriptionInit/type}} is
{{RTCSdpType/"rollback"}} and
connection.{{RTCPeerConnection/[[SignalingState]]}}
is either {{RTCSignalingState/"stable"}},
{{RTCSignalingState/"have-local-pranswer"}}, or
{{RTCSignalingState/"have-remote-pranswer"}}, then [= reject
=] p with a newly [= exception/created =]
{{InvalidStateError}} and abort these steps.
Let jsepSetOfTransceivers be a shallow copy of
connection's [= set of transceivers =].
[=In parallel=], start the process to apply
description as described in [[!RFC9429]],
with these additional restrictions:
Use jsepSetOfTransceivers as the source of
truth with regard to what "RtpTransceivers" exist, and
their {{RTCRtpTransceiver/[[JsepMid]]}} internal slot as their "mid
property".
If remote is false and this
triggers the ICE candidate gathering process in [[!RFC9429]], the [= ICE Agent =]
MUST NOT gather candidates from gathering sources that are
[= administratively prohibited =].
If remote is true and this
triggers ICE connectivity checks in [[!RFC9429]], the
[= ICE Agent =] MUST NOT attempt to connect to candidates
that are [= administratively prohibited =].
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.
If the process to apply description fails for
any reason, then the user agent MUST queue a task that
runs the following steps:
If connection.{{RTCPeerConnection/[[IsClosed]]}} is
true, then abort these steps.
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.
If the process to apply description failed to
parse the SDP as defined in [[!RFC9429]] Section 5.8.
including session-level parsing (5.8.1.) and media-level
parsing (5.8.2.), but excluding semantics verification
(5.8.3.), then [= reject =] p with an
{{RTCError}} (with {{RTCError/errorDetail}} set to
{{RTCErrorDetailType/"sdp-syntax-error"}} and the
{{RTCError/sdpLineNumber}} attribute set to the line
number in the SDP where the syntax error was
detected) and abort these steps.
If remote is true, the
connection's {{RTCRtcpMuxPolicy}} is
{{RTCRtcpMuxPolicy/require}} and the description does
not use RTCP mux, then [= reject =] p with
a newly [= exception/created =]
{{InvalidAccessError}} and abort these steps.
If the description attempted to renegotiate RIDs, as
described above, then [= reject =] p with
a newly [= exception/created =]
{{InvalidAccessError}} and abort these steps.
If the description failed semantics
validation as defined in [[!RFC9429]] Section 5.8.3.,
then [= reject =] p with a newly [=
exception/created =] {{InvalidAccessError}} and abort
these steps.
For all other errors, [= reject =] p with
a newly [= exception/created =] {{OperationError}}.
If description is applied successfully, the
user agent MUST queue a task that runs the following
steps:
If connection.{{RTCPeerConnection/[[IsClosed]]}} is
true, then abort these steps.
If remote is true and
description is of type
{{RTCSdpType/"offer"}}, then if any
{{RTCPeerConnection/addTrack()}} methods on
connection succeeded
during the process to apply description,
abort these steps and start the process over as if
they had succeeded prior, to include the extra
transceiver(s) in the process.
If any promises from {{RTCRtpSender/setParameters}}
methods on {{RTCRtpSender}}s associated with
connection are not [=settled=], abort these
steps and start the process over.
If description is of type
{{RTCSdpType/"offer"}} and
connection.{{RTCPeerConnection/[[SignalingState]]}}
is {{RTCSignalingState/"stable"}}, then run the following steps:
Set
connection.{{RTCPeerConnection/[[LastStableStateSctpTransport]]}}
to
connection.{{RTCPeerConnection/[[SctpTransport]]}}.
For each transceiver in connection's
[= set of transceivers =], run the following steps:
Set
transceiver.{{RTCRtpTransceiver/[[Sender]]}}.{{RTCRtpSender/[[LastStableStateSenderTransport]]}}
to
transceiver.{{RTCRtpTransceiver/[[Sender]]}}.{{RTCRtpSender/[[SenderTransport]]}}.
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`.
Set
transceiver.{{RTCRtpTransceiver/[[Receiver]]}}.{{RTCRtpReceiver/[[LastStableStateReceiverTransport]]}}
to
transceiver.{{RTCRtpTransceiver/[[Receiver]]}}.{{RTCRtpReceiver/[[ReceiverTransport]]}}.
Set
transceiver.{{RTCRtpTransceiver/[[Receiver]]}}.{{RTCRtpReceiver/[[LastStableStateAssociatedRemoteMediaStreams]]}}
to
transceiver.{{RTCRtpTransceiver/[[Receiver]]}}.{{RTCRtpReceiver/[[AssociatedRemoteMediaStreams]]}}.
Set
transceiver.{{RTCRtpTransceiver/[[Receiver]]}}.{{RTCRtpReceiver/[[LastStableStateReceiveCodecs]]}}
to
transceiver.{{RTCRtpTransceiver/[[Receiver]]}}.{{RTCRtpReceiver/[[ReceiveCodecs]]}}.
If remote is false, then run
one of the following steps:
If description is of type
{{RTCSdpType/"offer"}}, set
connection.{{RTCPeerConnection/[[PendingLocalDescription]]}}
to a new {{RTCSessionDescription}} object
constructed from description, set
connection.{{RTCPeerConnection/[[SignalingState]]}} to
{{RTCSignalingState/"have-local-offer"}}, and [=
release early candidates =].
If description is of type
{{RTCSdpType/"answer"}}, then this completes an
offer answer negotiation. Set
connection.{{RTCPeerConnection/[[CurrentLocalDescription]]}}
to a new {{RTCSessionDescription}} object
constructed from description, and set
connection.{{RTCPeerConnection/[[CurrentRemoteDescription]]}}
to
connection.{{RTCPeerConnection/[[PendingRemoteDescription]]}}.
Set both
connection.{{RTCPeerConnection/[[PendingRemoteDescription]]}}
and
connection.{{RTCPeerConnection/[[PendingLocalDescription]]}}
to null. Set both
connection.{{RTCPeerConnection/[[LastCreatedOffer]]}}
and
connection.{{RTCPeerConnection/[[LastCreatedAnswer]]}}
to "", set
connection.{{RTCPeerConnection/[[SignalingState]]}} to
{{RTCSignalingState/"stable"}}, and [= release
early candidates =]. Finally, if none of the ICE
credentials in
connection.{{RTCPeerConnection/[[LocalIceCredentialsToReplace]]}}
are present in description, then set
connection.{{RTCPeerConnection/[[LocalIceCredentialsToReplace]]}}
to an empty set.
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 =].
Otherwise, (if remote is
true) run one of the following steps:
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"}}.
If description is of type
{{RTCSdpType/"answer"}}, then this completes an
offer answer negotiation. Set
connection.{{RTCPeerConnection/[[CurrentRemoteDescription]]}}
to a new {{RTCSessionDescription}} object
constructed from description, and set
connection.{{RTCPeerConnection/[[CurrentLocalDescription]]}}
to
connection.{{RTCPeerConnection/[[PendingLocalDescription]]}}.
Set both
connection.{{RTCPeerConnection/[[PendingRemoteDescription]]}}
and
connection.{{RTCPeerConnection/[[PendingLocalDescription]]}}
to null. Set both
connection.{{RTCPeerConnection/[[LastCreatedOffer]]}}
and
connection.{{RTCPeerConnection/[[LastCreatedAnswer]]}}
to "", and set
connection.{{RTCPeerConnection/[[SignalingState]]}} to
{{RTCSignalingState/"stable"}}. Finally, if none
of the ICE credentials in
connection.{{RTCPeerConnection/[[LocalIceCredentialsToReplace]]}}
are present in the newly set
connection.{{RTCPeerConnection/[[CurrentLocalDescription]]}},
then set
connection.{{RTCPeerConnection/[[LocalIceCredentialsToReplace]]}}
to an empty set.
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"}}.
If description is of type
{{RTCSdpType/"offer"}}, and it describes an
SCTP association as defined in [[RFC8841]]
Section 10.2, and
connection.{{RTCPeerConnection/[[SctpTransport]]}}
is null, set
connection.{{RTCPeerConnection/[[SctpTransport]]}}
to the result of
[= create an RTCSctpTransport|creating an RTCSctpTransport =]
with an initial state of
{{RTCSctpTransportState/"connecting"}}.
If description is of type
{{RTCSdpType/"answer"}}, and it initiates the closure
of an existing SCTP association, as defined in
[[RFC8841]], Sections 10.3 and 10.4, set
connection.{{RTCPeerConnection/[[SctpTransport]]}} to
null.
Let trackEventInits,
muteTracks, addList,
removeList and errorList be
empty lists.
If description is of type
{{RTCSdpType/"answer"}} or {{RTCSdpType/"pranswer"}},
then run the following steps:
If description initiates the
establishment of a new SCTP association, as
defined in [[RFC8841]], Sections 10.3 and 10.4,
or an SCTP association already exists,
[= update the data max message size =] of
connection.{{RTCPeerConnection/[[SctpTransport]]}}.
If description negotiates the DTLS
role of the SCTP transport, then for each
{{RTCDataChannel}}, channel, with a
null {{RTCDataChannel/id}}, run the
following step:
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.
If description is not of type
{{RTCSdpType/"rollback"}}, then run the following
steps:
If remote is false, then
run the following steps for each [= media
description =] in description:
If the [= media description =] was not yet [=
associated =] with an {{RTCRtpTransceiver}}
object then run the following steps:
Let transceiver be the
{{RTCRtpTransceiver}} used to create the
[= media description =].
Set
transceiver.{{RTCRtpTransceiver/[[Mid]]}} to
transceiver.{{RTCRtpTransceiver/[[JsepMid]]}}.
If
transceiver.{{RTCRtpTransceiver/[[Stopped]]}}
is true, abort these sub
steps.
If the [= media description =] is
indicated as using an existing [= media
transport =] according to [[RFC8843]],
let transport be the
{{RTCDtlsTransport}} object representing
the RTP/RTCP component of that transport.
Otherwise, let transport be a
newly created {{RTCDtlsTransport}} object
with a new underlying
{{RTCIceTransport}}.
Set
transceiver.{{RTCRtpTransceiver/[[Sender]]}}.{{RTCRtpSender/[[SenderTransport]]}}
to transport.
Set
transceiver.{{RTCRtpTransceiver/[[Receiver]]}}.{{RTCRtpReceiver/[[ReceiverTransport]]}}
to transport.
Let transceiver be the
{{RTCRtpTransceiver}} [= associated =] with
the [= media description =].
If transceiver.{{RTCRtpTransceiver/[[Stopped]]}}
is true, abort these sub steps.
Let direction be an
{{RTCRtpTransceiverDirection}} value
representing the direction from the [= media
description =].
If direction is
{{RTCRtpTransceiverDirection/"sendrecv"}} or
{{RTCRtpTransceiverDirection/"recvonly"}},
set
transceiver.{{RTCRtpTransceiver/[[Receptive]]}}
to true, otherwise set it to
false.
Set
transceiver.{{RTCRtpTransceiver/[[Receiver]]}}.{{RTCRtpReceiver/[[ReceiveCodecs]]}}
to the codecs that description
negotiates for receiving and which the user
agent is currently prepared to receive.
If the direction is
{{RTCRtpTransceiverDirection/"sendonly"}} or
{{RTCRtpTransceiverDirection/"inactive"}},
the receiver is not prepared to receive
anything, and the list will be empty.
If description is of type
{{RTCSdpType/"answer"}} or
{{RTCSdpType/"pranswer"}}, then run the
following steps:
If transceiver.
{{RTCRtpTransceiver/[[Sender]]}}.{{RTCRtpSender/[[SendEncodings]]}}
.length is greater than 1, then
run the following steps:
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.
If description is missing any of
the previously negotiated layers, then
remove the dictionaries that correspond to
the missing layers from
transceiver.{{RTCRtpTransceiver/[[Sender]]}}.{{RTCRtpSender/[[SendEncodings]]}}.
Set
transceiver.{{RTCRtpTransceiver/[[Sender]]}}.{{RTCRtpSender/[[SendCodecs]]}}
to the codecs that description
negotiates for sending and which the user
agent is currently capable of sending,
and set
transceiver.{{RTCRtpTransceiver/[[Sender]]}}.{{RTCRtpSender/[[LastReturnedParameters]]}}
to null.
If direction is
{{RTCRtpTransceiverDirection/"sendonly"}}
or
{{RTCRtpTransceiverDirection/"inactive"}},
and
transceiver.{{RTCRtpTransceiver/[[FiredDirection]]}}
is either
{{RTCRtpTransceiverDirection/"sendrecv"}}
or
{{RTCRtpTransceiverDirection/"recvonly"}},
then run the following steps:
[= Set the associated remote streams
=] given
transceiver.{{RTCRtpTransceiver/[[Receiver]]}},
an empty list, another empty list,
and removeList.
[= process the removal of a remote
track =] for the [= media description
=], given transceiver and
muteTracks.
Set
transceiver.{{RTCRtpTransceiver/[[CurrentDirection]]}}
and
transceiver.{{RTCRtpTransceiver/[[FiredDirection]]}}
to direction.
Otherwise, (if remote is
true) run the following steps for
each [= media description =] in
description:
If the description is of type
{{RTCSdpType/"offer"}} and the
[= media description =] contains a request
to receive simulcast, use the order of the
rid values specified in the simulcast
attribute to create an
{{RTCRtpEncodingParameters}} dictionary for
each of the simulcast layers, populating the
{{RTCRtpCodingParameters/rid}} member
according to the corresponding rid value
(using only the first value if
comma-separated alternatives exist), and
let proposedSendEncodings be the
list containing the created dictionaries.
Otherwise, let proposedSendEncodings
be an empty list.
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.
Let supportedEncodings be the
maximum number of encodings that the
implementation can support. If the length of
proposedSendEncodings is greater than
supportedEncodings, truncate
proposedSendEncodings so that its length is
supportedEncodings.
If proposedSendEncodings is non-empty,
set each encoding's
{{RTCRtpEncodingParameters/scaleResolutionDownBy}}
to 2^(length of proposedSendEncodings -
encoding index - 1).
As described by [[!RFC9429]],
attempt to find an existing
{{RTCRtpTransceiver}} object,
transceiver, to represent the [=
media description =].
If a suitable transceiver was found
(transceiver is set), and
proposedSendEncodings is non-empty,
run the following steps:
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.
If no suitable transceiver was found
(transceiver is unset), run the
following steps:
[= Create an RTCRtpSender =],
sender, from the [= media
description =] using
proposedSendEncodings.
[= Create an RTCRtpReceiver =],
receiver, from the [= media
description =].
[= Create an RTCRtpTransceiver =] with
sender, receiver
and an {{RTCRtpTransceiverDirection}}
value of
{{RTCRtpTransceiverDirection/"recvonly"}},
and let transceiver be the
result.
Add transceiver to the
connection's [= set of
transceivers =].
If description is of type
{{RTCSdpType/"answer"}} or
{{RTCSdpType/"pranswer"}}, and
transceiver.
{{RTCRtpTransceiver/[[Sender]]}}.{{RTCRtpSender/[[SendEncodings]]}}
.length is greater than 1, then
run the following steps:
If description indicates that
simulcast is not supported or desired, or
description is missing all of
the previously negotiated layers,
then remove all dictionaries in
transceiver.{{RTCRtpTransceiver/[[Sender]]}}.{{RTCRtpSender/[[SendEncodings]]}}
except the first one and abort these sub
steps.
If description is missing any of
the previously negotiated layers, then
remove the dictionaries that correspond to
the missing layers from
transceiver.{{RTCRtpTransceiver/[[Sender]]}}.{{RTCRtpSender/[[SendEncodings]]}}.
Set transceiver.{{RTCRtpTransceiver/[[Mid]]}} to
transceiver.{{RTCRtpTransceiver/[[JsepMid]]}}.
Let direction be an
{{RTCRtpTransceiverDirection}} value
representing the direction from the [= media
description =], but with the send and receive
directions reversed to represent this peer's
point of view. If the [= media description =]
is rejected, set direction to
{{RTCRtpTransceiverDirection/"inactive"}}.
If direction is
{{RTCRtpTransceiverDirection/"sendrecv"}} or
{{RTCRtpTransceiverDirection/"recvonly"}},
let msids be a list of the MSIDs
that the media description indicates
transceiver.{{RTCRtpTransceiver/[[Receiver]]}}.{{RTCRtpReceiver/[[ReceiverTrack]]}}
is to be associated with. Otherwise, let
msids be an empty list.
msids will be an empty list here
if [= media description =] is rejected.
[= Process remote tracks =] with
transceiver, direction,
msids, addList,
removeList, and
trackEventInits.
Set
transceiver.{{RTCRtpTransceiver/[[Receiver]]}}.{{RTCRtpReceiver/[[ReceiveCodecs]]}}
to the codecs that description
negotiates for receiving and which the user
agent is currently prepared to receive.
If description is of type
{{RTCSdpType/"answer"}} or
{{RTCSdpType/"pranswer"}}, then run the
following steps:
Set
transceiver.{{RTCRtpTransceiver/[[Sender]]}}.{{RTCRtpSender/[[SendCodecs]]}}
to the codecs that description
negotiates for sending and which the user
agent is currently capable of sending.
Set
transceiver.{{RTCRtpTransceiver/[[CurrentDirection]]}}
to direction.
Let transport be the
{{RTCDtlsTransport}} object representing
the RTP/RTCP component of the [= media
transport =] used by
transceiver's [= associated =]
[= media description =], according to
[[RFC8843]].
Set
transceiver.{{RTCRtpTransceiver/[[Sender]]}}.{{RTCRtpSender/[[SenderTransport]]}}
to transport.
Set
transceiver.{{RTCRtpTransceiver/[[Receiver]]}}.{{RTCRtpReceiver/[[ReceiverTransport]]}}
to transport.
Set the {{RTCIceTransport/[[IceRole]]}} of
transport according to the
rules of [[RFC8445]].
The rules of [[RFC8445]] that apply here
are:
If {{RTCIceTransport/[[IceRole]]}} is not
{{RTCIceRole/unknown}}, do not modify
{{RTCIceTransport/[[IceRole]]}}.
If description is a
local offer, set it to
{{RTCIceRole/controlling}}.
If description is a
remote offer, and contains
a=ice-lite,
set {{RTCIceTransport/[[IceRole]]}} to
{{RTCIceRole/controlling}}.
If description is a
remote offer, and does not contain
a=ice-lite,
set {{RTCIceTransport/[[IceRole]]}} to
{{RTCIceRole/controlled}}.
This ensures that
{{RTCIceTransport/[[IceRole]]}} always has a value
after the first offer is processed.
If the [= media description =] is rejected,
and
transceiver.{{RTCRtpTransceiver/[[Stopped]]}} is
false, then [= stop the
RTCRtpTransceiver =] transceiver.
Otherwise, (if description is of type
{{RTCSdpType/"rollback"}}) run the following steps:
Let pendingDescription be either
connection.{{RTCPeerConnection/[[PendingLocalDescription]]}}
or
connection.{{RTCPeerConnection/[[PendingRemoteDescription]]}},
whichever one is not null.
Set
connection.{{RTCPeerConnection/[[SctpTransport]]}}
to
connection.{{RTCPeerConnection/[[LastStableStateSctpTransport]]}}.
For each transceiver in the
connection's [= set of transceivers =]
run the following steps:
If transceiver was not [=
associated =] with a [= media description =]
prior to pendingDescription being set,
disassociate it and set both
transceiver.{{RTCRtpTransceiver/[[JsepMid]]}}
and transceiver.{{RTCRtpTransceiver/[[Mid]]}} to
null.
Set
transceiver.{{RTCRtpTransceiver/[[Sender]]}}.{{RTCRtpSender/[[SenderTransport]]}}
to
transceiver.{{RTCRtpTransceiver/[[Sender]]}}.{{RTCRtpSender/[[LastStableStateSenderTransport]]}}.
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]]}}.
Set
transceiver.{{RTCRtpTransceiver/[[Receiver]]}}.{{RTCRtpReceiver/[[ReceiverTransport]]}}
to
transceiver.{{RTCRtpTransceiver/[[Receiver]]}}.{{RTCRtpReceiver/[[LastStableStateReceiverTransport]]}}.
Set
transceiver.{{RTCRtpTransceiver/[[Receiver]]}}.{{RTCRtpReceiver/[[ReceiveCodecs]]}}
to
transceiver.{{RTCRtpTransceiver/[[Receiver]]}}.{{RTCRtpReceiver/[[LastStableStateReceiveCodecs]]}}.
If
connection.{{RTCPeerConnection/[[SignalingState]]}}
is {{RTCSignalingState/"have-remote-offer"}},
run the following sub steps:
Let msids be a list of the
ids of all
{{MediaStream}} objects in
transceiver.{{RTCRtpTransceiver/[[Receiver]]}}.{{RTCRtpReceiver/[[LastStableStateAssociatedRemoteMediaStreams]]}},
or an empty list if there are none.
Process remote tracks with
transceiver,
transceiver.{{RTCRtpTransceiver/[[CurrentDirection]]}},
msids, addList,
removeList, and
trackEventInits.
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 =].
Set
connection.{{RTCPeerConnection/[[PendingLocalDescription]]}}
and
connection.{{RTCPeerConnection/[[PendingRemoteDescription]]}}
to null, and set
connection.{{RTCPeerConnection/[[SignalingState]]}} to
{{RTCSignalingState/"stable"}}.
If description is of type
{{RTCSdpType/"answer"}}, then run the following
steps:
For each transceiver in the
connection's [= set of transceivers =]
run the following steps:
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 =].
If connection.{{RTCPeerConnection/[[SignalingState]]}} is
now {{RTCSignalingState/"stable"}}, run the following
steps:
For any transceiver that was removed
from the [= set of transceivers =] in a previous
step, if any of its transports
(transceiver.{{RTCRtpTransceiver/[[Sender]]}}.{{RTCRtpSender/[[SenderTransport]]}}
or
transceiver.{{RTCRtpTransceiver/[[Receiver]]}}.{{RTCRtpReceiver/[[ReceiverTransport]]}})
are still not closed and they're no longer
referenced by a non-stopped transceiver, close
the {{RTCDtlsTransport}}s and their associated
{{RTCIceTransport}}s. This results in events
firing on these objects in a queued task.
For each transceiver in connection's [= set of transceivers =]:
Let codecs be transceiver.{{RTCRtpTransceiver/[[Sender]]}}.{{RTCRtpSender/[[SendCodecs]]}}.
If codecs is not an empty list:
For each encoding in
transceiver.{{RTCRtpTransceiver/[[Sender]]}}.{{RTCRtpSender/[[SendEncodings]]}},
if encoding.{{RTCRtpEncodingParameters/codec}} does not match any entry in
codecs, using the [= codec dictionary match =] algorithm with
ignoreAsymmetricalParameters set to true, [=map/remove=]
encoding.{{RTCRtpEncodingParameters/codec}}.
[= Clear the negotiation-needed flag =] and [=
update the negotiation-needed flag =].
If connection.{{RTCPeerConnection/[[SignalingState]]}}
changed above, [= fire an event =] named
{{RTCPeerConnection/signalingstatechange}} at connection.
For each channel in errorList,
[= fire an event =] named {{RTCDataChannel/error}}
using the {{RTCErrorEvent}} interface with the
{{RTCError/errorDetail}} attribute set to
{{RTCErrorDetailType/"data-channel-failure"}} at
channel.
For each track in muteTracks,
[= set the muted state =] of track to the
value true.
For each stream and track pair
in removeList, [= remove the track =]
track from stream.
For each stream and track pair
in addList, [= add the track =]
track to stream.
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.
[= Resolve =] p with
undefined.
Return p.
Set the configuration
To set a configuration with
configuration, run the following steps:
Let connection be the target {{RTCPeerConnection}}
object.
Let oldConfig be
connection.{{RTCPeerConnection/[[Configuration]]}}.
If oldConfig is not null, run the
following steps, and if any of them fail, [= exception/throw =]
an {{InvalidModificationError}}:
If the length of
configuration.{{RTCConfiguration/certificates}}
is different from the length of
oldConfig.{{RTCConfiguration/certificates}},
fail.
Let index be 0.
While index is less than the length of
configuration.{{RTCConfiguration/certificates}},
run the following steps:
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.
Increment index by 1.
If the value of
configuration.{{RTCConfiguration/bundlePolicy}}
differs from
oldConfig.{{RTCConfiguration/bundlePolicy}},
then fail.
If the value of
configuration.{{RTCConfiguration/rtcpMuxPolicy}}
differs from
oldConfig.{{RTCConfiguration/rtcpMuxPolicy}},
then fail.
If the value of
configuration.{{RTCConfiguration/iceCandidatePoolSize}}
differs from
oldConfig.{{RTCConfiguration/iceCandidatePoolSize}},
and {{RTCPeerConnection/setLocalDescription}} has already been
called, then fail.
Let iceServers be
configuration.{{RTCConfiguration/iceServers}}.
Truncate iceServers to the maximum number of supported elements.
For each server in
iceServers,
run the following steps:
Let urls be
server.{{RTCIceServer/urls}}.
If urls is a string, set urls to a
list consisting of just that string.
If urls is empty, [= exception/throw =] a
"{{SyntaxError}}" {{DOMException}}.
For each url in urls, run the [=validate an ICE server URL=] algorithm on url.
Set the [= ICE Agent =]'s ICE transports setting to the
value of
configuration.{{RTCConfiguration/iceTransportPolicy}}.
As defined in [[!RFC9429]], if the new [= ICE
transports setting =] changes the existing setting, no action
will be taken until the next gathering phase. If a script
wants this to happen immediately, it should do an ICE
restart.
Set the [= ICE Agent =]'s prefetched ICE candidate pool
size as defined in [[!RFC9429]] to the
value of
configuration.{{RTCConfiguration/iceCandidatePoolSize}}.
If the new [= ICE candidate pool size =] changes the existing
setting, this may result in immediate gathering of new pooled
candidates, or discarding of existing pooled candidates, as
defined in [[!RFC9429]].
Set the [= ICE Agent =]'s ICE
servers list to
iceServers.
As defined in [[!RFC9429]], if a new list of servers
replaces the [= ICE Agent =]'s existing [= ICE servers list=], no
action will be taken until the next gathering phase. If a
script wants this to happen immediately, it should do an ICE
restart. However, if the [= ICE candidate pool size | ICE
candidate pool =] has a nonzero size, any existing pooled
candidates will be discarded, and new candidates will be
gathered from the new servers.
Store configuration in the
{{RTCPeerConnection/[[Configuration]]}} internal slot.
To validate an ICE server URL url, run the following steps:
Let parsedURL be the result of
[=basic url parser|parsing=]
url.
If any of the following conditions apply, then [=exception/throw=] a
"{{SyntaxError}}" {{DOMException}}:
parsedURL is failure
parsedURL's [=url/scheme=] is neither `"stun"`,
`"stuns"`, `"turn"`, nor `"turns"`
parsedURL does not have an [=url/opaque path=]
parsedURL's [=url/opaque path=] contains one or more `"/"` or `"@"`
parsedURL's [=url/fragment=] is non-null
parsedURL's [=url/scheme=] is `"stun"` or `"stuns"`,
and parsedURL's [=url/query=] is non-null
If parsedURL's [=url/scheme=] is not implemented by the
user agent, then [=exception/throw=] a {{NotSupportedError}}.
Let hostAndPortURL be result of
[=basic url parser|parsing=] the concatenation of
`"https://"` and parsedURL's [=url/path=].
If hostAndPortURL is failure, then [=exception/throw=] a
"{{SyntaxError}}" {{DOMException}}.
If hostAndPortURL's [=url/path=],
[=url/username=], or [=url/password=] is non-null, then
[=exception/throw=] a "{{SyntaxError}}" {{DOMException}}.
For "stun" and "stuns" schemes, this validates
[[!RFC7064]] section 3.1.
For "turn" and "turns" schemes, this and the steps below validate
[[!RFC7065]] section 3.1.
If parsedURL's [=url/query=] is non-null and if parsedURL's [=url/query=] is different from either "transport=udp" or "transport=tcp", [=exception/throw=] a "{{SyntaxError}}" {{DOMException}}.
If parsedURL's' [=url/scheme=] is "turn" or
"turns", and either of
server.{{RTCIceServer/username}} or
server.{{RTCIceServer/credential}} are
[=map/exist|missing=] or their UTF-8 representations
fail to conform to [[RFC8489]] section 14.3 and [[RFC8265]]
section 4.1 respectively, then [= exception/throw =] an
{{InvalidAccessError}}.
Interface Definition
The RTCPeerConnection interface presented in this
section is extended by several partial interfaces throughout this
specification. Notably, the [= RTP Media API =] section, which adds
the APIs to send and receive {{MediaStreamTrack}} objects.
localDescription
of type {{RTCSessionDescription}}, readonly,
nullable
The {{localDescription}} attribute MUST return
the [=local description=].
The local description is
{{RTCPeerConnection/[[PendingLocalDescription]]}} if it is not
null, otherwise it is
{{RTCPeerConnection/[[CurrentLocalDescription]]}}.
Note that
{{RTCPeerConnection/[[CurrentLocalDescription]]}}.{{RTCSessionDescription/sdp}}
and
{{RTCPeerConnection/[[PendingLocalDescription]]}}.{{RTCSessionDescription/sdp}}
need not be string-wise identical to the
{{RTCSessionDescriptionInit/sdp}} value passed to the
corresponding {{setLocalDescription}} call (i.e. SDP may be
parsed and reformatted, and ICE candidates may be added).
currentLocalDescription
of type {{RTCSessionDescription}}, readonly,
nullable
The {{currentLocalDescription}} attribute MUST return
{{RTCPeerConnection/[[CurrentLocalDescription]]}}.
It represents the local description that was successfully
negotiated the last time the {{RTCPeerConnection}}
transitioned into the stable state plus any local
candidates that have been generated by the [= ICE Agent =]
since the offer or answer was created.
pendingLocalDescription
of type {{RTCSessionDescription}}, readonly,
nullable
The {{pendingLocalDescription}} attribute MUST return
{{RTCPeerConnection/[[PendingLocalDescription]]}}.
It represents a local description that is in the process of
being negotiated plus any local candidates that have been
generated by the [= ICE Agent =] since the offer or answer
was created. If the {{RTCPeerConnection}} is in the stable
state, the value is null.
remoteDescription
of type {{RTCSessionDescription}}, readonly,
nullable
The {{remoteDescription}} attribute MUST return
the [=remote description=].
The remote description is
{{RTCPeerConnection/[[PendingRemoteDescription]]}} if it is not
null, otherwise it is
{{RTCPeerConnection/[[CurrentRemoteDescription]]}}.
Note that
{{RTCPeerConnection/[[CurrentRemoteDescription]]}}.{{RTCSessionDescription/sdp}}
and
{{RTCPeerConnection/[[PendingRemoteDescription]]}}.{{RTCSessionDescription/sdp}}
need not be string-wise identical to the
{{RTCSessionDescriptionInit/sdp}} value passed to the
corresponding {{setRemoteDescription}} call (i.e. SDP may be
parsed and reformatted, and ICE candidates may be added).
currentRemoteDescription
of type {{RTCSessionDescription}}, readonly,
nullable
The {{currentRemoteDescription}} attribute MUST return
{{RTCPeerConnection/[[CurrentRemoteDescription]]}}.
It represents the last remote description that was
successfully negotiated the last time the
{{RTCPeerConnection}} transitioned into the stable state
plus any remote candidates that have been supplied via
{{RTCPeerConnection/addIceCandidate()}} since the offer or
answer was created.
pendingRemoteDescription
of type {{RTCSessionDescription}}, readonly,
nullable
The {{pendingRemoteDescription}} attribute MUST return
{{RTCPeerConnection/[[PendingRemoteDescription]]}}.
It represents a remote description that is in the process
of being negotiated, complete with any remote candidates
that have been supplied via
{{RTCPeerConnection/addIceCandidate()}} since the offer or
answer was created. If the {{RTCPeerConnection}} is in the
stable state, the value is null.
signalingState of
type {{RTCSignalingState}},
readonly
The {{signalingState}} attribute MUST return the
{{RTCPeerConnection/RTCPeerConnection}} object's
{{RTCPeerConnection/[[SignalingState]]}}.
iceGatheringState
of type {{RTCIceGatheringState}}, readonly
The {{iceGatheringState}} attribute MUST return the
{{RTCPeerConnection}} object's
{{RTCPeerConnection/[[IceGatheringState]]}}.
iceConnectionState
of type {{RTCIceConnectionState}}, readonly
The {{iceConnectionState}} attribute MUST return the
{{RTCPeerConnection}} object's
{{RTCPeerConnection/[[IceConnectionState]]}}.
connectionState
of type {{RTCPeerConnectionState}}, readonly
The {{connectionState}} attribute MUST return the
{{RTCPeerConnection}} object's
{{RTCPeerConnection/[[ConnectionState]]}}.
canTrickleIceCandidates of type
boolean, readonly, nullable
The {{canTrickleIceCandidates}} attribute indicates whether
the remote peer is able to accept trickled ICE candidates
[[RFC8838]]. The value is determined based on whether a
remote description indicates support for trickle ICE, as
defined in [[!RFC9429]].
Prior to the completion of
{{RTCPeerConnection/setRemoteDescription}}, this value is
null.
onnegotiationneeded of type
EventHandler
The event type of this event handler is
{{RTCPeerConnection/negotiationneeded}}.
onicecandidate of type EventHandler
The event type of this event handler is {{RTCPeerConnection/icecandidate}}.
onicecandidateerror of type
EventHandler
The event type of this event handler is
{{RTCPeerConnection/icecandidateerror}}.
onsignalingstatechange of type
EventHandler
The event type of this event handler is
{{RTCPeerConnection/signalingstatechange}}.
oniceconnectionstatechange of type
EventHandler
The event type of this event handler is
{{RTCPeerConnection/iceconnectionstatechange}}
onicegatheringstatechange of type
EventHandler
The event type of this event handler is
{{RTCPeerConnection/icegatheringstatechange}}.
onconnectionstatechange of type
EventHandler
The event type of this event handler is
{{RTCPeerConnection/connectionstatechange}}.
Methods
createOffer
The {{createOffer}} method generates a blob of SDP that
contains an RFC 3264 offer with the supported
configurations for the session, including descriptions of
the local {{MediaStreamTrack}}s attached to this
{{RTCPeerConnection}}, the codec/RTP/RTCP capabilities
supported by this implementation, and parameters of the [=
ICE agent =] and the DTLS connection. The
options parameter may be supplied to provide
additional control over the offer generated.
If a system has limited resources (e.g. a finite number of
decoders), {{createOffer}} needs to return an offer that
reflects the current state of the system, so that
{{setLocalDescription}} will succeed when it attempts to
acquire those resources. The session descriptions MUST
remain usable by {{setLocalDescription}} without causing an
error until at least the end of the [= fulfillment =]
callback of the returned promise.
Creating the SDP MUST follow the appropriate process for
generating an offer described in [[!RFC9429]], except the user
agent MUST treat a {{RTCRtpTransceiver/stopping}}
transceiver as {{RTCRtpTransceiver/stopped}} for the
purposes of RFC9429 in this case.
As an offer, the generated SDP will contain the full set of
codec/RTP/RTCP capabilities supported or preferred by the
session (as opposed to an answer, which will include only a
specific negotiated subset to use). In the event
{{createOffer}} is called after the session is established,
{{createOffer}} will generate an offer that is compatible
with the current session, incorporating any changes that
have been made to the session since the last complete
offer-answer exchange, such as addition or removal of
tracks. If no changes have been made, the offer will
include the capabilities of the current local description
as well as any additional capabilities that could be
negotiated in an updated offer.
The generated SDP will also contain the [= ICE agent =]'s
{{RTCIceParameters/usernameFragment}},
{{RTCIceParameters/password}} and ICE options (as defined
in [[RFC5245]], Section 14) and may also contain any local
candidates that have been gathered by the agent.
The {{RTCConfiguration/certificates}} value in
configuration for the {{RTCPeerConnection}}
provides the certificates configured by the application for
the {{RTCPeerConnection}}. These certificates, along with
any default certificates are used to produce a set of
certificate fingerprints. These certificate fingerprints
are used in the construction of SDP.
The process of generating an SDP exposes a subset of the
media capabilities of the underlying system, which provides
generally persistent cross-origin information on the
device. It thus increases the fingerprinting surface of the
application. In privacy-sensitive contexts, browsers can
consider mitigations such as generating SDP matching only a
common subset of the capabilities.
When the method is called, the user agent MUST run the
following steps:
Let connection be the {{RTCPeerConnection}}
object on which the method was invoked.
If connection.{{RTCPeerConnection/[[IsClosed]]}} is
true, return a promise [= rejected =] with
a newly [= exception/created =] {{InvalidStateError}}.
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:
If connection.{{RTCPeerConnection/[[SignalingState]]}} is
neither {{RTCSignalingState/"stable"}} nor
{{RTCSignalingState/"have-local-offer"}}, return a
promise [= rejected =] with a newly [=
exception/created =] {{InvalidStateError}}.
Let p be a new promise.
[=In parallel=], begin the [= in-parallel steps to create
an offer =] given connection and
p.
Return p.
The in-parallel steps to create an offer given
connection and a promise p are as
follows:
If connection was not constructed with a set
of certificates, and one has not yet been generated,
wait for it to be generated.
Inspect the offerer's system state to
determine the currently available resources as
necessary for generating the offer, as described in
[[!RFC9429]].
If this inspection failed for any reason, [= reject =]
p with a newly [= exception/created =]
{{OperationError}} and abort these steps.
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:
If connection.{{RTCPeerConnection/[[IsClosed]]}} is
true, then abort these steps.
If connection was modified in such a way
that additional inspection of the [= offerer's system
state =] is necessary, then [=in parallel=] begin the [=
in-parallel steps to create an offer =] again, given
connection and p, and abort these
steps.
This may be necessary if, for example, {{createOffer}}
was called when only an audio {{RTCRtpTransceiver}} was
added to connection, but while performing
the [= in-parallel steps to create an offer =], a video
{{RTCRtpTransceiver}} was added, requiring additional
inspection of video system resources.
Given the information that was obtained from previous
inspection, the current state of connection
and its {{RTCRtpTransceiver}}s, generate an SDP offer,
sdpString, as described in [[!RFC9429]].
As described in [[RFC8843]] (Section 7), if
bundling is used (see {{RTCBundlePolicy}}) an
offerer tagged m= section must be selected in order
to negotiate a BUNDLE group. The user agent MUST
choose the m= section that corresponds to the first
non-stopped transceiver in the [= set of
transceivers =] as the offerer tagged m= section.
This allows the remote endpoint to predict which
transceiver is the offerer tagged m= section
without having to parse the SDP.
Let filteredCodecs be the result of
applying the following filter on
transceiver.{{RTCRtpTransceiver/[[PreferredCodecs]]}}.
The filtering MUST NOT change the order of the codec
preferences:
Let kind be transceiver's
{{RTCRtpTransceiver/[[Receiver]]}}'s
{{RTCRtpReceiver/[[ReceiverTrack]]}}'s
{{MediaStreamTrack/kind}}.
If
transceiver.{{RTCRtpTransceiver/direction}}
is {{RTCRtpTransceiverDirection/"sendonly"}}
or {{RTCRtpTransceiverDirection/"sendrecv"}},
exclude any codecs not included in the
[=RTCRtpSender/list of implemented send codecs=] for
kind, using the [= codec dictionary match =]
algorithm with ignoreAsymmetricalParameters
set to true.
If
transceiver.{{RTCRtpTransceiver/direction}}
is {{RTCRtpTransceiverDirection/"recvonly"}}
or {{RTCRtpTransceiverDirection/"sendrecv"}},
exclude any codecs not included in the
[=list of implemented receive codecs=] for
kind, using the [= codec dictionary match =]
algorithm with ignoreAsymmetricalParameters
set to true.
The codec preferences of a [= media
description =]'s [= associated =] transceiver,
transceiver, is said to be the value of
filteredCodecs if non-empty and said to
be unset otherwise.
If the length of the {{RTCRtpSender/[[SendEncodings]]}} slot
of the {{RTCRtpSender}} is larger than 1, then for
each encoding given in {{RTCRtpSender/[[SendEncodings]]}} of
the {{RTCRtpSender}}, add an a=rid send line to the corresponding
media section, and add an a=simulcast:send line giving the RIDs
in the same order as given in the
{{RTCRtpSendParameters/encodings}} field. No RID
restrictions are set.
[[RFC8853]] section 5.2 specifies that the
order of RIDs in the a=simulcast line suggests a
proposed order of preference. If the browser
decides not to transmit all encodings, one should
expect it to stop sending the last encoding in the
list first.
Let offer be a newly created
{{RTCSessionDescriptionInit}} dictionary with its
{{RTCSessionDescriptionInit/type}} member initialized
to the string {{RTCSdpType/"offer"}} and its
{{RTCSessionDescriptionInit/sdp}} member initialized to
sdpString.
Set the {{RTCPeerConnection/[[LastCreatedOffer]]}} internal slot to
sdpString.
[= Resolve =] p with offer.
createAnswer
The {{createAnswer}} method generates an [[!SDP]] answer
with the supported configuration for the session that is
compatible with the parameters in the remote configuration.
Like {{createOffer}}, the returned blob of SDP contains
descriptions of the local {{MediaStreamTrack}}s attached to
this {{RTCPeerConnection}}, the codec/RTP/RTCP options
negotiated for this session, and any candidates that have
been gathered by the [= ICE Agent =]. The
options parameter may be supplied to provide
additional control over the generated answer.
Like {{createOffer}}, the returned description SHOULD
reflect the current state of the system. The session
descriptions MUST remain usable by {{setLocalDescription}}
without causing an error until at least the end of the [=
fulfillment =] callback of the returned promise.
As an answer, the generated SDP will contain a specific
codec/RTP/RTCP configuration that, along with the
corresponding offer, specifies how the media plane should
be established. The generation of the SDP MUST follow the
appropriate process for generating an answer described in
[[!RFC9429]].
The generated SDP will also contain the [= ICE agent =]'s
{{RTCIceParameters/usernameFragment}},
{{RTCIceParameters/password}} and ICE options (as defined
in [[RFC5245]], Section 14) and may also contain any local
candidates that have been gathered by the agent.
The {{RTCConfiguration/certificates}} value in
configuration for the {{RTCPeerConnection}}
provides the certificates configured by the application for
the {{RTCPeerConnection}}. These certificates, along with
any default certificates are used to produce a set of
certificate fingerprints. These certificate fingerprints
are used in the construction of SDP.
An answer can be marked as provisional, as described in
[[!RFC9429]], by setting
the {{RTCSessionDescriptionInit/type}} to
{{RTCSdpType/"pranswer"}}.
When the method is called, the user agent MUST run the
following steps:
Let connection be the {{RTCPeerConnection}}
object on which the method was invoked.
If connection.{{RTCPeerConnection/[[IsClosed]]}} is
true, return a promise [= rejected =] with
a newly [= exception/created =] {{InvalidStateError}}.
Return the result of [= chaining =] the result of [=
creating an answer =] with connection to
connection's [= operations chain =].
To create an answer
given connection run the following steps:
If connection.{{RTCPeerConnection/[[SignalingState]]}} is
neither {{RTCSignalingState/"have-remote-offer"}} nor
{{RTCSignalingState/"have-local-pranswer"}}, return a
promise [= rejected =] with a newly [=
exception/created =] {{InvalidStateError}}.
Let p be a new promise.
[=In parallel=], begin the [= in-parallel steps to create
an answer =] given connection and
p.
Return p.
The in-parallel steps to create an answer given
connection and a promise p are as
follows:
If connection was not constructed with a set
of certificates, and one has not yet been generated,
wait for it to be generated.
Inspect the answerer's system state to
determine the currently available resources as
necessary for generating the answer, as described in
[[!RFC9429]].
If this inspection failed for any reason, [= reject =]
p with a newly [= exception/created =]
{{OperationError}} and abort these steps.
Queue a task that runs the [= final steps to create an
answer =] given p.
The final steps to create an answer given a
promise p are as follows:
If connection.{{RTCPeerConnection/[[IsClosed]]}} is
true, then abort these steps.
If connection was modified in such a way
that additional inspection of the [= answerer's system
state =] is necessary, then [=in parallel=] begin the [=
in-parallel steps to create an answer =] again given
connection and p, and abort these
steps.
This may be necessary if, for example, {{createAnswer}}
was called when an {{RTCRtpTransceiver}}'s direction
was {{RTCRtpTransceiverDirection/"recvonly"}}, but
while performing the [= in-parallel steps to create an
answer =], the direction was changed to
{{RTCRtpTransceiverDirection/"sendrecv"}}, requiring
additional inspection of video encoding resources.
Given the information that was obtained from previous
inspection and the current state of
connection and its {{RTCRtpTransceiver}}s,
generate an SDP answer, sdpString, as
described in [[!RFC9429]].
Let filteredCodecs be the result of
applying the following filter on
transceiver.{{RTCRtpTransceiver/[[PreferredCodecs]]}}.
The filtering MUST NOT change the order of the
codec preferences:
Let kind be transceiver's
{{RTCRtpTransceiver/[[Receiver]]}}'s
{{RTCRtpReceiver/[[ReceiverTrack]]}}'s
{{MediaStreamTrack/kind}}.
If
transceiver.{{RTCRtpTransceiver/direction}}
is {{RTCRtpTransceiverDirection/"sendonly"}}
or {{RTCRtpTransceiverDirection/"sendrecv"}},
exclude any codecs not included in the
[=RTCRtpSender/list of implemented send codecs=] for
kind, using the [= codec dictionary match =]
algorithm with ignoreAsymmetricalParameters
set to true.
If
transceiver.{{RTCRtpTransceiver/direction}}
is {{RTCRtpTransceiverDirection/"recvonly"}}
or {{RTCRtpTransceiverDirection/"sendrecv"}},
exclude any codecs not included in the
[=list of implemented receive codecs=] for
kind, using the [= codec dictionary match =]
algorithm with ignoreAsymmetricalParameters
set to true.
The codec preferences of a [= media
description =]'s [= associated =] transceiver,
transceiver, is said to be the value of
filteredCodecs if non-empty and said to
be unset otherwise.
If this is an answer to an offer to receive
simulcast, then for each media section requesting
to receive simulcast, run the following steps:
If the a=simulcast
attribute contains comma-separated alternatives
for RIDs, remove all but the first ones.
If there are any identically named RIDs in the
a=simulcast attribute,
remove all but the first one. No RID
restrictions are set.
Exclude from the media section in the answer any
RID not found in the corresponding transceiver's
{{RTCRtpTransceiver/[[Sender]]}}.{{RTCRtpSender/[[SendEncodings]]}}.
When a
{{RTCPeerConnection/setRemoteDescription(offer)}}
establishes a sender's [=proposed envelope=],
the sender's {{RTCRtpSender/[[SendEncodings]]}}
is updated in
{{RTCSignalingState/"have-remote-offer"}}, exposing
it to rollback. However, once a
[=simulcast envelope=] has been established for
the sender, subsequent pruning of the
sender's {{RTCRtpSender/[[SendEncodings]]}}
happen when this answer is set with
{{RTCPeerConnection/setLocalDescription}}.
Let answer be a newly created
{{RTCSessionDescriptionInit}} dictionary with its
{{RTCSessionDescriptionInit/type}} member initialized
to the string {{RTCSdpType/"answer"}} and its
{{RTCSessionDescriptionInit/sdp}} member initialized to
sdpString.
Set the {{RTCPeerConnection/[[LastCreatedAnswer]]}} internal slot to
sdpString.
[= Resolve =] p with answer.
setLocalDescription
The {{setLocalDescription}} method instructs the
{{RTCPeerConnection}} to apply the supplied
{{RTCLocalSessionDescriptionInit}} as the local
description.
This API changes the local media state. In order to
successfully handle scenarios where the application wants
to offer to change from one media format to a different,
incompatible format, the {{RTCPeerConnection}} MUST be able
to simultaneously support use of both the current and
pending local descriptions (e.g. support codecs that exist
in both descriptions) until a final answer is received, at
which point the {{RTCPeerConnection}} can fully adopt the
pending local description, or rollback to the current
description if the remote side rejected the change.
Passing in a description is optional. If left out, then
{{setLocalDescription}} will implicitly [= create an offer
=] or [= create an answer =], as needed. As noted in
[[!RFC9429]], if a
description with SDP is passed in, that SDP is not allowed
to have changed from when it was returned from either
{{createOffer}} or {{createAnswer}}.
When the method is invoked, the user agent MUST run the
following steps:
Let description be the method's first
argument.
Let connection be the {{RTCPeerConnection}}
object on which the method was invoked.
Let sdp be
description.{{RTCSessionDescriptionInit/sdp}}.
Return the result of [= chaining =] the following steps
to connection's [= operations chain =]:
Let type be
description.{{RTCSessionDescriptionInit/type}}
if [=map/exists|present=], or {{RTCSdpType/"offer"}} if not
[=map/exists|present=] and
connection.{{RTCPeerConnection/[[SignalingState]]}}
is either {{RTCSignalingState/"stable"}},
{{RTCSignalingState/"have-local-offer"}}, or
{{RTCSignalingState/"have-remote-pranswer"}};
otherwise {{RTCSdpType/"answer"}}.
If type is {{RTCSdpType/"offer"}}, and
sdp is not the empty string and not
equal to
connection.{{RTCPeerConnection/[[LastCreatedOffer]]}},
then return a promise [= rejected =] with a newly
[= exception/created =]
{{InvalidModificationError}} and abort these steps.
If type is {{RTCSdpType/"answer"}} or
{{RTCSdpType/"pranswer"}}, and sdp is
not the empty string and not equal to
connection.{{RTCPeerConnection/[[LastCreatedAnswer]]}},
then return a promise [= rejected =] with a newly
[= exception/created =]
{{InvalidModificationError}} and abort these steps.
If sdp is the empty string, and
type is {{RTCSdpType/"offer"}}, then run
the following sub steps:
Set sdp to the value of
connection.{{RTCPeerConnection/[[LastCreatedOffer]]}}.
If sdp is the empty string, or if it
no longer accurately represents the [=
offerer's system state =] of
connection, then let p be
the result of [= creating an offer =] with
connection, and return the result of
[= promise/reacting =] to p with a
fulfillment step that [= set a local
session description | sets the local
session description =] indicated by its first
argument.
If sdp is the empty string, and
type is {{RTCSdpType/"answer"}} or
{{RTCSdpType/"pranswer"}}, then run the following
sub steps:
Set sdp to the value of
connection.{{RTCPeerConnection/[[LastCreatedAnswer]]}}.
If sdp is the empty string, or if it
no longer accurately represents the [=
answerer's system state =] of
connection, then let p be
the result of [= creating an answer =] with
connection, and return the result of
[= promise/reacting =] to p with the
following fulfillment steps:
Let answer be the first argument
to these fulfillment steps.
Return the result of [= setting the local
session description =] indicated by
{type,
answer.{{RTCSessionDescriptionInit/sdp}}}.
Return the result of [= setting the local
session description =] indicated by {type, sdp}.
As noted in [[!RFC9429]], calling this
method may trigger the ICE candidate gathering process by
the [= ICE Agent =].
setRemoteDescription
The {{setRemoteDescription}} method instructs the
{{RTCPeerConnection}} to apply the supplied
{{RTCSessionDescriptionInit}} as the remote offer or
answer. This API changes the local media state.
When the method is invoked, the user agent MUST run the
following steps:
Let description be the method's first
argument.
Let connection be the {{RTCPeerConnection}}
object on which the method was invoked.
Return the result of [= chaining =] the following steps
to connection's [= operations chain =]:
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:
Let p be the result of [= setting
the local session description =] indicated by
{type:
{{RTCSdpType/"rollback"}}}.
Return the result of [= promise/reacting =] to
p with a fulfillment step that [=
set a remote session description | sets the
remote session description =]
description, and abort these steps.
Return the result of [= setting the remote
session description =] description.
addIceCandidate
The {{addIceCandidate}} method provides a remote candidate
to the [= ICE Agent =]. This method can also be used to
indicate the end of remote candidates when called with an
empty string for the {{RTCIceCandidate/candidate}} member.
The only members of the argument used by this method are
{{RTCIceCandidate/candidate}}, {{RTCIceCandidate/sdpMid}},
{{RTCIceCandidate/sdpMLineIndex}}, and
{{RTCIceCandidate/usernameFragment}}; the rest are ignored.
When the method is invoked, the user agent MUST run the
following steps:
Let candidate be the method's argument.
Let connection be the {{RTCPeerConnection}}
object on which the method was invoked.
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}}.
Return the result of [= chaining =] the following steps
to connection's [= operations chain =]:
If {{RTCPeerConnection/remoteDescription}} is
null return a promise [= rejected =]
with a newly [= exception/created =]
{{InvalidStateError}}.
If candidate.{{RTCIceCandidate/sdpMid}}
is not null, run the following steps:
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}}.
Else, if
candidate.{{RTCIceCandidate/sdpMLineIndex}}
is not null, run the following steps:
If
candidate.{{RTCIceCandidate/sdpMLineIndex}}
is equal to or larger than the number of media
descriptions in
{{RTCPeerConnection/remoteDescription}}, return
a promise [= rejected =] with a newly [=
exception/created =] {{OperationError}}.
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.
If
candidate.{{RTCIceCandidate/usernameFragment}}
is not null, and is not equal to any
username fragment present in the corresponding [=
media description =] of an applied remote
description, return a promise [= rejected =] with a
newly [= exception/created =] {{OperationError}}.
Let p be a new promise.
[=In parallel=], if the candidate is not [=
administratively prohibited =], add the ICE
candidate candidate as described in
[[!RFC9429]].
Use
candidate.{{RTCIceCandidate/usernameFragment}}
to identify the ICE [= generation =]; if
{{RTCIceCandidate/usernameFragment}} is
null, process the candidate
for the most recent ICE [= generation =].
If
candidate.{{RTCIceCandidate/candidate}}
is an empty string, process candidate as
an end-of-candidates indication for the
corresponding [= media description =] and ICE
candidate [= generation =]. If both
candidate.{{RTCIceCandidate/sdpMid}} and
candidate.{{RTCIceCandidate/sdpMLineIndex}}
are null, then this end-of-candidates
indication applies to all [=
media description =]s.
If candidate could not be
successfully added the user agent MUST queue a
task that runs the following steps:
If
connection.{{RTCPeerConnection/[[IsClosed]]}}
is true, then abort these
steps.
[= Reject =] p with a newly [=
exception/created =] {{OperationError}} and
abort these steps.
If candidate is applied
successfully, or if the candidate was [=
administratively prohibited =] the user agent
MUST queue a task that runs the following
steps:
If
connection.{{RTCPeerConnection/[[IsClosed]]}}
is true, then abort these
steps.
If
connection.{{RTCPeerConnection/[[PendingRemoteDescription]]}}
is not null, and represents
the ICE [= generation =] for which
candidate was processed, add
candidate to
connection.{{RTCPeerConnection/[[PendingRemoteDescription]]}}.sdp.
If
connection.{{RTCPeerConnection/[[CurrentRemoteDescription]]}}
is not null, and represents
the ICE [= generation =] for which
candidate was processed, add
candidate to
connection.{{RTCPeerConnection/[[CurrentRemoteDescription]]}}.sdp.
[= Resolve =] p with
undefined.
Return p.
A candidate or a [= gathering source =] can be administratively prohibited.
A remote candidate is [= administratively prohibited =] if
the UA decides not to allow connection attempts to this
address.
Local candidates are gathered from a gathering source which
can be local (network interface) or remote (remote candidate,
STUN server or TURN server).
A local gathering source is [= administratively prohibited =]
if the UA decides not to use the source network interface for
WebRTC traffic.
A remote gathering source is [= administratively prohibited =]
if the UA decides not to allow connection attempts to the
source address.
If all candidates are said to be [= administratively prohibited =],
the UA MUST NOT allow connection to any remote candidate and MUST
NOT gather candidates from any gathering source.
For privacy reasons, there is no indication to the
developer about whether or not an address/port is blocked;
it behaves exactly as if there was no response from the
address.
The UA MUST prohibit connections to addresses on the
[[!Fetch]] [= block bad port =] list, and MAY choose to
prohibit connections to other addresses.
If the {{RTCConfiguration/iceTransportPolicy}} member of
the {{RTCConfiguration}} is
{{RTCIceTransportPolicy/relay}}, candidates requiring
external resolution, such as mDNS candidates and DNS
candidates, MUST be prohibited.
Due to WebIDL processing,
{{RTCPeerConnection/addIceCandidate}}(null) is
interpreted as a call with the default dictionary present,
which, in the above algorithm, indicates end-of-candidates
for all media descriptions and ICE candidate generation.
This is by design for legacy reasons.
restartIce
The {{restartIce}} method tells the {{RTCPeerConnection}}
that ICE should be restarted. Subsequent calls to
{{createOffer}} will create descriptions that will restart
ICE, as described in section 9.1.1.1 of [[RFC5245]].
When this method is invoked, the user agent MUST run the
following steps:
Let connection be the {{RTCPeerConnection}}
on which the method was invoked.
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]]}}.
[= Update the negotiation-needed flag =] for
connection.
getConfiguration
Returns an {{RTCConfiguration}} object representing the
current configuration of this {{RTCPeerConnection}} object.
When this method is called, the user agent MUST return the
{{RTCConfiguration}} object stored in the
{{RTCPeerConnection/[[Configuration]]}} internal slot.
setConfiguration
The {{setConfiguration}} method updates the configuration
of this {{RTCPeerConnection}} object. This includes
changing the configuration of the [= ICE Agent =]. As noted
in [[!RFC9429]],
when the ICE configuration changes in a way that requires a
new gathering phase, an ICE restart is required.
When the {{setConfiguration}} method is invoked, the user
agent MUST run the following steps:
Let connection be the {{RTCPeerConnection}}
on which the method was invoked.
If connection.{{RTCPeerConnection/[[IsClosed]]}} is
true, [= exception/throw =] an
{{InvalidStateError}}.
[= Set the configuration =] specified by
configuration.
close
When the {{close}} method is invoked, the user agent MUST
run the following steps:
Let connection be the {{RTCPeerConnection}}
object on which the method was invoked.
[= close the connection =] with
connection and the value false.
The close the connection algorithm given a
connection and a disappear boolean,
is as follows:
If connection.{{RTCPeerConnection/[[IsClosed]]}} is
true, abort these steps.
Set connection.{{RTCPeerConnection/[[IsClosed]]}} to
true.
Set connection.{{RTCPeerConnection/[[SignalingState]]}} to
{{RTCSignalingState/"closed"}}. This does not fire any
event.
Let transceivers be the result of executing
the {{CollectTransceivers}} algorithm. For every
{{RTCRtpTransceiver}} transceiver in
transceivers, run the following steps:
If transceiver.{{RTCRtpTransceiver/[[Stopped]]}} is
true, abort these sub steps.
[= Stop the RTCRtpTransceiver =] with
transceiver and disappear.
Set the {{RTCDataChannel/[[ReadyState]]}} slot of each of
connection's {{RTCDataChannel}}s to
{{RTCDataChannelState/"closed"}}.
The {{RTCDataChannel}}s will be closed abruptly and the
closing procedure will not be invoked.
If connection.{{RTCPeerConnection/[[SctpTransport]]}} is
not null, tear down the underlying SCTP
association by sending an SCTP ABORT chunk and set the
{{RTCSctpTransport/[[SctpTransportState]]}} to
{{RTCSctpTransportState/"closed"}}.
Set the {{RTCDtlsTransport/[[DtlsTransportState]]}} slot of each of
connection's {{RTCDtlsTransport}}s to
{{RTCDtlsTransportState/"closed"}}.
Destroy connection's [= ICE Agent =],
abruptly ending any active ICE processing and releasing
any relevant resources (e.g. TURN permissions).
Set the {{RTCIceTransport/[[IceTransportState]]}} slot of each of
connection's {{RTCIceTransport}}s to
{{RTCIceTransportState/"closed"}}.
Set
connection.{{RTCPeerConnection/[[IceConnectionState]]}}
to {{RTCIceConnectionState/"closed"}}. This does not
fire any event.
Set connection.{{RTCPeerConnection/[[ConnectionState]]}} to
{{RTCPeerConnectionState/"closed"}}. This does not fire
any event.
Legacy Interface Extensions
The IDL
definition of these methods are documented in the main
definition of the {{RTCPeerConnection}} interface since overloaded
functions are not allowed to be defined in partial interfaces.
Supporting the methods in this section is optional. However, if
these methods are supported it is mandatory to implement according
to what is specified here.
The addStream method that used to exist on
{{RTCPeerConnection}} is easy to polyfill as:
When the createOffer method
is called, the user agent MUST run the following steps:
Let successCallback be the method's first
argument.
Let failureCallback be the callback
indicated by the method's second argument.
Let options be the callback indicated by
the method's third argument.
Run the steps specified by {{RTCPeerConnection}}'s
{{RTCPeerConnection/createOffer()}} method with
options as the sole argument, and let
p be the resulting promise.
Upon [= fulfillment =] of p with value
offer, invoke successCallback
with offer as the argument.
Upon [= rejection =] of p with reason
r, invoke failureCallback with
r as the argument.
Return a promise [= resolved =] with
undefined.
setLocalDescription
When the setLocalDescription method is called,
the user agent MUST run the following steps:
Let description be the method's first
argument.
Let successCallback be the callback
indicated by the method's second argument.
Let failureCallback be the callback
indicated by the method's third argument.
Run the steps specified by {{RTCPeerConnection}}'s
{{RTCPeerConnection/setLocalDescription}} method with
description as the sole argument, and let
p be the resulting promise.
Upon [= fulfillment =] of p, invoke
successCallback with
undefined as the argument.
Upon [= rejection =] of p with reason
r, invoke failureCallback with
r as the argument.
Return a promise [= resolved =] with
undefined.
createAnswer
The legacy createAnswer
method does not take an {{RTCAnswerOptions}} parameter,
since no known legacy createAnswer implementation ever
supported it.
When the createAnswer
method is called, the user agent MUST run the following
steps:
Let successCallback be the method's first
argument.
Let failureCallback be the callback
indicated by the method's second argument.
Run the steps specified by {{RTCPeerConnection}}'s
{{RTCPeerConnection/createAnswer()}} method with no
arguments, and let p be the resulting
promise.
Upon [= fulfillment =] of p with value
answer, invoke successCallback
with answer as the argument.
Upon [= rejection =] of p with reason
r, invoke failureCallback with
r as the argument.
Return a promise [= resolved =] with
undefined.
setRemoteDescription
When the setRemoteDescription method is called,
the user agent MUST run the following steps:
Let description be the method's first
argument.
Let successCallback be the callback
indicated by the method's second argument.
Let failureCallback be the callback
indicated by the method's third argument.
Run the steps specified by {{RTCPeerConnection}}'s
{{RTCPeerConnection/setRemoteDescription}} method
with description as the sole argument, and
let p be the resulting promise.
Upon [= fulfillment =] of p, invoke
successCallback with
undefined as the argument.
Upon [= rejection =] of p with reason
r, invoke failureCallback with
r as the argument.
Return a promise [= resolved =] with
undefined.
addIceCandidate
When the addIceCandidate
method is called, the user agent MUST run the following
steps:
Let candidate be the method's first
argument.
Let successCallback be the callback
indicated by the method's second argument.
Let failureCallback be the callback
indicated by the method's third argument.
Run the steps specified by {{RTCPeerConnection}}'s
{{RTCPeerConnection/addIceCandidate()}} method with
candidate as the sole argument, and let
p be the resulting promise.
Upon [= fulfillment =] of p, invoke
successCallback with
undefined as the argument.
Upon [= rejection =] of p with reason
r, invoke failureCallback with
r as the argument.
This section describes a set of legacy extensions that may be
used to influence how an offer is created, in addition to the
media added to the {{RTCPeerConnection}}. Developers are
encouraged to use the {{RTCRtpTransceiver}} API instead.
When {{RTCPeerConnection/createOffer}} is called with any of the
legacy options specified in this section, run the followings
steps instead of the regular {{RTCPeerConnection/createOffer}}
steps:
Let options be the methods first argument.
Let connection be the current
{{RTCPeerConnection}} object.
For each offerToReceive<Kind>
member in options with kind, kind, run
the following steps:
If the value of the dictionary member is false,
For each non-stopped
{{RTCRtpTransceiverDirection/"sendrecv"}} transceiver
of [=RTCRtpTransceiver/transceiver kind=] kind, set
transceiver.{{RTCRtpTransceiver/[[Direction]]}} to
{{RTCRtpTransceiverDirection/"sendonly"}}.
For each non-stopped
{{RTCRtpTransceiverDirection/"recvonly"}} transceiver
of [=RTCRtpTransceiver/transceiver kind=] kind, set
transceiver.{{RTCRtpTransceiver/[[Direction]]}} to
{{RTCRtpTransceiverDirection/"inactive"}}.
Continue with the next option, if any.
If connection has any non-stopped
{{RTCRtpTransceiverDirection/"sendrecv"}} or
{{RTCRtpTransceiverDirection/"recvonly"}} transceivers of
[=RTCRtpTransceiver/transceiver kind=] kind, continue with the
next option, if any.
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 =].
If transceiver is unset because the previous
operation threw an error, abort these steps.
Set transceiver.{{RTCRtpTransceiver/[[Direction]]}} to
{{RTCRtpTransceiverDirection/"recvonly"}}.
Run the steps specified by {{RTCPeerConnection/createOffer}}
to create the offer.
This setting provides additional control over the
directionality of audio. For example, it can be used to
ensure that audio can be received, regardless if audio is
sent or not.
offerToReceiveVideo of type boolean
This setting provides additional control over the
directionality of video. For example, it can be used to
ensure that video can be received, regardless if video is
sent or not.
Garbage collection
An {{RTCPeerConnection}} object MUST not be garbage collected as
long as any event can cause an event handler to be triggered on the
object. When the object's {{RTCPeerConnection/[[IsClosed]]}} internal slot is
true, no such event handler can be triggered and it is
therefore safe to garbage collect the object.
All {{RTCDataChannel}} and {{MediaStreamTrack}} objects that are
connected to an {{RTCPeerConnection}} have a strong reference to
the {{RTCPeerConnection}} object.
Error Handling
General Principles
All methods that return promises are governed by the standard error
handling rules of promises. Methods that do not return promises may
throw exceptions to indicate errors.
Session Description Model
RTCSdpType
The {{RTCSdpType}} enum describes the type of an
{{RTCSessionDescriptionInit}}, {{RTCLocalSessionDescriptionInit}},
or {{RTCSessionDescription}} instance.
An {{RTCSdpType}} of {{RTCSdpType/"offer"}} indicates
that a description MUST be treated as an [[!SDP]] offer.
pranswer
An {{RTCSdpType}} of {{RTCSdpType/"pranswer"}} indicates
that a description MUST be treated as an [[!SDP]] answer,
but not a final answer. A description used as an SDP
pranswer may be applied as a response to an SDP offer, or
an update to a previously sent SDP pranswer.
answer
An {{RTCSdpType}} of {{RTCSdpType/"answer"}} indicates
that a description MUST be treated as an [[!SDP]] final
answer, and the offer-answer exchange MUST be considered
complete. A description used as an SDP answer may be
applied as a response to an SDP offer or as an update to
a previously sent SDP pranswer.
rollback
An {{RTCSdpType}} of {{RTCSdpType/"rollback"}} indicates
that a description MUST be treated as canceling the
current SDP negotiation and moving the SDP [[!SDP]] offer
back to what it was in the previous stable state. Note
the local or remote SDP descriptions in the previous
stable state could be null if there has not
yet been a successful offer-answer negotiation. An
{{RTCSdpType/"answer"}} or {{RTCSdpType/"pranswer"}}
cannot be rolled back.
RTCSessionDescription Class
The {{RTCSessionDescription}} class is used by
{{RTCPeerConnection}} to expose local and remote session
descriptions.
The {{RTCSessionDescription()}}
constructor takes a dictionary argument,
description, whose content is used to initialize
the new {{RTCSessionDescription}} object. This constructor
is deprecated; it exists for legacy compatibility reasons
only.
Attributes
type of type {{RTCSdpType}}, readonly
The type of this session description.
sdp of type DOMString, readonly, defaulting to
""
The string representation of the SDP [[!SDP]].
Methods
toJSON()
When called, run [[!WEBIDL]]'s [= default toJSON steps =].
The type of this description. If not [=map/exists|present=], then
{{RTCPeerConnection/setLocalDescription}} will infer the type
based on the {{RTCPeerConnection}}'s
{{RTCPeerConnection/[[SignalingState]]}}.
sdp of type DOMString
The string representation of the SDP [[!SDP]]; if
{{RTCLocalSessionDescriptionInit/type}} is
{{RTCSdpType/"rollback"}}, this member is unused.
Session Negotiation Model
Many changes to state of an {{RTCPeerConnection}} will require
communication with the remote side via the signaling channel, in
order to have the desired effect. The app can be kept informed as to
when it needs to do signaling, by listening to the
{{RTCPeerConnection/negotiationneeded}} event. This event is fired
according
to the state of the connection's negotiation-needed flag,
represented by a {{RTCPeerConnection/[[NegotiationNeeded]]}} internal slot.
Setting Negotiation-Needed
If an operation is performed on an {{RTCPeerConnection}} that
requires signaling, the connection will be marked as needing
negotiation. Examples of such operations include adding or stopping
an {{RTCRtpTransceiver}}, or adding the first {{ RTCDataChannel}}.
Internal changes within the implementation can also result in the
connection being marked as needing negotiation.
Note that the exact procedures for [= update the negotiation-needed
flag | updating the negotiation-needed flag =] are specified below.
Clearing Negotiation-Needed
The [=negotiation-needed flag=] is cleared when a session description
of type {{RTCSdpType/"answer"}} [= set a session description | is
set =] successfully, and the supplied description
matches the state of the {{RTCRtpTransceiver}}s and
{{RTCDataChannel}}s that currently exist on the
{{RTCPeerConnection}}. Specifically, this means that all
non-{{RTCRtpTransceiver/stopped}} transceivers have an [=
associated =] section in the local description with matching
properties, and, if any data channels have been created, a data
section exists in the local description.
Note that the exact procedures for [= update the negotiation-needed
flag | updating the negotiation-needed flag =] are specified below.
Updating the Negotiation-Needed flag
The process below occurs where referenced elsewhere in this
document. It also may occur as a result of internal changes within
the implementation that affect negotiation. If such changes occur,
the user agent MUST [= update the negotiation-needed flag =].
To update the negotiation-needed flag for
connection, run the following steps:
If the length of connection.{{RTCPeerConnection/[[Operations]]}}
is not 0, then set
connection.{{RTCPeerConnection/[[UpdateNegotiationNeededFlagOnEmptyChain]]}}
to true, and abort these steps.
Queue a task to run the following steps:
If connection.{{RTCPeerConnection/[[IsClosed]]}} is
true, abort these steps.
If the length of
connection.{{RTCPeerConnection/[[Operations]]}} is not
0, then set
connection.{{RTCPeerConnection/[[UpdateNegotiationNeededFlagOnEmptyChain]]}}
to true, and abort these steps.
If connection.{{RTCPeerConnection/[[SignalingState]]}} is not
{{RTCSignalingState/"stable"}}, abort these steps.
The [=negotiation-needed flag=] will be updated once the state
transitions to {{RTCSignalingState/"stable"}}, as part of
the steps for [= setting a session description =].
If the result of [= check if negotiation is needed |
checking if negotiation is needed =] is false,
clear the negotiation-needed flag by setting
connection.{{RTCPeerConnection/[[NegotiationNeeded]]}} to
false, and abort these steps.
If connection.{{RTCPeerConnection/[[NegotiationNeeded]]}} is
already true, abort these steps.
Set connection.{{RTCPeerConnection/[[NegotiationNeeded]]}} to
true.
[= Fire an event =] named {{RTCPeerConnection/negotiationneeded}} at
connection.
The task queueing prevents {{RTCPeerConnection/negotiationneeded}} from firing
prematurely, in the common situation where multiple
modifications to connection are being made at
once.
Additionally, we avoid racing with negotiation methods by
only firing {{RTCPeerConnection/negotiationneeded}} when the [= operations
chain =] is empty.
To check if negotiation is needed for
connection, perform the following checks:
If any implementation-specific negotiation is required, as
described at the start of this section, return
true.
If
connection.{{RTCPeerConnection/[[LocalIceCredentialsToReplace]]}}
is not empty, return true.
Let description be
connection.{{RTCPeerConnection/[[CurrentLocalDescription]]}}.
If connection has created any {{RTCDataChannel}}s,
and no m= section in description has been negotiated
yet for data, return true.
For each transceiver in connection's [=
set of transceivers =], perform the following checks:
If transceiver.{{RTCRtpTransceiver/[[Stopping]]}} is
true and
transceiver.{{RTCRtpTransceiver/[[Stopped]]}} is
false, return true.
If transceiver isn't {{RTCRtpTransceiver/
stopped}} and isn't yet [= associated =] with an m= section
in description, return true.
If transceiver isn't {{RTCRtpTransceiver/
stopped}} and is [= associated =] with an m= section in
description then perform the following checks:
If transceiver.{{RTCRtpTransceiver/[[Direction]]}} is
{{RTCRtpTransceiverDirection/"sendrecv"}} or
{{RTCRtpTransceiverDirection/"sendonly"}}, and the [=
associated =] m= section in description
either doesn't contain a single a=msid line, or the number of MSIDs from
the a=msid lines in this
m= section, or the MSID values
themselves, differ from what is in
transceiver.sender.{{RTCRtpSender/[[AssociatedMediaStreamIds]]}},
return true.
If description is of type
{{RTCSdpType/"offer"}}, and the direction of the [=
associated =] m= section in neither
connection.{{RTCPeerConnection/[[CurrentLocalDescription]]}}
nor
connection.{{RTCPeerConnection/[[CurrentRemoteDescription]]}}
matches transceiver.{{RTCRtpTransceiver/[[Direction]]}},
return true. In this step, when the
direction is compared with a direction found in
{{RTCPeerConnection/[[CurrentRemoteDescription]]}}, the description's
direction must be reversed to represent the peer's
point of view.
If description is of type
{{RTCSdpType/"answer"}}, and the direction of the [=
associated =] m= section in the description
does not match
transceiver.{{RTCRtpTransceiver/[[Direction]]}}
intersected with the offered direction (as described in
[[!RFC9429]]),
return true.
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.
If all the preceding checks were performed and
true was not returned, nothing remains to be
negotiated; return false.
Interfaces for Interactive Connectivity Establishment
RTCIceCandidate Interface
This interface describes an ICE candidate, described in [[RFC5245]]
Section 2. Other than {{RTCIceCandidate/candidate}},
{{RTCIceCandidate/sdpMid}},
{{RTCIceCandidate/sdpMLineIndex}},
{{RTCIceCandidate/usernameFragment}},
{{RTCIceCandidate/relayProtocol}}, and
{{RTCIceCandidate/url}}, the remaining attributes
are derived from parsing the {{RTCIceCandidateInit/candidate}}
member in candidateInitDict, if it is well formed.
The RTCIceCandidate() constructor
takes a dictionary argument, candidateInitDict,
whose content is used to initialize the new
{{RTCIceCandidate}} object.
When invoked, run the following steps:
If both
the {{RTCIceCandidateInit/sdpMid}} and
{{RTCIceCandidateInit/sdpMLineIndex}} members of
candidateInitDict are null, [=
exception/throw =] a {{TypeError}}.
Return the result of [= creating an RTCIceCandidate =]
with candidateInitDict.
To create an
RTCIceCandidate with a candidateInitDict
dictionary, run the following steps:
Let iceCandidate be a newly created
{{RTCIceCandidate}} object.
Create internal slots for the following attributes of
iceCandidate, initilized to null:
{{foundation}}, {{component}}, {{priority}}, {{address}},
{{protocol}}, {{port}}, {{type}}, {{tcpType}},
{{relatedAddress}}, and {{relatedPort}}.
Create internal slots for the following attributes of
iceCandidate, initilized to their namesakes in
candidateInitDict: {{candidate}}, {{sdpMid}},
{{sdpMLineIndex}}, {{usernameFragment}},
{{relayProtocol}}, {{url}}.
Let candidate be the
{{RTCIceCandidateInit/candidate}} dictionary member of
candidateInitDict. If candidate is
not an empty string, run the following steps:
Parse candidate using the [=
candidate-attribute =] grammar.
If parsing of [= candidate-attribute =] has failed,
abort these steps.
If any field in the parse result represents an
invalid value for the corresponding attribute in
iceCandidate, abort these steps.
Set the corresponding internal slots in
iceCandidate to the field values of the
parsed result.
Return iceCandidate.
The constructor for {{RTCIceCandidate}} only does basic
parsing and type checking for the dictionary members in
candidateInitDict. Detailed validation on the
well-formedness of {{RTCIceCandidateInit/candidate}},
{{RTCIceCandidateInit/sdpMid}},
{{RTCIceCandidateInit/sdpMLineIndex}},
{{RTCIceCandidateInit/usernameFragment}} with the
corresponding session description is done when passing
the {{RTCIceCandidate}} object to
{{RTCPeerConnection/addIceCandidate()}}.
To maintain backward compatibility, any error on parsing
the candidate attribute is ignored. In such
case, the {{candidate}} attribute holds the raw
{{RTCIceCandidateInit/candidate}} string given in
candidateInitDict, but derivative attributes
such as {{foundation}}, {{priority}}, etc are set to
null.
Attributes
Most attributes below are defined in section 15.1 of [[RFC5245]].
candidate of type DOMString, readonly
This carries the [= candidate-attribute =] as defined in
section 15.1 of [[RFC5245]]. If this {{RTCIceCandidate}}
represents an end-of-candidates indication or a peer
reflexive remote candidate, {{candidate}} is an empty string.
sdpMid of type DOMString, readonly, nullable
If not null, this contains the media stream
"identification-tag" defined in [[!RFC5888]] for the
media component this candidate is associated with.
sdpMLineIndex of type unsigned short, readonly, nullable
If not null, this indicates the index (starting
at zero) of the [= media description =] in the SDP this
candidate is associated with.
foundation of type DOMString, readonly, nullable
A unique identifier that allows ICE to correlate candidates
that appear on multiple {{RTCIceTransport}}s.
component of type {{RTCIceComponent}}, readonly, nullable
The assigned network component of the candidate
({{RTCIceComponent/"rtp"}} or {{RTCIceComponent/"rtcp"}}).
This corresponds to the component-id
field in [= candidate-attribute =], decoded to the string
representation as defined in {{RTCIceComponent}}.
priority of type unsigned long, readonly, nullable
The assigned priority of the candidate.
address of type DOMString, readonly, nullable
The address of the candidate, allowing for IPv4 addresses,
IPv6 addresses, and fully qualified domain names (FQDNs).
This corresponds to the connection-address field in [=
candidate-attribute =].
Remote candidates may be exposed, for instance via
{{RTCIceTransport/[[SelectedCandidatePair]]}}.{{RTCIceCandidatePair/remote}}.
By default, the user agent MUST leave the
{{RTCIceCandidate/address}} attribute as null
for any exposed remote candidate. Once a
{{RTCPeerConnection}} instance learns on an address by the
web application using
{{RTCPeerConnection/addIceCandidate}}, the user agent can
expose the {{address}} attribute value in any
{{RTCIceCandidate}} of the {{RTCPeerConnection}} instance
representing a remote candidate with that newly learnt
address.
The addresses exposed in candidates gathered via ICE and
made visibile to the application in {{RTCIceCandidate}}
instances can reveal more information about the device
and the user (e.g. location, local network topology) than
the user might have expected in a non-WebRTC enabled
browser.
These addresses are always exposed to the application,
and potentially exposed to the communicating party, and
can be exposed without any specific user consent (e.g.
for peer connections used with data channels, or to
receive media only).
These addresses can also be used as temporary or
persistent cross-origin states, and thus contribute to
the fingerprinting surface of the device.
Applications can avoid exposing addresses to the
communicating party, either temporarily or permanently,
by forcing the [= ICE Agent =] to report only relay
candidates via the
{{RTCConfiguration/iceTransportPolicy}} member of
{{RTCConfiguration}}.
To limit the addresses exposed to the application itself,
browsers can offer their users different policies
regarding sharing local addresses, as defined in
[[RFC8828]].
protocol of type {{RTCIceProtocol}}, readonly, nullable
The protocol of the candidate
({{RTCIceProtocol/"udp"}}/{{RTCIceProtocol/"tcp"}}). This
corresponds to the transport field
in [= candidate-attribute =].
port of type unsigned short, readonly, nullable
The port of the candidate.
type of type {{RTCIceCandidateType}}, readonly,
nullable
The type of the candidate. This corresponds to the
candidate-types field in [=
candidate-attribute =].
tcpType of type {{RTCIceTcpCandidateType}}, readonly,
nullable
If {{protocol}} is {{RTCIceProtocol/"tcp"}}, {{tcpType}}
represents the type of TCP candidate. Otherwise, {{tcpType}}
is null. This corresponds to the tcp-type field in [= candidate-attribute =].
relatedAddress of type DOMString, readonly, nullable
For a candidate that is derived from another, such as a relay
or reflexive candidate, the {{relatedAddress}} is the IP
address of the candidate that it is derived from. For host
candidates, the {{relatedAddress}} is null. This
corresponds to the rel-address field
in [= candidate-attribute =].
relatedPort of type unsigned short, readonly, nullable
For a candidate that is derived from another, such as a relay
or reflexive candidate, the {{relatedPort}} is the port of
the candidate that it is derived from. For host candidates,
the {{relatedPort}} is null. This corresponds to
the rel-port field in [=
candidate-attribute =].
usernameFragment of type DOMString, readonly, nullable
This carries the ufrag as defined in
section 15.4 of [[RFC5245]].
relayProtocol of type RTCIceServerTransportProtocol, readonly, nullable
For local candidates of type {{RTCIceCandidateType/"relay"}} this is the
protocol used by the endpoint to communicate with the TURN server. For
all other candidates it is `null`.
url of type USVString, readonly, nullable
For local candidates of type {{RTCIceCandidateType/"srflx"}} or type
{{RTCIceCandidateType/"relay"}} this is the URL of the ICE server
from which the candidate was obtained. For all other candidates it is
`null`.
Methods
toJSON()
To invoke the {{toJSON()}} operation of the
{{RTCIceCandidate}} interface, run the following steps:
Let json be a new
{{RTCIceCandidateInit}} dictionary.
For each attribute identifier
attr in «{{candidate}}, {{sdpMid}},
{{sdpMLineIndex}}, {{usernameFragment}}»:
Let value be the result of getting the
underlying value of the attribute identified by
attr, given this {{RTCIceCandidate}} object.
Set json[attr]
to value.
Return json.
{{relayProtocol}} and {{url}} exist for local examination,
not signaling, and do not survive stringification.
This carries the [= candidate-attribute =] as defined in
section 15.1 of [[RFC5245]]. If this represents an
end-of-candidates indication, {{candidate}} is an empty
string.
sdpMid of type DOMString, nullable, defaulting to
null
If not null, this contains the [= media stream
"identification-tag" =] defined in [[!RFC5888]] for the media
component this candidate is associated with.
sdpMLineIndex of type unsigned short, nullable, defaulting
to null
If not null, this indicates the index (starting
at zero) of the [= media description =] in the SDP this
candidate is associated with.
usernameFragment of type DOMString, nullable, defaulting to
null
If not null, this carries the ufrag as defined in section 15.4 of [[RFC5245]].
relayProtocol of type RTCIceServerTransportProtocol, nullable, defaulting to
null
Initializes the {{RTCIceCandidate/relayProtocol}} attribute.
url of type USVString, nullable, defaulting to
null
Initializes the {{RTCIceCandidate/url}} attribute.
candidate-attribute Grammar
The [= candidate-attribute =] grammar is used to parse the
{{RTCIceCandidateInit/candidate}} member of
candidateInitDict in the {{RTCIceCandidate()}}
constructor.
The primary grammar for [= candidate-attribute =] is defined in
section 15.1 of [[RFC5245]]. In addition, the browser MUST support
the grammar extension for ICE TCP as defined in section 4.5 of
[[!RFC6544]].
The browser MAY support other grammar extensions for [=
candidate-attribute =] as defined in other RFCs.
RTCIceProtocol Enum
The {{RTCIceProtocol}} represents the protocol of the ICE
candidate.
enum RTCIceProtocol {
"udp",
"tcp"
};
{{RTCIceProtocol}} Enumeration description
Enum 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]].
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.
A host candidate, as defined in Section 4.1.1.1 of
[[RFC5245]].
srflx
A server reflexive candidate, as defined in Section
4.1.1.2 of [[RFC5245]].
prflx
A peer reflexive candidate, as defined in Section 4.1.1.2
of [[RFC5245]].
relay
A relay candidate, as defined in Section 7.1.3.2.1 of
[[RFC5245]].
RTCIceServerTransportProtocol Enum
The {{RTCIceServerTransportProtocol}} represents the type of the transport
protocol used between the client and the server, as defined in [[RFC8656]] section 3.1.
The TURN client is using UDP as transport to the server.
tcp
The TURN client is using TCP as transport to the server.
tls
The TURN client is using TLS as transport to the server.
RTCPeerConnectionIceEvent
The {{RTCPeerConnection/icecandidate}} event of the
{{RTCPeerConnection}} uses the {{RTCPeerConnectionIceEvent}}
interface.
When firing an {{RTCPeerConnectionIceEvent}} event that contains an
{{RTCIceCandidate}} object, it MUST include values for both
{{RTCIceCandidate/sdpMid}} and {{RTCIceCandidate/sdpMLineIndex}}.
If the {{RTCIceCandidate}} is of type
{{RTCIceCandidateType/"srflx"}} or type
{{RTCIceCandidateType/"relay"}}, the
{{RTCPeerConnectionIceEvent/url}} property of the event MUST be set
to the URL of the ICE server from which the candidate was obtained.
The {{RTCPeerConnection/icecandidate}} event is used for three different types of
indications:
A candidate has been gathered. The
{{RTCPeerConnectionIceEvent/candidate}} member of the event
will be populated normally. It should be signaled to the
remote peer and passed into
{{RTCPeerConnection/addIceCandidate}}.
An {{RTCIceTransport}} has finished gathering a [= generation
=] of candidates, and is providing an end-of-candidates
indication as defined by Section 8.2 of [[RFC8838]]. This
is indicated by
{{RTCPeerConnectionIceEvent/candidate}}.{{RTCIceCandidate/candidate}}
being set to an empty string. The
{{RTCPeerConnectionIceEvent/candidate}} object should be
signaled to the remote peer and passed into
{{RTCPeerConnection/addIceCandidate}} like a typical ICE
candidate, in order to provide the end-of-candidates
indication to the remote peer.
All {{RTCIceTransport}}s have finished gathering candidates,
and the {{RTCPeerConnection}}'s {{RTCIceGatheringState}} has
transitioned to {{RTCIceGatheringState/"complete"}}. This is
indicated by the {{RTCPeerConnectionIceEvent/candidate}}
member of the event being set to null. This only
exists for backwards compatibility, and this event does not
need to be signaled to the remote peer. It's equivalent to an
{{RTCPeerConnection/icegatheringstatechange}} event with the
{{RTCIceGatheringState/"complete"}} state.
candidate of type {{RTCIceCandidate}}, readonly, nullable
The {{candidate}} attribute is the {{RTCIceCandidate}}
object with the new ICE candidate that caused the event.
This attribute is set to null when an event is
generated to indicate the end of candidate gathering.
Even where there are multiple media components, only one
event containing a null candidate is fired.
url of type USVString, readonly, nullable
The {{url}} attribute is the STUN or TURN URL that
identifies the STUN or TURN server used to gather this
candidate. If the candidate was not gathered from a STUN or
TURN server, this parameter will be set to
null.
This attribute is deprecated; it exists for legacy compatibility reasons only.
Prefer the candidate {{RTCIceCandidate/url}}.
The {{address}} attribute is the local IP address used to
communicate with the STUN or TURN server.
On a multihomed system, multiple interfaces may be used to
contact the server, and this attribute allows the
application to figure out on which one the failure
occurred.
If the local IP address value is not already exposed as
part of a local candidate, the {{address}} attribute will
be set to null.
port of type unsigned short, readonly, nullable
The {{port}} attribute is the port used to communicate with
the STUN or TURN server.
If the {{address}} attribute is null, the
{{port}} attribute is also set to null.
url of type USVString, readonly
The {{url}} attribute is the STUN or TURN URL that
identifies the STUN or TURN server for which the failure
occurred.
errorCode of type unsigned short, readonly
The {{errorCode}} attribute is the numeric STUN error code
returned by the STUN or TURN server [[STUN-PARAMETERS]].
If no host candidate can reach the server, {{errorCode}}
will be set to the value 701 which is outside the STUN
error code range. This error is only fired once per server
URL while in the {{RTCIceGatheringState}} of
{{RTCIceGatheringState/"gathering"}}.
errorText of type USVString, readonly
The {{errorText}} attribute is the STUN reason text
returned by the STUN or TURN server [[STUN-PARAMETERS]].
If the server could not be reached, {{errorText}} will be
set to an implementation-specific value providing details
about the error.
Dictionary RTCPeerConnectionIceErrorEventInit
Members
address of type DOMString, nullable
The local address used to communicate with the STUN or TURN
server, or null.
port of type unsigned short, nullable
The local port used to communicate with the STUN or TURN
server, or null.
url of type USVString
The STUN or TURN URL that identifies the STUN or TURN
server for which the failure occurred.
errorCode of type unsigned short, required
The numeric STUN error code returned by the STUN or TURN
server.
errorText of type USVString
The STUN reason text returned by the STUN or TURN server.
Certificate Management
The certificates that {{RTCPeerConnection}} instances use to
authenticate with peers use the {{RTCCertificate}} interface. These
objects can be explicitly generated by applications using the
{{RTCPeerConnection/generateCertificate}} method and can be provided
in the {{RTCConfiguration}} when constructing a new
{{RTCPeerConnection}} instance.
The explicit certificate management functions provided here are
optional. If an application does not provide the
{{RTCConfiguration/certificates}} configuration option when
constructing an {{RTCPeerConnection}} a new set of certificates MUST
be generated by the user agent. That set MUST include an ECDSA
certificate with a private key on the P-256 curve and a signature
with a SHA-256 hash.
The {{generateCertificate}} function causes the user agent to create an X.509 certificate [[!X509V3]] and
corresponding private key. A handle to information is
provided in the form of the {{RTCCertificate}} interface. The
returned {{RTCCertificate}} can be used to control the
certificate that is offered in the DTLS sessions established
by {{RTCPeerConnection}}.
The keygenAlgorithm argument is used to control
how the private key associated with the certificate is
generated. The keygenAlgorithm argument uses the
WebCrypto [[!WebCryptoAPI]] AlgorithmIdentifier
type.
The following values MUST be supported by a user agent: { name: "RSASSA-PKCS1-v1_5",
modulusLength: 2048, publicExponent: new Uint8Array([1, 0,
1]), hash: "SHA-256" }, and { name:
"ECDSA", namedCurve:
"P-256"
}.
It is expected that a user agent will have a small or
even fixed set of values that it will accept.
The certificate produced by this process also contains a
signature. The validity of this signature is only relevant
for compatibility reasons. Only the public key and the
resulting certificate fingerprint are used by
{{RTCPeerConnection}}, but it is more likely that a
certificate will be accepted if the certificate is well
formed. The browser selects the algorithm used to sign the
certificate; a browser SHOULD select SHA-256 [[!FIPS-180-4]]
if a hash algorithm is needed.
The resulting certificate MUST NOT include information that
can be linked to a user or user agent. Randomized
values for distinguished name and serial number SHOULD be
used.
When the method is called, the user agent MUST run the
following steps:
Let keygenAlgorithm be the first argument to
{{generateCertificate}}.
Let expires be a value of
2592000000 (30*24*60*60*1000)
This means the certificate will by default expire in 30
days from the time of the {{generateCertificate}} call.
If keygenAlgorithm is an object, run the
following steps:
Let certificateExpiration be the result of
converting
the ECMAScript object represented by
keygenAlgorithm to an
{{RTCCertificateExpiration}} dictionary.
If the conversion fails with an error,
return a promise that is [= rejected =] with
error.
If
certificateExpiration.{{RTCCertificateExpiration/expires}}
is not undefined, set expires
to
certificateExpiration.{{RTCCertificateExpiration/expires}}.
If expires is greater than 31536000000,
set expires to 31536000000.
This means the certificate cannot be valid for
longer than 365 days from the time of the
{{generateCertificate}} call.
A user agent MAY further cap the value of
expires.
Let normalizedKeygenAlgorithm be the result of
normalizing an algorithm with an operation name of generateKey
and a supportedAlgorithms
value specific to production of certificates for
{{RTCPeerConnection}}.
If the above normalization step fails with an
error, return a promise that is [= rejected =]
with error.
If the normalizedKeygenAlgorithm parameter
identifies an algorithm that the user agent cannot
or will not use to generate a certificate for
{{RTCPeerConnection}}, return a promise that is [=
rejected =] with a {{DOMException}} of type
{{NotSupportedError}}. In particular,
normalizedKeygenAlgorithm MUST be an
asymmetric algorithm that can be used to produce a
signature used to authenticate DTLS connections.
Let p be a new promise.
Run the following steps [=in parallel=]:
Perform the generate key operation specified by
normalizedKeygenAlgorithm using
keygenAlgorithm.
Let generatedKeyingMaterial and
generatedKeyCertificate be the private
keying material and certificate generated by the
above step.
Let certificate be a new
{{RTCCertificate}} object.
Set certificate.[[\Expires]] to the
current time plus expires value.
Set certificate.{{RTCCertificate/[[Origin]]}} to the
[= relevant settings object =]'s
[=environment settings object/origin=].
Store the generatedKeyingMaterial in a
secure module, and let handle be a
reference identifier to it.
Set certificate.{{RTCCertificate/[[KeyingMaterialHandle]]}}
to handle.
Set certificate.{{RTCCertificate/[[Certificate]]}} to
generatedCertificate.
[=Queue a global task=] on the [=networking task source=] given the
current realm's [=global object=] as global to [=resolve=]
p with certificate.
Return p.
RTCCertificateExpiration Dictionary
{{RTCCertificateExpiration}} is used to set an expiration date on
certificates generated by
{{RTCPeerConnection/generateCertificate}}.
dictionary RTCCertificateExpiration {
[EnforceRange] unsigned long long expires;
};
expires, of type unsigned long long
An optional {{expires}} attribute MAY be added to the
definition of the algorithm that is passed to
{{RTCPeerConnection/generateCertificate}}. If this parameter is
[=map/exists|present=] it indicates the maximum time in milliseconds that the
{{RTCCertificate}} is valid for, measured from the time the
certificate is created.
RTCCertificate Interface
The {{RTCCertificate}} interface represents a certificate used to
authenticate WebRTC communications. In addition to the visible
properties, internal slots contain a handle to the generated
private keying materal ([[\KeyingMaterialHandle]]), a
certificate ([[\Certificate]]) that
{{RTCPeerConnection}} uses to authenticate with a peer, and the
origin ([[\Origin]]) that created the object.
The expires attribute indicates the date and
time in milliseconds relative to 1970-01-01T00:00:00Z after
which the certificate will be considered invalid by the
browser. After this time, attempts to construct an
{{RTCPeerConnection}} using this certificate fail.
Note that this value might not be reflected in a
notAfter parameter in the
certificate itself.
Methods
getFingerprints
Returns the list of certificate fingerprints, one of which
is computed with the digest algorithm used in the
certificate signature.
For the purposes of this API, the {{RTCCertificate/[[Certificate]]}} slot
contains unstructured binary data. No mechanism is provided for
applications to access the {{RTCCertificate/[[KeyingMaterialHandle]]}}
internal slot or the keying material it references. Implementations
MUST support applications storing and retrieving {{RTCCertificate}}
objects from persistent storage, in a manner that also preserves
the keying material referenced by {{RTCCertificate/[[KeyingMaterialHandle]]}}.
Implementations SHOULD store the sensitive keying material in a
secure module safe from same-process memory attacks. This allows
the private key to be stored and used, but not easily read using a
memory attack.
{{RTCCertificate}} objects are [= serializable objects =]
[[!HTML]]. Their [= serialization steps =], given value
and serialized, are:
Set serialized.[[\Expires]] to the value of
value.{{RTCCertificate/expires}} attribute.
Set serialized.[[\Certificate]] to a copy of the
unstructured binary data in
value.{{RTCCertificate/[[Certificate]]}}.
Set serialized.[[\Origin]] to a copy of the
unstructured binary data in value.{{RTCCertificate/[[Origin]]}}.
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:
Initialize value.{{RTCCertificate/expires}}
attribute to contain serialized.[[\Expires]].
Set value.{{RTCCertificate/[[Certificate]]}} to a copy of
serialized.[[\Certificate]]
Set value.{{RTCCertificate/[[Origin]]}} to a copy of
serialized.[[\Origin]]
Set value.{{RTCCertificate/[[KeyingMaterialHandle]]}} to the
private keying material handle resulting from deserializing
serialized.[[\KeyingMaterialHandle]]
Supporting structured cloning in this manner allows
{{RTCCertificate}} instances to be persisted to stores. It also
allows instances to be passed to other origins using APIs like
{{MessagePort/postMessage(message, options)}} [[html]]. However, the object cannot
be used by any other origin than the one that originally created
it.
RTP Media API
The RTP media API lets a web application send and receive
{{MediaStreamTrack}}s over a peer-to-peer connection. Tracks, when
added to an {{RTCPeerConnection}}, result in signaling; when this
signaling is forwarded to a remote peer, it causes corresponding tracks
to be created on the remote side.
There is not an exact 1:1 correspondence between tracks sent by one
{{RTCPeerConnection}} and received by the other. For one, IDs of tracks
sent have no mapping to the IDs of tracks received. Also,
{{RTCRtpSender/replaceTrack}} changes the track sent by an
{{RTCRtpSender}} without creating a new track on the receiver side; the
corresponding {{RTCRtpReceiver}} will only have a single track,
potentially representing multiple sources of media stitched together.
Both {{RTCPeerConnection/addTransceiver}} and
{{RTCRtpSender/replaceTrack}} can be used to cause the same track to be
sent multiple times, which will be observed on the receiver side as
multiple receivers each with its own separate track. Thus it's more
accurate to think of a 1:1 relationship between an {{RTCRtpSender}} on
one side and an {{RTCRtpReceiver}}'s track on the other side, matching
senders and receivers using the {{RTCRtpTransceiver}}'s
{{RTCRtpTransceiver/mid}} if necessary.
When sending media, the sender may need to rescale or resample the
media to meet various requirements, including the envelope negotiated by
SDP, alignment restrictions of the encoder, or even CPU overuse
detection or bandwidth estimation.
Following the rules in [[!RFC9429]],
the video MAY be downscaled. The
media MUST NOT be upscaled to create fake data that did not occur in
the input source, the media MUST NOT be cropped except as needed to
satisfy constraints on pixel counts, and the aspect ratio MUST NOT be
changed.
The WebRTC Working Group is seeking implementation feedback on the need
and timeline for a more complex handling of this situation. Some
possible designs have been discussed in GitHub issue 1283.
Whenever video is rescaled as a result of
{{RTCRtpEncodingParameters/scaleResolutionDownBy}},
situations when the resulting width or height is not an integer
may occur. The user agent MUST NOT transmit video larger than
the integer part
of the scaled width and height from
{{RTCRtpEncodingParameters/scaleResolutionDownBy}}, except to respect an
encoder's minimum resolution. What to transmit if the integer part of
the scaled width or height is zero is [=implementation-defined=].
The actual encoding and transmission of {{MediaStreamTrack}}s is
managed through objects called {{RTCRtpSender}}s. Similarly, the
reception and decoding of {{MediaStreamTrack}}s is managed through
objects called {{RTCRtpReceiver}}s. Each {{RTCRtpSender}} is associated
with at most one track, and each track to be received is associated
with exactly one {{RTCRtpReceiver}}.
The encoding and transmission of each {{MediaStreamTrack}} SHOULD be
made such that its characteristics (width,
height and frameRate
for video tracks; sampleSize, sampleRate and
channelCount for audio tracks) are to a
reasonable degree retained by the track created on the remote side.
There are situations when this does not apply, there may for example be
resource constraints at either endpoint or in the network or there may
be {{RTCRtpSender}} settings applied that instruct the implementation
to act differently.
An {{RTCPeerConnection}} object contains a set of {{RTCRtpTransceiver}}s,
representing the paired senders and receivers with some shared state.
This set is
initialized to the empty set when the {{RTCPeerConnection}} object is
created. {{RTCRtpSender}}s and {{RTCRtpReceiver}}s are always
created at the same time as an {{RTCRtpTransceiver}}, which they will
remain attached to for their lifetime. {{RTCRtpTransceiver}}s are
created implicitly when the application attaches a {{MediaStreamTrack}}
to an {{RTCPeerConnection}} via the {{RTCPeerConnection/addTrack()}}
method, or explicitly when the application uses the
{{RTCPeerConnection/addTransceiver}} method. They are also created when
a remote description is applied that includes a new media description.
Additionally, when a remote description is applied that indicates the
remote endpoint has media to send, the relevant {{MediaStreamTrack}}
and {{RTCRtpReceiver}} are surfaced to the application via the
{{RTCPeerConnection/track}} event.
In order for an {{RTCRtpTransceiver}} to send and/or receive media with
another endpoint this must be negotiated with SDP such that both
endpoints have an {{RTCRtpTransceiver}} object that is [= associated =]
with the same [= media description =].
When creating an offer, enough media descriptions will be generated to
cover all transceivers on that end. When this offer is set as the local
description, any disassociated transceivers get associated with media
descriptions in the offer.
When an offer is set as the remote description, any media descriptions
in it not yet associated with a transceiver get associated with a new
or existing transceiver. In this case, only disassociated transceivers
that were created via the {{RTCPeerConnection/addTrack()}} method may
be associated. Disassociated transceivers created via the
{{RTCPeerConnection/addTransceiver()}} method, however, won't get
associated even if media descriptions are available in the remote
offer. Instead, new transceivers will be created and associated if
there aren't enough {{RTCPeerConnection/addTrack()}}-created
transceivers. This sets {{RTCPeerConnection/addTrack()}}-created and
{{RTCPeerConnection/addTransceiver()}}-created transceivers apart in a
critical way that is not observable from inspecting their attributes.
When creating an answer, only media descriptions that were
present in the offer may be listed in the answer. As a consequence, any
transceivers that were not associated when setting the remote offer
remain disassociated after setting the local answer. This can be
remedied by the answerer creating a follow-up offer, initiating another
offer/answer exchange, or in the case of using
{{RTCPeerConnection/addTrack()}}-created transceivers, making sure that
enough media descriptions are offered in the initial exchange.
RTCPeerConnection Interface Extensions
The RTP media API extends the {{RTCPeerConnection}} interface as
described below.
The event type of this event handler is {{RTCPeerConnection/track}}.
Methods
getSenders
Returns a sequence of {{RTCRtpSender}} objects representing
the RTP senders that belong to non-stopped
{{RTCRtpTransceiver}} objects currently attached to this
{{RTCPeerConnection}} object.
When the {{getSenders}} method is invoked, the user agent
MUST return the result of executing the {{CollectSenders}}
algorithm.
We define the CollectSenders algorithm as follows:
Let
transceivers be the result of executing the
{{CollectTransceivers}} algorithm.
Let
senders be a new empty sequence.
For each transceiver in
transceivers,
If
transceiver.{{RTCRtpTransceiver/[[Stopped]]}} is
false, add
transceiver.{{RTCRtpTransceiver/[[Sender]]}} to
senders.
Return
senders.
getReceivers
Returns a sequence of {{RTCRtpReceiver}} objects representing
the RTP receivers that belong to non-stopped
{{RTCRtpTransceiver}} objects currently attached to this
{{RTCPeerConnection}} object.
When the {{getReceivers}} method is invoked, the user agent
MUST run the following steps:
Let
transceivers be the result of executing the
{{CollectTransceivers}} algorithm.
Let
receivers be a new empty sequence.
For each
transceiver in transceivers,
If transceiver.{{RTCRtpTransceiver/[[Stopped]]}} is
false, add
transceiver.{{RTCRtpTransceiver/[[Receiver]]}} to
receivers.
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:
Let
transceivers be a new sequence consisting of all
{{RTCRtpTransceiver}} objects in this {{RTCPeerConnection}}
object's [= set of transceivers =], in insertion order.
Return transceivers.
addTrack
Adds a new track to the {{RTCPeerConnection}}, and indicates
that it is contained in the specified {{MediaStream}}s.
When the {{addTrack}} method is invoked, the user agent MUST
run the following steps:
Let connection be the {{RTCPeerConnection}}
object on which this method was invoked.
Let track be the {{MediaStreamTrack}} object
indicated by the method's first argument.
Let kind be track.kind.
Let streams be a list of {{MediaStream}}
objects constructed from the method's remaining
arguments, or an empty list if the method was called with
a single argument.
If connection.{{RTCPeerConnection/[[IsClosed]]}} is
true, [= exception/throw =] an
{{InvalidStateError}}.
Let senders be the result of executing the
{{CollectSenders}} algorithm. If an {{RTCRtpSender}} for
track already exists in senders, [=
exception/throw =] an {{InvalidAccessError}}.
The steps below describe how to determine if an existing
sender can be reused. Doing so will cause future calls to
{{RTCPeerConnection/createOffer}} and
{{RTCPeerConnection/createAnswer}} to mark the
corresponding [= media description =] as sendrecv or sendonly and add the MSID of the sender's
streams, as defined in [[!RFC9429]].
If any {{RTCRtpSender}} object in senders
matches all the following criteria, let sender
be that object, or null otherwise:
The sender's track is null.
The [=RTCRtpTransceiver/transceiver kind=] of the
{{RTCRtpTransceiver}}, associated with the sender,
matches kind.
The {{RTCRtpTransceiver/[[Stopping]]}} slot of the
{{RTCRtpTransceiver}} associated with the sender is
false.
The sender has never been used to send. More
precisely, the {{RTCRtpTransceiver/[[CurrentDirection]]}} slot of
the {{RTCRtpTransceiver}} associated with the sender
has never had a value of
{{RTCRtpTransceiverDirection/"sendrecv"}} or
{{RTCRtpTransceiverDirection/"sendonly"}}.
If sender is not null, run the
following steps to use that sender:
Set sender.{{RTCRtpSender/[[SenderTrack]]}} to
track.
Set
sender.{{RTCRtpSender/[[AssociatedMediaStreamIds]]}}
to an empty set.
For each stream in streams, add
stream.id to
{{RTCRtpSender/[[AssociatedMediaStreamIds]]}} if it's not
already there.
Let transceiver be the
{{RTCRtpTransceiver}} associated with
sender.
If transceiver.{{RTCRtpTransceiver/[[Direction]]}} is
{{RTCRtpTransceiverDirection/"recvonly"}}, set
transceiver.{{RTCRtpTransceiver/[[Direction]]}} to
{{RTCRtpTransceiverDirection/"sendrecv"}}.
If transceiver.{{RTCRtpTransceiver/[[Direction]]}} is
{{RTCRtpTransceiverDirection/"inactive"}}, set
transceiver.{{RTCRtpTransceiver/[[Direction]]}} to
{{RTCRtpTransceiverDirection/"sendonly"}}.
If sender is null, run the
following steps:
Create an RTCRtpSender with track,
kind and streams, and let
sender be the result.
Create an RTCRtpReceiver with kind,
and let receiver be the result.
Create an RTCRtpTransceiver with
sender, receiver and an
{{RTCRtpTransceiverDirection}} value of
{{RTCRtpTransceiverDirection/"sendrecv"}}, and let
transceiver be the result.
Add transceiver to connection's
[= set of transceivers =].
A track could have contents that are inaccessible to the
application. This can be due to anything that would make
a track CORS cross-origin. These tracks can be supplied to the
{{RTCPeerConnection/addTrack()}} method, and have an
{{RTCRtpSender}} created for them, but content MUST NOT
be transmitted. Silence (audio), black frames (video) or
equivalently absent content is sent in place of track
content.
Note that this property can change over time.
[= Update the negotiation-needed flag =] for
connection.
Return sender.
removeTrack
Stops sending media from sender. The
{{RTCRtpSender}} will still appear in {{getSenders}}. Doing
so will cause future calls to {{createOffer}} to mark the [=
media description =] for the corresponding transceiver as
{{RTCRtpTransceiverDirection/"recvonly"}} or
{{RTCRtpTransceiverDirection/"inactive"}}, as defined in
[[!RFC9429]].
When the other peer stops sending a track in this manner, the
track is removed from any remote {{MediaStream}}s that were
initially revealed in the {{RTCPeerConnection/track}}
event, and if the {{MediaStreamTrack}} is not already muted,
a mute event is fired at the
track.
The same effect as {{removeTrack()}} can be achieved by
setting the
{{RTCRtpTransceiver}}.{{RTCRtpTransceiver/direction}}
attribute of the corresponding transceiver and invoking
{{RTCRtpSender}}.{{RTCRtpSender/replaceTrack}}(null) on the
sender. One minor difference is that
{{RTCRtpSender/replaceTrack()}} is asynchronous and
{{removeTrack()}} is synchronous.
When the {{removeTrack}} method is invoked, the user agent
MUST run the following steps:
Let sender be the argument to {{removeTrack}}.
Let connection be the {{RTCPeerConnection}}
object on which the method was invoked.
If connection.{{RTCPeerConnection/[[IsClosed]]}} is
true, [= exception/throw =] an
{{InvalidStateError}}.
If sender was not created by
connection, [= exception/throw =] an
{{InvalidAccessError}}.
Let transceiver be the {{RTCRtpTransceiver}}
object corresponding to sender.
If transceiver.{{RTCRtpTransceiver/[[Stopping]]}} is
true, abort these steps.
Let senders be the result of executing the
{{CollectSenders}} algorithm.
If sender is not in senders (which
indicates its transceiver was stopped or removed due to
[= setting a session description =] of
{{RTCSessionDescriptionInit/type}}
{{RTCSdpType/"rollback"}}), then abort these steps.
If sender.{{RTCRtpSender/[[SenderTrack]]}} is null,
abort these steps.
Set sender.{{RTCRtpSender/[[SenderTrack]]}} to null.
If transceiver.{{RTCRtpTransceiver/[[Direction]]}} is
{{RTCRtpTransceiverDirection/"sendrecv"}}, set
transceiver.{{RTCRtpTransceiver/[[Direction]]}} to
{{RTCRtpTransceiverDirection/"recvonly"}}.
If transceiver.{{RTCRtpTransceiver/[[Direction]]}} is
{{RTCRtpTransceiverDirection/"sendonly"}}, set
transceiver.{{RTCRtpTransceiver/[[Direction]]}} to
{{RTCRtpTransceiverDirection/"inactive"}}.
[= Update the negotiation-needed flag =] for
connection.
addTransceiver
Create a new {{RTCRtpTransceiver}} and add it to the [= set
of transceivers =].
Adding a transceiver will cause future calls to
{{createOffer}} to add a [= media description =] for the
corresponding transceiver, as defined in [[!RFC9429]].
The initial value of {{RTCRtpTransceiver/mid}} is null.
[= Setting a session description =] may later change it to a
non-null value.
The {{RTCRtpTransceiverInit/sendEncodings}} argument can be
used to specify the number of offered simulcast encodings,
and optionally their RIDs and encoding parameters.
When this method is invoked, the user agent MUST run the
following steps:
Let init be the second argument.
Let streams be
init.{{RTCRtpTransceiverInit/streams}}.
Let sendEncodings be
init.{{RTCRtpTransceiverInit/sendEncodings}}.
Let direction be
init.{{RTCRtpTransceiverInit/direction}}.
If the first argument is a string, let kind be
the first argument and run the following steps:
If kind is neither `"audio"` nor `"video"`,
[= exception/throw =] a {{TypeError}}.
Let track be null.
If the first argument is a {{MediaStreamTrack}}, let
track be the first argument and let kind be
track.{{MediaStreamTrack/kind}}.
If connection.{{RTCPeerConnection/[[IsClosed]]}} is
true, [= exception/throw =] an
{{InvalidStateError}}.
Validate sendEncodings by running the following
addTransceiver sendEncodings validation steps,
where each {{RTCRtpEncodingParameters}}
dictionary in it is an "encoding":
If any of the following conditions are met,
[=exception/throw=] a {{TypeError}}:
Any encoding [=map/contains=] a
{{RTCRtpCodingParameters/rid}} member whose value
does not conform to the grammar requirements specified
in Section 10 of [[RFC8851]].
Some but not all encodings [=map/contain=] a
{{RTCRtpCodingParameters/rid}} member.
Any encoding [=map/contains=] a
{{RTCRtpCodingParameters/rid}} member whose value
is the same as that of a {{RTCRtpCodingParameters/rid}}
[=map/contains | contained=] in another encoding in
sendEncodings.
If any encoding [=map/contains=] a read-only parameter other than
{{RTCRtpCodingParameters/rid}}, [= exception/throw =]
an {{InvalidAccessError}}.
If any encoding [=map/contains=] a
{{RTCRtpEncodingParameters/codec}} member whose value does
[= codec dictionary match | not match =] any codec in {{RTCRtpSender.getCapabilities(kind)}}.codecs,
[= exception/throw =] an {{OperationError}}.
If the user agent does not support changing codecs without negotiation or
does not support setting codecs for individual encodings, return a promise
[= rejected =] with a newly [= exception/created =] {{OperationError}}.
If kind is `"audio"`, remove the
{{RTCRtpEncodingParameters/scaleResolutionDownBy}} and
{{RTCRtpEncodingParameters/maxFramerate}}
members from all encodings that [=map/contain=] any of
them.
If any encoding [=map/contains=] a
{{RTCRtpEncodingParameters/scaleResolutionDownBy}}
member whose value is less than `1.0`, [=
exception/throw =] a {{RangeError}}.
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}}.
Let maxN be the maximum number of total
simultaneous encodings the user agent may support for
this kind, at minimum 1.This
should be an optimistic number since the codec to be
used is not known yet.
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`.
If the number of encodings stored
in sendEncodings exceeds maxN,
then trim sendEncodings from the tail
until its length is maxN.
If kind is `"video"` and none of the
encodings [=map/contain=] a
{{RTCRtpEncodingParameters/scaleResolutionDownBy}}
member, then for each encoding, add a
{{RTCRtpEncodingParameters/scaleResolutionDownBy}}
member with the value
2^(length of sendEncodings - encoding
index - 1). This results in smaller-to-larger
resolutions where the last encoding has no scaling
applied to it, e.g. 4:2:1 if the length is 3.
If the number of encodings now
stored in sendEncodings is 1,
then remove any {{RTCRtpCodingParameters/rid}} member
from the lone entry.
Providing a single, default
{{RTCRtpEncodingParameters}} in
sendEncodings allows the application to
subsequently set encoding parameters using
{{RTCRtpSender/setParameters}}, even when simulcast
isn't used.
Create an RTCRtpSender with track,
kind, streams and
sendEncodings and let sender be the
result.
If sendEncodings is set, then subsequent calls
to {{createOffer}} will be configured to send multiple
RTP encodings as defined in [[!RFC9429]]. When
{{RTCPeerConnection/setRemoteDescription}} is called with
a corresponding remote description that is able to
receive multiple RTP encodings as defined in
[[!RFC9429]], the
{{RTCRtpSender}} may send multiple RTP encodings and the
parameters retrieved via the transceiver's
{{RTCRtpTransceiver/sender}}.{{RTCRtpSender/getParameters()}}
will reflect the encodings negotiated.
Create an RTCRtpReceiver with kind and
let receiver be the result.
Create an RTCRtpTransceiver with
sender, receiver and
direction, and let transceiver be
the result.
Add transceiver to connection's [=
set of transceivers =].
[= Update the negotiation-needed flag =] for
connection.
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.
The {{RTCRtpTransceiver}}'s {{RTCRtpSender}}
sender will offer to send RTP, and will send RTP
if the remote peer accepts and
sender.{{RTCRtpSender/getParameters()}}.{{RTCRtpSendParameters/encodings}}[i].{{RTCRtpEncodingParameters/active}}
is true for any value of i. The
{{RTCRtpTransceiver}}'s {{RTCRtpReceiver}} will offer to
receive RTP, and will receive RTP if the remote peer accepts.
sendonly
The {{RTCRtpTransceiver}}'s {{RTCRtpSender}}
sender will offer to send RTP, and will send RTP
if the remote peer accepts and
sender.{{RTCRtpSender/getParameters()}}.{{RTCRtpSendParameters/encodings}}[i].{{RTCRtpEncodingParameters/active}}
is true for any value of i. The
{{RTCRtpTransceiver}}'s {{RTCRtpReceiver}} will not offer to
receive RTP, and will not receive RTP.
recvonly
The {{RTCRtpTransceiver}}'s {{RTCRtpSender}} will not offer
to send RTP, and will not send RTP. The
{{RTCRtpTransceiver}}'s {{RTCRtpReceiver}} will offer to
receive RTP, and will receive RTP if the remote peer accepts.
inactive
The {{RTCRtpTransceiver}}'s {{RTCRtpSender}} will not offer
to send RTP, and will not send RTP. The
{{RTCRtpTransceiver}}'s {{RTCRtpReceiver}} will not offer to
receive RTP, and will not receive RTP.
stopped
The {{RTCRtpTransceiver}} will neither send nor receive RTP.
It will generate a zero port in the offer. In answers, its
{{RTCRtpSender}} will not offer to send RTP, and its
{{RTCRtpReceiver}} will not offer to receive RTP. This is a
terminal state.
Processing Remote MediaStreamTracks
An application can reject incoming media descriptions by setting
the transceiver's direction to either
{{RTCRtpTransceiverDirection/"inactive"}} to turn off both
directions temporarily, or to
{{RTCRtpTransceiverDirection/"sendonly"}} to reject only the
incoming side. To permanently reject an m-line in a manner that
makes it available for reuse, the application would need to call
{{RTCRtpTransceiver}}.{{RTCRtpTransceiver/stop()}} and subsequently
initiate negotiation from its end.
To process remote tracks
given an {{RTCRtpTransceiver}} transceiver,
direction, msids, addList,
removeList, and trackEventInits, run the
following steps:
Set the associated remote streams with
transceiver.{{RTCRtpTransceiver/[[Receiver]]}}, msids,
addList, and removeList.
If direction is
{{RTCRtpTransceiverDirection/"sendrecv"}} or
{{RTCRtpTransceiverDirection/"recvonly"}} and
transceiver.{{RTCRtpTransceiver/[[FiredDirection]]}} is neither
{{RTCRtpTransceiverDirection/"sendrecv"}} nor
{{RTCRtpTransceiverDirection/"recvonly"}}, or the previous step
increased the length of addList, process the addition of a remote track with transceiver and
trackEventInits.
If direction is
{{RTCRtpTransceiverDirection/"sendonly"}} or
{{RTCRtpTransceiverDirection/"inactive"}}, set
transceiver.{{RTCRtpTransceiver/[[Receptive]]}} to
false.
If direction is
{{RTCRtpTransceiverDirection/"sendonly"}} or
{{RTCRtpTransceiverDirection/"inactive"}}, and
transceiver.{{RTCRtpTransceiver/[[FiredDirection]]}} is either
{{RTCRtpTransceiverDirection/"sendrecv"}} or
{{RTCRtpTransceiverDirection/"recvonly"}}, process the removal of a remote track for the media description,
with transceiver and muteTracks.
Set transceiver.{{RTCRtpTransceiver/[[FiredDirection]]}} to
direction.
To process the addition of
a remote track given an {{RTCRtpTransceiver}}
transceiver and trackEventInits, run the
following steps:
Let receiver be
transceiver.{{RTCRtpTransceiver/[[Receiver]]}}.
Let track be
receiver.{{RTCRtpReceiver/[[ReceiverTrack]]}}.
Let streams be
receiver.{{RTCRtpReceiver/[[AssociatedRemoteMediaStreams]]}}.
Create a new {{RTCTrackEventInit}} dictionary with
receiver, track, streams and
transceiver as members and add it to
trackEventInits.
To process the removal of a
remote track with an {{RTCRtpTransceiver}}
transceiver and muteTracks, run the following
steps:
Let receiver be
transceiver.{{RTCRtpTransceiver/[[Receiver]]}}.
Let track be
receiver.{{RTCRtpReceiver/[[ReceiverTrack]]}}.
If track.muted is false, add
track to muteTracks.
To set the associated
remote streams given {{RTCRtpReceiver}} receiver,
msids, addList, and removeList,
run the following steps:
Let connection be the {{RTCPeerConnection}} object
associated with receiver.
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.
Let streams be a list of the {{MediaStream}} objects
created for this connection with the ids corresponding to msids.
Let track be
receiver.{{RTCRtpReceiver/[[ReceiverTrack]]}}.
For each stream in
receiver.{{RTCRtpReceiver/[[AssociatedRemoteMediaStreams]]}}
that is not present in streams, add
stream and track as a pair to
removeList.
For each stream in streams that is not
present in
receiver.{{RTCRtpReceiver/[[AssociatedRemoteMediaStreams]]}},
add stream and track as a pair to
addList.
Set
receiver.{{RTCRtpReceiver/[[AssociatedRemoteMediaStreams]]}} to
streams.
RTCRtpSender Interface
The {{RTCRtpSender}} interface allows an application to control how a
given {{MediaStreamTrack}} is encoded and transmitted to a remote
peer. When {{RTCRtpSender/setParameters}} is called on an
{{RTCRtpSender}} object, the encoding is changed appropriately.
To create an RTCRtpSender with a {{MediaStreamTrack}},
track, a string, kind, a list of
{{MediaStream}} objects, streams, and optionally a list of
{{RTCRtpEncodingParameters}} objects, sendEncodings, run
the following steps:
Let sender be a new {{RTCRtpSender}} object.
Let sender have a [[\SenderTrack]] internal
slot initialized to track.
Let sender have a [[\SenderTransport]]
internal slot initialized to null.
Let sender have a
[[\LastStableStateSenderTransport]] internal slot
initialized to null.
Let sender have a [[\Dtmf]] internal slot
initialized to null.
If kind is "audio" then create an RTCDTMFSender dtmf and set the {{RTCRtpSender/[[Dtmf]]}}
internal slot to dtmf.
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]].
Set sender.{{RTCRtpSender/[[AssociatedMediaStreamIds]]}} to an
empty set.
For each stream in streams, add
stream.id to {{RTCRtpSender/[[AssociatedMediaStreamIds]]}} if
it's not already there.
Let sender have a [[\SendEncodings]]
internal slot, representing a list of
{{RTCRtpEncodingParameters}} dictionaries.
If sendEncodings is given as input to this algorithm,
and is non-empty, set the {{RTCRtpSender/[[SendEncodings]]}} slot to
sendEncodings. Otherwise, set it to a list containing
a single new {{RTCRtpEncodingParameters}} dictionary, and if
kind is `"video"`, add a
{{RTCRtpEncodingParameters/scaleResolutionDownBy}} member with the
value `1.0` to that dictionary.
{{RTCRtpEncodingParameters}} dictionaries contain
{{RTCRtpEncodingParameters/active}} members whose values are
true by default.
Let sender have a
[[\LastStableRidlessSendEncodings]] internal slot
initialized to null.
Let sender have a [[\SendCodecs]] internal
slot, representing a list of {{RTCRtpCodecParameters}}
dictionaries, and initialized to an empty list.
Let sender have a
[[\LastReturnedParameters]] internal slot, which will
be used to match {{RTCRtpSender/getParameters}} and
{{RTCRtpSender/setParameters}} transactions.
track of type {{MediaStreamTrack}}, readonly, nullable
The {{track}} attribute is the track that is associated with
this {{RTCRtpSender}} object. If {{track}} is ended, or if
the track's output is disabled, i.e. the track is disabled
and/or muted, the {{RTCRtpSender}} MUST send black frames
(video) and MUST NOT send (audio). In the case of video, the
{{RTCRtpSender}} SHOULD send one black frame per second. If
{{track}} is null then the {{RTCRtpSender}} does
not send. On getting, the attribute MUST return the value of
the {{RTCRtpSender/[[SenderTrack]]}} slot.
transport of type {{RTCDtlsTransport}}, readonly, nullable
The {{transport}} attribute is the transport over which media
from {{track}} is sent in the form of RTP packets. Prior to
construction of the {{RTCDtlsTransport}} object, the
{{transport}} attribute will be null. When bundling is used,
multiple {{RTCRtpSender}} objects will share one
{{transport}} and will all send RTP and RTCP over the same
transport.
On getting, the attribute MUST return the value of the
{{RTCRtpSender/[[SenderTransport]]}} slot.
Methods
getCapabilities, static
The static {{RTCRtpSender}}.{{getCapabilities()}} method provides a way to
discover the types of capabilities the user agent supports for sending media
of the given kind, without reserving any resources, ports, or other state.
When the {{getCapabilities}} method is called, the user agent MUST run the
following steps:
Let kind be the method's first argument.
If kind is neither `"video"` nor `"audio"` return `null`.
Return a new {{RTCRtpCapabilities}} dictionary, with its
{{RTCRtpCapabilities/codecs}} member initialized to the
[=RTCRtpSender/list of implemented send codecs=] for kind, and its
{{RTCRtpCapabilities/headerExtensions}} member initialized to the
[=list of implemented header extensions for sending=] with
kind.
The list of implemented send codecs, given kind, is
an [=implementation-defined=] list of {{RTCRtpCodec}}
dictionaries representing the most optimistic view of the codecs the user
agent supports for sending media of the given kind (video or audio).
The list of implemented header extensions for sending, given
kind, is an [=implementation-defined=] list of
{{RTCRtpHeaderExtensionCapability}} dictionaries representing the most
optimistic view of the header extensions the user agent supports for
sending media of the given kind (video or audio).
These capabilities provide generally persistent cross-origin
information on the device and thus increases the
fingerprinting surface of the application. In
privacy-sensitive contexts, user agents MAY consider mitigations
such as reporting only a common subset of the capabilities.
The codec capabilities returned affect the
{{RTCRtpTransceiver/setCodecPreferences()}} algorithm and
what inputs it throws {{InvalidModificationError}} on,
and should also be consistent with information revealed by
{{RTCPeerConnection/createOffer()}} and {{RTCPeerConnection/createAnswer()}} about codecs
negotiated for sending, to ensure any
privacy mitigations are effective.
setParameters
The {{setParameters}} method updates how {{track}} is encoded
and transmitted to a remote peer.
When the {{setParameters}} method is called, the user agent
MUST run the following steps:
Let parameters be the
method's first argument.
Let sender be the
{{RTCRtpSender}} object on which {{setParameters}} is
invoked.
Let transceiver be the
{{RTCRtpTransceiver}} object associated with
sender (i.e. sender is
transceiver.{{RTCRtpTransceiver/[[Sender]]}}).
If transceiver.{{RTCRtpTransceiver/[[Stopping]]}} is
true, return a promise [= rejected =] with a
newly [= exception/created =] {{InvalidStateError}}.
If
sender.{{RTCRtpSender/[[LastReturnedParameters]]}} is
null, return a promise [= rejected =] with a
newly [= exception/created =] {{InvalidStateError}}.
Validate parameters by running the following
setParameters validation steps:
Let encodings be
parameters.{{RTCRtpSendParameters/encodings}}.
Let codecs be
parameters.{{RTCRtpParameters/codecs}}.
Let choosableCodecs be codecs.
If choosableCodecs is an empty list, set choosableCodecs
to the [=RTCRtpSender/list of implemented send codecs=] for transceiver's kind.
Let N be the number
of {{RTCRtpEncodingParameters}} stored in
sender.{{RTCRtpSender/[[SendEncodings]]}}.
If any of the following conditions are met, return a
promise [= rejected =] with a newly [= exception/created
=] {{InvalidModificationError}}:
encodings.length is
different from N.
encodings has been re-ordered.
Any parameter in parameters is marked as a
Read-only parameter (such as RID) and has
a value that is different from the corresponding
parameter value in
sender.{{RTCRtpSender/[[LastReturnedParameters]]}}.
Note that this also applies to
transactionId.
Any encoding in encodings [=map/exists|contains=] a codec
not found in choosableCodecs, using the [= codec dictionary match =]
algorithm with ignoreAsymmetricalParameters set to true.
If [=RTCRtpTransceiver/transceiver kind=] is `"audio"`, remove the
{{RTCRtpEncodingParameters/scaleResolutionDownBy}} and
{{RTCRtpEncodingParameters/maxFramerate}}
members from all encodings that
[=map/contain=] any of them.
If [=RTCRtpTransceiver/transceiver kind=] is `"video"`, then for
each encoding in encodings that doesn't
[=map/contain=] a
{{RTCRtpEncodingParameters/scaleResolutionDownBy}}
member, add a
{{RTCRtpEncodingParameters/scaleResolutionDownBy}}
member with the value `1.0`.
If [=RTCRtpTransceiver/transceiver kind=] is `"video"`,
and any encoding in encodings
[=map/contains=] a
{{RTCRtpEncodingParameters/scaleResolutionDownBy}}
member whose value is less than `1.0`, return a
promise [= rejected =] with a newly [=
exception/created =] {{RangeError}}.
Verify that each encoding in encodings has
a {{RTCRtpEncodingParameters/maxFramerate}}
member whose value is greater than or equal to 0.0. If one of the
{{RTCRtpEncodingParameters/maxFramerate}}
values does not meet this requirement, return a
promise [= rejected =] with a newly [=
exception/created =] {{RangeError}}.
If the user agent does not support setting the codec for any encoding or mixing
different codec values on the different encodings, return a promise [= rejected =]
with a newly [= exception/created =] {{OperationError}}.
Let p be a new promise.
[=In parallel=], configure the media stack to use
parameters to transmit
sender.{{RTCRtpSender/[[SenderTrack]]}}.
If the media stack is successfully configured with
parameters, queue a task to run the following
steps:
Set
sender.{{RTCRtpSender/[[LastReturnedParameters]]}}
to null.
Set sender.{{RTCRtpSender/[[SendEncodings]]}}
to
parameters.{{RTCRtpSendParameters/encodings}}.
[= Resolve =] p with
undefined.
If any error occurred while configuring the media
stack, queue a task to run the following steps:
If an error occurred due to hardware resources
not being available, [= reject =] p with a
newly created {{RTCError}} whose
{{RTCError/errorDetail}} is set to
{{RTCErrorDetailType/"hardware-encoder-not-available"}}
and abort these steps.
If an error occurred due to a hardware encoder
not supporting parameters, [= reject =]
p with a newly created {{RTCError}} whose
{{RTCError/errorDetail}} is set to
{{RTCErrorDetailType/"hardware-encoder-error"}} and
abort these steps.
For all other errors, [= reject =] p
with a newly [= exception/created =]
{{OperationError}}.
Return p.
{{setParameters}} does not cause SDP renegotiation and can
only be used to change what the media stack is sending or
receiving within the envelope negotiated by Offer/Answer. The
attributes in the {{RTCRtpSendParameters}} dictionary are
designed to not enable this, so attributes like
{{RTCRtcpParameters/cname}} that cannot be changed are
read-only. Other things, like bitrate, are controlled using
limits such as {{RTCRtpEncodingParameters/maxBitrate}}, where
the user agent needs to ensure it does not exceed the maximum
bitrate specified by {{RTCRtpEncodingParameters/maxBitrate}},
while at the same time making sure it satisfies constraints
on bitrate specified in other places such as the SDP.
getParameters
The {{getParameters()}} method returns the {{RTCRtpSender}}
object's current parameters for how {{track}} is encoded and
transmitted to a remote {{RTCRtpReceiver}}.
When {{getParameters}} is called, the user agent MUST run the
following steps:
Let sender be the {{RTCRtpSender}} object on
which the getter was invoked.
If sender.{{RTCRtpSender/[[LastReturnedParameters]]}}
is not null, return
sender.{{RTCRtpSender/[[LastReturnedParameters]]}}, and
abort these steps.
Let result be a new {{RTCRtpSendParameters}}
dictionary constructed as follows:
{{RTCRtpSendParameters/transactionId}} is set to a new
unique identifier.
{{RTCRtpSendParameters/encodings}} is set to the value of
the {{RTCRtpSender/[[SendEncodings]]}} internal slot.
The {{RTCRtpParameters/headerExtensions}} sequence is
populated based on the header extensions that have been
negotiated for sending.
{{RTCRtpParameters/codecs}} is set to the value of the
{{RTCRtpSender/[[SendCodecs]]}} internal slot.
{{RTCRtpParameters/rtcp}}.{{RTCRtcpParameters/cname}} is
set to the CNAME of the associated {{RTCPeerConnection}}.
{{RTCRtpParameters/rtcp}}.{{RTCRtcpParameters/reducedSize}}
is set to true if reduced-size RTCP has been
negotiated for sending, and false otherwise.
Set sender.{{RTCRtpSender/[[LastReturnedParameters]]}}
to result.
Queue a task that sets
sender.{{RTCRtpSender/[[LastReturnedParameters]]}} to
null.
Return result.
{{getParameters}} may be used with {{setParameters}} to
change the parameters in the following way:
async function updateParameters() {
try {
const params = sender.getParameters();
// ... make changes to parameters
params.encodings[0].active = false;
await sender.setParameters(params);
} catch (err) {
console.error(err);
}
}
After a completed call to {{setParameters}}, subsequent calls
to {{getParameters}} will return the modified set of
parameters.
replaceTrack
Attempts to replace the {{RTCRtpSender}}'s current {{track}}
with another track provided (or with a null
track), without renegotiation.
When the {{replaceTrack}} method is invoked, the user agent
MUST run the following steps:
Let sender be the {{RTCRtpSender}} object on
which {{replaceTrack}} is invoked.
Let transceiver be the {{RTCRtpTransceiver}}
object associated with sender.
Let connection be the {{RTCPeerConnection}}
object associated with sender.
Let withTrack be the argument to this method.
If withTrack is non-null and
withTrack.kind differs from the
[=RTCRtpTransceiver/transceiver kind=] of transceiver, return
a promise [= rejected =] with a newly [=
exception/created =] {{TypeError}}.
Return the result of [= chaining =] the following steps
to connection's [= operations chain =]:
If transceiver.{{RTCRtpTransceiver/[[Stopping]]}} is
true, return a promise [= rejected =]
with a newly [= exception/created =]
{{InvalidStateError}}.
Let p be a new promise.
Let sending be true if
transceiver.{{RTCRtpTransceiver/[[CurrentDirection]]}}
is {{RTCRtpTransceiverDirection/"sendrecv"}} or
{{RTCRtpTransceiverDirection/"sendonly"}}, and
false otherwise.
Run the following steps [=in parallel=]:
If sending is true, and
withTrack is null, have
the sender stop sending.
If sending is true, and
withTrack is not null,
determine if withTrack can be sent
immediately by the sender without violating the
sender's already-negotiated envelope, and if it
cannot, then:
[=Queue a global task=] on the [=networking task source=] given the
current realm's [=global object=] as global to [=reject=]
p with a newly [=exception/created=] {{InvalidModificationError}}.
Abort these steps.
If sending is true, and
withTrack is not null,
have the sender switch seamlessly to transmitting
withTrack instead of the sender's
existing track.
Queue a task that runs the following steps:
If connection.{{RTCPeerConnection/[[IsClosed]]}}
is true, abort these steps.
Set sender.{{RTCRtpSender/[[SenderTrack]]}}
to withTrack.
[=Queue a global task=] on the [=networking task source=] given the
current realm's [=global object=] as global to [=resolve=]
p with undefined.
Return p.
Changing dimensions and/or frame rates might not require
negotiation. Cases that may require negotiation include:
Changing a resolution to a value outside of the
negotiated imageattr bounds, as described in [[RFC6236]].
Changing a frame rate to a value that causes the block
rate for the codec to be exceeded.
A video track differing in raw vs. pre-encoded format.
An audio track having a different number of channels.
Sources that also encode (typically hardware encoders)
might be unable to produce the negotiated codec; similarly,
software sources might not implement the codec that was
negotiated for an encoding source.
setStreams
Sets the {{MediaStream}}s to be associated with this sender's
track.
When the {{setStreams}} method is invoked, the user agent
MUST run the following steps:
Let sender be the {{RTCRtpSender}} object on
which this method was invoked.
Let connection be the {{RTCPeerConnection}}
object on which this method was invoked.
If connection.{{RTCPeerConnection/[[IsClosed]]}} is
true, [= exception/throw =] an
{{InvalidStateError}}.
Let streams be a list of {{MediaStream}}
objects constructed from the method's arguments, or an
empty list if the method was called without arguments.
Set
sender.{{RTCRtpSender/[[AssociatedMediaStreamIds]]}} to
an empty set.
For each stream in streams, add
stream.id to
{{RTCRtpSender/[[AssociatedMediaStreamIds]]}} if it's not already
there.
[= Update the negotiation-needed flag =] for
connection.
getStats
Gathers stats for this sender only and reports the result
asynchronously.
When the {{getStats()}} method is invoked, the user agent
MUST run the following steps:
Let selector be the {{RTCRtpSender}} object on
which the method was invoked.
Let p be a new promise, and run the following
steps [=in parallel=]:
Gather the stats indicated by selector
according to the [= stats selection algorithm =].
[=Queue a global task=] on the [=networking task source=] given the
current realm's [=global object=] as global to [=resolve=]
p with the resulting {{RTCStatsReport}} object,
containing the gathered stats.
headerExtensions of type sequence<{{RTCRtpHeaderExtensionParameters}}>,
required
A sequence containing parameters for RTP header extensions.
Read-only parameter.
rtcp of type {{RTCRtcpParameters}}, required
Parameters used for RTCP. Read-only parameter.
codecs of type sequence<{{RTCRtpCodecParameters}}>,
required
A sequence containing the media codecs that an
{{RTCRtpSender}} will choose from, as well as entries for
RTX, RED and FEC mechanisms. Corresponding to each media
codec where retransmission via RTX is enabled, there will
be an entry in {{codecs}} with a
{{RTCRtpCodec/mimeType}} attribute indicating
retransmission via audio/rtx or
video/rtx, and an
{{RTCRtpCodec/sdpFmtpLine}} attribute (providing
the "apt" and "rtx-time" parameters). Read-only parameter.
A unique identifier for the last set of parameters applied.
Ensures that {{RTCRtpSender/setParameters}} can only be
called based on a previous {{RTCRtpSender/getParameters}},
and that there are no intervening changes. [= Read-only
parameter =].
encodings of type sequence<{{RTCRtpEncodingParameters}}>,
required
A sequence containing parameters for RTP encodings of
media.
If set, this RTP encoding will be sent with the RID header
extension as defined by [[!RFC9429]]. The RID is not
modifiable via {{RTCRtpSender/setParameters}}. It can only
be set or modified in {{RTCPeerConnection/addTransceiver}}
on the sending side. Read-only parameter.
RTCRtpEncodingParameters Dictionary
dictionary RTCRtpEncodingParameters : RTCRtpCodingParameters {
boolean active = true;
RTCRtpCodec codec;
unsigned long maxBitrate;
double maxFramerate;
double scaleResolutionDownBy;
};
Dictionary {{RTCRtpEncodingParameters}} Members
active of type boolean, defaulting to
true
Indicates that this encoding is actively being sent.
Setting it to false causes this encoding to no
longer be sent. Setting it to true causes this
encoding to be sent. Since setting the value to
false does not cause the SSRC to be removed,
an RTCP BYE is not sent.
codec of type RTCRtpCodec
Optional value selecting which codec is used for this encoding's
RTP stream. If [=map/exists|absent=], the user agent can choose to use any codec negotiated for sending.
When {{codec}} is set and {{RTCRtpSender/[[SendCodecs]]}} have been negotiated,
the user agent SHOULD use the first {{RTCRtpSender/[[SendCodecs]]}} matching
{{codec}} for sending, according to the [= codec dictionary match =] algorithm
with ignoreAsymmetricalParameters set to true.
maxBitrate of type unsigned long
When [=map/exists|present=], indicates the maximum bitrate that can be
used to send this encoding. The user agent is free to
allocate bandwidth between the encodings, as long as the
{{maxBitrate}} value is not exceeded. The encoding may also
be further constrained by other limits (such as
per-transport or per-session bandwidth limits) below the
maximum specified here. {{maxBitrate}} is computed the same
way as the Transport Independent Application Specific
Maximum (TIAS) bandwidth defined in [[RFC3890]] Section
6.2.2, which is the maximum bandwidth needed without
counting IP or other transport layers like TCP or UDP. The
unit of {{maxBitrate}} is bits per second.
How the bitrate is achieved is media and encoding
dependent. For video, a frame will always be sent as fast
as possible, but frames may be dropped until bitrate is low
enough. Thus, even a bitrate of zero will allow sending one
frame. For audio, it might be necessary to stop playing if
the bitrate does not allow the chosen encoding enough
bandwidth to be sent.
maxFramerate of type double
This member can only be [=map/exists|present=] if the sender's kind is "video".
When [=map/exists|present=], indicates the maximum frame rate that can be used to
send this encoding, in frames per second. The user agent is free
to allocate bandwidth between the encodings, as long as the
{{maxFramerate}} value is not exceeded.
If changed with {{RTCRtpSender/setParameters()}}, the new frame rate takes
effect after the current picture is completed; setting the max frame
rate to zero thus has the effect of freezing the video on the next
frame.
scaleResolutionDownBy of type
double
This member is only [=map/exists|present=] if the sender's kind is "video". The video's
resolution will be scaled down in each dimension by the
given value before sending. For example, if the value is
2.0, the video will be scaled down by a factor of 2 in each
dimension, resulting in sending a video of one quarter the
size. If the value is 1.0, the video will not be affected.
The value must be greater than or equal to 1.0. By default,
scaling is applied in reverse order by a factor of two, to
produce an order of smaller to higher resolutions,
e.g. 4:2:1. If there is only one layer, the sender will by
default not apply any scaling, (i.e.
{{RTCRtpEncodingParameters/scaleResolutionDownBy}} will be
1.0).
Dictionary {{RTCRtpHeaderExtensionParameters}} Members
uri of type DOMString, required
The URI of the RTP header extension, as defined in
[[RFC5285]]. Read-only parameter.
id of type unsigned short, required
The value put in the RTP packet to identify the header
extension. Read-only parameter.
encrypted of type boolean
Whether the header extension is encrypted or not.
Read-only parameter.
The {{RTCRtpHeaderExtensionParameters}} dictionary enables an
application to determine whether a header extension is configured
for use within an {{RTCRtpSender}} or {{RTCRtpReceiver}}. For an
{{RTCRtpTransceiver}} transceiver, an application can
determine the "direction" parameter (defined in Section 5 of
[[RFC5285]]) of a header extension as follows without having to
parse SDP:
sendonly: The header extension is only included in
transceiver.{{RTCRtpTransceiver/sender}}.{{RTCRtpSender/getParameters()}}.{{RTCRtpParameters/headerExtensions}}.
recvonly: The header extension is only included in
transceiver.{{RTCRtpTransceiver/receiver}}.{{RTCRtpReceiver/getParameters()}}.{{RTCRtpParameters/headerExtensions}}.
sendrecv: The header extension is included in both
transceiver.{{RTCRtpTransceiver/sender}}.{{RTCRtpSender/getParameters()}}.{{RTCRtpParameters/headerExtensions}}
and
transceiver.{{RTCRtpTransceiver/receiver}}.{{RTCRtpReceiver/getParameters()}}.{{RTCRtpParameters/headerExtensions}}.
inactive: The header extension is included in neither
transceiver.{{RTCRtpTransceiver/sender}}.{{RTCRtpSender/getParameters()}}.{{RTCRtpParameters/headerExtensions}}
nor
transceiver.{{RTCRtpTransceiver/receiver}}.{{RTCRtpReceiver/getParameters()}}.{{RTCRtpParameters/headerExtensions}}.
RTCRtpCodec Dictionary
dictionary RTCRtpCodec {
required DOMString mimeType;
required unsigned long clockRate;
unsigned short channels;
DOMString sdpFmtpLine;
};
Dictionary {{RTCRtpCodec}} Members
The {{RTCRtpCodec}} dictionary provides information
about codec objects.
mimeType of type DOMString, required
The codec MIME media type/subtype. Valid media types and
subtypes are listed in [[IANA-RTP-2]].
clockRate of type unsigned long, required
The codec clock rate expressed in Hertz.
channels of type unsigned short
If [=map/exists|present=], indicates the maximum number of channels
(mono=1, stereo=2).
sdpFmtpLine of type DOMString
The "format specific parameters" field from the
a=fmtp line in the SDP
corresponding to the codec, if one exists, as defined by
[[!RFC9429]].
The {{RTCRtpCodecParameters}} dictionary provides information
about the negotiated codecs. The fields inherited from
{{RTCRtpCodec}} MUST all be Read-only parameters.
For an {{RTCRtpSender}}, the {{RTCRtpCodec/sdpFmtpLine}} parameters come from the
{{RTCPeerConnection/[[CurrentRemoteDescription]]}}, and for an
{{RTCRtpReceiver}}, they come from the local description (which is
{{RTCPeerConnection/[[PendingLocalDescription]]}} if not `null`, and
{{RTCPeerConnection/[[CurrentLocalDescription]]}} otherwise).
payloadType of type octet, required
The RTP payload type used to identify this codec.
Read-only parameter.
codecs of type sequence<{{RTCRtpCodec}}>,
required
Supported media codecs as well as entries for RTX, RED and
FEC mechanisms. Only combinations that would utilize
distinct payload types in a generated SDP offer are to be
provided. For example:
Two H.264/AVC codecs, one for each of two supported
packetization-mode values.
Two CN codecs with different clock rates.
There MUST only be a single entry in {{codecs}} for retransmission
via RTX, with {{RTCRtpCodec/sdpFmtpLine}} not [=map/exists|present=].
headerExtensions of type sequence<{{RTCRtpHeaderExtensionCapability}}>,
required
Dictionary {{RTCRtpHeaderExtensionCapability}} Members
uri of type DOMString, required
The URI of the RTP header extension, as defined in
[[RFC5285]].
RTCSetParameterOptions Dictionary
dictionary RTCSetParameterOptions {
};
Dictionary {{RTCSetParameterOptions}} Members
RTCSetParameterOptions is defined as an empty dictionary to allow for extensibility.
RTCRtpReceiver Interface
The {{RTCRtpReceiver}} interface allows an application to inspect the
receipt of a {{MediaStreamTrack}}.
To create an RTCRtpReceiver with a string,
kind, run the following steps:
Let receiver be a new {{RTCRtpReceiver}} object.
Let track be a new {{MediaStreamTrack}} object
[[!GETUSERMEDIA]]. The source of track is a
remote source provided by receiver. Note
that the track.id is
generated by the user agent and does not map to any track
IDs on the remote side.
Initialize track.kind to kind.
Initialize track.label to the result of concatenating
the string "remote " with kind.
Initialize track.readyState to live.
Initialize track.muted to true. See the
MediaStreamTrack
section about how the muted attribute
reflects if a {{MediaStreamTrack}} is receiving media data or
not.
Let receiver have a [[\ReceiverTrack]]
internal slot initialized to track.
Let receiver have a [[\ReceiverTransport]]
internal slot initialized to null.
Let receiver have a
[[\LastStableStateReceiverTransport]] internal slot
initialized to null.
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.
Let receiver have a
[[\LastStableStateAssociatedRemoteMediaStreams]]
internal slot and initialize it to an empty list.
Let receiver have a [[\ReceiveCodecs]]
internal slot, representing a list of {{RTCRtpCodecParameters}}
dictionaries, and initialized to an empty list.
Let receiver have a
[[\LastStableStateReceiveCodecs]] internal slot and
initialize it to an empty list.
Let receiver have a [[\JitterBufferTarget]]
internal slot initialized to null.
The {{track}} attribute is the track that is associated with
this {{RTCRtpReceiver}} object receiver.
Note that {{track}}.stop() is final,
although clones are not affected. Since
receiver.{{track}}.stop()
does not implicitly stop receiver, Receiver
Reports continue to be sent. On getting, the attribute MUST
return the value of the {{RTCRtpReceiver/[[ReceiverTrack]]}} slot.
transport of type {{RTCDtlsTransport}}, readonly, nullable
The {{transport}} attribute is the transport over which media
for the receiver's {{RTCRtpReceiver/track}} is received in
the form of RTP packets. Prior to construction of the
{{RTCDtlsTransport}} object, the {{transport}} attribute will
be null. When bundling is used, multiple
{{RTCRtpReceiver}} objects will share one {{transport}} and
will all receive RTP and RTCP over the same transport.
On getting, the attribute MUST return the value of the
{{RTCRtpReceiver/[[ReceiverTransport]]}} slot.
jitterBufferTarget of type {{DOMHighResTimeStamp}}, nullable
This attribute allows the application to specify a target duration
of time in milliseconds of media for the {{RTCRtpReceiver}}'s jitter
buffer to hold. This influences the amount of buffering done by the
user agent, which in turn affects retransmissions and packet loss
recovery. Altering the target value allows applications to control the
tradeoff between playout delay and the risk of running out of audio or
video frames due to network jitter.
The user agent MUST have a minimum allowed target and a
maximum allowed target reflecting what the user agent is
able or willing to provide based on network conditions and memory
constraints, which can change at any time.
This is a target value. The resulting change in delay can be gradually
observed over time. The receiver's average jitter buffer delay can be
measured as the delta
{{RTCInboundRtpStreamStats/jitterBufferDelay}} divided by the delta
{{RTCInboundRtpStreamStats/jitterBufferEmittedCount}}.
An average delay is expected even if DTX is used. For example, if
DTX is used and packets start flowing after silence, larger targets can
influence the user agent to buffer these packets rather than
playing them out.
On getting, this attribute MUST return the value of the
{{RTCRtpReceiver/[[JitterBufferTarget]]}} internal slot.
On setting, the user agent MUST run the following steps:
Let receiver be the
{{RTCRtpReceiver}} object on which the setter is
invoked.
Let target be the argument to the setter.
If target is negative or larger than 4000 milliseconds, then
[Page truncated to keep GeezerVison snappy.]
You are visitor 01402520 — GeezerVison does not store the pages you look up. Best viewed with Netscape Navigator 4.7 or Internet Explorer 6 at 800×600. No cookies required.