WebRTC 1.0: Real-time Communication Between Browsers

2. Conformance

As well as sections marked as non-normative, all authoring guidelines, diagrams, examples, and notes in this specification are non-normative. Everything else in this specification is normative.

The key words must, must not, required, should, should not, recommended, may, and optional in this specification are to be interpreted as described in [RFC2119].

This specification defines conformance criteria that apply to a single product: the user agent that implements the interfaces that it contains.

Implementations that use ECMAScript to implement the APIs defined in this specification must implement them in a manner consistent with the ECMAScript Bindings defined in the Web IDL specification [WEBIDL], as this specification uses that specification and terminology.

3. Terminology

The EventHandler interface represents a callback used for event handlers as defined in [HTML5].

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

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

4. Peer-to-peer connections

4.1 Introduction

An RTCPeerConnection allows two users to communicate directly, browser to browser. Communications are coordinated via a signaling channel which is provided by unspecified means, but generally by a script in the page via the server, e.g. using XMLHttpRequest.

4.2 Configuration

4.2.1 RTCConfiguration Type

dictionary RTCConfiguration {
    RTCIceServer[] iceServers;
};

4.2.1.1 Dictionary `RTCConfiguration` Members

iceServers of type array of RTCIceServer: An array containing STUN and TURN servers available to be used by ICE.

4.2.2 RTCIceServer Type

dictionary RTCIceServer {
    DOMString  url;
    DOMString? credential;
};

4.2.2.1 Dictionary `RTCIceServer` Members

credential of type DOMString, nullable: If the url element of the internal array is a TURN URI, then this is the credential to use with that TURN server.
url of type DOMString: A STUN or TURN URI as defined in [STUN-URI] and [TURN-URI].

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 array of RTCIceServer objects is:

[ { url:"stun:stun.example.net"] } , { url:"turn:user@turn.example.org", credential:"myPassword"} ]

4.3 RTCPeerConnection Interface

The general operation of the RTCPeerConnection is described in [RTCWEB-JSEP].

4.3.1 Operation

Calling new RTCPeerConnection(configuration ) creates an RTCPeerConnection object.

The configuration has the information to find and access the [STUN] and [TURN] servers. There may be multiple servers of each type and any TURN server also acts as a STUN server.

An RTCPeerConnection object has an associated ICE agent, [ICE] RTCPeerConnection readiness state, and ICE state. These are initialized when the object is created.

When the RTCPeerConnection() constructor is invoked, the user agent must run the following steps. This algorithm has a synchronous section (which is triggered as part of the event loop algorithm).

Create an ICE Agent and let connection's RTCPeerConnection ICE Agent be that ICE Agent and provide it the STUN and TURN servers from the configuration array. The ICE Agent will proceed with gathering as soon as the IceTransports constraint is not set to "none". At this point the ICE Agent does not know how many ICE components it needs (and hence the number of candidates to gather), but it can make a reasonable assumption. As the RTCPeerConnection object gets more information, the ICE Agent can adjust the number of components.
Set connection's RTCPeerConnection readiness state to new.
Set connection's RTCPeerConnection ice state to new.
Initialize an internal variable to represent a queue of operations with an empty set.
Let connection's localStreams attribute be an empty read-only MediaStream array.
Let connection's remoteStreams attribute be an empty read-only MediaStream array.
Return connection, but continue these steps asynchronously.
Await a stable state. The synchronous section consists of the remaining steps of this algorithm.

Once the RTCPeerConnection object has been initialized, for every call to createOffer, setLocalDescription, createAnswer and setRemoteDescription; execute the following steps:

Append an object representing the current call being handled (i.e. function name and corresponding arguments) to the operations array.
If the length of the operations array is exactly 1, execute the function from the front of the queue asynchronously.
When the ascynchronous operation completes (either successfully or with an error), remove the corresponding object from the operations array. After removal, if the array is non-empty, execute the first object queued asynchronously and repeat this step on completion.

The general idea is to have only one among createOffer, setLocalDescription, createAnswer and setRemoteDescription executing at any given time. If subsequent calls are made while one of them is still executing, they are added to a queue and processed when the previous operation is fully completed. It is valid, and expected, for normal error handling procedures to be applied.

Additionally, during the lifetime of the RTCPeerConnection object, the following procedures are followed when an ICE event occurs:

If iceState is "new" and the IceTransports constraint is not set to "none", it must queue a task to start gathering ICE addresses and set the iceState to "gathering".
If the ICE Agent has found one or more candidate pairs for each MediaStreamTrack that forms a valid connection, the ICE state is changed to "connected".
When the ICE Agent finishes checking all candidate pairs, if at least one connection has been found for each MediaStreamTrack, the iceState is changed to "completed"; else the iceState is changed to "failed".
If the iceState is "connected" or "completed" and both the local and remote session descriptions are set, the RTCPeerConnection state is set to "active".
If the iceState is "failed", a task is queued to call the close method.

Issue 1
ISSUE:: CJ - this seems wrong to me.

User agents negotiate the codec resolution, bitrate, and other media parameters. It is recommended that user agents initially negotiate for the maximum resolution of a video stream. For streams that are then rendered (using a video element), it is recommended that user agents renegotiate for a resolution that matches the rendered display size.

The word "components" in this context refers to an RTP media flow and does not have anything to do with how [ICE] uses the term "component".

When a user agent has reached the point where a MediaStream can be created to represent incoming components, the user agent must run the following steps:

Let connection be the RTCPeerConnection expecting this media.
Create a MediaStream object stream, to represent the incoming media stream.
Run the algorithm to represent an incoming component with a track for each incoming component.

Note
The creation of new incoming MediaStreams may be triggered either by SDP negotiation or by the receipt of media on a given flow.
Queue a task to run the following substeps:
1. If the connection's RTCPeerConnection readiness state is closed, abort these steps.
2. Add stream to the end of connection's remoteStreams array.
3. Fire a stream event named addstream with stream at the connection object.

When a user agent has negotiated media for a component that belongs to a media stream that is already represented by an existing MediaStream object, the user agent must associate the component with that MediaStream object.

When an RTCPeerConnection finds that a stream from the remote peer has been removed , the user agent must follow these steps:

Let connection be the RTCPeerConnection associated with the stream being removed.
Let stream be the MediaStream object that represents the media stream being removed, if any. If there isn't one, then abort these steps.
By definition, stream is now finished.

Note
A task is thus queued to update stream and fire an event.
Queue a task to run the following substeps:
1. If the connection's RTCPeerConnection readiness state is closed, abort these steps.
2. Remove stream from connection's remoteStreams array.
3. Fire a stream event named removestream with stream at the connection object.

The task source for the tasks listed in this section is the networking task source.

If something in the browser changes that causes the RTCPeerConnection object to need to initiate a new session description negotiation, a negotiationneeded event is fired at the RTCPeerConnection object.

In particular, if an RTCPeerConnection object is consuming a MediaStream on which a track is added, by, e.g., the addTrack() method being invoked, the RTCPeerConnection object must fire the "negotiationneeded" event. Removal of media components must also trigger "negotiationneeded".

To prevent network sniffing from allowing a fourth party to establish a connection to a peer using the information sent out-of-band to the other peer and thus spoofing the client, the configuration information should always be transmitted using an encrypted connection.

4.3.2 Interface Definition

typedef MediaStream[] MediaStreamArray;

Throughout this specification, the identifier MediaStreamArray is used to refer to the array of MediaStream type.

[Constructor (RTCConfiguration configuration, optional MediaConstraints constraints)]
interface RTCPeerConnection : EventTarget  {
    void           createOffer (RTCSessionDescriptionCallback successCallback, RTCPeerConnectionErrorCallback failureCallback, optional MediaConstraints constraints);
    void           createAnswer (RTCSessionDescriptionCallback successCallback, RTCPeerConnectionErrorCallback failureCallback, optional MediaConstraints? constraints = null);
    void           setLocalDescription (RTCSessionDescription description, RTCVoidCallback successCallback, RTCPeerConnectionErrorCallback failureCallback);
    readonly attribute RTCSessionDescription localDescription;
    void           setRemoteDescription (RTCSessionDescription description, RTCVoidCallback successCallback, RTCPeerConnectionErrorCallback failureCallback);
    readonly attribute RTCSessionDescription remoteDescription;
    readonly attribute RTCPeerState          readyState;
    void           updateIce (optional RTCConfiguration? configuration = null, optional MediaConstraints? constraints = null);
    void           addIceCandidate (RTCIceCandidate candidate);
    readonly attribute RTCGatheringState     iceGatheringState;
    readonly attribute RTCIceState           iceState;
    readonly attribute MediaStreamArray      localStreams;
    readonly attribute MediaStreamArray      remoteStreams;
    RTCDataChannel createDataChannel ([TreatNullAs=EmptyString] DOMString label, optional RTCDataChannelInit dataChannelDict);
             attribute EventHandler          ondatachannel;
    void           addStream (MediaStream stream, optional MediaConstraints constraints);
    void           removeStream (MediaStream stream);
    void           setIdentityProvider (DOMString provider, optional DOMString protocol, optional DOMString username);
    void           getIdentityAssertion ();
    readonly attribute RTCIdentityAssertion? peerIdentity;
    void           getStats (MediaStreamTrack? selector, RTCStatsCallback successCallback, RTCPeerConnectionErrorCallback failureCallback);
    void           close ();
             attribute EventHandler          onnegotiationneeded;
             attribute EventHandler          onicecandidate;
             attribute EventHandler          onopen;
             attribute EventHandler          onstatechange;
             attribute EventHandler          onaddstream;
             attribute EventHandler          onremovestream;
             attribute EventHandler          ongatheringchange;
             attribute EventHandler          onicechange;
             attribute EventHandler          onidentityresult;
};

4.3.2.1 Attributes

iceGatheringState of type RTCGatheringState, readonly

The iceGatheringState attribute must return the gathering state of the RTCPeerConnection ICE Agent connection state.

iceState of type RTCIceState, readonly

The iceState attribute must return the state of the RTCPeerConnection ICE Agent ICE state.

localDescription of type RTCSessionDescription, readonly

The localDescription attribute must return the RTCSessionDescription that was most recently passed to setLocalDescription(), plus any local candidates that have been generated by the ICE Agent since then.

A null object will be returned if the local description has not yet been set.

localStreams of type MediaStreamArray, readonly

Returns a live array containing the local streams (those that were added with addStream() ).

onaddstream of type EventHandler

This event handler, of event handler event type addstream, must be fired by all objects implementing the RTCPeerConnection interface. It is called any time a MediaStream is added by the remote peer. This will be fired only as a result of setRemoteDescription. Onnaddstream happens as early as possible after the setRemoteDescription. This callback does not wait for a given media stream to be accepted or rejected via SDP negotiation.

ondatachannel of type EventHandler

This event handler, of type datachannel , must be supported by all objects implementing the RTCPeerConnection interface.

ongatheringchange of type EventHandler

This event handler, of event handler event type icechange, must be fired by all objects implementing the RTCPeerConnection interface. It is called any time the iceGatheringState changes. NOTE: Is this really of type icechange??

onicecandidate of type EventHandler

This event handler, of event handler event type icecandidate, must be supported by all objects implementing the RTCPeerConnection interface. It is called any time there is a new ICE candidate added to a previous offer or answer.

onicechange of type EventHandler

This event handler, of event handler event type icechange, must be fired by all objects implementing the RTCPeerConnection interface. It is called any time the iceState changes.

onidentityresult of type EventHandler

This event handler, of event handler event type identityresult, must be fired by all objects implementing the RTCPeerConnection interface. It is called any time an identity verification succeeds or fails.

onnegotiationneeded of type EventHandler

This event handler, of event handler event type negotiationneeded , must be supported by all objects implementing the RTCPeerConnection interface.

onopen of type EventHandler

This event handler, of event handler event type open, must be supported by all objects implementing the RTCPeerConnection interface.

Note

Open issue if the "onopen" is needed or not.

onremovestream of type EventHandler

This event handler, of event handler event type removestream, must be fired by all objects implementing the RTCPeerConnection interface. It is called any time a MediaStream is removed by the remote peer. This will be fired only as a result of setRemoteDescription.

onstatechange of type EventHandler

This event handler, of event handler event type statechange, must be supported by all objects implementing the RTCPeerConnection interface. It is called any time the readyState changes, i.e., from a call to setLocalDescription, a call to setRemoteDescription, or code. It does not fire for the initial state change into new.

peerIdentity of type RTCIdentityAssertion, readonly, nullable

Contains the peer identity assertion information if an identity assertion was provided and verified.

readyState of type RTCPeerState, readonly

The readyState attribute must return the RTCPeerConnection object's RTCPeerConnection readiness state.

remoteDescription of type RTCSessionDescription, readonly

The remoteDescription attribute must return the RTCSessionDescription that was most recently passed to setRemoteDescription(), plus any remote candidates that have been supplied via addIceCandidate() since then.

A null object will be returned if the remote description has not yet been set.

remoteStreams of type MediaStreamArray, readonly

Returns a live array containing the remote streams (those that were added by the remote side).

This array is updated when addstream and removestream events are fired.

4.3.2.2 Methods

addIceCandidate

The addIceCandidate() method provides a remote candidate to the ICE Agent. In addition to being added to the remote description, connectivity checks will be sent to the new candidates as long as the "IceTransports" constraint is not set to "none". This call will result in a change to the state of the ICE Agent, and may result in a change to media state if it results in different connectivity being established.

An exception with an RTCError object of type INVALID_CANDIDATE_TYPE is thrown if candidate parameter is malformed.

Parameter	Type	Nullable	Optional	Description
candidate	`RTCIceCandidate`	✘	✘

Return type: void

addStream

Adds a new stream to the RTCPeerConnection.

When the addStream() method is invoked, the user agent must run the following steps:

If the RTCPeerConnection object's RTCPeerConnection readiness state is closed, abort these steps, and throw an exception with an RTCError object of type INVALID_STATE.
If stream is already in the RTCPeerConnection object's localStreams object, then abort these steps.
Add stream to the end of the RTCPeerConnection object's localStreams object.
Parse the constraints provided by the application and apply them to the MediaStream, if possible. If the constraints could not be successfully applied, provide an RTCError object of type INCOMPATIBLE_CONSTRAINTS to the failure callback.
Fire a negotiationneeded event.

Issue 3
ISSUE: Should this fire if the RTCPeerConnection is in "new"?

Parameter	Type	Nullable	Optional	Description
stream	`MediaStream`	✘	✘
constraints	`MediaConstraints`	✘	✔

Return type: void

close

When the close() method is invoked, the user agent must run the following steps:

If the RTCPeerConnection object's RTCPeerConnection readiness state is closed, throw an INVALID_STATE exception.
Destroy the RTCPeerConnection ICE Agent, abruptly ending any active ICE processing and any active streaming, and releasing any relevant resources (e.g. TURN permissions).
Set the object's RTCPeerConnection readiness state to closed.

No parameters.

Return type: void

createAnswer

The createAnswer method generates an [SDP] answer with the supported configuration for the session that is compatible with the parameters in the remote configuration. Like createOffer, the returned blob contains descriptions of the local MediaStreams attached to this RTCPeerConnection, the codec/RTP/RTCP options negotiated for this session, and any candidates that have been gathered by the ICE Agent. The constraints parameter may be supplied to provide additional control over the generated answer.

As an answer, the generated SDP will contain a specific configuration that, along with the corresponding offer, specifies how the media plane should be established. The generation of the SDP must follow the appropriate process for generating an answer.

Session descriptions generated by createAnswer must be immediately usable by setLocalDescription without generating an error if setLocalDescription is called from the successCallback function. Like createOffer, the returned description should reflect the current state of the system. The session descriptions must remain usable by setLocalDescription without causing an error until at least the end of the successCallback function. Calling this method is needed to get the ICE user name fragment and password.

An answer can be marked as provisional, as described in [RTCWEB-JSEP], by setting the type to "pranswer".

If the RTCPeerConnection is configured to generate Identity assertions, then the session description shall contain an appropriate assertion.

If this RTCPeerConnection object is closed before the SDP generation process completes, the USER agent must suppress the result and not call any of the result callbacks.

If the SDP generation process completed successfully, the user agent must queue a task to invoke successCallback with a newly created RTCSessionDescription object, representing the generated answer, as its argument.

If the SDP generation process failed for any reason, the user agent must queue a task to invoke errorCallback with an RTCError object of type TBD as its argument.

An exception with an RTCError object of type INVALID_CONSTRAINTS_TYPE is thrown if the constraints parameter is malformed, and an RTCError object of type INCOMPATIBLE_CONSTRAINTS is provided to the failure callback if the constraints could not be successfully applied.

Parameter	Type	Nullable	Optional
successCallback	`RTCSessionDescriptionCallback`	✘	✘
failureCallback	`RTCPeerConnectionErrorCallback`	✘	✘
constraints	`MediaConstraints = null`	✔	✔

Return type: void

createDataChannel

Creates a new RTCDataChannel object with the given label. The RTCDataChannelInit dictionary can be used to configure properties of the underlying channel such as data reliability. A corresponding RTCDataChannel object is dispatched at the other peer if the channel setup was successful.

When the createDataChannel() method is invoked, the user agent must run the following steps.

If the RTCPeerConnection object’s RTCPeerConnection readiness state is closed, throw an INVALID_STATE exception.
Let channel be a newly created RTCDataChannel object.
Initialize channel's label attribute to the value of the first argument.
Initialize channel's reliable attribute to true.
If the second argument is present and it contains a reliable dictionary member, then set channel's reliable attribute to the dictionary member value.
Return channel and continue these steps in the background.
Create channel's associated underlying data transport.

Parameter	Type	Nullable	Optional	Description
label	`DOMString`	✘	✘
dataChannelDict	`RTCDataChannelInit`	✘	✔

Return type: RTCDataChannel

createOffer

The createOffer method generates a blob of SDP that contains an RFC 3264 offer with the supported configurations for the session, including descriptions of the local MediaStreams attached to this RTCPeerConnection, the codec/RTP/RTCP options supported by this implementation, and any candidates that have been gathered by the ICE Agent. The constraints parameter may be supplied to provide additional control over the offer generated. More information about constraints can be found in [RTCWEB-CONSTRAINTS].

As an offer, the generated SDP will contain the full set of capabilities supported by the session (as opposed to an answer, which will include only a specific negotiated subset to use); for each SDP line, the generation of the SDP must follow the appropriate process for generating an offer. In the event createOffer is called after the session is established, createOffer will generate an offer that is compatible with the current session, incorporating any changes that have been made to the session since the last complete offer-answer exchange, such as addition or removal of streams. If no changes have been made, the offer will include the capabilities of the current local description as well as any additional capabilities that could be negotiated in an updated offer.

Session descriptions generated by createOffer must be immediately usable by setLocalDescription without causing an error as long as setLocalDiscription is called within the successCallback function. If a system has limited resources (e.g. a finite number of decoders), createOffer needs to return an offer that reflects the current state of the system, so that setLocalDescription will succeed when it attempts to acquire those resources. The session descriptions must remain usable by setLocalDescription without causing an error until at least end of the successCallback function. Calling this method is needed to get the ICE user name fragment and password.

If the RTCPeerConnection is configured to generate Identity assertions, then the session description shall contain an appropriate assertion.

If this RTCPeerConnection object is closed before the SDP generation process completes, the USER agent must suppress the result and not call any of the result callbacks.

If the SDP generation process failed for any reason, the user agent must queue a task to invoke errorCallback with an RTCError object of type TBD as its argument.

To Do: Discuss privacy aspects of this from a fingerprinting point of view - it's probably around as bad as access to a canvas :-)

Parameter	Type	Nullable	Optional
successCallback	`RTCSessionDescriptionCallback`	✘	✘
failureCallback	`RTCPeerConnectionErrorCallback`	✘	✘
constraints	`MediaConstraints`	✘	✔

Return type: void

getIdentityAssertion

Initiates the process of obtaining an identity assertion. Applications need not make this call. It is merely intended to allow them to start the process of obtaining identity assertions before a call is initiated. If an identity is needed, either because the browser has been configured with a default identity provider or because the setIdentityProvider() method was called, then an identity will be automatically requested when an offer or answer is created.

Queue a task to run the following substeps.

If the connection's RTCPeerConnection readiness state is closed, abort these steps.
Instantiate a new IdP proxy and request an identity assertion.

No parameters.

Return type: void

getStats

When the getStats() method is invoked, the user agent must queue a task to run the following substeps:

If the RTCPeerConnection object's RTCPeerConnection readiness state is closed, throw an INVALID_STATE exception.
Gather the stats indicated by the selector. If the selector is invalid, call the failureCallback.
Call the successCallback, supplying the relevant statistics object.

The "selector" may be a MediaStreamTrack that is a member of a MediaStream on the incoming or outgoing streams. The callback reports on all relevant statistics for that selector. If the selector is blank or missing, stats for the whole RTCPeerConnection are reported. TODO: Evaluate the need for other selectors than MediaStreamTrack.

The returned structure contains a list of RTCStatsElements, each reporting stats for one object that the implementation thinks is relevant for the selector. One achieves the total for the selector by summing over all the elements; for instance, if a MediaStreamTrack is carried by multiple SSRCs over the network, the getStats() function may return one RTCStatsElement per SSRC (which can be distinguished by the value of the “ssrc” stats attribute).

An RTCPeerConnection must return consistent stats for each element in the array, adding new elements to the end as needed; this is needed so that an application can simply correlate a value read at one moment to a value read at a later moment.

Parameter	Type	Nullable	Optional
selector	`MediaStreamTrack`	✔	✘
successCallback	`RTCStatsCallback`	✘	✘
failureCallback	`RTCPeerConnectionErrorCallback`	✘	✘

Return type: void

removeStream

Removes the given stream from the localStream array in the RTCPeerConnection and fires the negotiationneeded event.

When the other peer stops sending a stream in this manner, a removestream event is fired at the RTCPeerConnection object.

When the removeStream() method is invoked, the user agent must run the following steps:

If the RTCPeerConnection object's RTCPeerConnection readiness state is closed, throw an INVALID_STATE exception.
If stream is not in the RTCPeerConnection object's localStreams object, then abort these steps.
Remove stream from the RTCPeerConnection object's localStreams object.
Fire a negotiationneeded event.

Parameter	Type	Nullable	Optional	Description
stream	`MediaStream`	✘	✘

Return type: void

setIdentityProvider

Sets the identity provider to be used for a given PeerConnection object. Applications need not make this call; if the browser is already configured for an IdP, then that configured IdP will be used to get an assertion.

When the setIdentityProvider() method is invoked, the user agent must run the following steps:

Set the current identity values to the triplet (provider, protocol, username).
If the RTCPeerConnection object's RTCPeerConnection readiness state is active, and any of the identity settings have changed, queue a task to run the following substeps:
1. If the connection's RTCPeerConnection readiness state is closed, abort these steps, and throw an exception with an RTCError object of type INVALID_STATE.
2. Instantiate a new IdP proxy and request an identity assertion.
3. If/when the assertion is obtained, fire a negotiationneeded event.

Parameter	Type	Nullable	Optional
provider	`DOMString`	✘	✘
protocol	`DOMString`	✘	✔
username	`DOMString`	✘	✔

Return type: void

setLocalDescription

The setLocalDescription() method instructs the RTCPeerConnection to apply the supplied RTCSessionDescription as the local description.

This API changes the local media state. In order to successfully handle scenarios where the application wants to offer to change from one media format to a different, incompatible format, the RTCPeerConnection must be able to simultaneously support use of both the old and new local descriptions (e.g. support codecs that exist in both descriptions) until a final answer is received, at which point the RTCPeerConnection can fully adopt the new local description, or roll back to the old description if the remote side denied the change.

Issue 2

ISSUE: how to indicate to roll back?

To Do: specify what parts of the SDP can be changed between the createOffer and setLocalDescription

Changes to the state of media transmission will occur when a final answer is successfully applied. localDescription must return the previous description until the new description is successfully applied.

The failureCallback will be called if the RTCSessionDescription is a valid description but cannot be applied at the media layer, e.g., if there are insufficient resources to apply the SDP. The user agent must roll back as necessary if the new description was partially applied when the failure occurred.

An RTCError object of type INVALID_SESSION_DESCRIPTION is provided to the failure callback if the SDP content is invalid.

Parameter	Type	Nullable	Optional
description	`RTCSessionDescription`	✘	✘
successCallback	`RTCVoidCallback`	✘	✘
failureCallback	`RTCPeerConnectionErrorCallback`	✘	✘

Return type: void

setRemoteDescription

The setRemoteDescription() method instructs the RTCPeerConnection to apply the supplied RTCSessionDescription as the remote offer or answer. This API changes the local media state.

If a=identity attributes are present, the browser verifies the identity following the procedures in [XREF sec.identity-proxy-assertion-request].

Changes to the state of media transmission will occur when a final answer is successfully applied. remoteDescription must return the previous description until the new description is successfully applied.

An RTCError object of type INVALID_SESSION_DESCRIPTION is provided to the failure callback if the SDP content is invalid.

Parameter	Type	Nullable	Optional
description	`RTCSessionDescription`	✘	✘
successCallback	`RTCVoidCallback`	✘	✘
failureCallback	`RTCPeerConnectionErrorCallback`	✘	✘

Return type: void

updateIce

The updateIce method updates the ICE Agent process of gathering local candidates and pinging remote candidates. If there is a mandatory constraint called "IceTransports" it will control how the ICE engine can act. This can be used to limit the use to TURN candidates by a callee to avoid leaking location information prior to the call being accepted.

This call may result in a change to the state of the ICE Agent, and may result in a change to media state if it results in connectivity being established.

Note

This method was previously used to restart ICE. We should document the new procedure in the correct place.

Parameter	Type	Nullable	Optional	Description
configuration	`RTCConfiguration = null`	✔	✔
constraints	`MediaConstraints = null`	✔	✔

Return type: void

4.3.3 Garbage collection

A Window object has a strong reference to any RTCPeerConnection objects created from the constructor whose global object is that Window object.

4.4 State Definitions

4.4.1 RTCPeerState Enum

enum RTCPeerState {
    "new",
    "have-local-offer",
    "have-local-pranswer",
    "have-remote-pranswer",
    "active (also could be called "open", "stable")",
    "closed"
};

Enumeration description
`new`	The object was just created, and no networking has yet occurred.
`have-local-offer`	A local description, of type "offer", has been supplied.
`have-local-pranswer`	A remote description of type "offer" has been supplied and a local description of type "pranswer" has been supplied.
`have-remote-pranswer`	A local description of type "offer" has been supplied and a remote description of type "pranswer" has been supplied.
`active (also could be called "open", "stable")`	Both local and remote descriptions have been supplied, and the offer-answer exchange is complete.
`closed`	The connection is closed.

The non-normative peer state transitions are:

An example set of transitions might be:

Caller transition:

new PeerConnection(): new
setLocal(offer): have-local-offer
setRemote(pranswer): have-remote-pranswer
setRemote(answer): active
close(): closed

Callee transition:

new PeerConnection(): new
setRemote(offer): received-offer
setLocal(pranswer): have-local-pranswer
setLocal(answer): active
close(): closed

4.4.2 RTCGatheringState Enum

enum RTCGatheringState {
    "new",
    "gathering",
    "complete"
};

Enumeration description
`new`	The object was just created, and no networking has occurred yet.
`gathering`	The ICE engine is in the process of gathering candidates for this RTCPeerConnection.
`complete`	The ICE engine has completed gathering. Events such as adding a new interface or new TURN server could cause the state to go back to gathering.

4.4.3 RTCIceState Enum

Note

There is active discussion around changing these states.

enum RTCIceState {
    "starting",
    "checking",
    "connected",
    "completed",
    "failed",
    "disconnected",
    "closed"
};

Enumeration description
`starting`	The ICE Agent is gathering addresses and/or waiting for remote candidates to be supplied.
`checking`	The ICE Agent has received remote candidates on at least one component, and is checking candidate pairs but has not yet found a connection. In addition to checking, it may also still be gathering.
`connected`	The ICE Agent has found a usable connection for all components but is still checking other candidate pairs to see if there is a better connection. It may also still be gathering.
`completed`	The ICE Agent has finished gathering and checking and found a connection for all components.
`failed`	The ICE Agent is finished checking all candidate pairs and failed to find a connection for at least one component.
`disconnected`	Liveness checks have failed for one or more components. This is more aggressive than `failed`, and may trigger intermittently (and resolve itself without action) on a flaky network.
`closed`	The ICE Agent has shut down and is no longer responding to STUN requests.

States take either the value of any component or all components, as outlined below:

checking occurs if ANY component has received a candidate and can start checking
connected occurs if ALL components have established a working connection
completed occurs if ALL components have finalized the running of their ICE processes
failed occurs if ANY component has given up trying to connect
disconnected occurs if ANY component has failed liveness checks
closed occurs only if PeerConnection.close() has been called.

Note

The WG is discussing if starting/checking should be one state or two.

If a component is discarded as a result of signaling (e.g. RTCP mux or BUNDLE), the state may advance directly from checking to completed.

An example transition might look like:

new PeerConnection(): Starting
(Starting, remote candidates received): Checking
(Checking, found usable connection): Connected
(Checking, gave up): Failed
(Connected, finished all checks): Completed
(Completed, lost connectivity): Disconnected
(any state, ICE restart occurs): Starting
close(): Closed

The non-normative ICE state transitions are:

4.5 Callback Definitions

4.5.1 RTCVoidCallback

callback RTCVoidCallback = void ();

4.5.2 RTCPeerConnectionErrorCallback

callback RTCPeerConnectionErrorCallback = void (RTCError error);

4.5.2.1 Callback `RTCPeerConnectionErrorCallback` Parameters

error of type RTCError: An error object encapsulating information about what went wrong.

4.6 Error Handling

4.6.1 General Principles

Errors are indicated in two ways: exceptions and objects passed to error callbacks. Both forms of error reporting must provide an object of type RTCError. An exception must be thrown in the following cases:

The type of any argument passed to a function did not match what was expected. An appropriate string from the RTCExceptionName enum must be used as the error name.
A function call was made when the RTCPeerConnection is in an invalid state, or a state in which that particular function is not allowed to be executed. In this case, the string INVALID_STATE must be used as the error name.

In all other cases, an error object must be provided to the failure callback. The error name in the object provided must be picked from either the RTCExceptionName or RTCErrorName enums.

4.6.2 RTCError

interface RTCError {
    readonly attribute DOMString  name;
    readonly attribute DOMString? message;
};

4.6.2.1 Attributes

message of type DOMString, readonly, nullable: A human readable description of the error. This string may vary between different user agents.
name of type DOMString, readonly: A string representing the type of error. This string must be one of those defined by the RTCExceptionName or RTCErrorName enums for the error object to be valid.

4.6.3 RTCSdpError

interface RTCSdpError : RTCError {
    readonly attribute long sdpLineNumber;
};

4.6.3.1 Attributes

sdpLineNumber of type long, readonly: The line number of an RTCSessionDescription at which the error was encountered.

4.6.4 RTCExceptionName

enum RTCExceptionName {
    "INVALID_SUCCESS_CALLBACK",
    "INVALID_FAILURE_CALLBACK",
    "INVALID_CONSTRAINTS_TYPE",
    "INVALID_SESSION_DESCRIPTION_TYPE",
    "INVALID_CONFIGURATION_TYPE",
    "INVALID_CANDIDATE_TYPE",
    "INVALID_MEDIASTREAM",
    "INVALID_MEDIASTREAM_TRACK",
    "INVALID_STATE"
};

Enumeration description
`INVALID_SUCCESS_CALLBACK`	The provided successCallback is not a function.
`INVALID_FAILURE_CALLBACK`	The provided failureCallback is not a function.
`INVALID_CONSTRAINTS_TYPE`	The provided constraints object is not a dictionary with either the `mandatory` or `optional` keys.
`INVALID_SESSION_DESCRIPTION_TYPE`	The provided session description is not an object of type `RTCSessionDescription`.
`INVALID_CONFIGURATION_TYPE`	The provided configuration is not an object of type `RTCConfiguration`.
`INVALID_CANDIDATE_TYPE`	The provided candidate is not an object of type `RTCIceCandidate`.
`INVALID_MEDIASTREAM`	The provided media stream is not an object of type `MediaStream`.
`INVALID_MEDIASTREAM_TRACK`	The provided track is not an object of type `MediaStreamTrack`.
`INVALID_STATE`	The function was called on a `RTCPeerConnection` that is an invalid state, or a state in which the function is not allowed to be executed.

4.6.5 RTCErrorName

enum RTCErrorName {
    "INVALID_SESSION_DESCRIPTION",
    "INCOMPATIBLE_CONSTRAINTS"
};

Enumeration description
`INVALID_SESSION_DESCRIPTION`	The provided `RTCSessionDescription` either contained invalid SDP, or SDP that could not be correctly applied to the `RTCPeerConnection` due to its current state. User agents should provide as much additional information in the error message as possible, including the `sdpLineNumber`, if appropriate.
`INCOMPATIBLE_CONSTRAINTS`	The provided `MediaConstraints` could not be correctly applied to the `RTCPeerConnection` due to its current state. User agents should provide as much additional information in the error message as possible.

4.7 Session Description Model

4.7.1 RTCSdpType

The RTCSdpType enum describes the type of an RTCSessionDescription instance.

enum RTCSdpType {
    "offer",
    "pranswer",
    "answer"
};

Enumeration description
`offer`	An RTCSdpType of "offer" indicates that a description should be treated as an [SDP] offer.
`pranswer`	An RTCSdpType of "pranswer" indicates that a description should be treated as an [SDP] answer, but not a final answer. A description used as an SDP "pranswer" may be applied as a response to a SDP offer, or an update to a previously sent SDP "pranswer".
`answer`	An RTCSdpType of "answer" indicates that a description should be treated as an [SDP] final answer, and the offer-answer exchange should be considered complete. A description used as an SDP answer may be applied as a response to an SDP offer or as an update to a previously sent SDP "pranswer".

4.7.2 RTCSessionDescription Class

The RTCSessionDescription() constructor takes an optional dictionary argument, descriptionInitDict, whose content is used to initialize the new RTCSessionDescription object. If a dictionary key is not present in descriptionInitDict, the corresponding attribute will be initialized to null. If the constructor is run without the dictionary argument, all attributes will be initialized to null. This class is a future extensible carrier for the data contained in it and does not perform any substantive processing.

Objects implementing the RTCSessionDescription interface must serialize with the serialization pattern "{ attribute }".

[Constructor (optional RTCSessionDescriptionInit descriptionInitDict)]
interface RTCSessionDescription {
             attribute RTCSdpType? type;
             attribute DOMString?  sdp;
};
dictionary RTCSessionDescriptionInit {
    RTCSdpType type;
    DOMString  sdp;
};

4.7.2.1 Attributes

sdp of type DOMString, nullable: The string representation of the SDP [SDP]
type of type RTCSdpType, nullable: The type of SDP this RTCSessionDescription represents.

4.7.2.2 Dictionary `RTCSessionDescriptionInit` Members

sdp of type DOMString
type of type RTCSdpType: DOMString sdp

4.7.3 RTCSessionDescriptionCallback

callback RTCSessionDescriptionCallback = void (RTCSessionDescription sdp);

4.7.3.1 Callback `RTCSessionDescriptionCallback` Parameters

sdp of type RTCSessionDescription: The object containing the SDP [SDP].

4.8 Interfaces for Connectivity Establishment

4.8.1 RTCIceCandidate Type

The RTCIceCandidate() constructor takes an optional dictionary argument, candidateInitDict, whose content is used to initialize the new RTCIceCandidate object. If a dictionary key is not present in candidateInitDict, the corresponding attribute will be initialized to null. If the constructor is run without the dictionary argument, all attributes will be initialized to null. This class is a future extensible carrier for the data contained in it and does not perform any substantive processing.

Objects implementing the RTCIceCandidate interface must serialize with the serialization pattern "{ attribute }".

[Constructor (optional RTCIceCandidateInit candidateInitDict)]
interface RTCIceCandidate {
             attribute DOMString?      candidate;
             attribute DOMString?      sdpMid;
             attribute unsigned short? sdpMLineIndex;
};
dictionary RTCIceCandidateInit {
    DOMString      candidate;
    DOMString      sdpMid;
    unsigned short sdpMLineIndex;
};

4.8.1.1 Attributes

candidate of type DOMString, nullable: This carries the candidate-attribute as defined in section 15.1 of [ICE].
sdpMLineIndex of type unsigned short, nullable: This indicates the index (starting at zero) of the m-line in the SDP this candidate is associated with.
sdpMid of type DOMString, nullable: If present, this contains the identifier of the "media stream identification" as defined in [RFC 3388] for the m-line this candidate is associated with.

4.8.1.2 Dictionary `RTCIceCandidateInit` Members

candidate of type DOMString: DOMString sdpMid
sdpMLineIndex of type unsigned short
sdpMid of type DOMString: unsigned short sdpMLineIndex

4.8.2 RTCPeerConnectionIceEvent

The icecandidate event of the RTCPeerConnection uses the RTCPeerConnectionIceEvent interface.

Firing an RTCPeerConnectionIceEvent event named e with an RTCIceCandidate candidate 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 RTCPeerConnectionIceEvent interface with the candidate attribute set to the new ICE candidate, must be created and dispatched at the given target.

[Constructor(DOMString type, RTCPeerConnectionIceEventInit eventInitDict)]
interface RTCPeerConnectionIceEvent : Event {
    readonly attribute RTCIceCandidate candidate;
};
dictionary RTCPeerConnectionIceEventInit : EventInit {
    RTCIceCandidate candidate;
};

4.8.2.1 Attributes

candidate of type RTCIceCandidate, readonly: The candidate attribute is the RTCIceCandidate object with the new ICE candidate that caused the event.

4.8.2.2 Dictionary `RTCPeerConnectionIceEventInit` Members

candidate of type RTCIceCandidate

5. Peer-to-peer Data API

The Peer-to-peer Data API lets a web application send and receive generic application data peer-to-peer.

Issue 4: More Open Issues

Data channel setup signaling (signaling via SDP and application specific signaling channel or first channel via SDP and consecutive channels via internal signaling).
What can be shared with the WebSocket API specification regarding actual interfaces.

5.1 RTCDataChannel

The RTCDataChannel interface represents a bi-directional data channel between two peers. A RTCDataChannel is created via a factory method on an RTCPeerConnection object. The corresponding RTCDataChannel object is then dispatched at the other peer if the channel setup was successful.

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 reliability mode, are configured by the peer taking the initiative to create the channel. The other peer cannot change any transport properties of an offered data channel. The actual wire protocol between the peers is out of the scope for this specification.

A RTCDataChannel created with createDataChannel() must initially be in the connecting state. If the RTCDataChannel object’s underlying data transport is successfully set up, the user agent must announce the RTCDataChannel as open.

When the user agent is to announce a RTCDataChannel as open, the user agent must queue a task to run the following steps:

If the associated RTCPeerConnection object's RTCPeerConnection readiness state is closed, abort these steps.
Let channel be the RTCDataChannel object to be announced.
Set channel's readyState attribute to open.
Fire a simple event named open at channel.

When an underlying data transport has been established, the user agent of the peer that did not initiate the creation process must queue a task to run the following steps:

If the associated RTCPeerConnection object's RTCPeerConnection readiness state is closed, abort these steps.
Let configuration be an information bundle with key-value pairs, received from the other peer as a part of the process to establish the underlying data channel.
Let channel be a newly created RTCDataChannel object.
Initialize channel's label attribute to value that corresponds to the "label" key in configuration.
Initialize channel's reliable attribute to true.
If configuration contains a key named "reliable", set channel's reliable attribute to the corresponding value.
Set channel's readyState attribute to open.
Fire a datachannel event named datachannel with channel at the RTCPeerConnection object.

When the process of tearing down a RTCDataChannel object's underlying data transport is initiated, the user agent must run the following steps:

If the associated RTCPeerConnection object's RTCPeerConnection readiness state is closed, abort these steps.
Let channel be the RTCDataChannel object which is about to be closed.
If channel's readyState is closing or closed, then abort these steps.
Set channel's readyState attribute to closing.
Queue a task to run the following steps:
1. Close channel's underlying data transport.
  
  Note
  The data transport protocol will specify what happens to, e.g. buffered data, when the data transport is closed.
2. Set channel's readyState attribute to closed.
3. Fire a simple event named close at channel.

interface RTCDataChannel : EventTarget {
    readonly attribute DOMString           label;
    readonly attribute boolean             reliable;
    readonly attribute RTCDataChannelState readyState;
    readonly attribute unsigned long       bufferedAmount;
             attribute EventHandler        onopen;
             attribute EventHandler        onerror;
             attribute EventHandler        onclose;
    void close ();
             attribute EventHandler        onmessage;
             attribute DOMString           binaryType;
    void send (DOMString data);
    void send (ArrayBuffer data);
    void send (Blob data);
};

5.1.1 Attributes

binaryType of type DOMString: Note
FIXME: align behavior with WebSocket API
bufferedAmount of type unsigned long, readonly: Note
FIXME: align behavior with WebSocket API
label of type DOMString, readonly: The RTCDataChannel.label attribute represents a label that can be used to distinguish this RTCDataChannel object from other RTCDataChannel objects. The attribute must return the value to which it was set when the RTCDataChannel object was created.
onclose of type EventHandler: This event handler, of type close, must be supported by all objects implementing the RTCDataChannel interface.
onerror of type EventHandler: This event handler, of type error, must be supported by all objects implementing the RTCDataChannel interface.
onmessage of type EventHandler: This event handler, of type message ,must be supported by all objects implementing the RTCDataChannel interface.
onopen of type EventHandler: This event handler, of type open, must be supported by all objects implementing the RTCDataChannel interface.
readyState of type RTCDataChannelState, readonly: The RTCDataChannel.readyState attribute represents the state of the RTCDataChannel object. It must return the value to which the user agent last set it (as defined by the processing model algorithms).
reliable of type boolean, readonly: The RTCDataChannel.reliable attribute returns true if the RTCDataChannel is reliable, and false otherwise. The attribute must return the value to which it was set when the RTCDataChannel was created.

5.1.2 Methods

close

Closes the RTCDataChannel. It may be called regardless of whether the RTCDataChannel object was created by this peer or the remote peer.

When the close() method is called, the user agent must initiate the process of tearing down the RTCDataChannel object’s underlying data transport.

No parameters.

Return type: void

send

Note

FIXME: align behavior with WebSocket API

Parameter	Type	Nullable	Optional	Description
data	`DOMString`	✘	✘

Return type: void

send

Note

FIXME: align behavior with WebSocket API

Parameter	Type	Nullable	Optional	Description
data	`ArrayBuffer`	✘	✘

Return type: void

send

Note

FIXME: align behavior with WebSocket API

Parameter	Type	Nullable	Optional	Description
data	`Blob`	✘	✘

Return type: void

dictionary RTCDataChannelInit {
    boolean reliable;
};

5.1.3 Dictionary `RTCDataChannelInit` Members

reliable of type boolean: FIXME: write description

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

Enumeration description
`connecting`	The user agent is attempting to establish the underlying data transport. This is the initial state of a `RTCDataChannel` object created with `createDataChannel()` .
`open`	The underlying data transport is established and communication is possible. This is the initial state of a `RTCDataChannel` object dispatched as a part of a `RTCDataChannelEvent` .
`closing`	The process of closing down the underlying data transport has started.
`closed`	The underlying data transport has been closed or could not be established.

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

5.2.1 Attributes

channel of type RTCDataChannel, readonly: The channel attribute represents the RTCDataChannel object associated with the event.

5.2.2 Dictionary `RTCDataChannelEventInit` Members

channel of type RTCDataChannel

5.3 Garbage Collection

A RTCDataChannel object must not be garbage collected if its

readyState is connecting and at least one event listener is registered for open events, message events, error events, or close events.
readyState is open and at least one event listener is registered for message events, error events, or close events.
readyState is closing and at least one event listener is registered for error events, or close events.
underlying data transport is established and data is queued to be transmitted.

6. Statistics Model

6.1 Introduction

The basic statistics model is that the browser maintains a set of statistics indexed by selector. The "selector" may be a MediaStreamTrack that is a member of a MediaStream on the incoming or outgoing streams. The calling Web application provides the selector to the getStats() method and the browser returns (in the JavaScript) a set of statistics that it believes is relevant to the selector.

The statistics returned are designed in such a way that repeated queries yield the same statistics in the same place in the structure. Thus, a Web application can make measurements over a given time period by requesting measurements at the beginning and end of that period.

6.2 RTCStatsCallback

callback RTCStatsCallback = void (RTCStatsElement[] statsElements, MediaStreamTrack? selector);

6.2.1 Callback `RTCStatsCallback` Parameters

statsElements of type array of RTCStatsElement: The objects containing the stats result.
selector of type MediaStreamTrack, nullable: The selector object that the statistics were gathered for. Currently only MediaStreamTrack is supported as a selector object.

6.3 RTCStatsElement dictionary

Each RTCStatsElement object consists of two RTCStatsReport objects, one corresponding to local statistics and one to remote statistics.

dictionary RTCStatsElement {
    RTCStatsReport local;
    RTCStatsReport remote;
};

6.3.1 Dictionary `RTCStatsElement` Members

local of type RTCStatsReport: The statistics corresponding to local properties.
remote of type RTCStatsReport: The statistics corresponding to remote properties.

6.4 RTCStatsReport Type

Each RTCStatsReport has a timestamp. Individual statistics are accessed by passing string names to the getValue() method. Note that while stats names are standardized [[OPEN ISSUE: Need to define an IANA registry for this and populate with pointers to existing things such as the RTCP statistics. ]], 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 RTCStatsReport.

interface RTCStatsReport {
    readonly attribute long timestamp;
    any getValue (DOMString statName);
};

6.4.1 Attributes

timestamp of type long, readonly: The timestamp in milliseconds since the UNIX epoch (Jan 1, 1970, UTC).

6.4.2 Methods

getValue

The getValue() method returns the value for the statistic that corresponds to statName.

Parameter	Type	Nullable	Optional	Description
statName	`DOMString`	✘	✘

Return type: any

6.5 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 sound track is audio track 0 of remote stream 0 of pc1. The following example code might be used:

Example 1

var baseline, now;
var selector = pc.remoteStreams[0].audioTracks[0];

pc.getStats(selector, function (stats) {
    baseline = stats;
});

// ... wait a bit
setTimeout(function () {
    pc.getStats(selector, function (stats) {
        now = stats;
        processStats();
    });
}, aBit);

function processStats() {
    // Real code would:
    // - Check that timestamp of “local stats” and “remote stats”
    //   are reasonably consistent.
    // - Sum up over all the elements rather than just accessing
    //   element zero.

    var packetsSent = now[0].remote.getValue("packetsSent") -
            baseline[0].remote.getValue("packetsSent");

    var packetsReceived = now[0].local.getValue("packetsReceived") -
            baseline[0].local.getValue("packetsReceived");

    // if fractionLost is > 0.3, we have probably found the culprit
    var fractionLost = (packetsSent - packetsReceived) / packetsSent;
}

7. Identity

7.1 Identity Provider Interaction

WebRTC offers and answers (and hence the channels established by RTCPeerConnection objects) can be authenticated by using web-based Identity Providers. The idea is that the entity sending the offer/answer acts as the Authenticating Party (AP) and obtains an identity assertion from the IdP which it attaches to the offer/answer. The consumer of the offer/answer (i.e., the RTCPeerConnection on which setRemoteDescription() is called acts as the Relying Party (RP) and verifies the assertion.

The interaction with the IdP is designed to decouple the browser from any particular identity provider; 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 browser was written. The generic protocol details are described in [RTCWEB-SECURITY-ARCH]. This document specifies the procedures required to instantiate the IdP proxy, request identity assertions, and consume the results.

7.1.1 Peer-Connection/IdP Communications

In order to communicate with the IdP, the browser must instantiate an isolated interpreted context [TODO: What's the technical term?], such as an invisible IFRAME. The initial contents of the context are loaded from a URI derived from the IdP's domain name. [RTCWEB-SECURITY-ARCH; Section XXX].

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

If the setIdentityProvider() method has been called, the IdP provided shall be used.
If the setIdentityProvider() method has not been called, then the browser shall use an IdP configured into the browser. If more than one such IdP is configured, the browser should provide the user with a chooser interface.

In order to verify assertions, the IdP domain name and protocol shall be equal to the "domain" and "protocol" fields of the identity assertion.

The context must have a MessageChannel named window.TBD which is "entangled" to the RTCPeerConnection and is unique to that subcontext. This channel is used for messaging between the RTCPeerConnection and the IdP. All messages sent via this channel are strings, specifically the JSONified versions of JavaScript structs.

All messages sent from the RTCPeerConnection to the IdP context must have an origin of rtcweb://peerconnection/. The fact that ordinary Web pages cannot set their origin values arbitrarily is an essential security feature, as it stops attackers from requesting WebRTC-compatible identity assertions from IdPs. For this reason, the origin must be included in the identity assertion and verified by the consuming RTCPeerConnection.

7.1.2 Requesting Assertions

The identity assertion request process involves the following steps.

The RTCPeerConnection instantiates an IdP context as described in the previous section.
The IdP serves up the IdP JavaScript code to the IdP context.
Once the IdP is loaded and ready to receive messages it sends a "READY" message [RTCWEB-SECURITY-ARCH; Section 5.6.5.2]. Note that this does not imply that the user is logged in, merely that enough IdP state is booted up to be ready to handle PostMessage calls.
The IdP sends a "SIGN" message (Section 5.6.5.2.2) to the IdP proxy context. This message includes the material the RTCPeerConnection desires to be bound to the user's identity.
If the user is not logged in, at this point the IdP will initiate the login process. For instance, it might pop up a dialog box inviting the user to enter their (IdP) username and password.
Once the user is logged in (potentially after the previous step), the IdP proxy generates an identity assertion (depending on the authentication protocol this may involve interacting with the IDP server).
Once the assertion is generated, the IdP proxy sends a response (Section 5.6.5.2.2) containing the assertion to the RTCPeerConnection over the message channel.
The RTCPeerConnection stores the assertion for use with future offers or answers. If the identity request was triggered by a createOffer() or createAnswer(), then the assertion is inserted in the offer/answer.

7.1.3 Verifying Assertions

The identity assertion request process involves the following steps.

The RTCPeerConnection instantiates an IdP context as described in the previous section.
The IdP serves up the IdP JavaScript code to the IdP context.
Once the IdP is loaded and ready to receive messages it sends a "READY" message [RTCWEB-SECURITY-ARCH; Section 5.6.5.2]. Note that this does not imply that the user is logged in, merely that enough IdP state is booted up to be ready to handle PostMessage calls.
The IdP sends a "VERIFY" message (Section 5.6.5.2.2) to the IdP proxy context. This message includes assertion from the offer/answer which is to be verified.
The IdP proxy verifies the identity assertion (depending on the authentication protocol this may involve interacting with the IDP server).
Once the assertion is verified the IdP proxy sends a response containing the verified assertion results (Section 5.6.5.2.3) to the RTCPeerConnection over the message channel.
The RTCPeerConnection displays the assertion information in the browser UI and stores the assertion in the peerIdentity attribute for availability to the JavaScript application. The assertion information to be displayed shall contain the domain name of the IdP and the identity returned by the IdP and must be displayed via some mechanism which cannot be spoofed by content. [[OPEN ISSUE: The identity information should also be available in the inspector interface defined in [RTCWEB-SECURITY-ARCH; Section 5.5].

7.2 RTCIdentityAssertion Type

dictionary RTCIdentityAssertion {
    DOMString idp;
    DOMString name;
};

7.2.1 Dictionary `RTCIdentityAssertion` Members

idp of type DOMString: A domain name representing the identity provider.
name of type DOMString: An RFC822-conformant [TODO: REF] representation of the verified peer identity. This identity will have been verified via the procedures described in [RTCWEB-SECURITY-ARCH].

7.3 Examples

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.

This example shows how to configure the identity provider and protocol.

Example 2

pc.setIdentityProvider("example.com", "default", "alice@example.com");

This example shows how to consume identity assertions inside a Web application.

Example 3

pc.onidentityresult = function(result) {
  console.log("IdP= " + pc.peerIdentity.idp +
              " identity=" + pc.peerIdentity.name);
};

8. Media Stream API Extensions for Network Use

8.1 Introduction

The MediaStream interface, as defined in the [GETUSERMEDIA] specification, typically represents a stream of data of audio and/or video. A MediaStream may be extended to represent a stream that either comes from or is sent to a remote node (and not just the local camera, for instance). The extensions required to enable this capability on the MediaStream object will be described in this document.

A MediaStream as defined in [GETUSERMEDIA] may contain zero or more MediaStreamTrack objects. A MediaStreamTrack sent to another peer will appear as one and only one MediaStreamTrack to the recipient. A peer is defined as a user agent that supports this specification.

Channels are the smallest unit considered in the MediaStream specification. Channels are intended to be encoded together for transmission as, for instance, an RTP payload type. All of the channels that a codec needs to encode jointly must be in the same MediaStreamTrack and the codecs should be able to encode, or discard, all the channels in the track.

The concepts of an input and output to a given MediaStream apply in the case of MediaStream objects transmitted over the network as well. A MediaStream created by an RTCPeerConnection object (described later in this document) will take as input the data received from a remote peer. Similarly, a MediaStream from a local source, for instance a camera via [GETUSERMEDIA], will have an output that represents what is transmitted to a remote peer if the object is used with an RTCPeerConnection object.

The concept of duplicating MediaStream objects as described in [GETUSERMEDIA] is also applicable here. This feature can be used, for instance, in a video-conferencing scenario to display the local video from the user’s camera and microphone in a local monitor, while only transmitting the audio to the remote peer (e.g. in response to the user using a "video mute" feature). Combining tracks from different MediaStream objects into a new MediaStream is useful in certain situations.

Note

In this document, we only specify aspects of the following objects that are relevant when used along with an RTCPeerConnection. Please refer to the original definitions of the objects in the [GETUSERMEDIA] document for general information on using MediaStream and MediaStreamTrack.

8.2 MediaStream

8.2.1 id

The id attribute specified in MediaStream returns an id that is unique to this stream, so that streams can be recognized after they are sent through the RTCPeerConnection API.

When a MediaStream is created to represent a stream obtained from a remote peer, the id attribute is initialized from information provided by the remote source.

Note

The id of a MediaStream object is unique to the source of the stream, but that does not mean it is not possible to end up with duplicates. For example, a locally generated stream could be sent from one user agent to a remote peer using RTCPeerConnection and then sent back to the original user agent in the same manner, in which case the original user agent will have multiple streams with the same id (the locally-generated one and the one received from the remote peer).

8.2.2 Events on MediaStream

A new media track may be associated with an existing MediaStream. For example, if a remote peer adds a new MediaStreamTrack object to a MediaStream that is being sent over an RTCPeerConnection, this is observed on the local user agent. If this happens for the reason exemplified, or for any other reason than the addTrack() method being invoked locally on a MediaStream or tracks being added as the stream is created (i.e. the stream is initialized with tracks), the user agent must run the following steps:

Let stream be the target MediaStream object.
Represent component with track: Run the following steps to create a track representing the incoming component:
1. Create a MediaStreamTrack object track to represent the component.
2. Initialize track’s kind attribute to "audio" or "video" depending on the media type of the incoming component.
3. Initialize track’s id attribute to the component track id.
4. Initialize track’s label attribute to "remote audio" or "remote video" depending on the media type of the incoming component.
5. Initialize track’s readyState attribute to muted.
6. Add track to stream’s track set.
Fire a track event named addtrack with the newly created MediaStreamTrack object at stream.

An existing media track may also be disassociated from a MediaStream. If this happens for any other reason than the removeTrack() method being invoked locally on a MediaStream or the stream being destroyed, the user agent must run the following steps:

Let stream be the target MediaStream object.
Let track be the MediaStreamTrack object representing the media component about to be removed.
Remove track from stream’s track set.
Fire a track event named removetrack with track at stream.

The event source for the onended event in the networked case is the RTCPeerConnection object.

8.3 MediaStreamTrack

A MediaStreamTrack object’s reference to its MediaStream in the non-local media source case (an RTP source, as is the case for a MediaStream received over an RTCPeerConnection) is always strong.

When a track belongs to a MediaStream that comes from a remote peer and the remote peer has permanently stopped sending data the ended event must be fired on the track, as specified in [GETUSERMEDIA].

Issue 5

ISSUE: How do you know when it has stopped? This seems like an SDP question, not a media-level question.

A track in a MediaStream, received with an RTCPeerConnection, must have its readyState attribute [GETUSERMEDIA] set to muted until media data arrives.

In addition, a MediaStreamTrack has its readyState set to muted on the remote peer if the local user agent disables the corresponding MediaStreamTrack in the MediaStream that is being sent. When the addstream event triggers on an RTCPeerConnection, all MediaStreamTrack objects in the resulting MediaStream are muted until media data can be read from the RTP source.

Issue 6

ISSUE: How do you know when it has been disabled? This seems like an SDP question, not a media-level question.

8.4 AudioMediaStreamTrack

Note

The DTMF API is undergoing significant list discussion and will probably change.

The AudioMediaStreamTrack is a specialization of a normal MediaStreamTrack that only carries audio and is extended to have the capability to send and/or receive DTMF codes.

interface AudioMediaStreamTrack : MediaStreamTrack {
    readonly attribute boolean canInsertDTMF;
    void insertDTMF (DOMString tones, optional long duration);
};

8.4.1 Attributes

canInsertDTMF of type boolean, readonly: The canInsertDTMF attribute must indicate if the AudioMediaStreamTrack is capable of sending DTMF.

8.4.2 Methods

insertDTMF

When an AudioMediaStreamTrack object’s insertDTMF() method is invoked, the user agent must queue a task that sends the DTMF tones.

The tone parameters is treated as a series of characters. The characters 0 through 9, A through D, #, and * generate the associated DTMF tones. The characters a to d are equivalent to A to D. The character',' indicates a delay of 2 seconds before processing the next character in the tones parameter. Unrecognized characters are ignored.

The duration parameter indicates the duration in ms to use for each character passed in the tones parameters. The duration cannot be more than 6000 or less than 70. The default duration is 100 ms for each tone. The gap between tones must be at least 50 ms but should be as short as possible.

Issue 7

ISSUE: How are invalid values handled?

If insertDTMF is called on the same object while an existing task for this object to generate DTMF is still running, the previous task is canceled. Calling insertDTMF with an empty tones parameter can be used to cancel any tones currently being sent.

Note

Editor Note: We need to add a callback to insertDTMF that is called after the tones are sent. This is needed to allow the application to know when it can send new tones without canceling the tones that are currently being sent.

Note

Editor Note: It seems we would want a callback or event for incoming tones. The proposal sent to the list had them played as audio to the speaker but I don’t see how that is useful.

Parameter	Type	Nullable	Optional	Description
tones	`DOMString`	✘	✘
duration	`long`	✘	✔

Return type: void

8.5 MediaStreamEvent

The addstream and removestream events use the MediaStreamEvent interface.

Firing a stream event named e with a MediaStream stream 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 MediaStreamEvent interface with the stream attribute set to stream, must be created and dispatched at the given target.

[Constructor(DOMString type, MediaStreamEventInit eventInitDict)]
interface MediaStreamEvent : Event {
    readonly attribute MediaStream? stream;
};
dictionary MediaStreamEventInit : EventInit {
    MediaStream stream;
};

8.5.1 Attributes

stream of type MediaStream, readonly, nullable: The stream attribute represents the MediaStream object associated with the event.

8.5.2 Dictionary `MediaStreamEventInit` Members

stream of type MediaStream

9.1 Simple Peer-to-peer Example

This section is non-normative.

When two peers decide they are going to set up a connection to each other, they both go through these steps. The STUN/TURN server configuration describes a server they can use to get things like their public IP address or to set up NAT traversal. They also have to send data for the signaling channel to each other using the same out-of-band mechanism they used to establish that they were going to communicate in the first place.

Example 4

var signalingChannel = new SignalingChannel();
var configuration = { "iceServers": [{ "url": "stun:stun.example.org" }] };
var pc;

// call start() to initiate
function start() {
    pc = new RTCPeerConnection(configuration);

    // send any ice candidates to the other peer
    pc.onicecandidate = function (evt) {
        if (evt.candidate)
            signalingChannel.send(JSON.stringify({ "candidate": evt.candidate }));
    };

    // let the "negotiationneeded" event trigger offer generation
    pc.onnegotiationneeded = function () {
        pc.createOffer(localDescCreated, logError);
    }

    // once remote stream arrives, show it in the remote video element
    pc.onaddstream = function (evt) {
        remoteView.src = URL.createObjectURL(evt.stream);
    };

    // get a local stream, show it in a self-view and add it to be sent
    navigator.getUserMedia({ "audio": true, "video": true }, function (stream) {
        selfView.src = URL.createObjectURL(stream);
        pc.addStream(stream);
    });
}

function localDescCreated(desc) {
    pc.setLocalDescription(desc, function () {
        signalingChannel.send(JSON.stringify({ "sdp": pc.localDescription }));
    }, logError);
}

signalingChannel.onmessage = function (evt) {
    if (!pc)
        start();

    var message = JSON.parse(evt.data);
    if (message.sdp)
        pc.setRemoteDescription(new RTCSessionDescription(message.sdp), function () {
            // if we received an offer, we need to answer
            if (pc.remoteDescription.type == "offer")
                pc.createAnswer(localDescCreated, logError);
        }, logError);
    else
        pc.addIceCandidate(new RTCIceCandidate(message.candidate));
};

function logError(error) {
    log(error.name + ": " + error.message);
}

9.2 Advanced Peer-to-peer Example

This example shows the more complete functionality.

Example 5

TODO

9.3 Peer-to-peer Data Example

This example shows how to create a RTCDataChannel object and perform the offer/answer exchange required to connect the channel to the other peer. The RTCDataChannel is used in the context of a simple chat application and listeners are attached to monitor when the channel is ready, messages are received and when the channel is closed.

Note

This example uses the negotiationneeded event to initiate the offer/answer dialog. The exact behavior surrounding the negotiationneeded event is not specified in detail at the moment. This example can hopefully help to drive that discussion. An assumption made in this example is that the event only triggeres when a new negotiation should be started. This means that an action (such as addStream()) that normally would have fired the negotiationneeded event will not do so during an ongoing offer/answer dialog.

Example 6

var signalingChannel = new SignalingChannel();
var configuration = { "iceServers": [{ "url": "stun:stun.example.org" }] };
var pc;
var channel;

// call start(true) to initiate
function start(isInitiator) {
    pc = new RTCPeerConnection(configuration);

    // send any ice candidates to the other peer
    pc.onicecandidate = function (evt) {
        if (evt.candidate)
            signalingChannel.send(JSON.stringify({ "candidate": evt.candidate }));
    };

    // let the "negotiationneeded" event trigger offer generation
    pc.onnegotiationneeded = function () {
        pc.createOffer(localDescCreated, logError);
    }

    if (isInitiator) {
        // create data channel and setup chat
        channel = pc.createDataChannel("chat");
        setupChat();
    } else {
        // setup chat on incoming data channel
        pc.ondatachannel = function (evt) {
            channel = evt.channel;
            setupChat();
        };
    }
}

function localDescCreated(desc) {
    pc.setLocalDescription(desc, function () {
        signalingChannel.send(JSON.stringify({ "sdp": pc.localDescription }));
    }, logError);
}

signalingChannel.onmessage = function (evt) {
    if (!pc)
        start(false);

    var message = JSON.parse(evt.data);
    if (message.sdp)
        pc.setRemoteDescription(new RTCSessionDescription(message.sdp), function () {
            // if we received an offer, we need to answer
            if (pc.remoteDescription.type == "offer")
                pc.createAnswer(localDescCreated, logError);
        }, logError);
    else
        pc.addIceCandidate(new RTCIceCandidate(message.candidate));
};

function setupChat() {
    channel.onopen = function () {
        // e.g. enable send button
        enableChat(channel);
    };

    channel.onmessage = function (evt) {
        showChatMessage(evt.data);
    };
}

function sendChatMessage(msg) {
    channel.send(msg);
}

function logError(error) {
    log(error.name + ": " + error.message);
}

9.4 Call Flow Browser to Browser

Note

Editors' Note: This example flow needs to be discussed on the list and is likely wrong in many ways.

This shows an example of one possible call flow between two browsers. This does not show every callback that gets fired but instead tries to reduce it down to only show the key events and messages.

A message sequence chart detailing a call flow between two browsers

Event name	Interface	Fired when...
`open`	`Event`	The `RTCDataChannel` object's underlying data transport has been established (or re-established).
`MessageEvent`	`Event`	A message was successfully received. TODO: Ref where MessageEvent is defined?
`error`	`Event`	TODO.
`close`	`Event`	The `RTCDataChannel` object's underlying data transport has bee closed.

Event name	Interface	Fired when...
`connecting`	`Event`	TODO
`open`	`Event`	TODO
`addstream`	`MediaStreamEvent`	A new stream has been added to the `remoteStreams` array.
`removestream`	`MediaStreamEvent`	A stream has been removed from the `remoteStreams` array.
`negotiationneeded`	`Event`	The browser wishes to inform the application that session negotiation needs to be done at some point in the near future.
`statechange`	`Event`	TODO
`icechange`	`Event`	TODO
`icecandidate`	`RTCPeerConnectionIceEvent`	TODO
`identityresult`	`RTCIdentityEvent`	TODO

11. Security Considerations

TBD.

12. IANA Registrations

IANA is requested to register the constraints defined in Constraints Section as specified in [RTCWEB-CONSTRAINTS].

12.1 Constraints

TOOD: Need to change the naming and declaration of these constraints to match the constraints draft once that is a bit further along. The names here now are likely not quite right but they serve as a place holder.

Issue 8

ISSUE: there are multiple ways to add constraints. How are multiple values reconciled?

The following new constraints are defined that can be used with an RTCPeerConnection object:

OfferToReceiveVideo

This is an enum type constraint that can take the values "true" and "false". The default is a non mandatory "true" for an RTCPeerConnection object that has a video stream at the point in time when the constraints are being evaluated and is non mandatory "false" otherwise.

In some cases, an RTCPeerConnection may wish to receive video but not send any video. The RTCPeerConnection needs to know if it should signal to the remote side whether it wishes to receive video or not. This constraint allows an application to indicate its preferences for receiving video when creating an offer.

OfferToReceiveAudio

This is an enum type constraint that can take the values "true" and "false". The default is a non mandatory "true".

In some cases, an RTCPeerConnection may wish to receive audio but not send any audio. The RTCPeerConnection needs to know if it should signal to the remote side whether it wishes to receive audio. This constraints allows an application to indicate its preferences for receiving audio when creating an offer.

VoiceActivityDetection

This is an enum type constraint that can take the values "true" and "false". The default is a non mandatory "true".

Many codecs and system are capable of detecting "silence" and changing their behavior in this case by doing things such as not transmitting any media. In many cases, such as when dealing with sounds other than spoken voice or emergency calling, it is desirable to be able to turn off this behavior. This constraint allows the application to provide information about whether it wishes this type of processing enabled or disabled.

IceTransports

This is an enum type constraint that can take the values "none", "relay", and "all". The default is a non mandatory "all".

This constraint indicates which candidates the ICE engine is allowed to use. The value "none" means the ICE engine must not send or receive any packets at this point. The value "relay" indicates the ICE engine must only use media relay candidates such as candidates passing through a TURN server. This can be used to reduce leakage of IP addresses in certain use cases. The value of "all" indicates all values can be used.

RequestIdentity

This is an enum type constraint that can take the values "yes", "no", and "ifconfigured". The default is a non mandatory "ifconfigured".

This constraint indicates whether an identity should be requested. The constraint may be used with either of the createOffer() or createAnswer() calls or with the constructor. The value "yes" means that an identity must be requested. The value "no" means that no identity is to be requested. The value "ifconfigured" means that an identity will be requested if either the user has configured an identity in the browser or if the setIdentityProvider() call has been made in JavaScript. As this is the default value, an identity will be requested if and only if the user has configured an IdP in some way. Note that as long as DTLS-SRTP is in used, fingerprints will be sent regardless of the value of this constraint.

TODO items - need to register with IANA.

13. Change Log

This section will be removed before publication.

Changes since Nov 13, 2012

Made some clarifications as to how operation queuing works, and fixed a few errors with the error handling description.
Introduced new representation of tracks in a stream (removed MediaStreamTrackList). Added algorithm for creating a track to represent an incoming network media component.
Renamed MediaStream.label to MediaStream.id (the definition needs some more work).

Changes since Nov 03, 2012

Added text describing the queuing mechanism for RTCPeerConnection.
Updated simple P2P example to include all mandatory (error) callbacks.
Updated P2P data example to include all mandatory (error) callbacks. Also added some missing RTC prefixes.

Changes since Oct 19, 2012

Clarified how createOffer() and createAnswer() use their callbacks.
Made all failure callbacks mandatory.
Added error object types, general error handling principles, and rules for when errors should be thrown.

Changes since Sept 23, 2012

Restructured the document layout and created separate sections for features like Peer-to-peer Data API, Statistics and Identity.

Changes since Aug 16, 2012

Replaced stringifier with serializer on RTCSessionDescription and RTCIceCandidate (used when JSON.stringify() is called).
Removed offer and createProvisionalAnswer arguments from the createAnswer() method.
Removed restart argument from the updateIce() method.
Made RTCDataChannel an EventTarget
Updated simple PeerConnection example to match spec changes.
Added section about RTCDataChannel garbage collection.
Added stuff for identity proxy.
Added stuff for stats.
Added stuff peer and ice state reporting.
Minor changes to sequence diagrams.
Added a more complete RTCDataChannel example
Various fixes from Dan's Idp API review.
Patched the Stats API.

Changes since Aug 13, 2012

Made the RTCSessionDescription and RTCIceCandidate constructors take dictionaries instead of a strings. Also added detailed stringifier algorithm.
Went through the list of issues (issue numbers are only valid with HEAD at fcda53c460). Closed (fixed/wontfix): 1, 8, 10, 13, 14, 16, 18, 19, 22, 23, 24. Converted to notes: 4, 12. Updated: 9.
Incorporate changes proposed by Li Li.
Use an enum for DataChannelState and fix IDLs where using an optional argument also requires all previous optional arguments to have a default value.

Changes since Jul 20, 2012

Added RTC Prefix to names (including the notes below).
Moved to new definition of configuration and ice servers object.
Added correlating lines to candidate structure.
Converted setLocalDescription and setRemoteDescription to be asynchronous.
Added call flows.

Changes since Jul 13, 2012

Removed peer attribute from RTCPeerConnectionIceEvent (duplicates functionality of Event.target attribute).
Removed RTCIceCandidateCallback (no longer used).
Removed RTCPeerConnectionEvent (we use a simple event instead).
Removed RTCSdpType argument from setLocalDescription() and setRemoteDescription(). Updated simple example to match.

Changes since May 28, 2012

Changed names to use RTC Prefix.
Changed the data structure used to pass in STUN and TURN servers in configuration.
Updated simple RTCPeerConnection example (RTCPeerConnection constructor arguments; use icecandidate event).
Initial import of new Data API.
Removed some left-overs from the old Data Stream API.
Renamed "underlying data channel" to "underlying data transport". Fixed closing procedures. Fixed some typos.

Changes since April 27, 2012

Major rewrite of RTCPeerConnection section to line up with IETF JSEP draft.
Added simple RTCPeerConnection example. Initial update of RTCSessionDescription and RTCIceCandidate to support serialization and construction.

Changes since 21 April 2012

Moved MediaStream and related definitions to getUserMedia.
Removed section "Obtaining local multimedia content".
Updated getUserMedia() calls in examples (changes in Media Capture TF spec).
Introduced MediaStreamTrackList interface with support for adding and removing tracks.
Updated the algorithm that is run when RTCPeerConnection receives a stream (create new stream when negotiated instead of when data arrives).

Changes since 12 January 2012

Clarified the relation of Stream, Track, and Channel.

Changes since 17 October 2011

Tweak the introduction text and add a reference to the IETF RTCWEB group.
Changed the first argument to getUserMedia to be an object.
Added a MediaStreamHints object as a second argument to RTCPeerConnection.addStream.
Added AudioMediaStreamTrack class and DTMF interface.

Changes since 23 August 2011

Separated the SDP and ICE Agent into separate agents and added explicit state attributes for each.
Removed the send method from PeerConenction and associated callback function.
Modified MediaStream() constructor to take a list of MediaStreamTrack objects instead of a MediaStream. Removed text about MediaStream parent and child relationship.
Added abstract.
Moved a few paragraphs from the MediaStreamTrack.label section to the MediaStream.label section (where they belong).
Split MediaStream.tracks into MediaStream.audioTracks and MediaStream.videoTracks.
Removed a sentence that implied that track access is limited to LocalMediaStream.
Updated a few getUserMedia()-examples to use MediaStreamOptions.
Replaced calls to URL.getObjectURL() with URL.createObjectURL() in example code.
Fixed some broken getUserMedia() links.
Introduced state handling on MediaStreamTrack (removed state handling from MediaStream).
Reintroduced onended on MediaStream to simplify checking if all tracks are ended.
Aligned the MediaStreamTrack ended event dispatching behavior with that of MediaStream.
Updated the LocalMediaStream.stop() algorithm to implicitly use the end track algorithm.
Replaced an occurrence the term finished track with ended track (to align with rest of spec).
Moved (and extended) the explanation about track references and media sources from LocalMediaStream to MediaStreamTrack.

B.1 Normative references

[GETUSERMEDIA]: D. Burnett, A. Narayanan. Media Capture and Streams 28 June 2012. W3C Working Draft (Work in progress.) URL: http://dev.w3.org/TR/2012/WD-mediacapture-streams-20120628/
[HTML5]: Ian Hickson; David Hyatt. HTML5. 29 March 2012. W3C Working Draft. (Work in progress.) URL: http://www.w3.org/TR/html5
[ICE]: J. Rosenberg. Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols. April 2010. Internet RFC 5245. URL: http://tools.ietf.org/html/rfc5245
[RFC2119]: S. Bradner. Key words for use in RFCs to Indicate Requirement Levels. March 1997. Internet RFC 2119. URL: http://www.ietf.org/rfc/rfc2119.txt
[RTCWEB-CONSTRAINTS]: D. Burnett. IANA Registry for RTCWeb Media Constraints. URL: http://datatracker.ietf.org/doc/draft-burnett-rtcweb-constraints-registry/
[SDP]: J. Rosenberg, H. Schulzrinne. An Offer/Answer Model with the Session Description Protocol (SDP). June 2002. Internet RFC 3264. URL: http://tools.ietf.org/html/rfc3264
[STUN]: J. Rosenberg, R. Mahy, P. Matthews, D. Wing. Session Traversal Utilities for NAT (STUN). October 2008. Internet RFC 5389. URL: http://tools.ietf.org/html/rfc5389
[STUN-URI]: S. Nandakumar, G. Salgueiro, P. Jones, and M. Petit-Huguenin. URI Scheme for Session Traversal Utilities for NAT (STUN) Protocol. 12 March 2012. Internet Draft (work in progress). URL: http://tools.ietf.org/html/draft-nandakumar-rtcweb-stun-uri
[TURN]: P. Mahy, P. Matthews, J. Rosenberg. Traversal Using Relays around NAT (TURN): Relay Extensions to Session Traversal Utilities for NAT (STUN). April 2010. Internet RFC 5766. URL: http://tools.ietf.org/html/rfc5766
[TURN-URI]: M. Petit-Huguenin, S. Nandakumar, G. Salgueiro, and P. Jones. Traversal Using Relays around NAT (TURN) Uniform Resource Identifiers. 12 March 2012. Internet Draft (work in progress). URL: http://tools.ietf.org/html/draft-petithuguenin-behave-turn-uris
[WEBIDL]: Cameron McCormack. Web IDL. 27 September 2011. W3C Working Draft. (Work in progress.) URL: http://www.w3.org/TR/2011/WD-WebIDL-20110927/

B.2 Informative references

[RTCWEB-JSEP]: J. Uberti, C. Jennings. Javascript Session Establishment Protocol. URL: http://datatracker.ietf.org/doc/draft-ietf-rtcweb-jsep/

WebRTC 1.0: Real-time Communication Between Browsers

W3C Editor's Draft 12 December 2012

Abstract

Status of This Document

Table of Contents

1. Introduction

2. Conformance

3. Terminology

4. Peer-to-peer connections

4.1 Introduction

4.2 Configuration

4.2.1 RTCConfiguration Type

4.2.1.1 Dictionary RTCConfiguration Members

4.2.2 RTCIceServer Type

4.2.2.1 Dictionary RTCIceServer Members

4.3 RTCPeerConnection Interface

4.3.1 Operation

4.3.2 Interface Definition

4.3.2.1 Attributes

4.3.2.2 Methods

4.3.3 Garbage collection

4.4 State Definitions

4.4.1 RTCPeerState Enum

4.4.2 RTCGatheringState Enum

4.4.3 RTCIceState Enum

4.5 Callback Definitions

4.5.1 RTCVoidCallback

4.5.2 RTCPeerConnectionErrorCallback

4.5.2.1 Callback RTCPeerConnectionErrorCallback Parameters

4.6 Error Handling

4.6.1 General Principles

4.6.2 RTCError

4.6.2.1 Attributes

4.6.3 RTCSdpError

4.6.3.1 Attributes

4.6.4 RTCExceptionName

4.6.5 RTCErrorName

4.7 Session Description Model

4.7.1 RTCSdpType

4.7.2 RTCSessionDescription Class

4.7.2.1 Attributes

4.7.2.2 Dictionary RTCSessionDescriptionInit Members

4.7.3 RTCSessionDescriptionCallback

4.7.3.1 Callback RTCSessionDescriptionCallback Parameters

4.8 Interfaces for Connectivity Establishment

4.8.1 RTCIceCandidate Type

4.8.1.1 Attributes

4.8.1.2 Dictionary RTCIceCandidateInit Members

4.8.2 RTCPeerConnectionIceEvent

4.8.2.1 Attributes

4.8.2.2 Dictionary RTCPeerConnectionIceEventInit Members

5. Peer-to-peer Data API

5.1 RTCDataChannel

5.1.1 Attributes

5.1.2 Methods

5.1.3 Dictionary RTCDataChannelInit Members

5.2 RTCDataChannelEvent

5.2.1 Attributes

5.2.2 Dictionary RTCDataChannelEventInit Members

5.3 Garbage Collection

6. Statistics Model

6.1 Introduction

6.2 RTCStatsCallback

6.2.1 Callback RTCStatsCallback Parameters

6.3 RTCStatsElement dictionary

6.3.1 Dictionary RTCStatsElement Members

6.4 RTCStatsReport Type

6.4.1 Attributes

6.4.2 Methods

6.5 Example

7. Identity

7.1 Identity Provider Interaction

7.1.1 Peer-Connection/IdP Communications

7.1.2 Requesting Assertions

7.1.3 Verifying Assertions

7.2 RTCIdentityAssertion Type

7.2.1 Dictionary RTCIdentityAssertion Members

7.3 Examples

8. Media Stream API Extensions for Network Use

8.1 Introduction

4.2.1.1 Dictionary `RTCConfiguration` Members

4.2.2.1 Dictionary `RTCIceServer` Members

4.5.2.1 Callback `RTCPeerConnectionErrorCallback` Parameters

4.7.2.2 Dictionary `RTCSessionDescriptionInit` Members

4.7.3.1 Callback `RTCSessionDescriptionCallback` Parameters

4.8.1.2 Dictionary `RTCIceCandidateInit` Members

4.8.2.2 Dictionary `RTCPeerConnectionIceEventInit` Members

5.1.3 Dictionary `RTCDataChannelInit` Members

5.2.2 Dictionary `RTCDataChannelEventInit` Members

6.2.1 Callback `RTCStatsCallback` Parameters

6.3.1 Dictionary `RTCStatsElement` Members

7.2.1 Dictionary `RTCIdentityAssertion` Members

8.5.2 Dictionary `MediaStreamEventInit` Members