Terminology

The EventHandler interface, representing a callback used for event handlers, and the ErrorEvent interface are defined in [[!HTML5]].

The concepts queue a task, fires a simple event and networking task source are defined in [[!HTML5]].

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

The terms MediaStream, MediaStreamTrack, and MediaStreamConstraints are defined in [[!GETUSERMEDIA]].

Scope

For Scalable Video Coding (SVC), the terms single-session transmission (SST) and multi-session transmission (MST) are defined in [[RFC6190]]. This specification only supports SST but not MST. The term Single Real-time transport protocol stream Single Transport (SRST), defined in [[RFC7656]] Section 3.7, refers to an SVC implementation that transmits all layers within a single transport, using a single Real-time Transport Protocol (RTP) stream and synchronization source (SSRC). The term Multiple RTP stream Single Transport (MRST), also defined in [[RFC7656]] Section 3.7, refers to an implementation that transmits all layers within a single transport, using multiple RTP streams with a distinct SSRC for each layer. This specification supports SVC codecs utilizing SRST transport (such as with H.264/SVC, VP8 and VP9). Also, sending of simulcast is supported. SVC codecs supporting MRST transport (such as H.264/SVC and HEVC) can also be supported, along with reception of simulcast. However, these features should be considered experimental, since implementation experience is limited.

Overview

An RTCIceGatherer instance can be associated to multiple RTCIceTransport objects. The RTCIceGatherer does not prune local candidates until at least one RTCIceTransport object has become associated and all associated RTCIceTransport objects are in the completed or failed state.

As noted in [[!RFC5245]] Section 7.1.2.2, an incoming connectivity check contains an ICE-CONTROLLING or ICE-CONTROLLED attribute, depending on the role of the ICE agent initiating the check. Since an RTCIceGatherer object does not have a role, it cannot determine whether to respond to an incoming connectivity check with a 487 (Role Conflict) error; however, it can validate that an incoming connectivity check utilizes the correct local username fragment and password, and if not, can respond with an 401 (Unauthorized) error, as described in [[!RFC5389]] Section 10.1.2.

For incoming connectivity checks that pass validation, the RTCIceGatherer MUST buffer the incoming connectivity checks so as to be able to provide them to associated RTCIceTransport objects so that they can respond.

Operation

An RTCIceGatherer instance is constructed from an RTCIceGatherOptions object.

An RTCIceGatherer object in the closed state can be garbage-collected when it is no longer referenced.

Interface Definition

[ Constructor (RTCIceGatherOptions options)]
interface RTCIceGatherer : RTCStatsProvider {
    readonly        attribute RTCIceComponent     component;
    readonly        attribute RTCIceGathererState state;
    void                      close ();
    void                      gather (optional RTCIceGatherOptions options);
    RTCIceParameters          getLocalParameters ();
    sequence<RTCIceCandidate> getLocalCandidates ();
    RTCIceGatherer            createAssociatedGatherer ();
                    attribute EventHandler        onstatechange;
                    attribute EventHandler        onerror;
};

The RTCIceParameters Object

The RTCIceParameters object includes the ICE username fragment and password and other ICE-related parameters.

dictionary RTCIceParameters {
             DOMString usernameFragment;
             DOMString password;
             boolean   iceLite;
};

The RTCIceCandidate Object

The RTCIceCandidate object includes information relating to an ICE candidate.

{
  foundation: "abcd1234",
  priority: 1694498815,
  ip: "192.0.2.33",
  protocol: "udp",
  port: 10000,
  type: "host"
};
                

        typedef (RTCIceCandidate or RTCIceCandidateComplete) RTCIceGatherCandidate;

dictionary RTCIceCandidate {
             DOMString              foundation;
             unsigned long          priority;
             DOMString              ip;
             RTCIceProtocol         protocol;
             unsigned short         port;
             RTCIceCandidateType    type;
             RTCIceTcpCandidateType tcpType;
             DOMString              relatedAddress = "";
             unsigned short         relatedPort;
};

enum RTCIceProtocol {
    "udp",
    "tcp"
};

enum RTCIceTcpCandidateType {
    "active",
    "passive",
    "so"
};

enum RTCIceCandidateType {
    "host",
    "srflx",
    "prflx",
    "relay"
};

dictionary RTCIceCandidateComplete

RTCIceCandidateComplete is a dictionary signifying that all RTCIceCandidates are gathered.

dictionary RTCIceCandidateComplete {
             boolean complete = true;
};

enum RTCIceGathererState

RTCIceGathererState represents the current state of the ICE gatherer.

enum RTCIceGathererState {
    "new",
    "gathering",
    "complete",
    "closed"
};

RTCIceGathererIceErrorEvent

The icecandidateerror event of the RTCIceGatherer object uses the RTCIceGathererIceErrorEvent interface.

        [ Constructor (DOMString type, RTCIceGathererIceErrorEventInit eventInitDict)]
interface RTCIceGathererIceErrorEvent : Event {
    readonly        attribute RTCIceCandidate? hostCandidate;
    readonly        attribute DOMString        url;
    readonly        attribute unsigned short   errorCode;
    readonly        attribute USVString        errorText;
};

        dictionary RTCIceGathererIceErrorEventInit : EventInit {
             RTCIceCandidate hostCandidate;
             DOMString       url;
             unsigned short  errorCode;
             USVString       errorText;
};

RTCIceGathererEvent

The icecandidate event of the RTCIceGatherer object uses the RTCIceGathererEvent interface.

Firing an RTCIceGathererEvent event named e with an RTCIceCandidate candidate and URL url means that an event with the name e, which does not bubble (except where otherwise stated) and is not cancelable (except where otherwise stated), and which uses the RTCIceGathererEvent interface with the candidate attribute set to the new ICE candidate, MUST be created and dispatched at the given target.

        [ Constructor (DOMString type, RTCIceGathererEventInit eventInitDict)]
interface RTCIceGathererEvent : Event {
    readonly        attribute RTCIceGatherCandidate candidate;
    readonly        attribute DOMString             url;
};

dictionary RTCIceGathererEventInit : EventInit {
             RTCIceGatherCandidate candidate;
             DOMString             url;
};

dictionary RTCIceGatherOptions

RTCIceGatherOptions provides options relating to the gathering of ICE candidates.

dictionary RTCIceGatherOptions {
             RTCIceGatherPolicy     gatherPolicy;
             sequence<RTCIceServer> iceServers;
};

enum RTCIceGatherPolicy

RTCIceGatherPolicy denotes the policy relating to the gathering of ICE candidates.

enum RTCIceGatherPolicy {
    "all",
    "nohost",
    "relay"
};

enum RTCIceCredentialType

RTCIceCredentialType represents the type of credential used by a TURN server.

enum RTCIceCredentialType {
    "password",
    "token"
};

The RTCIceServer Object

The RTCIceServer is used to provide STUN or TURN server configuration. In network topologies with multiple layers of NATs, it is desirable to have a STUN server between every layer of NATs in addition to the TURN servers to minimize the peer to peer network latency.

An example of an array of RTCIceServer objects:

[
  { urls: "stun:stun1.example.net" },
  { urls: "turn:turn.example.org", username: "user", credential: "myPassword",
    credentialType: "password"}
]
                

dictionary RTCIceServer {
    required (DOMString or sequence<DOMString>) urls;
             DOMString                          username;
             DOMString                          credential;
             RTCIceCredentialType               credentialType = "password";
};

Example

      // Example to demonstrate use of RTCIceCandidateComplete
// Include some helper functions
import {trace, errorHandler, mySendLocalCandidate, myIceGathererStateChange,
  myIceTransportStateChange, myDtlsTransportStateChange} from 'helper';

// Create ICE gather options
var gatherOptions = {
  gatherPolicy: "relay",
  iceServers: [
    { urls: "stun:stun1.example.net" },
    { urls: "turn:turn.example.org", username: "user", credential: "myPassword", 
      credentialType: "password" }
   ]
};
// Create IceGatherer object
var iceGatherer = new RTCIceGatherer(gatherOptions);

// Handle state changes
iceGatherer.onstatechange = function(event) {
  myIceGathererStateChange("iceGatherer", event.state);
};

// Prepare to signal local candidates
iceGatherer.onlocalcandidate = function(event) {
  mySendLocalCandidate(event.candidate);
};

// Start gathering
iceGatherer.gather();

// Set up response function
mySignaller.onResponse = function(responseSignaller, response) {
  // We may get N responses
  // ... deal with the N responses as shown in Example 5 of Section 3.11.
};

mySignaller.send({
  "ice": iceGatherer.getLocalParameters()
});
                

      // Helper functions used in all the examples (helper.js)
export function trace(text) {
  // This function is used for logging.
  text = text.trimRight();
  if (window.performance) {
    var now = (window.performance.now() / 1000).toFixed(3);
    console.log(now + ": " + text);
  } else {
    console.log(text);
  }
}

export function errorHandler(error) {
  trace("Error encountered: " + error.name);
}

export function mySendLocalCandidate(candidate, component, kind, parameters) {
  // Set default values
  kind = kind || "all";
  component = component || "RTP";
  parameters = parameters || null;

  // Signal the local candidate
  mySignaller.mySendLocalCandidate({
    "candidate": candidate,
    "component": component,
    "kind": kind,
    "parameters": parameters
  });
}

export function myIceGathererStateChange(name, state) {
  switch (state) {
    case "new": 
      trace("IceGatherer: " + name + " Has been created");
      break;
    case "gathering":
      trace("IceGatherer: " + name + " Is gathering candidates");
      break;
    case "complete":
      trace("IceGatherer: " + name + " Has finished gathering (for now)");
      break;
    case "closed":
      trace("IceGatherer: " + name + " Is closed");
      break;
    default:
      trace("IceGatherer: " + name + " Invalid state");
  }
}

export function myIceTransportStateChange(name, state) {
  switch (state) {
    case "new":
      trace("IceTransport: " + name + " Has been created");
      break;
    case "checking":
      trace("IceTransport: " + name + " Is checking");
      break;
    case "connected":
      trace("IceTransport: " + name + " Is connected");
      break;
    case "disconnected":
      trace("IceTransport: " + name + " Is disconnected");
      break;
    case "completed":
      trace("IceTransport: " + name + " Has finished checking (for now)");
      break;
    case "failed":
      trace("IceTransport: " + name + " Has failed");
      break;
    case "closed":
      trace("IceTransport: " + name + " Is closed");
      break;
    default:
      trace("IceTransport: " + name + " Invalid state");
  }
}

export function myDtlsTransportStateChange(name, state){
  switch(state){
  case "new":
     trace('DtlsTransport: ' + name + ' Has been created');
     break;
  case "connecting":
     trace('DtlsTransport: ' + name + ' Is connecting');
     break;
  case "connected":
     trace('DtlsTransport: ' + name + ' Is connected');
     break;
  case "failed":
     trace('DtlsTransport: ' + name + ' Has failed');
     break;
  case "closed":
     trace('DtlsTransport: ' + name + ' Is closed');
     break;
  default:
     trace('DtlsTransport: ' + name + ' Invalid state');
  }
}
                

Overview

An RTCIceTransport instance is associated to a transport object (such as RTCDtlsTransport), and provides RTC related methods to it.

Operation

An RTCIceTransport instance is constructed (optionally) from an RTCIceGatherer. If gatherer.state is closed or gatherer.component is RTCP, then throw an InvalidStateError exception.

An RTCIceTransport object in the closed state can be garbage-collected when it is no longer referenced.

Interface Definition

[ Constructor (optional RTCIceGatherer gatherer)]
interface RTCIceTransport : RTCStatsProvider {
    readonly        attribute RTCIceGatherer?      iceGatherer;
    readonly        attribute RTCIceRole           role;
    readonly        attribute RTCIceComponent      component;
    readonly        attribute RTCIceTransportState state;
    sequence<RTCIceCandidate> getRemoteCandidates ();
    RTCIceCandidatePair?      getSelectedCandidatePair ();
    void                      start (RTCIceGatherer gatherer, RTCIceParameters remoteParameters, optional RTCIceRole role);
    void                      stop ();
    RTCIceParameters?         getRemoteParameters ();
    RTCIceTransport           createAssociatedTransport ();
    void                      addRemoteCandidate (RTCIceGatherCandidate remoteCandidate);
    void                      setRemoteCandidates (sequence<RTCIceCandidate> remoteCandidates);
                    attribute EventHandler         onstatechange;
                    attribute EventHandler         oncandidatepairchange;
};

enum RTCIceComponent

RTCIceComponent contains the component-id of the RTCIceTransport, which will be RTP unless RTP and RTCP are not multiplexed and the RTCIceTransport object was returned by createAssociatedTransport().

enum RTCIceComponent {
    "RTP",
    "RTCP"
};

enum RTCIceRole

RTCIceRole contains the current role of the ICE transport.

enum RTCIceRole {
    "controlling",
    "controlled"
};

enum RTCIceTransportState

RTCIceTransportState represents the current state of the ICE transport.

enum RTCIceTransportState {
    "new",
    "checking",
    "connected",
    "completed",
    "disconnected",
    "failed",
    "closed"
};

Some example transitions might be:

• new RTCIceTransport(): new
• (new, remote candidates received): checking
• (checking, found usable connection): connected
• (checking, checks fail but gathering still in progress): disconnected
• (checking, gave up): failed
• (disconnected, new local candidates): checking
• (connected, finished all checks): completed
• (completed, lost connectivity): disconnected
• (any state, ICE restart occurs): new
• close(): closed

RTCIceCandidatePairChangedEvent

The icecandidatepairchange event of the RTCIceTransport object uses the RTCIceCandidatePairChangedEvent interface.

Firing an RTCIceCandidatePairChangedEvent event named e with an RTCIceCandidatePair pair means that an event with the name e, which does not bubble (except where otherwise stated) and is not cancelable (except where otherwise stated), and which uses the RTCIceCandidatePairChangedEvent interface with pair set to the selected RTCIceCandidatePair, MUST be created and dispatched at the given target.

        [ Constructor (DOMString type, RTCIceCandidatePairChangedEventInit eventInitDict)]
interface RTCIceCandidatePairChangedEvent : Event {
    readonly        attribute RTCIceCandidatePair pair;
};

        dictionary RTCIceCandidatePairChangedEventInit : EventInit {
             RTCIceCandidatePair pair;
};

dictionary RTCIceCandidatePair

The RTCIceCandidatePair contains the currently selected ICE candidate pair.

dictionary RTCIceCandidatePair {
             RTCIceCandidate local;
             RTCIceCandidate remote;
};

Example

      // Example to demonstrate forking when RTP and RTCP are not multiplexed,
// so that both RTP and RTCP IceGatherer and IceTransport objects are needed.
// Include some helper functions
import {trace, errorHandler, mySendLocalCandidate, myIceGathererStateChange,
  myIceTransportStateChange, myDtlsTransportStateChange} from 'helper';

// Create ICE gather options
var gatherOptions = {
  gatherPolicy: "relay",
  iceServers: [
    { urls: "stun:stun1.example.net" },
    { urls: "turn:turn.example.org", username: "user", credential: "myPassword",
      credentialType: "password" }
   ]
};

// Create ICE gatherer objects
var iceRtpGatherer = new RTCIceGatherer(gatherOptions);
var iceRtcpGatherer = iceRtpGatherer.createAssociatedGatherer();

// Prepare to signal local candidates
iceRtpGatherer.onlocalcandidate = function(event) {
  mySendLocalCandidate(event.candidate, "RTP", "audio",
    iceRtpGatherer.getLocalParameters());
};

iceRtcpGatherer.onlocalcandidate = function(event) {
  mySendLocalCandidate(event.candidate, "RTCP", "audio",
    iceRtpGatherer.getLocalParameters());
};

// Start gathering
iceRtpGatherer.gather();
iceRtcpGatherer.gather();

// Initialize the ICE transport arrays
var iceRtpTransports = [];
var iceRtcpTransports = [];

// Set up response function
mySignaller.onResponse = function(responseSignaller, response) {
  // We may get N responses

  // Create the ICE RTP and RTCP transports
  var iceRtpTransport = new RTCIceTransport(iceRtpGatherer);
  var iceRtcpTransport = iceRtpTransport.createAssociatedTransport();

  // Start the RTP and RTCP ICE transports so that outgoing ICE connectivity checks can begin
  // The RTP and RTCP ICE parameters are the same, so only the RTP parameters are used
  iceRtpTransport.start(iceRtpGatherer, response.icertp, RTCIceRole.controlling);
  iceRtcpTransport.start(iceRtcpGatherer, response.icertp, RTCIceRole.controlling);

  iceRtpTransports.push(iceRtpTransport);
  iceRtcpTransports.push(iceRtcpTransport);

  // Prepare to add ICE candidates signalled by the remote peer
  responseSignaller.onRemoteCandidate = function(remote) {
    // Locate the ICE transport that the signaled candidate relates to by matching
   //  the userNameFragment.
    var transports;
    if (remote.component === "RTP") {
      transports = iceRtpTransports;
    } else {
      transports = iceRtcpTransports;
    }

    for (var j = 0; j < iceTransport.length; j++) {
      var transport = transports[j];
      if (transport.getRemoteParameters().userNameFragment === remote.parameters.userNameFragment)
        transport.addRemoteCandidate(remote.candidate);
      }
    }
  };
};

mySignaller.send({
  // The RTP and RTCP parameters are identical, so no need to send both
  "icertp": iceRtpGatherer.getLocalParameters()
});
                

Overview

An RTCDtlsTransport instance is associated to an RTCRtpSender, an RTCRtpReceiver, or an RTCSctpTransport instance.

Operation

A RTCDtlsTransport instance is constructed using an RTCIceTransport and a sequence of RTCCertificate objects. If certificates is non-empty, check that the expires attribute of each RTCCertificate object is in the future. If a certificate has expired, throw an InvalidParameter exception; otherwise, store the certificates.

A newly constructed RTCDtlsTransport MUST listen and respond to incoming DTLS packets before start() is called. However, to complete the negotiation it is necessary to verify the remote fingerprint, which is dependent on remoteParameters, passed to start(). To verify the remote fingerprint, compute the fingerprint value for the selected remote certificate using the signature digest algorithm, and compare it against remoteParameters.fingerprints. If the selected remote certificate RTCDtlsFingerprint.value matches remoteParameters.fingerprints[j].value and RTCDtlsFingerprint.algorithm matches remoteParameters.fingerprints[j].algorithm for any value of j, the remote fingerprint is verified. After the DTLS handshake exchange completes (but before the remote fingerprint is verified) incoming media packets may be received. A modest buffer MUST be provided to avoid loss of media prior to remote fingerprint validation (which can begin after start() is called).

If an attempt is made to construct a RTCDtlsTransport instance from an RTCIceTransport in the closed state, an InvalidStateError exception is thrown. Since the Datagram Transport Layer Security (DTLS) negotiation occurs between transport endpoints determined via ICE, implementations of this specification MUST support multiplexing of STUN, TURN, DTLS and RTP and/or RTCP. This multiplexing, originally described in [[!RFC5764]] Section 5.1.2, is being revised in [[MUX-FIXES]].

An RTCDtlsTransport object in the closed or failed states can be garbage-collected when it is no longer referenced.

Interface Definition

typedef (octet[]) ArrayBuffer;

        [ Constructor (RTCIceTransport transport, sequence<RTCCertificate> certificates)]
interface RTCDtlsTransport : RTCStatsProvider  {
    readonly        attribute FrozenArray<RTCCertificate> certificates;
    readonly        attribute RTCIceTransport          transport;
    readonly        attribute RTCDtlsTransportState    state;
    RTCDtlsParameters     getLocalParameters ();
    RTCDtlsParameters?    getRemoteParameters ();
    sequence<ArrayBuffer> getRemoteCertificates ();
    void                  start (RTCDtlsParameters remoteParameters);
    void                  stop ();
                    attribute EventHandler             onstatechange;
                    attribute EventHandler             onerror;
};

The RTCDtlsParameters Object

The RTCDtlsParameters object includes information relating to DTLS configuration.

dictionary RTCDtlsParameters {
             RTCDtlsRole                  role = "auto";
             sequence<RTCDtlsFingerprint> fingerprints;
};

The RTCDtlsFingerprint Object

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

dictionary RTCDtlsFingerprint {
             DOMString algorithm;
             DOMString value;
};

enum RTCDtlsRole

RTCDtlsRole indicates the role of the DTLS transport.

enum RTCDtlsRole {
    "auto",
    "client",
    "server"
};

enum RTCDtlsTransportState

RTCDtlsTransportState indicates the state of the DTLS transport.

enum RTCDtlsTransportState {
    "new",
    "connecting",
    "connected",
    "closed",
    "failed"
};

Examples

      // This is an example of how to offer ICE and DTLS parameters and
// ICE candidates and get back ICE and DTLS parameters and ICE candidates,
// and start both ICE and DTLS, when RTP and RTCP are multiplexed.
// Assume that we have a way to signal (mySignaller).
// Include some helper functions
import {trace, errorHandler, mySendLocalCandidate, myIceGathererStateChange, 
  myIceTransportStateChange, myDtlsTransportStateChange} from 'helper';

function initiate(mySignaller) {
  // Prepare the ICE gatherer
  var gatherOptions = {
    gatherPolicy: "all",
    iceServers: [
      { urls: "stun:stun1.example.net" },
      { urls: "turn:turn.example.org", username: "user", credential: "myPassword",
        credentialType: "password" }
     ]
  };
  var iceGatherer = new RTCIceGatherer(gatherOptions);
  iceGatherer.onlocalcandidate = function(event) {
    mySignaller.mySendLocalCandidate(event.candidate);
  };
  
  // Start gathering
  iceGatherer.gather();

  // Initialize the ICE and DTLS transport arrays
  var iceTransports = [];
  var dtlsTransports = [];

  // Create the DTLS certificate and parameters
  var certs;
  var dtlsParameters = {};
  var keygenAlgorithm = { name: "ECDSA", namedCurve: "P-256" };
  RTCCertificate.generateCertificate(keygenAlgorithm).then(function(certificate){
    certs[0] = certificate;
    // Obtain the fingerprint of the created certificate
    dtlsParameters.fingerprints[0] = certificate.fingerprint;
  }, function(){
    trace('Certificate could not be created');
  });
  // Prepare to handle remote ICE candidates
  mySignaller.onRemoteCandidate = function(remote) {
    // Figure out which IceTranport a remote candidate relates to by matching
    // the userNameFragment/password
    var j = 0;
    for (j = 0; j < iceTransport.length; j++) {
      var transport = iceTransports[j];
      if (transport.getRemoteParameters().userNameFragment === remote.parameters.userNameFragment)
        transport.addRemoteCandidate(remote.candidate);
      }
    }  };
  // ... create RtpSender/RtpReceiver objects as illustrated in Section 6.5 Example 8.

  mySignaller.mySendInitiate({
    "ice": iceGatherer.getLocalParameters(),
    "dtls": dtlsParameters,
    // ... marshall RtpSender/RtpReceiver capabilities as illustrated in Section 6.5 Example 8.
  }, function(remote) {
    // Create the ICE and DTLS transports
    var iceTransport = new RTCIceTransport(iceGatherer);
    iceTransport.start(iceGatherer, remote.ice, RTCIceRole.controlling);
    iceTransports.push(iceTransport);
    // Construct a RTCDtlsTransport object with the same certificate and fingerprint
    // as in the Offer so that the remote peer can verify it.
    var dtlsTransport = new RTCDtlsTransport(iceTransport, certs);
    dtlsTransport.start(remote.dtls);
    dtlsTransports.push(dtlsTransport);

    // ... configure RtpSender/RtpReceiver objects as illustrated in Section 6.5 Example 8.
  });
}
                

      // This is an example of how to answer with ICE and DTLS
// and DTLS parameters and ICE candidates and start both ICE and DTLS,
// assuming that RTP and RTCP are multiplexed.
// Include some helper functions
import {trace, errorHandler, mySendLocalCandidate, myIceGathererStateChange, 
  myIceTransportStateChange, myDtlsTransportStateChange} from 'helper';

// Assume that remote info is signalled to us.
function accept(mySignaller, remote) {
  // Prepare the ICE gatherer
  var gatherOptions = {
    gatherPolicy: "all",
    iceServers: [
      { urls: "stun:stun1.example.net" },
      { urls: "turn:turn.example.org", username: "user", credential: "myPassword",
        credentialType: "password" }
     ]
  };
  var iceGatherer = new RTCIceGatherer(gatherOptions);
  iceGatherer.onlocalcandidate = function(event) {
    mySignaller.mySendLocalCandidate(event.candidate);
  };
  
  // Start gathering
  iceGatherer.gather();

  // Create the DTLS certificate
  var certs;
  var keygenAlgorithm = { name: "ECDSA", namedCurve: "P-256" };
  RTCCertificate.generateCertificate(keygenAlgorithm).then(function(certificate){
    certs[0] = certificate;
  }, function(){
    trace('Certificate could not be created');
  });

  // Create ICE and DTLS transports
  var ice = new RTCIceTransport(iceGatherer);
  var dtls = new RTCDtlsTransport(ice, certs);

  // Prepare to handle remote candidates
  mySignaller.onRemoteCandidate = function(remote) {
    ice.addRemoteCandidate(remote.candidate);
  };
  // ... create RtpSender/RtpReceiver objects as illustrated in Section 6.5 Example 8.

  mySignaller.mySendAccept({
    "ice": iceGatherer.getLocalParameters(),
    "dtls": dtls.getLocalParameters()
    // ... marshall RtpSender/RtpReceiver capabilities as illustrated in Section 6.5 Example 8.
  });

  // Start the ICE transport with an implicit gather policy of "all"
  ice.start(iceGatherer, remote.ice, RTCIceRole.controlled);

  // Start the DTLS transport
  dtls.start(remote.dtls);

  // ... configure RtpSender/RtpReceiver objects as illustrated in Section 6.5 Example 8.
}
                

Overview

An RTCRtpSender instance is associated to a sending MediaStreamTrack and provides RTC related methods to it.

Operation

A RTCRtpSender instance is constructed from an MediaStreamTrack object and associated to an RTCDtlsTransport. If an attempt is made to construct an RTCRtpSender object with transport.state or rtcpTransport.state closed, or if track.readyState is ended, throw an InvalidStateError exception.

An RTCRtpSender object can be garbage-collected once stop() is called and it is no longer referenced.

Interface Definition

        [ Constructor (MediaStreamTrack track, RTCDtlsTransport transport, optional RTCDtlsTransport rtcpTransport)]
interface RTCRtpSender : RTCStatsProvider {
    readonly        attribute MediaStreamTrack  track;
    readonly        attribute RTCDtlsTransport  transport;
    readonly        attribute RTCDtlsTransport? rtcpTransport;
    void                      setTransport (RTCDtlsTransport transport, optional RTCDtlsTransport rtcpTransport);
    Promise<void>             setTrack (MediaStreamTrack track);
    static RTCRtpCapabilities getCapabilities (DOMString kind);
    Promise<void>             send (RTCRtpParameters parameters);
    void                      stop ();
                    attribute EventHandler      onssrcconflict;
};

RTCSsrcConflictEvent

The ssrcconflict event of the RTCRtpSender object uses the RTCSsrcConflictEvent interface.

Firing an RTCSsrcConflictEvent event named e with an ssrc means that an event with the name e, which does not bubble (except where otherwise stated) and is not cancelable (except where otherwise stated), and which uses the RTCSsrcConflictEvent interface with the ssrc attribute set to the conflicting SSRC MUST be created and dispatched at the given target.

        [ Constructor (DOMString type, RTCSsrcConflictEventInit eventInitDict)]
interface RTCSsrcConflictEvent : Event {
    readonly        attribute unsigned long ssrc;
};

dictionary RTCSsrcConflictEventInit : EventInit {
             unsigned long ssrc;
};

Overview

An RTCRtpReceiver instance produces an associated receiving MediaStreamTrack and provides RTC related methods to it.

Operation

A RTCRtpReceiver instance is constructed from a value of kind and an RTCDtlsTransport object. If an attempt is made to construct an RTCRtpReceiver object with transport.state or rtcpTransport.state with a value of closed, throw an InvalidStateError exception. Upon construction, track is set, and the value of track.kind is determined based on the value of kind passed in the constructor.

An RTCRtpReceiver object can be garbage-collected once stop() is called and it is no longer referenced.

Interface Definition

        [ Constructor (DOMString kind, RTCDtlsTransport transport, optional RTCDtlsTransport rtcpTransport)]
interface RTCRtpReceiver : RTCStatsProvider {
    readonly        attribute MediaStreamTrack  track;
    readonly        attribute RTCDtlsTransport  transport;
    readonly        attribute RTCDtlsTransport? rtcpTransport;
    void                               setTransport (RTCDtlsTransport transport, optional RTCDtlsTransport rtcpTransport);
    static RTCRtpCapabilities          getCapabilities (DOMString kind);
    Promise<void>                      receive (RTCRtpParameters parameters);
    sequence<RTCRtpContributingSource> getContributingSources ();
    void                               stop ();
};

dictionary RTCRtpContributingSource

The RTCRtpContributingSource object contains information about a contributing source. Each time an RTP packet is received, the RTCRtpContributingSource objects are updated. If the RTP packet contains CSRCs, then the RTCRtpContributingSource objects corresponding to those CSRCs are updated, and the level values for those CSRCs are updated based on the mixer-client header extension [[!RFC6464]] if present. If the RTP packet contains no CSRCs, then the RTCRtpContributingSource object corresponding to the SSRC is updated, and the level value for the SSRC is updated based on the client-mixer header extension [[!RFC6464]] if present.

dictionary RTCRtpContributingSource {
             DOMHighResTimeStamp timestamp;
             unsigned long       source;
             byte                audioLevel;
             boolean             voiceActivityFlag;
};

Examples

      // Assume we already have a way to signal, a transport
// (RTCDtlsTransport), and audio and video tracks. This is an example
// of how to offer them and get back an answer with audio and
// video tracks, and begin sending and receiving them.
// The example assumes that RTP and RTCP are multiplexed.
function myInitiate(mySignaller, transport, audioTrack, videoTrack) {
  var audioSender = new RTCRtpSender(audioTrack, transport);
  var videoSender = new RTCRtpSender(videoTrack, transport);
  var audioReceiver = new RTCRtpReceiver("audio", transport);
  var videoReceiver = new RTCRtpReceiver("video", transport);

  // Retrieve the audio and video receiver capabilities
  var recvAudioCaps = RTCRtpReceiver.getCapabilities("audio");
  var recvVideoCaps = RTCRtpReceiver.getCapabilities("video");

  // Retrieve the audio and video sender capabilities
  var sendAudioCaps = RTCRtpSender.getCapabilities("audio");
  var sendVideoCaps = RTCRtpSender.getCapabilities("video");

  mySignaller.myOfferTracks({
    // The initiator offers its receiver and sender capabilities.
    "recvAudioCaps": recvAudioCaps,
    "recvVideoCaps": recvVideoCaps,
    "sendAudioCaps": sendAudioCaps,
    "sendVideoCaps": sendVideoCaps
  }, function(answer) {
    // The responder answers with its receiver capabilities

    // Derive the send and receive parameters
    var audioSendParams = myCapsToSendParams(sendAudioCaps, answer.recvAudioCaps);
    var videoSendParams = myCapsToSendParams(sendVideoCaps, answer.recvVideoCaps);
    var audioRecvParams = myCapsToRecvParams(recvAudioCaps, answer.sendAudioCaps);
    var videoRecvParams = myCapsToRecvParams(recvVideoCaps, answer.sendVideoCaps);
    audioSender.send(audioSendParams).then(function() {
      trace("Set audio sender parameters");
      }, function() {
        trace("Could not set audio sender parameters");
      }
    );
    videoSender.send(videoSendParams).then(function() {
      trace("Set video sender parameters");
      }, function() {
        trace("Could not set video sender parameters");
      }
    );
    audioReceiver.receive(audioRecvParams).then(function() {
      trace("Set audio receiver parameters");
      }, function() {
        trace("Could not set audio receiver parameters");
      }
    );
    videoReceiver.receive(videoRecvParams).then(function() {
      trace("Set video receiver parameters");
      }, function() {
        trace("Could not set video receiver parameters");
      }
    );
    // Now we can render/play
    // audioReceiver.track and videoReceiver.track.
  });
}
                

      // Assume we already have a way to signal, a transport (RTCDtlsTransport)
// and audio and video tracks. This is an example of how to answer an
// offer with audio and video tracks, and begin sending and receiving them.
// The example assumes that RTP and RTCP are multiplexed.
function myAccept(mySignaller, remote, transport, audioTrack, videoTrack) {
  var audioSender = new RTCRtpSender(audioTrack, transport);
  var videoSender = new RTCRtpSender(videoTrack, transport);
  var audioReceiver = new RTCRtpReceiver("audio", transport);
  var videoReceiver = new RTCRtpReceiver("video", transport);

  // Retrieve the send and receive capabilities
  var recvAudioCaps = RTCRtpReceiver.getCapabilities("audio");
  var recvVideoCaps = RTCRtpReceiver.getCapabilities("video");
  var sendAudioCaps = RTCRtpSender.getCapabilities("audio");
  var sendVideoCaps = RTCRtpSender.getCapabilities("video");

  mySignaller.myAnswerTracks({
    "recvAudioCaps": recvAudioCaps,
    "recvVideoCaps": recvVideoCaps,
    "sendAudioCaps": sendAudioCaps,
    "sendVideoCaps": sendVideoCaps
  });

  // Derive the send and receive parameters using Javascript functions defined in Section 17.2.
  var audioSendParams = myCapsToSendParams(sendAudioCaps, remote.recvAudioCaps);
  var videoSendParams = myCapsToSendParams(sendVideoCaps, remote.recvVideoCaps);
  var audioRecvParams = myCapsToRecvParams(recvAudioCaps, remote.sendAudioCaps);
  var videoRecvParams = myCapsToRecvParams(recvVideoCaps, remote.sendVideoCaps);
  audioSender.send(audioSendParams).then(function() {
    trace("Set audio sender parameters");
    }, function() {
      trace("Could not set audio sender parameters");
    }
  );
  videoSender.send(videoSendParams).then(function() {
    trace("Set video sender parameters");
    }, function() {
      trace("Could not set video sender parameters");
    }
  );
  audioReceiver.receive(audioRecvParams).then(function() {
    trace("Set audio receiver parameters");
    }, function() {
      trace("Could not set audio receiver parameters");
    }
  );
  videoReceiver.receive(videoRecvParams).then(function() {
    trace("Set video receiver parameters");
    }, function() {
      trace("Could not set video receiver parameters");
    }
  );
  // Now we can render/play
  // audioReceiver.track and videoReceiver.track.
}
                

Overview

An RTCIceTransportController object provides methods to add and retrieve RTCIceTransport objects with a component of RTP (associated RTCIceTransport objects with a component of RTCP are included implicitly).

Operation

An RTCIceTransportController instance is automatically constructed.

Interface Definition

[Constructor()]
interface RTCIceTransportController {
    void                      addTransport (RTCIceTransport transport, optional unsigned long index);
    sequence<RTCIceTransport> getTransports ();
};

Examples

      // This is an example of how to utilize distinct ICE transports for Audio and Video
// as well as for RTP and RTCP. If both sides can multiplex audio/video
// and RTP/RTCP then the multiplexing will occur.
//
// Assume we have an audioTrack and a videoTrack to send.
//
// Include some helper functions
import {trace, errorHandler, mySendLocalCandidate, myIceGathererStateChange,
  myIceTransportStateChange, myDtlsTransportStateChange} from 'helper';
// Create the ICE gather options
var gatherOptions = {
  gatherPolicy: "all",
  iceServers: [
    { urls: "stun:stun1.example.net" },
    { urls: "turn:turn.example.org", username: "user", credential: "myPassword",
      credentialType: "password" }
   ]
};

// Create the RTP and RTCP ICE gatherers for audio and video
var audioRtpIceGatherer = new RTCIceGatherer(gatherOptions);
var audioRtcpIceGatherer = audioRtpIceGatherer.createAssociatedGatherer();
var videoRtpIceGatherer = new RTCIceGatherer(gatherOptions);
var videoRtcpIceGatherer = videoRtpIceGatherer.createAssociatedGatherer();

// Set up the ICE gatherer error handlers
audioRtpIceGatherer.onerror = errorHandler;
audioRtcpIceGatherer.onerror = errorHandler;
videoRtpIceGatherer.onerror = errorHandler;
videoRtcpIceGatherer.onerror = errorHandler;

// Create the RTP and RTCP ICE transports for audio and video
var audioRtpIceTransport = new RTCIceTransport(audioRtpIceGatherer);
var audioRtcpIceTransport = audioRtpIceTransport.createAssociatedTransport();
var videoRtpIceTransport = new RTCIceTransport(videoRtpIceGatherer);
var videoRtcpIceTransport = videoRtpIceTransport.createAssociatedTransport();

// Enable local ICE candidates to be signaled to the remote peer.
audioRtpIceGatherer.onlocalcandidate = function(event) {
  mySendLocalCandidate(event.candidate, "RTP", "audio");
};
audioRtcpIceGatherer.onlocalcandidate = function(event) {
  mySendLocalCandidate(event.candidate, "RTCP", "audio");
};
videoRtpIceGatherer.onlocalcandidate = function(event) {
  mySendLocalCandidate(event.candidate, "RTP", "video");
};
videoRtcpIceGatherer.onlocalcandidate = function(event) {
  mySendLocalCandidate(event.candidate, "RTCP", "video");
};

// Start gathering
audioRtpIceGatherer.gather();
audioRtcpIceGatherer.gather();
videoRtpIceGatherer.gather();
videoRtcpIceGatherer.gather();

// Set up the ICE state change event handlers
audioRtpIceTransport.onstatechange = function(event) {
  myIceTransportStateChange("audioRtpIceTransport", event.state);
};
audioRtcpIceTransport.onstatechange = function(event) {
  myIceTransportStateChange("audioRtcpIceTransport", event.state);
};
videoRtpIceTransport.onstatechange = function(event) {
  myIceTransportStateChange("videoRtpIceTransport", event.state);
};
videoRtcpIceTransport.onstatechange = function(event) {
  myIceTransportStateChange("videoRtcpIceTransport", event.state);
};

// Prepare to add ICE candidates signaled by the remote peer on any of the ICE transports
mySignaller.onRemoteCandidate = function(remote) {
  switch (remote.kind) {
    case "audio":
      if (remote.component === "RTP") {
        audioRtpIceTransport.addRemoteCandidate(remote.candidate);
      } else {
        audioRtcpIceTransport.addRemoteCandidate(remote.candidate);
      }
      break;
    case "video":
      if (remote.component === "RTP") {
        videoRtpIceTransport.addRemoteCandidate(remote.candidate);
      } else {
        videoRtcpIceTransport.addRemoteCandidate(remote.candidate);
      }
      break;
    default:
      trace("Invalid media type received: " + remote.kind);
  }
};
// Create the DTLS certificate
var certs;
var keygenAlgorithm = { name: "ECDSA", namedCurve: "P-256" };
RTCCertificate.generateCertificate(keygenAlgorithm).then(function(certificate){
  certs[0] = certificate;
}, function(){
  trace('Certificate could not be created');
});

// Create the DTLS transports (using the same certificate)
var audioRtpDtlsTransport = new RTCDtlsTransport(audioRtpIceTransport, certs);
var audioRtcpDtlsTransport = new RTCDtlsTransport(audioRtcpIceTransport, certs);
var videoRtpDtlsTransport = new RTCDtlsTransport(videoRtpIceTransport, certs);
var videoRtcpDtlsTransport = new RTCDtlsTransport(videoRtcpIceTransport, certs);

// Create the sender and receiver objects
var audioSender = new RTCRtpSender(audioTrack, audioRtpDtlsTransport, audioRtcpDtlsTransport);
var videoSender = new RTCRtpSender(videoTrack, videoRtpDtlsTransport, videoRtcpDtlsTransport);
var audioReceiver = new RTCRtpReceiver("audio", audioRtpDtlsTransport, audioRtcpDtlsTransport);
var videoReceiver = new RTCRtpReceiver("video", videoRtpDtlsTransport, videoRtcpDtlsTransport);

// Retrieve the receiver and sender capabilities
var recvAudioCaps = RTCRtpReceiver.getCapabilities("audio");
var recvVideoCaps = RTCRtpReceiver.getCapabilities("video");
var sendAudioCaps = RTCRtpSender.getCapabilities("audio");
var sendVideoCaps = RTCRtpSender.getCapabilities("video");

// Exchange ICE/DTLS parameters and Send/Receive capabilities

mySignaller.myOfferTracks({
  // Indicate that the initiator would prefer to multiplex both A/V and RTP/RTCP
  "bundle": true,
  // Indicate that the initiator is willing to multiplex RTP/RTCP without A/V mux
  "rtcpMux": true,
  // Offer the ICE parameters
  "audioRtpIce": audioRtpIceGatherer.getLocalParameters(),
  "audioRtcpIce": audioRtcpIceGatherer.getLocalParameters(),
  "videoRtpIce": videoRtpIceGatherer.getLocalParameters(),
  "videoRtcpIce": videoRtcpIceGatherer.getLocalParameters(),
  // Offer the DTLS parameters
  "audioRtpDtls": audioRtpDtlsTransport.getLocalParameters(),
  "audioRtcpDtls": audioRtcpDtlsTransport.getLocalParameters(),
  "videoRtpDtls": videoRtpDtlsTransport.getLocalParameters(),
  "videoRtcpDtls": videoRtcpDtlsTransport.getLocalParameters(),
  // Offer the receiver and sender audio and video capabilities.
  "recvAudioCaps": recvAudioCaps,
  "recvVideoCaps": recvVideoCaps,
  "sendAudioCaps": sendAudioCaps,
  "sendVideoCaps": sendVideoCaps
}, function(answer) {
  // The responder answers with its preferences, parameters and capabilities
  // Since we didn"t create transport arrays, we are assuming that there
  // is no forking (only one response)
  //
  // Derive the send and receive parameters, assuming that RTP/RTCP mux will be enabled.
  var audioSendParams = myCapsToSendParams(sendAudioCaps, answer.recvAudioCaps);
  var videoSendParams = myCapsToSendParams(sendVideoCaps, answer.recvVideoCaps);
  var audioRecvParams = myCapsToRecvParams(recvAudioCaps, answer.sendAudioCaps);
  var videoRecvParams = myCapsToRecvParams(recvVideoCaps, answer.sendVideoCaps);
  //
  // If the responder wishes to enable bundle, we will enable it
  if (answer.bundle) {
    // Since bundle implies RTP/RTCP multiplexing, we only need a single
    // ICE transport and DTLS transport. No need for the ICE transport controller.
    audioRtpIceTransport.start(audioRtpIceGatherer, answer.audioRtpIce, RTCIceRole.controlling);
    audioRtpDtlsTransport.start(remote.audioRtpDtls);
    //
    // Replace the transport on the Sender and Receiver objects
    //
    audioSender.setTransport(audioRtpDtlsTransport);
    videoSender.setTransport(audioRtpDtlsTransport);
    audioReceiver.setTransport(audioRtpDtlsTransport);
    videoReceiver.setTransport(audioRtpDtlsTransport);
    // If BUNDLE was requested, then also assume RTP/RTCP mux
    answer.rtcpMux = true;
  } else {
    var controller = new RTCIceTransportController();
    if (answer.rtcpMux) {
      // The peer doesn"t want BUNDLE, but it does want to multiplex RTP/RTCP
      // Now we need audio and video ICE transports
      // as well as an ICE Transport Controller object
      controller.addTransport(audioRtpIceTransport);
      controller.addTransport(videoRtpIceTransport);
      // Start the audio and video ICE transports
      audioRtpIceTransport.start(audioRtpIceGatherer, answer.audioRtpIce, RTCIceRole.controlling);
      videoRtpIceTransport.start(videoRtpIceGatherer, answer.videoRtpIce, RTCIceRole.controlling);
      // Start the audio and video DTLS transports
      audioRtpDtlsTransport.onerror = errorHandler;
      audioRtpDtlsTransport.start(answer.audioRtpDtls);
      videoRtpDtlsTransport.onerror = errorHandler;
      videoRtpDtlsTransport.start(answer.videoRtpDtls);
      // Replace the transport on the Sender and Receiver objects
      //
      audioSender.setTransport(audioRtpDtlsTransport);
      videoSender.setTransport(videoRtpDtlsTransport);
      audioReceiver.setTransport(audioRtpDtlsTransport);
      videoReceiver.setTransport(videoRtpDtlsTransport);
    } else {
      // We arrive here if the responder does not want BUNDLE
      // or RTP/RTCP multiplexing
      //
      // Now we need all the audio and video RTP and RTCP ICE transports
      // as well as an ICE Transport Controller object
      controller.addTransport(audioRtpIceTransport);
      controller.addTransport(videoRtpIceTransport);
      // Start the ICE transports
      audioRtpIceTransport.start(audioRtpIceGatherer, answer.audioRtpIce, RTCIceRole.controlling);
      audioRtcpIceTransport.start(audioRtcpIceGatherer, answer.audioRtcpIce, 
        RTCIceRole.controlling);
      videoRtpIceTransport.start(videoRtpIceGatherer, answer.videoRtpIce, RTCIceRole.controlling);
      videoRtcpIceTransport.start(videoRtcpIceGatherer, answer.videoRtcpIce,
        RTCIceRole.controlling);
      // Start the DTLS transports that are needed
      audioRtpDtlsTransport.start(answer.audioRtpDtls);
      audioRtcpDtlsTransport.start(answer.audioRtcpDtls);
      videoRtpDtlsTransport.start(answer.videoRtpDtls);
      videoRtcpDtlsTransport.start(answer.videoRtcpDtls);
      // Disable RTP/RTCP multiplexing
      audioSendParams.rtcp.mux = false;
      videoSendParams.rtcp.mux = false;
      audioRecvParams.rtcp.mux = false;
      videoRecvParams.rtcp.mux = false;
    }
  }
  // Set the audio and video send and receive parameters.
  audioSender.send(audioSendParams).then(function() {
    trace("Set audio sender parameters");
    }, function() {
      trace("Could not set audio sender parameters");
    }
  );
  videoSender.send(videoSendParams).then(function() {
    trace("Set video sender parameters");
    }, function() {
      trace("Could not set video sender parameters");
    }
  );
  audioReceiver.receive(audioRecvParams).then(function() {
    trace("Set audio receiver parameters");
    }, function() {
      trace("Could not set audio receiver parameters");
    }
  );
  videoReceiver.receive(videoRecvParams).then(function() {
    trace("Set video receiver parameters");
    }, function() {
      trace("Could not set video receiver parameters");
    }
  );
// Now we can render/play audioReceiver.track and videoReceiver.track
                

Overview

An RTCRtpListener instance is associated to an RTCDtlsTransport.

Operation

An RTCRtpListener instance is constructed from an RTCDtlsTransport object.

RTP matching rules

When the RTCRtpListener object receives an RTP packet over an RTCDtlsTransport, the RTCRtpListener attempts to determine which RTCRtpReceiver object to deliver the packet to, based on the values of the SSRC and payload type fields in the RTP header, as well as the value of the MID RTP header extension, if present.

The RTCRtpListener maintains three tables in order to facilitate matching: the ssrc_table which maps SSRC values to RTCRtpReceiver objects; the muxId_table which maps values of the MID header extension to RTCRtpReceiver objects and the pt_table which maps payload type values to RTCRtpReceiver objects.

For an RTCRtpReceiver object receiver, table entries are added when receiver.receive() is called, and are removed when receiver.stop() is called. If receiver.receive() is called again, all entries referencing receiver are removed prior to adding new entries.

SSRC table: Set ssrc_table[parameters.encodings[i].ssrc] to receiver for each entry where parameters.encodings[i].ssrc is set, for values of i from 0 to the number of encodings. Set ssrc_table[parameters.encodings[i].rtx.ssrc] to receiver for each entry where parameters.encodings[i].rtx.ssrc is set, for values of i from 0 to the number of encodings. Set ssrc_table[parameters.encodings[i].fec.ssrc] to receiver for each entry where parameters.encodings[i].fec.ssrc is set, for values of i from 0 to the number of encodings. If ssrc_table[ssrc] is already set to a value other than receiver, then receiver.receive() will throw an InvalidParameters exception.

muxId table: If parameters.muxId is set, muxId_table[parameters.muxId] is set to receiver. If muxId_table[muxId] is already set to a value other than receiver, then receiver.receive() will throw an InvalidParameters exception.

payload type table: If parameters.muxId is unset and parameters.encodings[i].ssrc is unset for all values of i from 0 to the number of encodings, then add entries to pt_table by setting pt_table[parameters.codecs[j].payloadType] to receiver, for values of j from 0 to the number of codecs. If pt_table[pt] is already set to a value other than receiver then receiver.receive() will throw an InvalidParameters exception.

When an RTP packet arrives, the implementation determines the RTCRtpReceiver rtp_receiver to send it to as follows: If ssrc_table[packet.ssrc] is set: set rtp_receiver to ssrc_table[packet.ssrc] and check whether the value of packet.pt is equal to one of the values of parameters.codecs[j].payloadtype for rtp_receiver, where j varies from 0 to the number of codecs. If so, route the packet to rtp_receiver. If packet.pt does not match, fire the unhandledrtp event.

Else if packet.muxId is set: If muxId_table[packet.muxId] is unset, fire the unhandledrtp event, else set rtp_receiver to muxId_table[packet.muxId] and check whether the value of packet.pt is equal to one of the values of parameters.codecs[j].payloadtype for the RTCRtpReceiver object rtp_receiver, where j varies from 0 to the number of codecs. If so, set ssrc_table[packet.ssrc] to rtp_receiver and route the packet to rtp_receiver. If packet.pt does not match, fire the unhandledrtp event.

Else if pt_table[packet.pt] is set: set rtp_receiver to pt_table[packet.pt], set ssrc_table[packet.ssrc] to rtp_receiver, set pt_table[packet.pt] to null and route the packet to rtp_receiver. Question: Do we remove all pt_table[packet.pt] entries set to rtp_receiver?

Else if no matches are found in the ssrc_table, muxId_table or pt_table, fire the unhandledrtp event.

Interface Definition

[ Constructor (RTCDtlsTransport transport)]
interface RTCRtpListener {
    readonly        attribute RTCDtlsTransport transport;
                    attribute EventHandler     onunhandledrtp;
};

RTCRtpUnhandledEvent

The unhandledrtp event of the RTCRtpListener object uses the RTCRtpUnhandledEvent interface.

Firing an RTCRtpUnhandledEvent event named e means that an event with the name e, which does not bubble (except where otherwise stated) and is not cancelable (except where otherwise stated), and which uses the RTCRtpUnhandledEvent interface MUST be created and dispatched at the given target.

        [ Constructor (DOMString type, RTCRtpUnhandledEventInit eventInitDict)]
interface RTCRtpUnhandledEvent : Event {
    readonly        attribute DOMString     muxId;
    readonly        attribute DOMString     rid;
    readonly        attribute payloadtype   payloadType;
    readonly        attribute unsigned long ssrc;
};

dictionary RTCRtpUnhandledEventInit : EventInit {
             DOMString     muxId;
             DOMString     rid;
             payloadtype   payloadType;
             unsigned long ssrc;
};

Example

dictionary RTCRtpCapabilities

The RTCRtpCapabilities object expresses the capabilities of RTCRtpSender and RTCRtpReceiver objects. Features which are mandatory to implement in [[!RTP-USAGE]], such as RTP/RTCP multiplexing [[!RFC5761]], audio/video multiplexing [[!RTP-MULTI-STREAM]] and reduced size RTCP [[!RFC5506]] are assumed to be available and are therefore not included in RTCRtpCapabilities, although these features can be set via RTCRtpParameters.

dictionary RTCRtpCapabilities {
             sequence<RTCRtpCodecCapability> codecs;
             sequence<RTCRtpHeaderExtension> headerExtensions;
             sequence<DOMString>             fecMechanisms;
};

dictionary RTCRtcpFeedback

RTCRtcpFeedback provides information on RTCP feedback messages.

dictionary RTCRtcpFeedback {
             DOMString type;
             DOMString parameter;
};

dictionary RTCRtpCodecCapability

RTCRtpCodecCapability provides information on the capabilities of a codec.

typedef object Dictionary;

typedef octet payloadtype;

dictionary RTCRtpCodecCapability {
             DOMString                 name;
             DOMString                 mimeType;
             DOMString                 kind;
             unsigned long             clockRate;
             payloadtype               preferredPayloadType;
             unsigned long             maxptime;
             unsigned long             ptime;
             unsigned long             numChannels;
             sequence<RTCRtcpFeedback> rtcpFeedback;
             Dictionary                parameters;
             Dictionary                options;
             unsigned short            maxTemporalLayers = 0;
             unsigned short            maxSpatialLayers = 0;
             boolean                   svcMultiStreamSupport;
};

dictionary RTCRtpParameters

RTCRtpParameters contains the RTP stack settings.

dictionary RTCRtpParameters {
             DOMString                                 muxId = "";
    required sequence<RTCRtpCodecParameters>           codecs;
             sequence<RTCRtpHeaderExtensionParameters> headerExtensions;
             sequence<RTCRtpEncodingParameters>        encodings;
             RTCRtcpParameters                         rtcp;
             RTCDegradationPreference                  degradationPreference = "balanced";
};

enum RTCDegradationPreference

RTCDegradationPreference can be used to indicate the desired choice between degrading resolution and degrading framerate when bandwidth is constrained.

enum RTCDegradationPreference {
    "maintain-framerate",
    "maintain-resolution",
    "balanced"
};

dictionary RTCRtcpParameters

RTCRtcpParameters provides information on RTCP settings.

dictionary RTCRtcpParameters {
             unsigned long ssrc;
             DOMString     cname;
             boolean       reducedSize = false;
             boolean       mux = true;
};

dictionary RTCRtpCodecParameters

RTCRtpCodecParameters provides information on codec settings.

dictionary RTCRtpCodecParameters {
    required DOMString                 name;
             DOMString                 mimeType;
    required payloadtype               payloadType;
             unsigned long             clockRate;
             unsigned long             maxptime;
             unsigned long             ptime;
             unsigned long             numChannels;
             sequence<RTCRtcpFeedback> rtcpFeedback;
             Dictionary                parameters;
};

dictionary RTCRtpEncodingParameters

RTCRtpEncodingParameters provides information relating to the encoding. Note that all encoding parameters (such as maxBitrate, maxFramerate and resolutionScale) are applied prior to codec-specific constraints.

dictionary RTCRtpEncodingParameters {
             unsigned long       ssrc;
             payloadtype         codecPayloadType;
             RTCRtpFecParameters fec;
             RTCRtpRtxParameters rtx;
             RTCPriorityType     priority;
             unsigned long       maxBitrate;
             double              resolutionScale;
             double              framerateScale;
             unsigned long       maxFramerate;
             boolean             active = true;
             DOMString           encodingId;
             sequence<DOMString> dependencyEncodingIds;
};

Usage of the attributes is defined in the table below:

Examples

Basic Example

          // Send a thumbnail along with regular size, prioritizing the thumbnail (ssrc: 2)
var encodings = [{ ssrc: 1, priority: 1.0 }];
var encodings = [{ ssrc: 2, priority: 10.0 }];

// Sign Language (prefer  framerate)
var encodings = [{ degradationPreference: "maintain-framerate" }];

// Screencast (prefer resolution)
var encodings = [{ degradationPreference: "maintain-resolution" }];

// Remote Desktop (High framerate, must not downscale)
var encodings = [{ degradationPreference: "maintain-framerate" }];

// Audio more important than video
var audioEncodings = [{ priority: 10.0 }];
var videoEncodings = [{ priority: 0.1 }];

// Video more important than audio
var audioEncodings = [{ priority: 0.1 }];
var videoEncodings = [{ priority: 10.0 }];

// Crank up the quality
var encodings = [{ maxBitrate: 10000000 }];

// Keep the bandwidth low
var encodings = [{ maxBitrate: 100000 }];
                    

Temporal Scalability

          // Example of 3-layer temporal scalability encoding
var encodings = [{
  // Base framerate is one quarter of the input framerate
  encodingId: "0",
  framerateScale: 4.0
}, {
  // Temporal enhancement (half the input framerate when combined with the base layer)
  encodingId: "1",
  dependencyEncodingIds: ["0"],
  framerateScale: 2.0
}, {
  // Another temporal enhancement layer (full input framerate when all layers combined)
  encodingId: "2",
  dependencyEncodingIds: ["0", "1"],
  framerateScale: 1.0
}];

// Example of 3-layer temporal scalability with all but the base layer disabled
var encodings = [{
  encodingId: "0",
  framerateScale: 4.0
}, {
  encodingId: "1",
  dependencyEncodingIds: ["0"],
  framerateScale: 2.0,
  active: false
}, {
  encodingId: "2",
  dependencyEncodingIds: ["0", "1"],
  framerateScale: 1.0,
  active: false
}];

Below is a representation of a 3-layer temporal scalability encoding. In the diagram, I0 is the base layer I-frame, and P0 represents base-layer P-frames. P1 represents the first temporal enhancement layer, and P2 represents the second temporal enhancement layer.

Spatial Simulcast

          // Example of 3-layer spatial simulcast
var encodings = [{
  // Simulcast layer at one quarter scale
  encodingId: "0",
  resolutionScale: 4.0
}, {
  // Simulcast layer at one half scale
  encodingId: "1",
  resolutionScale: 2.0
}, {
  // Simulcast layer at full scale
  encodingId: "2",
  resolutionScale: 1.0
}];

// Example of 3-layer spatial simulcast with all but the lowest resolution layer disabled
var encodings = [{
  encodingId: "0",
  resolutionScale: 4.0
}, {
  encodingId: "1",
  resolutionScale: 2.0,
  active: false
}, {
  encodingId: "2",
  resolutionScale: 1.0,
  active: false
}];

// Example of 2-layer spatial simulcast combined with 2-layer temporal scalability
var encodings = [{
  // Low resolution base layer (half the input framerate, half the input resolution)
  encodingId: "0",
  resolutionScale: 2.0,
  framerateScale: 2.0
}, {
  // High resolution Base layer (half the input framerate, full input resolution)
  encodingId: "E0",
  resolutionScale: 1.0,
  framerateScale: 2.0
}, {
  // Temporal enhancement to the low resolution base layer (full input framerate, half resolution)
  encodingId: "1",
  dependencyEncodingIds: ["0"],
  resolutionScale: 2.0,
  framerateScale: 1.0
}, {
  // Temporal enhancement to the high resolution base layer (full input framerate and resolution)
  encodingId: "E1",
  dependencyEncodingIds: ["E0"],
  resolutionScale: 1.0,
  framerateScale: 1.0
}];
                    

Below is a representation of 2-layer temporal scalability combined with 2-layer spatial simulcast. Solid arrows represent temporal prediction. In the diagram, I0 is the base-layer I-frame, and P0 represents base-layer P-frames. EI0 is an enhanced resolution base-layer I-frame, and EP0 represents P-frames within the enhanced resolution base layer. P1 represents the first temporal enhancement layer, and EP1 represents a temporal enhancement to the enhanced resolution simulcast base-layer.

Spatial Scalability

          // Example of 3-layer spatial scalability encoding
var encodings = [{
  // Base layer with one quarter input resolution
  encodingId: "0",
  resolutionScale: 4.0
}, {
  // Spatial enhancement layer yielding half resolution when combined with the base layer
  encodingId: "1",
  dependencyEncodingIds: ["0"],
  resolutionScale: 2.0
}, {
  // Additional spatial enhancement layer yielding full resolution when combined with all layers
  encodingId: "2",
  dependencyEncodingIds: ["0", "1"],
  resolutionScale: 1.0
}]

// Example of 3-layer spatial scalability with all but the base layer disabled
var encodings = [{
  encodingId: "0",
  resolutionScale: 4.0
}, {
  encodingId: "1",
  dependencyEncodingIds: ["0"],
  resolutionScale: 2.0,
  active: false
}, {
  encodingId: "2",
  dependencyEncodingIds: ["0", "1"],
  resolutionScale: 1.0,
  active: false
}];

// Example of 2-layer spatial scalability combined with 2-layer temporal scalability
var encodings = [{
  // Base layer (half input framerate, half resolution)
  encodingId: "0",
  resolutionScale: 2.0,
  framerateScale: 2.0
}, {
  // Temporal enhancement to the base layer (full input framerate, half resolution)
  encodingId: "1",
  dependencyEncodingIds: ["0"],
  resolutionScale: 2.0,
  framerateScale: 1.0
}, {
  // Spatial enhancement to the base layer (half input framerate, full resolution)
  encodingId: "E0",
  dependencyEncodingIds: ["0"],
  resolutionScale: 1.0,
  framerateScale: 2.0
}, {
  // Temporal enhancement to the spatial enhancement layer (full input framerate, full resolution)
  encodingId: "E1",
  dependencyEncodingIds: ["E0", "1"],
  resolutionScale: 1.0,
  framerateScale: 1.0
}];
                    

Below is a representation of 2-layer temporal scalability combined with 2-layer spatial scalability. Solid arrows represent temporal prediction and dashed arrows represent inter-layer prediction. In the diagram, I0 is the base-layer I-frame, and EI0 is an intra spatial enhancement. P0 represents base-layer P-frames, and P1 represents the first temporal enhancement layer. EP0 represents a resolution enhancement to the base-layer P frames, and EP1 represents a resolution enhancement to the second temporal layer P-frames.

enum RTCPriorityType

RTCPriorityType can be used to indicate the relative priority of various flows. This allows applications to indicate to the browser whether a particular media flow is high, medium, low or of very low importance to the application. WebRTC uses the priority and Quality of Service (QoS) framework described in [[RTCWEB-TRANSPORT]] and [[!TSVWG-RTCWEB-QOS]] to provide priority and DSCP marketing for packets that will help provide QoS in some networking environments. Applications that use this API should be aware that often better overall user experience is obtained by lowering the priority of things that are not as important rather than raising the the priority of the things that are.

enum RTCPriorityType {
    "very-low",
    "low",
    "medium",
    "high"
};

dictionary RTCRtpFecParameters

dictionary RTCRtpFecParameters {
             unsigned long ssrc;
             DOMString     mechanism;
};

dictionary RTCRtpRtxParameters

dictionary RTCRtpRtxParameters {
             unsigned long ssrc;
};

// Example of RTX and RED + ulpfec
//
// SDP from createOffer() in WebRTC 1.0
//
//   m=video 62125 UDP/TLS/RTP/SAVPF 100 101 116 117 96
//   a=sendonly
//   a=rtpmap:100 VP8/90000
//   a=rtpmap:101 VP9/90000
//   a=rtpmap:116 red/90000
//   a=rtpmap:117 ulpfec/90000
//   a=rtpmap:96 rtx/90000
//   a=fmtp:96 apt=100
//   a=rtpmap:97 rtx/90000
//   a=fmtp:97 apt=101
//   a=rtpmap:98 rtx/90000
//   a=fmtp:98 apt=116
//   a=ssrc-group:FID 2224031971 3254585230
//   a=ssrc:2224031971 cname:oC/i06PA+Lda+t1P
//   a=ssrc:3254585230 cname:oC/i06PA+Lda+t1P
//
//   Define RTCRtpCodecParameters
//
var codecs = [
//   Define VP9 codec parameters
  {
    name: "vp9",
    payloadType: 101,
    clockRate: 90000
  },
//   Define VP8 codec parameters
  {
    name: "vp8",
    payloadType: 100,
    clockRate: 90000
  },
//   Define retransmission of VP9
  {
    name: "rtx",
    payloadType: 97,
    clockrate: 90000,
    parameters: {
      apt: 101
    }
  },
//   Define retransmission of VP8
  {
    name: "rtx",
    payloadType: 96,
    clockrate: 90000,
    parameters: {
      apt: 100
    }
  },
//   Define RED codec parameters
  {
    name: "red",
    payloadType: 116,
    clockRate: 90000,
    parameters: {
      payloadTypes: []
    }
  },
//   Define ulpfec codec parameters
  {
    name: "ulpfec",
    payloadType: 117,
    clockRate: 90000
  },
//   Define RTX codec parameters
  {
    name: "rtx",
    payloadType: 98,
    clockrate: 90000,
    parameters: {
      apt: 116
    }
  }
]; 
//
//   Define rtx parameters
var rtxParams = {
  ssrc: 3254585230
}; 
//   Define FEC parameters for "red+ulpfec"
var redulpfec = {
  ssrc: 3254585230,
  mechanism: "red+ulpfec"
}; 
//   Define RTCRtpEncodingParameters
//
var encodings = [
//   Define VP8 encoding parameters (without RED)
  {
    ssrc: 2224031971,
    codecPayloadType: 100,
    rtx: rtxParams
  },
//   Define VP8 encoding parameters with RED
  {
    ssrc:  2224031971,
    codecPayloadType: 100,
    fec: redulpfec,
    rtx: rtxParams
  },
//   Define VP9 encoding parameters (without RED)
  {
    ssrc:  2224031971,
    codecPayloadType: 101,
    rtx: rtxParams
  },
//   Define VP9 encoding parameters with RED
  {
    ssrc:  2224031971,
    codecPayloadType: 101,
    fec: redulplfec,
    rtx: rtxParams
  }
];  
                    

dictionary RTCRtpHeaderExtension

The RTCRtpHeaderExtension dictionary enables a header extension to be configured for use within an RTCRtpSender or RTCRtpReceiver. In order to provide the equivalent of the "direction" parameter defined in [[!RFC5285]] Section 5, an application can do the following:

1. sendonly: Include the header extension only when calling send(parameters).
2. recvonly: Include the header extension only when calling receive(parameters).
3. sendrecv: Include the header extension when calling send(parameters) and receive(parameters).
4. inactive: Don't include the header extension when calling either send(parameters) or receive(parameters).

dictionary RTCRtpHeaderExtension {
             DOMString      kind;
             DOMString      uri;
             unsigned short preferredId;
             boolean        preferredEncrypt = false;
};

dictionary RTCRtpHeaderExtensionParameters

dictionary RTCRtpHeaderExtensionParameters {
    required DOMString      uri;
    required unsigned short id;
             boolean        encrypt = false;
             Dictionary     parameters;
};

RTP header extensions

Registered RTP header extensions are listed in [[!IANA-RTP-10]]. Header extensions mentioned in [[!RTP-USAGE]] and [[!RID]] include:

Overview

An RTCDtmfSender instance allows sending DTMF tones to/from the remote peer, as per [[!RFC4733]].

Operation

An RTCDtmfSender object is constructed from an RTCRtpSender sender. If sender.track.kind is not "audio", throw an InvalidParameters exception.

Interface Definition

[ Constructor (RTCRtpSender sender)]
interface RTCDtmfSender {
    readonly        attribute boolean      canInsertDTMF;
    void insertDTMF (DOMString tones, optional long duration, optional long interToneGap);
    readonly        attribute RTCRtpSender sender;
                    attribute EventHandler ontonechange;
    readonly        attribute DOMString    toneBuffer;
    readonly        attribute long         duration;
    readonly        attribute long         interToneGap;
};

RTCDTMFToneChangeEvent

The tonechange event uses the RTCDTMFToneChangeEvent interface.

Firing a tonechange event named e with a DOMString tone means that an event with the name e, which does not bubble (except where otherwise stated) and is not cancelable (except where otherwise stated), and which uses the RTCDTMFToneChangeEvent interface with the tone attribute set to tone, MUST be created and dispatched at the given target.

        [ Constructor (DOMString type, RTCDTMFToneChangeEventInit eventInitDict)]
interface RTCDTMFToneChangeEvent : Event {
    readonly        attribute DOMString tone;
};

dictionary RTCDTMFToneChangeEventInit : EventInit {
             DOMString tone = "";
};

DTMF Example

Examples assume that sendObject is an RTCRtpSender object.

Sending the DTMF signal "1234" with 500 ms duration per tone:

      var sender = new RTCDtmfSender(sendObject);
if (sender.canInsertDTMF) {
  var duration = 500;
  sender.insertDTMF("1234", duration);
} else {
  trace("DTMF function not available");
}
                

Send the DTMF signal "1234", and light up the active key using lightKey(key) while the tone is playing (assuming that lightKey("") will darken all the keys):

      var sender = new RTCDtmfSender(sendObject);
sender.ontonechange = function(e) {
  if (!e.tone) return;

  // light up the key when playout starts
  lightKey(e.tone);

  // turn off the light after tone duration
  setTimeout(lightKey, sender.duration, "");
};
sender.insertDTMF("1234");
                

Send a 1-second "1" tone followed by a 2-second "2" tone:

      var sender = new RTCDtmfSender(sendObject);
sender.ontonechange = function(e) {
  if (e.tone === "1") sender.insertDTMF("2", 2000);
};
sender.insertDTMF("1", 1000);
                

It is always safe to append to the tone buffer. This example appends before any tone playout has started as well as during playout.

      var sender = new RTCDtmfSender(sendObject);
sender.insertDTMF("123");

// append more tones to the tone buffer before playout has begun
sender.insertDTMF(sender.toneBuffer + "456");

sender.ontonechange = function(e) {
  if (e.tone === "1") {
    // append more tones when playout has begun
    sender.insertDTMF(sender.toneBuffer + "789");
  }
};
                

Send the DTMF signal "123" and abort after sending "2".

      var sender = new RTCDtmfSender(sendObject);
sender.ontonechange = function(e) {
  if (e.tone === "2") {
    // empty the buffer to not play any tone after "2"
    sender.insertDTMF("");
  }
};
sender.insertDTMF("123");
                

Overview

An RTCDataChannel class instance allows sending data messages to/from the remote peer.

Operation

An RTCDataChannel object is constructed from a RTCDataTransport object and an RTCDataChannelParameters object. If parameters is invalid, throw an InvalidParameters exception. If transport.state is closed, throw an InvalidState exception.

An RTCDataChannel object can be garbage-collected once readyState is closed and it is no longer referenced.

Interface Definition

The RTCDataChannel interface represents a bi-directional data channel between two peers. There are two ways to establish a connection with RTCDataChannel. The first way is to construct an RTCDataChannel at one of the peers with the RTCDataChannelParameters.negotiated attribute unset or set to its default value false. This will announce the new channel in-band and trigger an ondatachannel event with the corresponding RTCDataChannel object at the other peer. The second way is to let the application negotiate the RTCDataChannel. To do this, create an RTCDataChannel object with the RTCDataChannelParameters.negotiated dictionary member set to true, and signal out-of-band (e.g. via a web server) to the other side that it should create a corresponding RTCDataChannel with the RTCDataChannelParameters.negotiated dictionary member set to true and the same id. This will connect the two separately created RTCDataChannel objects. The second way makes it possible to create channels with asymmetric properties and to create channels in a declarative way by specifying matching ids. Each RTCDataChannel has an associated underlying data transport that is used to transport actual data to the other peer. The transport properties of the underlying data transport, such as in order delivery settings and reliability mode, are configured by the peer as the channel is created. The properties of a channel cannot change after the channel has been created.

        [ Constructor (RTCDataTransport transport, RTCDataChannelParameters parameters)]
interface RTCDataChannel : EventTarget {
    readonly        attribute RTCDataTransport    transport;
    readonly        attribute RTCDataChannelState readyState;
    readonly        attribute unsigned long       bufferedAmount;
                    attribute unsigned long       bufferedAmountLowThreshold;
                    attribute DOMString           binaryType;
    RTCDataChannelParameters getParameters ();
    void                     close ();
                    attribute EventHandler        onopen;
                    attribute EventHandler        onbufferedamountlow;
                    attribute EventHandler        onerror;
                    attribute EventHandler        onclose;
                    attribute EventHandler        onmessage;
    void                     send (USVString data);
    void                     send (Blob data);
    void                     send (ArrayBuffer data);
    void                     send (ArrayBufferView data);
};

The send() method is overloaded to handle different data argument types. When any version of the method is called, the user agent MUST run the following steps:

1. Let channel be the RTCDataChannel object on which data is to be sent.

2. If readyState attribute is connecting, throw an InvalidStateError exception and abort these steps.

3. Execute the sub step that corresponds to the type of the methods argument:

   • string object:

     Let data be the object and increase the bufferedAmount attribute by the number of bytes needed to express data as UTF-8.

   • Blob object:

     Let data be the raw data represented by the Blob object and increase the bufferedAmount attribute by the size of data, in bytes.

   • ArrayBuffer object:

     Let data be the data stored in the buffer described by the ArrayBuffer object and increase the bufferedAmount attribute by the length of the ArrayBuffer in bytes.

   • ArrayBufferView object:

     Let data be the data stored in the section of the buffer described by the ArrayBuffer object that the ArrayBufferView object references and increase the bufferedAmount attribute by the length of the ArrayBufferView in bytes.

4. If channel's underlying data transport is not established yet, or if the closing procedure has started, then abort these steps.

5. Attempt to send data on channel's underlying data transport; if the data cannot be sent, e.g. because it would need to be buffered but the buffer is full, the user agent MUST abruptly close channel's underlying data transport with an error.

Interface Definition

interface RTCDataTransport : RTCStatsProvider {
};

enum RTCDataChannelState

enum RTCDataChannelState {
    "connecting",
    "open",
    "closing",
    "closed"
};

dictionary RTCDataChannelParameters

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

dictionary RTCDataChannelParameters {
             USVString      label = "";
             boolean        ordered = true;
             unsigned long  maxPacketLifetime;
             unsigned long  maxRetransmits;
             USVString      protocol = "";
             boolean        negotiated = false;
             unsigned short id;
};

Overview

An RTCSctpTransport inherits from an RTCDataTransport object, which is associated to an RTCDataChannel object.

Operation

An RTCSctpTransport is constructed from an RTCDtlsTransport object, and optionally a port number (with a default of 5000, or the next unused port). If a port already in use is provided in the constructor, throw an InvalidParameters exception. Creation of an RTCSctpTransport causes an SCTP INIT request to be issued over the RTCDtlsTransport from the local RTCSctpTransport to the remote RTCSctpTransport where the remote RTCSctpTransport responds with an SCTP INIT-ACK. Since both local and remote parties must mutually create an RTCSctpTransport, SCTP SO (Simultaneous Open) is used to establish a connection over SCTP.

An RTCSctpTransport object can be garbage-collected once stop() is called and it is no longer referenced.

Interface Definition

        [ Constructor (RTCDtlsTransport transport, optional unsigned short port)]
interface RTCSctpTransport : RTCDataTransport {
    readonly        attribute RTCDtlsTransport      transport;
    readonly        attribute RTCSctpTransportState state;
    readonly        attribute unsigned short        port;
    static RTCSctpCapabilities getCapabilities ();
    void                       start (RTCSctpCapabilities remoteCaps);
    void                       stop ();
                    attribute EventHandler          ondatachannel;
                    attribute EventHandler          onstatechange;
};

enum RTCSctpTransportState {
    "new",
    "connecting",
    "connected",
    "closed"
};

dictionary RTCSctpCapabilities {
             unsigned short maxMessageSize;
};

RTCDataChannelEvent

The datachannel event uses the RTCDataChannelEvent interface.

Firing a datachannel event named e with a RTCDataChannel channel means that an event with the name e, which does not bubble (except where otherwise stated) and is not cancelable (except where otherwise stated), and which uses the RTCDataChannelEvent interface with the channel attribute set to channel, MUST be created and dispatched at the given target.

        [ Constructor (DOMString type, RTCDataChannelEventInit eventInitDict)]
interface RTCDataChannelEvent : Event {
    readonly        attribute RTCDataChannel channel;
};

dictionary RTCDataChannelEventInit : EventInit {
             RTCDataChannel channel;
};

Example

function initiate(signaller) {
  // Prepare the ICE gatherer
  var gatherOptions = {
    gatherPolicy: "all",
    iceServers: [
      { urls: "stun:stun1.example.net" },
      { urls: "turn:turn.example.org", username: "user", credential: "myPassword",
        credentialType: "password" }
     ]
  };
  var iceGatherer = new RTCIceGatherer(gatherOptions);
  iceGatherer.onlocalcandidate = function(event) {
    mySignaller.mySendLocalCandidate(event.candidate);
  };
  
  // Start gathering
  iceGatherer.gather();

  // Create the DTLS certificate
  var certs;
  var keygenAlgorithm = { name: "ECDSA", namedCurve: "P-256" };
  RTCCertificate.generateCertificate(keygenAlgorithm).then(function(certificate){
    certs[0] = certificate;
  }, function(){
    trace('Certificate could not be created');
  });

  // Create ICE and DTLS transports
  var ice = new RTCIceTransport(iceGatherer);
  var dtls = new RTCDtlsTransport(ice, certs);

  // Prepare to handle remote ICE candidates
  mySignaller.onRemoteCandidate = function(remote) {
    ice.addRemoteCandidate(remote.candidate);
  };
  var sctp = new RTCSctpTransport(dtls);

  // Construct RTCDataChannelParameters dictionary
  var parameters = {
    label: "channel1", 
    ordered: true,
    protocol: "ship",
    negotiated: false
  };

  signaller.sendInitiate({
    // ... include ICE/DTLS info from other example.
    "sctpCapabilities": RTCSctpTransport.getCapabilities()
  }, function(remote) {
    sctp.start(remote.sctpCapabilities);
  // Create the data channel object
  var channel = new RTCDataChannel(sctp, parameters);
  channel.send("foo");
  });
}

function accept(signaller, remote) {
  var gatherOptions = {
    gatherPolicy: "all",
    iceServers: [
      { urls: "stun:stun1.example.net" },
      { urls: "turn:turn.example.org", username: "user", credential: "myPassword",
        credentialType: "password" }
     ]
  };
  var iceGatherer = new RTCIceGatherer(gatherOptions);
  iceGatherer.onlocalcandidate = function(event) {
    mySignaller.mySendLocalCandidate(event.candidate);
  };
  
  // Start gathering
  iceGatherer.gather();
  
  // Create the DTLS certificate
  var certs;
  var keygenAlgorithm = { name: "ECDSA", namedCurve: "P-256" };
  RTCCertificate.generateCertificate(keygenAlgorithm).then(function(certificate){
    certs[0] = certificate;
  }, function(){
    trace('Certificate could not be created');
  });

  // Create ICE and DTLS transports
  var ice = new RTCIceTransport(iceGatherer);
  var dtls = new RTCDtlsTransport(ice, certs);

  // Prepare to handle remote candidates
  mySignaller.onRemoteCandidate = function(remote) {
    ice.addRemoteCandidate(remote.candidate);
  };

  signaller.sendAccept({
    // ... include ICE/DTLS info from other examples.
    "sctpCapabilities": RTCSctpTransport.getCapabilities()
  });

  // Create the SctpTransport object and start it
  var sctp = new RTCSctpTransport(dtls);
  sctp.start(remote.sctpCapabilties);

  // Assume in-band signalling. We could also have sent
  // RTCDataChannelParameters in signalling and constructed
  // the data channel with negotiated: true.

  sctp.ondatachannel = function(channel) {
    channel.onmessage = function(message) {
      if (message === "foo") {
        channel.send("bar");
      }
    };
  };
}
                

RTCStatsReport Object

The getStats() method delivers a successful result in the form of a RTCStatsReport object. A RTCStatsReport object represents a map between strings, identifying the inspected objects (RTCStats.id), and their corresponding RTCStats objects.

An RTCStatsReport may be composed of several RTCStats objects, each reporting stats for one underlying object. One achieves the total for the object by summing over all stats of a certain type; for instance, if an RTCRtpSender object is sending RTP streams involving multiple SSRCs over the network, the RTCStatsReport may contain one RTCStats object per SSRC (which can be distinguished by the value of the ssrc stats attribute).

interface RTCStatsReport {
    getter RTCStats (DOMString id);
};

RTCStats Dictionary

An RTCStats dictionary represents the stats gathered by inspecting a specific object. The RTCStats dictionary is a base type that specifies as set of default attributes, such as timestamp and type. Specific stats are added by extending the RTCStats dictionary.

Note that while stats names are standardized, any given implementation may be using experimental values or values not yet known to the Web application. Thus, applications MUST be prepared to deal with unknown stats.

Statistics need to be synchronized with each other in order to yield reasonable values in computation; for instance, if "bytesSent" and "packetsSent" are both reported, they both need to be reported over the same interval, so that "average packet size" can be computed as "bytes / packets" - if the intervals are different, this will yield errors. Thus implementations MUST return synchronized values for all stats in a RTCStats object.

dictionary RTCStats {
             DOMHighResTimeStamp timestamp;
             RTCStatsType        type;
             DOMString           id;
};

RTCP matching rules

Since statistics are retrieved from objects within the ORTC API, and information within RTCP packets is used to maintain some of the statistics, the handling of RTCP packets is important to the operation of the statistics API.

RTCP packets arriving on an RTCDtlsTransport are decrypted and a notification is sent to all RTCRtpSender and RTCRtpReceiver objects utilizing that transport. RTCRtpSender and RTCRtpReceiver objects then examine the RTCP packets to determine the information relevant to their operation and the statistics maintained by them.

RTCP packets should be queued for 30 seconds and all RTCRtpSender and RTCRtpReceiver objects on the related RTCDTlsTransport have access to those packets until the packet is removed from the queue, should the RTCRtpSender or RTCRtpReceiver objects need to examine them.

Relevant SSRC fields within selected RTCP packets are summarized within [[!RFC3550]] Section 6.4.1 (Sender Report), Section 6.4.2 (Receiver Report), Section 6.5 (SDES), Section 6.6 (BYE), [[!RFC4585]] Section 6.1 (Feedback Messages), and [[!RFC3611]] Section 2 (Extended Reports).

Example

Consider the case where the user is experiencing bad sound and the application wants to determine if the cause of it is packet loss. The following example code might be used:

var mySender = new RTCRtpSender(myTrack);
var myPreviousReport = null;

// ... wait a bit
setTimeout(function() {
  mySender.getStats().then(function(report) {
    processStats(report);
    myPreviousReport = report;
  });
}, aBit);

function processStats(currentReport) {
  if (myPreviousReport === null) return;

  // currentReport + myPreviousReport are an RTCStatsReport interface
  // compare the elements from the current report with the baseline
  for (var i in currentReport) {
    var now = currentReport[i];
    if (now.type !== "outboundrtp") continue;

    // get the corresponding stats from the previous report
    base = myPreviousReport[now.id];

    // base + now will be of RTCRtpStreamStats dictionary type
    if (base) {
      remoteNow = currentReport[now.associateStatsId];
      remoteBase = myPreviousReport[base.associateStatsId];
      var packetsSent = now.packetsSent - base.packetsSent;
      var packetsReceived = remoteNow.packetsReceived - remoteBase.packetsReceived;
      // if fractionLost is > 0.3, we have probably found the culprit
      var fractionLost = (packetsSent - packetsReceived) / packetsSent;
    }
  }
}
                

Overview

An RTCIdentity instance enables authentication of a DTLS transport using a web-based identity provider (IdP). The idea is that the initiator acts as the Authenticating Party (AP) and obtains an identity assertion from the IdP which is then conveyed in signaling. The responder acts as the Relying Party (RP) and verifies the assertion.

getIdentityAssertion() sets the identity provider to be used for a given RTCIdentity object, and initiates the process of obtaining an identity assertion.

The interaction with the IdP is designed to decouple the browser from any particular identity provider, so that the browser need only know how to load the IdP's Javascript (which is deterministic from the IdP's identity), and the generic protocol for requesting and verifying assertions. The IdP provides whatever logic is necessary to bridge the generic protocol to the IdP's specific requirements. Thus, a single browser can support any number of identity protocols, including being forward compatible with IdPs which did not exist at the time the Identity Provider API was implemented. The generic protocol details are described in [[!RTCWEB-SECURITY-ARCH]]. This section specifies the procedures required to instantiate the IdP proxy, request identity assertions, and consume the results.

Operation

An RTCIdentity instance is constructed from an RTCDtlsTransport object.

Identity Provider Selection

In order to communicate with the IdP, the browser instantiates an isolated interpreted context, effectively an invisible IFRAME. The initial contents of the context are loaded from a URI derived from the IdP's domain name, as described in [[!RTCWEB-SECURITY-ARCH]].

For purposes of generating assertions, the IdP shall be chosen as follows:

1. If the getIdentityAssertion() method has been called, the IdP provided shall be used.
2. If the getIdentityAssertion() method has not been called, then the browser can use an IdP configured into the browser.

In order to verify assertions, the IdP domain name and protocol are taken from the domain and protocol fields of the identity assertion.

Instantiating an IdP Proxy

The browser creates an IdP proxy by loading an isolated, invisible IFRAME with HTML content from the IdP URI. The URI for the IdP is a well-known URI formed from the domain and protocol fields, as specified in [[!RTCWEB-SECURITY-ARCH]].

When an IdP proxy is required, the browser performs the following steps:

1. An invisible, sandboxed IFRAME is created within the browser context. The IFRAME sandbox attribute is set to "allow-forms allow-scripts allow-same-origin" to limit the capabilities available to the IdP. The browser MUST prevent the IdP proxy from navigating the browsing context to a different location. The browser MUST prevent the IdP proxy from interacting with the user (this includes, in particular, popup windows and user dialogs).
2. Once the IdP proxy is created, the browser creates a MessageChannel [[!webmessaging]] within the context of the IdP proxy and assigns one port from the channel to a variable named rtcwebIdentityPort on the window. This message channel forms the basis of communication between the browser and the IdP proxy. Since it is an essential security property of the web sandbox that a page is unable to insert objects into content from another origin, this ensures that the IdP proxy can trust that messages originating from window.rtcwebIdentityPort are from RTCIdentity and not some other page. This protection ensures that pages from other origins are unable to instantiate IdP proxies and obtain identity assertions.
3. The IdP proxy completes loading and informs the RTCIdentity object that it is ready by sending a "READY" message to the message channel port [[!RTCWEB-SECURITY-ARCH]]. Once this message is received by the RTCIdentity object, the IdP is considered ready to receive requests to generate or verify identity assertions.

[TODO: This is not sufficient unless we expect the IdP to protect this information. Otherwise, the identity information can be copied from a session with "good" properties to any other session with the same fingerprint information. Since we want to reuse credentials, that would be bad.] The identity mechanism MUST provide an indication to the remote side of whether it requires the stream contents to be protected. Implementations MUST have an user interface that indicates the different cases and identity for these.

Requesting Identity Assertions

The identity assertion request process involves the following steps:

1. The RTCIdentity instantiates an IdP proxy as described in Identity Provider Selection section and waits for the IdP to signal that it is ready.
2. The IdP sends a "SIGN" message to the IdP proxy. This message includes the material the RTCIdentity object desires to be bound to the user's identity.
3. If the user has been authenticated by the IdP, and the IdP is willing to generate an identity assertion, the IdP generates an identity assertion. This step depends entirely on the IdP. The methods by which an IdP authenticates users or generates assertions is not specified, though this could involve interacting with the IdP server or other servers.
4. The IdP proxy sends a response containing the identity assertion to the RTCIdentity object over the message channel.
5. The RTCIdentity object MAY store the identity assertion.

The format and contents of the messages that are exchanged are described in detail in [[!RTCWEB-SECURITY-ARCH]].

The IdP proxy can return an "ERROR" response. If an error is encountered, the getIdentityAssertion Promise MUST be rejected.

The browser SHOULD limit the time that it will allow for this process. This includes both the loading of the IdP proxy and the identity assertion generation. Failure to do so potentially causes the corresponding operation to take an indefinite amount of time. This timer can be cancelled when the IdP produces a response. The timer running to completion can be treated as equivalent to an error from the IdP.

Verifying Identity Assertions

Identity assertion validation happens when setIdentityAssertion() is invoked. The process runs asynchronously.

The identity assertion validation process involves the following steps:

1. The RTCIdentity instantiates an IdP proxy as described in Identity Provider Selection section and waits for the IdP to signal that it is ready.
2. The IdP sends a "VERIFY" message to the IdP proxy. This message includes the assertion which is to be verified.
3. The IdP proxy verifies the identity assertion (depending on the authentication protocol this could involve interacting with the IDP server).
4. Once the assertion is verified, the IdP proxy sends a response containing the verified assertion results to the RTCIdentity object over the message channel.
5. The RTCIdentity object validates that the fingerprint provided by the IdP in the validation response matches the certificate fingerprint that is, or will be, used for communications. This is done by waiting for the DTLS connection to be established and checking that the certificate fingerprint on the connection matches the one provided by the IdP.
6. The RTCIdentity validates that the domain portion of the identity matches the domain of the IdP as described in [[!RTCWEB-SECURITY-ARCH]].
7. The RTCIdentity stores the assertion in the peerIdentity, and returns an RTCIdentityAssertion object when the Promise from setIdentityAssertion is fulfilled. The assertion information to be displayed MUST contain the domain name of the IdP as provided in the assertion.
8. The browser MAY display identity information to a user in browser UI. Any user identity information that is displayed in this fashion MUST use a mechanism that cannot be spoofed by content.

The IdP might fail to validate the identity assertion by providing an "ERROR" response to the validation request. Validation can also fail due to the additional checks performed by the browser. In both cases, the process terminates and no identity information is exposed to the application or the user.

The browser MUST cause the Promise of setIdentityAssertion to be rejected if validation of an identity assertion fails for any reason.

The browser SHOULD limit the time that it will allow for this process. This includes both the loading of the IdP proxy and the identity assertion validation. Failure to do so potentially causes the corresponding operation to take an indefinite amount of time. This timer can be cancelled when the IdP produces a response. The timer running to completion can be treated as equivalent to an error from the IdP.

The format and contents of the messages that are exchanged are described in detail in [[!RTCWEB-SECURITY-ARCH]].

As defined in [[!WEBRTC10]] Section 10.4, the peerIdentity parameter to getUserMedia() enables media to be sent to a specifically identified peer, without the contents of mediastreams being accessible to applications. If a MediaStreamTrack with a peerIdentity constraint applied is attached to an RTCRtpSender, media is not sent unless the attached RTCDtlsTransport has validated the same peerIdentity as the MediaStreamTrack 's constraint.

RTCIdentity Interface

The Identity API is described below.

[ Constructor (RTCDtlsTransport transport)]
interface RTCIdentity {
    readonly        attribute RTCIdentityAssertion? peerIdentity;
    readonly        attribute RTCDtlsTransport      transport;
    Promise<DOMString> getIdentityAssertion (DOMString provider, optional DOMString protocol = "default", optional DOMString username);
    Promise<RTCIdentityAssertion> setIdentityAssertion (DOMString assertion);
};

dictionary RTCIdentityError

dictionary RTCIdentityError {
             DOMString  idp;
             DOMString? loginUrl;
             DOMString  protocol;
};

dictionary RTCIdentityAssertion

dictionary RTCIdentityAssertion {
             DOMString idp;
             DOMString name;
};

Example

The identity system is designed so that applications need not take any special action in order for users to generate and verify identity assertions; if a user has configured an IdP into their browser, then the browser will automatically request/generate assertions and the other side will automatically verify them and display the results. However, applications may wish to exercise tighter control over the identity system as shown by the following examples.

        // Set ICE gather options and construct the RTCIceGatherer object, assuming that
// we are using RTP/RTCP mux and A/V mux so that only one RTCIceTransport is needed.
// Include some helper functions
import {trace, errorHandler, mySendLocalCandidate, myIceGathererStateChange, 
  myIceTransportStateChange, myDtlsTransportStateChange} from 'helper';
var gatherOptions = {
  gatherPolicy: "all",
  iceServers: [
    { urls: "stun:stun1.example.net" },
    { urls: "turn:turn.example.org", username: "user", credential: "myPassword",
      credentialType: "password" }
   ]
};
var iceGatherer = new RTCIceGatherer(gatherOptions);
iceGatherer.onlocalcandidate = function(event) {
  mySendLocalCandidate(event.candidate);
};
// Start gathering
iceGatherer.gather();
// Construct the ICE transport
var ice = new RTCIceTransport(iceGatherer);
// Create the DTLS certificate
var certs;
var keygenAlgorithm = { name: "ECDSA", namedCurve: "P-256" };
RTCCertificate.generateCertificate(keygenAlgorithm).then(function(certificate){
  certs[0] = certificate;
}, function(){
  trace('Certificate could not be created');
});

// Create the RTCDtlsTransport object.
var dtls = new RTCDtlsTransport(ice, certs);
var identity = new RTCIdentity(dtls);
identity
  .getIdentityAssertion("example.com", "default", "alice@example.com")
  .then(signalAssertion(assertion), function(e) {
    trace("Could not obtain an Identity Assertion. idp: " + e.idp + " Protocol: " 
      + e.protocol + " loginUrl: " + e.loginUrl);
  });

function signalAssertion(assertion) {
  mySignalInitiate({
    "myAssertion": assertion,
    "ice": iceGatherer.getLocalParameters(),
    "dtls": dtls.getLocalParameters()
  }, function(response) {
    ice.start(iceGatherer, response.ice, RTCIceRole.controlling);
    // Call dtls.start() before setIdentityAssertion so the peer assertion can be validated.
    dtls.start(response.dtls);
    identity.setIdentityAssertion(response.myAssertion).then(function(peerAssertion) {
      trace("Peer identity assertion validated. idp: " + peerAssertion.idp + " name: " 
        + peerAssertion.name);
    }, function(e) {
      trace("Could not validate peer assertion. idp: " + e.idp + " Protocol: " + e.protocol);
    });
  });
}
                    

Overview

The RTCCertificate interface enables the certificates used by an RTCDtlsTransport to be provided in the constructor. This makes it possible to support forking, where the offerer will create multiple RTCDtlsTransport objects using the same local certificate and fingerprint.

RTCCertificate Interface

The Certificate API is described below.

interface RTCCertificate {
    readonly        attribute DOMTimeStamp       expires;
    readonly        attribute RTCDtlsFingerprint fingerprint;
    AlgorithmIdentifier            getAlgorithm ();
    static Promise<RTCCertificate> generateCertificate (AlgorithmIdentifier keygenAlgorithm);
};

Changes since 04 May 2016

1. Clarified support for simulcast reception and MRST SVC codecs, as noted in: Issue 175
2. Clarified handling of media prior to remote fingerprint verification, as noted in: Issue 200
3. Simplified text relating to event handlers, as noted in: Issue 309
4. Clarified meaning of RTCRtpCodecCapability.options, as noted in: Issue 412
5. Clarified exceptions and error conditions in the RTCDtmfSender, as noted in: Issue 446
6. Provided rtcp.ssrc advice for implementations, as noted in: Issue 462
7. Clarified effect of RTCRtpReceiver.track.stop(), as noted in: Issue 498
8. Summarized header extension parameters implementation experience, as noted in: Issue 502
9. Updated text relating to consent failures, as noted in: Issue 517
10. Clarified muxId usage, as noted in: Issue 528
11. Clarified meaning of name, as noted in: Issue 529
12. Updated ICE transition diagram, as noted in: Issue 535
13. Clarified "rtx" entries in RTCRtpCodecCapability and RTCRtpCodecParameters, as noted in: Issue 539
14. Updated text relating to "server could not be reached", as noted in: Issue 542
15. Corrected codec name usage, as noted in: Issue 544 and Issue 548
16. Clarified that codecPayloadType can be unset, as noted in: Issue 545
17. Converted figures to SVG format with figure/caption markup, as noted in: Issue 572

Changes since 01 March 2016

1. Added the gather() method, as noted in: Issue 165
2. Removed "public" from RTCIceGatherPolicy, as noted in: Issue 224
3. Removed the minQuality attribute, as noted in: Issue 351
4. Made send() and receive() asynchronous, as noted in: Issue 399, Issue 463, Issue 468 and Issue 469
5. Provided additional information on ICE candidate errors, as noted in: Issue 402
6. Added state attribute to RTCSctpTransport, as noted in: Issue 403
7. Provided an example of RTX/RED/FEC configuration, as noted in: Issue 404
8. Clarified payloadType uniqueness, as noted in: Issue 405
9. Updated the list of header extensions, as noted in: Issue 409
10. Added "goog-remb" to the list of feedback mechanisms, as noted in: Issue 410
11. Added kind argument to the RTCRtpReceiver constructor, as noted in: Issue 411
12. Clarified send() restrictions on kind, as noted in: Issue 414
13. Added getAlgorithm() method, as noted in: Issue 427
14. Changed RTCDataChannel protocol and label to USVString, as noted in: Issue 429
15. Clarified nullable attributes and methods returning empty lists, as noted in: Issue 433
16. Clarified support for the "direction" parameter, as noted in: Issue 442
17. Clarified the apt capability of the "red" codec, as noted in: Issue 444
18. Clarified usage of RTCRtpEncodingParameters attributes, as noted in: Issue 445
19. Clarified firing of onssrcconflict event, as noted in: Issue 448
20. Clarified that CNAME is only set on an RTCRtpSender, as noted in: Issue 450
21. Updated references, as noted in: Issue 457
22. Described behavior of send() and receive() with unset RTCRtpEncodingParameters, as noted in: Issue 461
23. Corrected dictionary initialization in the examples, noted in: Issue 464 and Issue 465
24. Corrected use of enums in the examples, noted in: Issue 466
25. Clarified handling of identity constraints, as noted in: Issue 467 and Issue 468
26. Clarified use of RTCRtpEncodingParameters, as noted in: Issue 470
27. Changed hostCandidate type, as noted in: Issue 474
28. Renamed state change event handlers to onstatechange, as noted in: Issue 475
29. Updated description of RTCIceGatherer closed state, as noted in: Issue 476
30. Updated description of RTCIceTransport object, as noted in: Issue 477
31. Updated description of relatedPort, as noted in: Issue 484
32. Updated description of RTCIceParameters, as noted in: Issue 485
33. Clarified exceptions in RTCDataChannel construction, as noted in: Issue 492
34. Provided a reference to error.message, as noted in: Issue 495
35. Clarified RTCRtpReceiver description, as noted in: Issue 496
36. Clarified default for clockRate attribute, as noted in: Issue 500
37. Removed use of "null if unset", as noted in: Issue 503
38. Updated RTCSctpTransport constructor, as noted in: Issue 504
39. Clarified behavior of getCapabilities(), as noted in: Issue 509
40. Addressed issues with RTCDataChannelParameters, as noted in: Issue 519

Changes since 20 November 2015

1. Clarified unhandledrtp event contents prior to calling receive(), as noted in: Issue 243
2. Added support for ptime, as noted in: Issue 160
3. Clarified behavior of send() when encodings is unset, as noted in: Issue 187
4. Fixed invalid import in examples, as noted in: Issue 250
5. Added support for Forward Error Correction (FEC), as noted in: Issue 253
6. Added support for "V" bit in RTCRtpContributingSource, as noted in: Issue 263
7. Added definition of maxBitrate, as noted in: Issue 267
8. Clarified definition of audioLevel, as noted in: Issue 377
9. Use USVString for datachannel.send(), as noted in: PR 387
10. Clarified requirements for DTMF A-D tone support, as noted in: Issue 391
11. Changed RTCRtpContributingSource from an interface to a dictionary, as noted in: Issue 289
12. Added support for maxFramerate encoding parameter, as noted in: Issue 412
13. Clarified behavior of getRemoteCertificates(), as noted in: Issue 378
14. Added support for remote peer ICE-lite implementation, as noted in: Issue 293
15. Clarified RTCDtlsTransportState definition, as noted in: Issue 294
16. Added explanation for unset iceServers, as noted in: Issue 302
17. Sync of certificate management API with WebRTC 1.0 changes, as noted in: Issue 303
18. Added "public" to RTCIceGatherPolicy, as noted in: Issue 305
19. Fixed problems in Examples 6, 7, 22 and 24, as noted in: Issue 310
20. Clarified value of the component attribute, as noted in: Issue 314
21. Clarified behavior with multiple local or remote certificates, as noted in: Issue 317
22. Added credentialType attribute to Examples, as noted in: Issue 323
23. Clarified alert handling in RTCDtlsTransportState, as noted in: Issue 327
24. Added example RTCIceTransportState transitions, as noted in: Issue 332
25. Clarified object garbage collection, as noted in: Issue 338
26. Fixed certificate example errors, as noted in: Issue 340
27. Clarified RTP matching rules, as noted in: Issue 344
28. Clarified value of rtcpTransport for BUNDLE and RTP/RTCP mux use, as noted in: Issue 349
29. Fixed markup issues in respec, as noted in: Issue 345
30. Addressed issues with document anchor links, as noted in: Issue 353
31. Clarified meaning of active for an RTCRtpReceiver, as noted in: Issue 355
32. Updated RTCDataChannel event table, as noted in: Issue 358
33. Clarified behavior of resolutionScale, as noted in: Issue 362
34. Updated RTP matching rules in Section 8.3 to support FEC/RTX/RED, as noted in: Issue 368
35. Clarified certificate checking behavior, as noted in: Issue 372
36. Clarified encodingId syntax, as noted in: Issue 375
37. Added url to RTCIceGathererEvent, as noted in: Issue 376
38. Added RangeError for resolutionScale <1.0, as noted in: Issue 379
39. Added clarification on level asymmetry, as noted in: Issue 382
40. Clarified DTMF tone requirements, as noted in: Issue 384
41. Clarified Generic NACK settings, as noted in: Issue 395

Changes since 05 October 2015

1. Added support for Opus capabilities and settings, as noted in: Issue 252
2. Added payloadType attribute to RTCRtpRtxParameters, as noted in: Issue 254
3. Clarified meaning of unset RTCRtpCodecCapability.clockRate, as noted in: Issue 255
4. Updated VP8 and H.264 capabilities and added VP8 and H.264 settings, as noted in: Issue 258
5. Added RTX codec parameters, as noted in: Issue 259
6. Added RED codec parameters, as noted in: Issue 260
7. Substituted degradationPreference for framerateBias and moved it to RTCRtpParameters, as noted in: Issue 262
8. Added RID support to the unhandledrtp event, as noted in: Issue 265
9. Updated references, as noted in: Issue 268
10. Changed codec parameter and option names to camelCase, as noted in: Issue 273
11. Added section of codec options, as noted in: Issue 274
12. Clarified meaning of codec capabilities and options, as noted in: Issue 275 and Issue 277
13. Clarified behavior in RTCRtpSender constructor and setTrack() when track.readyState is "ended", as noted in: Issue 278

Changes since 22 June 2015

1. Added support for the WebRTC 1.0 certificate management API, as noted in: Issue 195
2. Added certificate argument to the RTCDtlsTransport constructor, as noted in: Issue 218
3. Added the failed state to RTCDtlsTransportState, as noted in: Issue 219
4. Changed getNominatedCandidatePair to getSelectedCandidatePair, as noted in: Issue 220
5. Added support for WebRTC 1.0 RTCIceCredentialType, as noted in: Issue 222
6. Clarified behavior of createAssociatedGatherer(), as noted in: Issue 223
7. Changed spelling from "iceservers" to "iceServers" for consistency with WebRTC 1.0, as noted in: Issue 225
8. Added support for SCTP port numbers, as noted in: Issue 227
9. Changed "outbound-rtp" to "outboundrtp" within the Statistics API, as noted in: Issue 229
10. Changed maxPacketLifetime and maxRetransmits from unsigned short to unsigned long, as noted in: Issue 231
11. Clarified DataChannel negotiation, as noted in: Issue 233
12. Added getContributingSources() method, as noted in: Issue 236
13. Fixes to Examples 5 and 6, as noted in: Issue 237 and Issue 239
14. Clarified behavior of RTCDataChannel.send(), as noted in: Issue 240
15. Fixed typos in Example 11, as noted in: Issue 241 and Issue 248
16. Added text relating to RTCDataChannel exceptions and errors, as noted in: Issue 242
17. Reconciliation of RTCRtpEncodingParameters dictionary with WebRTC 1.0, as noted in: Issue 249

Changes since 7 May 2015

1. Addressed Philipp Hancke's review comments, as noted in: Issue 198
2. Added the failed state to RTCIceTransportState, as noted in: Issue 199
3. Added text relating to handling of incoming media packets prior to remote fingerprint verification, as noted in: Issue 200
4. Added a complete attribute to the RTCIceCandidateComplete dictionary, as noted in: Issue 207
5. Updated the description of RTCIceGatherer.close() and the closed state, as noted in: Issue 208
6. Updated Statistics API error handling to reflect proposed changes to the WebRTC 1.0 API, as noted in: Issue 214
7. Updated Section 10 (RTCDtmfSender) to reflect changes in the WebRTC 1.0 API, as noted in: Issue 215
8. Clarified state transitions due to consent failure, as noted in: Issue 216
9. Added a reference to [[FEC]], as noted in: Issue 217

Changes since 25 March 2015

1. sender.setTrack() updated to return a Promise, as noted in: Issue 148
2. Added RTCIceGatherer as an optional argument to the RTCIceTransport constructor, as noted in: Issue 174
3. Clarified handling of contradictory RTP/RTCP multiplexing settings, as noted in: Issue 185
4. Clarified error handling relating to RTCIceTransport, RTCDtlsTransport and RTCIceGatherer objects in the closed state, as noted in: Issue 186
5. Added component attribute and createAssociatedGatherer() method to the RTCIceGatherer object, as noted in: Issue 188
6. Added close() method to the RTCIceGatherer object as noted in: Issue 189
7. Clarified behavior of TCP candidate types, as noted in: Issue 190
8. Clarified behavior of iceGatherer.onlocalcandidate, as noted in: Issue 191
9. Updated terminology in Section 1.1 as noted in: Issue 193
10. Updated RTCDtlsTransportState definitions, as noted in: Issue 194
11. Updated RTCIceTransportState definitions, as noted in: Issue 197

Changes since 22 January 2015

1. Updated Section 8.3 on RTP matching rules, as noted in: Issue 48
2. Further updates to the Statistics API, reflecting: Issue 85
3. Added support for maxptime, as noted in: Issue 160
4. Revised the text relating to RTCDtlsTransport.start(), as noted in: Issue 168
5. Clarified pre-requisites for insertDTMF(), based on: Issue 178
6. Added Section 13.4 and updated Section 9.5.1 to clarify aspects of RTCP sending and receiving, based on: Issue 180
7. Fixed miscellaneous typos, as noted in: Issue 183
8. Added informative reference to [[RFC3264]] Section 5.1, as noted in: Issue 184

Changes since 14 October 2014

1. Update to the Statistics API, reflecting: Issue 85
2. Update on 'automatic' use of scalable video coding, as noted in: Issue 156
3. Update to the H.264 parameters, as noted in: Issue 158
4. Update to the 'Big Picture', as noted in: Issue 159
5. Changed 'RTCIceTransportEvent' to 'RTCIceGathererEvent' as noted in: Issue 161
6. Update to RTCRtpUnhandledEvent as noted in: Issue 163
7. Added support for RTCIceGatherer.state as noted in: Issue 164
8. Revised the text relating to RTCIceTransport.start() as noted in: Issue 166
9. Added text relating to DTLS interoperability with WebRTC 1.0, as noted in: Issue 167
10. Added a reference to the ICE consent specification, as noted in: Issue 171

Changes since 20 August 2014

1. Address questions about RTCDtlsTransport.start(), as noted in: Issue 146
2. Address questions about RTCRtpCodecCapability.preferredPayloadType, as noted in: Issue 147
3. Address questions about RTCRtpSender.setTrack() error handling, as noted in: Issue 148
4. Address 'automatic' use of scalable video coding (in RTCRtpReceiver.receive()) as noted in: Issue 149
5. Renamed RTCIceListener to RTCIceGatherer as noted in: Issue 150
6. Added text on multiplexing of STUN, TURN, DTLS and RTP/RTCP, as noted in: Issue 151
7. Address issue with queueing of candidate events within the RTCIceGatherer, as noted in: Issue 152
8. Clarify behavior of RTCRtpReceiver.getCapabilities(kind), as noted in: Issue 153

Changes since 16 July 2014

1. Clarification of the ICE restart issue, as noted in : Issue 93
2. Clarified onerror usage in sender and receiver objects, as noted in: Issue 95
3. Clarified SST-MS capability issue noted in: Issue 108
4. Clarification of send() and receive() usage as noted in: Issue 119
5. Changed ICE state diagram as noted in: Issue 122
6. Removed getParameters methods and changed send() method as noted in: Issue 136
7. Changed definition of framerateScale and resolutionScale as noted in: Issue 137
8. Substituted muxId for receiverId as noted in: Issue 138 and Issue 140
9. Clarified the setting of track.kind as described in: Issue 141
10. Added SSRC conflict event to the RTCRtpSender, as described in: Issue 143
11. Addressed the "end of candidates" issues noted in: Issue 142 and Issue 144

Changes since 16 June 2014

1. Added section on WebRTC 1.0 compatibility issues, responding to Issue 66
2. Added Identity support, as described in Issue 78
3. Reworked getStats() method, as described in Issue 85
4. Removed ICE restart method described in Issue 93
5. Addressed CNAME and synchronization context issues described in Issue 94
6. Fixed WebIDL issues noted in Issue 97
7. Addressed NITs described in Issue 99
8. DTLS transport issues fixed as described in Issue 100
9. ICE transport issues fixed as described in Issue 101
10. ICE transport controller fixes made as described in Issue 102
11. Sender and Receiver object fixes made as described in Issue 103
12. Fixed RTCRtpEncodingParameters default issues described in Issue 104
13. Fixed 'Big Picture' issues descibed in Issue 105
14. Fixed RTCRtpParameters default issues described in Issue 106
15. Added a multi-stream capability, as noted in Issue 108
16. Removed quality scalability capabilities and parameters, as described in Issue 109
17. Added scalability examples as requested in Issue 110
18. Addressed WebRTC 1.0 Data Channel compatibility issue described in Issue 111
19. Removed header extensions from RTCRtpCodecParameters as described in Issue 113
20. Addressed RTP/RTCP non-mux issues with IdP as described in Issue 114
21. Added getParameter methods to RTCRtpSender and RTCRtpReceiver objects, as described in Issue 116
22. Added layering diagrams as requested in Issue 117
23. Added a typedef for payloadtype, as described in Issue 118
24. Moved onerror from the RTCIceTransport object to the RTCIceListener object as described in Issue 121
25. Added explanation of Voice Activity Detection (VAD), responding to Issue 129
26. Clarified the meaning of maxTemporalLayers and maxSpatialLayers, as noted in Issue 130
27. Added [[!RFC6051]] to the list of header extensions and removed RFC 5450, as noted in Issue 131
28. Addressed ICE terminology issues, as described in Issue 132
29. Separated references into Normative and Informative, as noted in Issue 133

Changes since 14 May 2014

1. Added support for non-multiplexed RTP/RTCP and ICE freezing, as described in Issue 57
2. Added support for getRemoteCertificates(), as described in Issue 67
3. Removed filterParameters() and createParameters() methods, as described in Issue 80
4. Partially addressed capabilities issues, as described in Issue 84
5. Addressed WebIDL type issues described in Issue 88
6. Addressed Overview section issues described in Issue 91
7. Addressed readonly attribute issues described in Issue 92
8. Added ICE restart method to address the issue described in Issue 93
9. Added onerror eventhandler to sender and receiver objects as described in Issue 95