Also inherits properties fromEventTarget.

iceTransportRead only

Returns a reference to the underlyingRTCIceTransport object.

stateRead only

Returns a stringwhich describes the underlying Datagram Transport Layer Security (DTLS) transport state.It can be one of the following values:new,connecting,connected,closed, orfailed.

Also inherits methods fromEventTarget.

getRemoteCertificates()

Returns an array ofArrayBuffer containing the certificates of the remote peer of the connection.

error

Sent when a transport-level error occurs on theRTCPeerConnection.

statechange

Sent when thestate of the DTLS transport changes.

RTCDtlsTransport objects are created when an app calls eithersetLocalDescription() orsetRemoteDescription(). The number of DTLS transports created and how they're used depends on the bundling mode used when creating theRTCPeerConnection.

Whether bundling is used depends on what the other endpoint is able to negotiate. All browsers support bundling, so when both endpoints are browsers, you can rest assured that bundling will be used.

Some non-browser legacy endpoints, however, may not support bundle. To be able to negotiate with such endpoints (or to exclude them entirely), thebundlePolicy property may be provided when creating the connection. ThebundlePolicy lets you control how to negotiate with these legacy endpoints. The default policy is"balanced", which provides a balance between performance and compatibility.

For example, to create the connection using the highest level of bundling:

const rtcConfig = {  bundlePolicy: "max-bundle",};const pc = new RTCPeerConnection(rtcConfig);

Bundling lets you use oneRTCDtlsTransport to carry the data for multiple higher-level transports, such as multipleRTCRtpTransceivers.

When not using BUNDLE

When the connection is created without using BUNDLE, each RTP or RTCP component of eachRTCRtpTransceiver has its ownRTCDtlsTransport; that is, everyRTCRtpSender andRTCRtpReceiver, has its own transport, and allRTCDataChannel objects share a transport dedicated to SCTP.

When using BUNDLE

When the connection is using BUNDLE, eachRTCDtlsTransport object represents a group ofRTCRtpTransceiver objects. If the connection was created usingmax-compat mode, each transport is responsible for handling all communication for a given type of media (audio, video, or data channel). Thus, a connection with any number of audio and video channels will always have exactly one DTLS transport for audio and one for video communications.

Because transports are established early in the negotiation process, it's likely that it won't be known until after they're created whether or not the remote peer supports bundling. For this reason, you'll sometimes see separate transports created at first, one for each track, then see them get bundled up once it's known that bundling is possible. If your code accessesRTCRtpSenders and/orRTCRtpReceivers directly, you may encounter situations where they're initially separate, then half or more of them get closed and the senders and receivers updated to refer to the appropriate remainingRTCDtlsTransport objects.

RTCDataChannels useSCTP to communicate. All of a peer connection's data channels share a singleRTCSctpTransport, found in the connection'ssctp property.

You can, in turn, identify theRTCDtlsTransport used to securely encapsulate the data channels' SCTP communications by looking at theRTCSctpTransport object'stransport property.

This example presents a function,tallySenders(), which iterates over anRTCPeerConnection'sRTCRtpSenders, tallying up how many of them are in various states. The function returns an object containing properties whose values indicate how many senders are in each state.

let pc = new RTCPeerConnection({ bundlePolicy: "max-bundle" });// …function tallySenders(pc) {  let results = {    transportMissing: 0,    connectionPending: 0,    connected: 0,    closed: 0,    failed: 0,    unknown: 0,  };  let senderList = pc.getSenders();  senderList.forEach((sender) => {    let transport = sender.transport;    if (!transport) {      results.transportMissing++;    } else {      switch (transport.state) {        case "new":        case "connecting":          results.connectionPending++;          break;        case "connected":          results.connected++;          break;        case "closed":          results.closed++;          break;        case "failed":          results.failed++;          break;        default:          results.unknown++;          break;      }    }  });  return results;}

Note that in this code, thenew andconnecting states are being treated as a singleconnectionPending status in the returned object.

• RTCRtpSender.transport andRTCRtpReceiver.transport
• RTCSctpTransport.transport