recursal/MDN huggingface dataset:
RTCPeerConnection: getIdentityAssertion() method
================================================

 The **`RTCPeerConnection.getIdentityAssertion()`** method
 initiates the gathering of an identity assertion. This has an effect only if the
 `signalingState` is not
 `"closed"`.

 The method returns a JavaScript `Promise` which resolves to an
 identity assertion encoded as a string.

 It is not expected for the application dealing with the `RTCPeerConnection`:
 this is automatically done; an explicit call only allows to anticipate the need.

Syntax
------


```js
getIdentityAssertion()
```


*There is neither parameter nor return value for this method.*

Example
-------


```js
const pc = new RTCPeerConnection();

pc.setIdentityProvider("developer.mozilla.org");
const assertion = await pc.getIdentityAssertion();
```

Specifications
--------------

| Specification |
| --- |
| Identity for WebRTC 1.0 # dom-rtcpeerconnection-getidentityassertion |

Browser compatibility
---------------------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

See also
--------

* WebRTC
RTCPeerConnection: getReceivers() method
========================================

 The **`RTCPeerConnection.getReceivers()`** method returns an array of `RTCRtpReceiver` objects, each of which represents one RTP receiver.
 Each RTP receiver manages the reception and decoding of data for a `MediaStreamTrack` on an `RTCPeerConnection`.

Syntax
------


```js
getReceivers()
```

### Return value

 An array of `RTCRtpReceiver` objects, one for each track on the connection.
 The array is empty if there are no RTP receivers on the connection.

The order of the returned `RTCRtpReceiver` instances is not defined by the specification, and may change from one call to `getReceivers()` to the next.

The array does not include receivers associated with transceivers that have been stopped (following offer/answer).

Example
-------

tbd

Specifications
--------------

| Specification |
| --- |
| WebRTC: Real-Time Communication in Browsers # dom-peerconnection-getreceivers |

Browser compatibility
---------------------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

See also
--------

* WebRTC
* `RTCRtpSender`
RTCPeerConnection: pendingLocalDescription property
===================================================

 The read-only property
 **`RTCPeerConnection.pendingLocalDescription`** returns an
 `RTCSessionDescription` object describing a pending configuration change
 for the local end of the connection. This does not describe the connection as it
 currently stands, but as it may exist in the near future. Use
 `RTCPeerConnection.currentLocalDescription` or
 `RTCPeerConnection.localDescription` to get the current state of the
 endpoint. For details on the difference, see
 Pending and current descriptions in the WebRTC Connectivity page.

Value
-----

 If a local description change is in progress, this is an
 `RTCSessionDescription` describing the proposed configuration. Otherwise,
 this returns `null`.

Examples
--------

 This example looks at the `pendingLocalDescription` to determine whether or
 not there's a description change being processed.


```js
const pc = new RTCPeerConnection();
// ...
const sd = pc.pendingLocalDescription;
if (sd) {
  // There's a description change underway!
} else {
  // No description change pending
}
```

Specifications
--------------

| Specification |
| --- |
| WebRTC: Real-Time Communication in Browsers # dom-peerconnection-pendinglocaldesc |

Browser compatibility
---------------------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

**Note:** The addition of `pendingLocalDescription` and
 `currentLocalDescription` to
 the WebRTC spec is relatively recent. In browsers which don't support them, only
 `localDescription` is available.


See also
--------

* `RTCPeerConnection.setLocalDescription()`,
 `RTCPeerConnection.currentLocalDescription`,
 `RTCPeerConnection.localDescription`
* `RTCPeerConnection.setRemoteDescription()`,
 `RTCPeerConnection.remoteDescription`,
 `RTCPeerConnection.pendingRemoteDescription`,
 `RTCPeerConnection.currentRemoteDescription`
* WebRTC
RTCPeerConnection: removeStream() method
========================================

**Deprecated:** This feature is no longer recommended. Though some browsers might still support it, it may have already been removed from the relevant web standards, may be in the process of being dropped, or may only be kept for compatibility purposes. Avoid using it, and update existing code if possible; see the compatibility table at the bottom of this page to guide your decision. Be aware that this feature may cease to work at any time.

**Non-standard:** This feature is non-standard and is not on a standards track. Do not use it on production sites facing the Web: it will not work for every user. There may also be large incompatibilities between implementations and the behavior may change in the future.

 The
 **`RTCPeerConnection.removeStream()`** method removes a
 `MediaStream` as a local source of audio or video. If the negotiation
 already happened, a new one will be needed for the remote peer to be able to use it.
 Because this method has been deprecated, you should instead use
 `removeTrack()` if your target browser
 versions have implemented it.

 If the `signalingState` is set to
 `"closed"`, an `InvalidStateError` is raised. If the
 `signalingState` is set to
 `"stable"`, the event `negotiationneeded` is sent on the
 `RTCPeerConnection`.

Syntax
------


```js
removeStream(mediaStream)
```

### Parameters

`mediaStream`

A `MediaStream` specifying the stream to remove from the connection.

### Return value

`undefined`.

Example
-------


```js
let pc;
let videoStream;
navigator.getUserMedia({ video: true }, (stream) => {
  pc = new RTCPeerConnection();
  videoStream = stream;
  pc.addStream(stream);
});
document.getElementById("closeButton").addEventListener(
  "click",
  (event) => {
    pc.removeStream(videoStream);
    pc.close();
  },
  false,
);
```

Browser compatibility
---------------------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

See also
--------

* WebRTC
* `RTCPeerConnection.removeTrack()`
* `RTCPeerConnection.addTrack()`
* `RTCPeerConnection.addStream()`
RTCPeerConnection: removeTrack() method
=======================================

 The
 **`RTCPeerConnection.removeTrack()`** method tells the local
 end of the connection to stop sending media from the specified track, without actually
 removing the corresponding `RTCRtpSender` from the list of senders as
 reported by `RTCPeerConnection.getSenders()`. If the track is
 already stopped, or is not in the connection's senders list, this method has no effect.

 If the connection has already been negotiated
 (`signalingState` is set to
 `"stable"`), it is marked as needing to be negotiated again; the remote peer
 won't experience the change until this negotiation occurs. A
 `negotiationneeded` event is sent to the `RTCPeerConnection` to
 let the local end know this negotiation must occur.

Syntax
------


```js
removeTrack(sender)
```

### Parameters

`sender`

A `RTCRtpSender` specifying the sender to remove from the connection.

### Return value

`undefined`.

### Exceptions

`InvalidStateError` `DOMException`

Thrown if the connection is not open.

Example
-------

 This example adds a video track to a connection and sets up a listener on a close
 button which removes the track when the user clicks the button.


```js
let pc;
let sender;
navigator.getUserMedia({ video: true }, (stream) => {
  pc = new RTCPeerConnection();
  const [track] = stream.getVideoTracks();
  sender = pc.addTrack(track, stream);
});

document.getElementById("closeButton").addEventListener(
  "click",
  (event) => {
    pc.removeTrack(sender);
    pc.close();
  },
  false,
);
```

Specifications
--------------

| Specification |
| --- |
| WebRTC: Real-Time Communication in Browsers # dom-rtcpeerconnection-removetrack |

Browser compatibility
---------------------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

See also
--------

* WebRTC API
RTCPeerConnection: getSenders() method
======================================

 The `RTCPeerConnection` method **`getSenders()`** returns an array of `RTCRtpSender` objects, each of which represents the RTP sender responsible for transmitting one track's data.
 A sender object provides methods and properties for examining and controlling the encoding and transmission of the track's data.

Syntax
------


```js
getSenders()
```

### Return value

 An array of `RTCRtpSender` objects, one for each track on the connection.
 The array is empty if there are no RTP senders on the connection.

The order of the returned `RTCRtpSender` instances is not defined by the specification, and may change from one call to `getSenders()` to the next.

The array does not include senders associated with transceivers that have been stopped (following offer/answer).

Example
-------

In this example, a `setMuting()` function is shown. This function takes as input an `RTCPeerConnection`, `pc`, and a Boolean, `muting`. The function gets the list of the peer connection's senders and iterates over every sender, setting the corresponding media track's `enabled` to the inverse of the specified `muting`.


```js
function setMuting(pc, muting) {
  let senderList = pc.getSenders();

  senderList.forEach((sender) => {
    sender.track.enabled = !muting;
  });
}
```

Specifications
--------------

| Specification |
| --- |
| WebRTC: Real-Time Communication in Browsers # dom-peerconnection-getsenders |

Browser compatibility
---------------------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

See also
--------

* WebRTC
* `RTCRtpSender`
RTCPeerConnection: signalingState property
==========================================

 The read-only **`signalingState`** property on the
 `RTCPeerConnection` interface returns a string value
 describing the state of the signaling process
 on the local end of the connection
 while connecting or reconnecting to another peer.
 See Signaling in our WebRTC session lifetime page.

 Because the signaling process is a state machine, being able to verify that your code
 is in the expected state when messages arrive can help avoid unexpected and avoidable
 failures. For example, if you receive an answer while the `signalingState`
 isn't `"have-local-offer"`, you know that something is wrong, since you
 should only receive answers after creating an offer but before an answer has been
 received and passed into `RTCPeerConnection.setLocalDescription()`. Your
 code will be more reliable if you watch for mismatched states like this and handle them
 gracefully.

This value may also be useful during debugging, for example.

 In addition, when the value of this property changes, a
 `signalingstatechange` event is sent to the `RTCPeerConnection`
 instance.

Value
-----

The allowed string values are:

`stable`

 There is no ongoing exchange of offer and answer underway.
 This may mean that the `RTCPeerConnection` object is new,
 in which case
 both the `localDescription`
 and `remoteDescription`
 are `null`;
 it may also mean that negotiation is complete
 and a connection has been established.


`have-local-offer`

 The local peer has called `RTCPeerConnection.setLocalDescription()`,
 passing in SDP representing an offer
 (usually created by calling `RTCPeerConnection.createOffer()`),
 and the offer has been applied successfully.


`have-remote-offer`

 The remote peer has created an offer
 and used the signaling server
 to deliver it to the local peer,
 which has set the offer
 as the remote description
 by calling `RTCPeerConnection.setRemoteDescription()`.


`have-local-pranswer`

 The offer sent by the remote peer has been applied
 and an answer has been created
 (usually by calling `RTCPeerConnection.createAnswer()`)
 and applied by calling `RTCPeerConnection.setLocalDescription()`.
 This provisional answer describes the supported media formats and so forth,
 but may not have a complete set of ICE candidates included.
 Further candidates will be delivered separately later.


`have-remote-pranswer`

 A provisional answer has been received
 and successfully applied
 in response to an offer previously sent
 and established by calling `setLocalDescription()`.


`closed`

The `RTCPeerConnection` has been closed.

Examples
--------


```js
const pc = new RTCPeerConnection(configuration);
const state = pc.signalingState;
```

Specifications
--------------

| Specification |
| --- |
| WebRTC: Real-Time Communication in Browsers # dom-peerconnection-signaling-state |

Browser compatibility
---------------------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

See also
--------

* Lifetime of a WebRTC session
* `RTCPeerConnection`
* `signalingstatechange`
* WebRTC
RTCPeerConnection: currentLocalDescription property
===================================================

 The read-only property
 **`RTCPeerConnection.currentLocalDescription`** returns an
 `RTCSessionDescription` object describing the local end of the connection
 as it was most recently successfully negotiated since the last time the
 `RTCPeerConnection` finished negotiating and connecting to a remote peer.
 Also included is a list of any ICE candidates that may already have been generated by
 the ICE agent since the offer or answer represented by the description was first
 instantiated.

 To change the `currentLocalDescription`, call
 `RTCPeerConnection.setLocalDescription()`, which triggers a series of
 events which leads to this value being set. For details on what exactly happens and why
 the change isn't necessarily instantaneous, see
 Pending and current descriptions in the WebRTC Connectivity page.


**Note:** Unlike `RTCPeerConnection.localDescription`, this value represents the
 actual current state of the local end of the connection; `localDescription`
 may specify a description which the connection is currently in the process of
 switching over to.


Value
-----

 The current description of the local end of the connection, if one has been set. If
 none has been successfully set, this value is `null`.

Examples
--------

 This example looks at the `currentLocalDescription` and displays an alert
 containing the `RTCSessionDescription` object's `type` and
 `sdp` fields.


```js
const pc = new RTCPeerConnection();
// ...
const sd = pc.currentLocalDescription;
if (sd) {
  alert(`Local session: type='${sd.type}'; sdp description='${sd.sdp}'`);
} else {
  alert("No local session yet.");
}
```

Specifications
--------------

| Specification |
| --- |
| WebRTC: Real-Time Communication in Browsers # dom-peerconnection-currentlocaldesc |

Browser compatibility
---------------------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

**Note:** The addition of `currentLocalDescription` and
 `pendingLocalDescription` to
 the WebRTC spec is relatively recent. In browsers which don't support them, just use
 `localDescription`.


See also
--------

* `RTCPeerConnection.setLocalDescription()`,
 `RTCPeerConnection.pendingLocalDescription`,
 `RTCPeerConnection.localDescription`
* `RTCPeerConnection.setRemoteDescription()`,
 `RTCPeerConnection.remoteDescription`,
 `RTCPeerConnection.pendingRemoteDescription`,
 `RTCPeerConnection.currentRemoteDescription`
* WebRTC
RTCPeerConnection: close() method
=================================

 The **`RTCPeerConnection.close()`** method closes the current
 peer connection.

Syntax
------


```js
close()
```


*This method has no parameters, and returns nothing.*

 Calling this method terminates the RTCPeerConnection's ICE agent, ending any ongoing
 ICE processing and any active streams. This also releases any resources in use by the
 ICE agent, including TURN permissions. All `RTCRtpSender` objects are
 considered to be stopped once this returns (they may still be in the process of
 stopping, but for all intents and purposes, they're stopped).

 Once this method returns, the signaling state as returned by
 `RTCPeerConnection.signalingState` is `closed`.

 Make sure that you `delete` all references to the previous
 `RTCPeerConnection` before attempting to create a new one that connects
 to the same remote peer, as not doing so might result in some errors depending on the
 browser.

Example
-------


```js
const pc = new RTCPeerConnection();
const dc = pc.createDataChannel("my channel");

dc.onmessage = (event) => {
  console.log(`received: ${event.data}`);
  pc.close(); // We decided to close after the first received message
};

dc.onopen = () => {
  console.log("datachannel open");
};

dc.onclose = () => {
  console.log("datachannel close");
};
```

Specifications
--------------

| Specification |
| --- |
| WebRTC: Real-Time Communication in Browsers # dom-rtcpeerconnection-close |

Browser compatibility
---------------------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

See also
--------

* WebRTC
* `RTCPeerConnection`
* `RTCPeerConnection.signalingState`
RTCPeerConnection: localDescription property
============================================

 The read-only property **`RTCPeerConnection.localDescription`** returns an `RTCSessionDescription` describing the session for the local end of the connection.
 If it has not yet been set, this is `null`.

Syntax
------


```js
const sessionDescription = peerConnection.localDescription
```


 On a more fundamental level, the returned value is the value of `RTCPeerConnection.pendingLocalDescription` if that property isn't `null`;
 otherwise, the value of `RTCPeerConnection.currentLocalDescription` is returned.
 See Pending and current descriptions in the WebRTC Connectivity page for details on this algorithm and why it's used.

Example
-------

This example looks at the `localDescription` and displays an alert containing the `RTCSessionDescription` object's `type` and `sdp` fields.


```js
const pc = new RTCPeerConnection();
// ...
const sd = pc.localDescription;
if (sd) {
  alert(`Local session: type='${sd.type}'; sdp description='${sd.sdp}'`);
} else {
  alert("No local session yet.");
}
```

Specifications
--------------

| Specification |
| --- |
| WebRTC: Real-Time Communication in Browsers # dom-peerconnection-localdescription |

Browser compatibility
---------------------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

See also
--------

* `RTCPeerConnection.setLocalDescription()`,
 `RTCPeerConnection.pendingLocalDescription`,
 `RTCPeerConnection.currentLocalDescription`
* `RTCPeerConnection.setRemoteDescription()`,
 `RTCPeerConnection.remoteDescription`,
 `RTCPeerConnection.pendingRemoteDescription`,
 `RTCPeerConnection.currentRemoteDescription`
* WebRTC
DOMMatrixReadOnly: DOMMatrixReadOnly() constructor
==================================================

 The **`DOMMatrixReadOnly`** constructor creates a new
 `DOMMatrixReadOnly` object which represents 4x4 matrices, suitable for 2D
 and 3D operations.

Syntax
------


```js
DOMMatrixReadOnly()
DOMMatrixReadOnly(init)
```

### Parameters

`init` Optional

 Either a string containing a sequence of numbers or an array of numbers
 specifying the matrix you want to create.


In case an array of numbers is passed, the behavior depends on the length of the array:

* for a 6-element array of components in the form `[a, b, c, d, e, f]`, a 2D read-only matrix is created, initialized with the provided components.
* for a 16-element array of components (in the column-major order) in the form `[m11, m12, m13, …, m42, m43, m44]`, a 3D read-only matrix is created, initialized with the provided components.

Specifications
--------------

| Specification |
| --- |
| Geometry Interfaces Module Level 1 # dom-dommatrixreadonly-dommatrixreadonly |

Browser compatibility
---------------------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.
DOMMatrixReadOnly: translate() method
=====================================

 The `translate()` method of the `DOMMatrixReadOnly` interface
 creates a new matrix being the result of the original matrix with a translation applied.

Syntax
------


```js
DOMMatrix.translate(translateX, translateY)
DOMMatrix.translate(translateX, translateY, translateZ)
```

### Parameters

`translateX`

A number representing the abscissa (x-coordinate) of the translating vector.

`translateY`

A number representing the ordinate (y-coordinate) of the translating vector.

`translateZ` Optional

 A number representing the z component of the translating vector. If not supplied,
 this defaults to 0. If this is anything other than 0, the resulting matrix will be
 3D.


### Return value

 Returns a `DOMMatrix`
 containing a new matrix being the result of the matrix being translated by the given
 vector. The original matrix is not modified.

 If a translation is applied about the z-axis, the resulting matrix will be a 4x4 3D
 matrix.

Examples
--------

 This SVG contains two squares, one red and one blue, each positioned at the document
 origin:


```html
<svg width="250" height="250" viewBox="0 0 50 50">
  <rect width="25" height="25" fill="red" />
  <rect id="transformed" width="25" height="25" fill="blue" />
</svg>
```


 The following JavaScript first creates an identity matrix, then uses the
 `translate()` method to create a new, translated matrix — which is then
 applied to the blue square as a `transform`. The red square is left in place.


```js
const matrix = new DOMMatrixReadOnly().translate(25, 25);

document
  .querySelector("#transformed")
  .setAttribute("transform", matrix.toString());
```

Specifications
--------------

| Specification |
| --- |
| Geometry Interfaces Module Level 1 # dom-dommatrixreadonly-translate |

Browser compatibility
---------------------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.
DOMMatrixReadOnly: flipX() method
=================================

The `flipX()` method of the `DOMMatrixReadOnly` interface creates a new matrix being the result of the original matrix flipped about the x-axis.

Syntax
------


```js
  DOMMatrixReadOnly.flipX()
```

### Return value

Returns a `DOMMatrix` containing a new matrix being the result of the original matrix flipped about the x-axis, which is equivalent to multiplying the matrix by `DOMMatrix(-1, 0, 0, 1, 0, 0)`. The original matrix is not modified.

Examples
--------

### Inverting a triangle

In this example, the SVG contains two paths in the shape of a triangle, both drawn to the same position. Note that the x co-ordinate of the viewBox attribute is negative, showing us content from both sides of the x-axis.

The JavaScript first creates an identity matrix, then uses the `flipX()` method to create a new matrix, which is then applied to the blue triangle, inverting it across the x-axis. The red triangle is left in place.

#### HTML


```html
<svg width="100" height="100" viewBox="-50 0 100 100">
  <path fill="red" d="M 0 50 L 50 0 L 50 100 Z" />
  <path id="flipped" fill="blue" d="M 0 50 L 50 0 L 50 100 Z" />
</svg>
```


#### JavaScript


```js
const flipped = document.getElementById("flipped");
const matrix = new DOMMatrixReadOnly();
const flippedMatrix = matrix.flipX();
flipped.setAttribute("transform", flippedMatrix.toString());
```


#### Result

Specifications
--------------

| Specification |
| --- |
| Geometry Interfaces Module Level 1 # dom-dommatrixreadonly-flipx |

Browser compatibility
---------------------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.