W3C

JSEP1 BRANCH - WebRTC 1.0: Real-time Communication Between Browsers

W3C Member Submission 17 March 2012

This version:
http://www.w3.org/TR/2012/Member-SUBM-webrtc-20120317/
Latest published version:
http://www.w3.org/TR/webrtc/
Latest editor's draft:
http://dev.w3.org/2011/webrtc/editor/webrtc.html
Previous version:
http://dev.w3.org/2011/webrtc/editor/webrtc-20120112.html
Editor:
Cullen Jennings, Cisco

Abstract

This is not a product of the WebRTC WG - it is merely a document being used to discuss possible changes to the documents that WG is developing. Much of the text here is from the WG document.

This document defines a set of APIs to represent streaming media, including audio and video, in JavaScript, to allow media to be sent over the network to another browser or device implementing the appropriate set of real-time protocols, and media received from another browser or device to be processed and displayed locally. This specification is being developed in conjunction with a protocol specification developed by the IETF RTCWEB group and an API specification to get access to local media devices developed by the Media Capture Task Force.

Status of This Document

This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current W3C publications and the latest revision of this technical report can be found in the W3C technical reports index at http://www.w3.org/TR/.

This document is not complete. It is subject to major changes and, while early experimentations are encouraged, it is therefore not intended for implementation. The API is based on preliminary work done in the WHATWG. The Web Real-Time Communications Working Group expects this specification to evolve significantly based on:

This document was published by the Web Real-Time Communications Working Group as a Member Submission. If you wish to make comments regarding this document, please send them to public-webrtc@w3.org (subscribe, archives). All feedback is welcome.

Publication as a Member Submission does not imply endorsement by the W3C Membership. This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress.

This document was produced by a group operating under the 5 February 2004 W3C Patent Policy. W3C maintains a public list of any patent disclosures made in connection with the deliverables of the group; that page also includes instructions for disclosing a patent. An individual who has actual knowledge of a patent which the individual believes contains Essential Claim(s) must disclose the information in accordance with section 6 of the W3C Patent Policy.

Table of Contents

1. 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].

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.

2. Introduction

This section is non-normative.

There are a number of facets to video-conferencing in HTML covered by this specification:

This document defines the APIs used for these features. This specification is being developed in conjunction with a protocol specification developed by the IETF RTCWEB group and an API specification to get access to local media devices developed by the Media Capture Task Force.

3. Stream API

3.1 Introduction

The MediaStream interface is used to represent streams of media data, typically (but not necessarily) of audio and/or video content, e.g. from a local camera or a remote site. The data from a MediaStream object does not necessarily have a canonical binary form; for example, it could just be "the video currently coming from the user's video camera". This allows user agents to manipulate media streams in whatever fashion is most suitable on the user's platform.

Each MediaStream object can contain zero or more tracks, in particular audio and video tracks. All tracks in a MediaStream are intended to be synchronized when rendered. Different MediaStreams do not need to be synchronized.

Each track in a MediaStream object has a corresponding MediaStreamTrack object.

A MediaStreamTrack represents content comprising one or more channels, where the channels have a defined well known relationship to each other (such as a stereo or 5.1 audio signal), and are intended to be encoded together for transmission as, for instance, an RTP payload type. One MediaStreamTrack sent to another peer must appear as one and only one MediaStreamTrack to the recipient. All of the channels that a codec needs to encode the media must be in the same MediaStreamTrack and the codecs should be able to encode, or discard, all the channels in the track.

A channel is the smallest atomic unit of media considered in this API specification.

A MediaStream object has an input and an output. The input depends on how the object was created: a LocalMediaStream object generated by a getUserMedia() [GETUSERMEDIA] call, for instance, might take its input from the user's local camera, while a MediaStream created by a PeerConnection object will take as input the data received from a remote peer. The output of the object controls how the object is used, e.g. what is saved if the object is written to a file, what is displayed if the object is used in a video element, or indeed what is transmitted to a remote peer if the object is used with a PeerConnection object.

Each track in a MediaStream object can be disabled, meaning that it is muted in the object's output. All tracks are initially enabled.

A MediaStream can be finished, indicating that its inputs have forever stopped providing data.

The output of a MediaStream object must correspond to the tracks in its input. Muted audio tracks must be replaced with silence. Muted video tracks must be replaced with blackness.

A new MediaStream object can be created from existing MediaStreamTrack objects using the MediaStream() constructor. The constructor takes two lists of MediaStreamTrack objects as arguments; one for audio tracks and one for video tracks. The lists can either be the track lists of another stream, subsets of such lists, or compositions of MediaStreamTrack objects from different MediaStream objects.

The ability to duplicate a MediaStream , i.e. create a new MediaStream object from the track lists of an existing stream, allows for greater control since separate MediaStream instances can be manipulated and consumed individually. This 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 makes it possible to, e.g., record selected tracks from a conversation involving several MediaStream objects with a single MediaStreamRecorder .

The LocalMediaStream interface is used when the user agent is generating the stream's data (e.g. from a camera or streaming it from a local video file).

When a LocalMediaStream object is being generated from a local file (as opposed to a live audio/video source), the user agent should stream the data from the file in real time, not all at once. This reduces the ease with which pages can distinguish live video from pre-recorded video, which can help protect the user's privacy.

3.2 Interface definitions

3.2.1 MediaStream

The MediaStream() constructor takes two arguments. The arguments are two lists with MediaStreamTrack objects which will be used to construct the audio and video track lists of the new MediaStream object. When the constructor is invoked, the UA must run the following steps:

  1. Let audioTracks be the constructor's first argument.

  2. Let videoTracks be the constructor's second argument.

  3. Let stream be a newly constructed MediaStream object.

  4. Set stream's label attribute to a newly generated value.

  5. If audioTracks is not null, then run the following sub steps for each element track in audioTracks:

    1. If track is of any other kind than "audio", then throw a SyntaxError exception.

    2. If track has the same underlying source as another element in stream's audio track list, then abort these steps.

    3. Add track to stream's audio track list.

  6. If videoTracks is not null, then run the following sub steps for each element track in videoTracks:

    1. If track is of any other kind than "video", then throw a SyntaxError exception.

    2. If track has the same underlying source as another element in stream's video track list, then abort these steps.

    3. Add track to stream's video track list.

A MediaStream can have multiple audio and video sources (e.g. because the user has multiple microphones, or because the real source of the stream is a media resource with many media tracks). The stream represented by a MediaStream thus has zero or more tracks.

The tracks of a MediaStream are stored in two track lists represented by MediaStreamTrackList objects; one for audio tracks and one for video tracks. The two track lists must contain the MediaStreamTrack objects that correspond to the tracks of the stream. The relative order of all tracks in a user agent must be stable. Tracks that come from a media resource whose format defines an order must be in the order defined by the format; tracks that come from a media resource whose format does not define an order must be in the relative order in which the tracks are declared in that media resource. Within these constraints, the order is user-agent defined.

An object that reads data from the output of a MediaStream is referred to as a MediaStream consumer. The list of MediaStream consumers currently include the media elements, PeerConnection and MediaStreamRecorder .

MediaStream consumers be able to handle tracks being added and removed. This behavior is specifier per consumer.

A new media component may be associated with an existing MediaStream . This happens, e.g., on the A-side when the B-side adds a new MediaStreamTrack object to one of the track lists of a MediaStream that is being sent over a PeerConnection . If this happens for the reason exemplified, or for any other reason than the add() method being invoked locally on a MediaStreamTrackList or tracks are being added as the stream is created (i.e. the stream is initialized with tracks), the user agent must run the following steps:

  1. Create a MediaStreamTrack object track to represent the new media component.

  2. If track's kind attribute equals "audio", add it to the MediaStream object's audioTracks MediaStreamTrackList object.

  3. If track's kind attribute equals "video", add it to the MediaStream object's videoTracks MediaStreamTrackList object.

  4. Fire a track event named addtrack with the newly created track at the MediaStreamTrackList object.

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

  1. Let track be the MediaStreamTrack object representing the media component about to be removed.

  2. Remove track from the MediaStreamTrackList object.

  3. Fire a track event named removetrack with track at the MediaStreamTrackList object.

A MediaStream object is said to be finished when all tracks belonging to the stream have ended. When this happens for any reason other than the stop() method being invoked, the user agent must queue a task that runs the following steps:

  1. If the object's ended attribute has the value true already, then abort these steps. (The stop() method was probably called just before the stream stopped for other reasons, e.g. the user clicked an in-page stop button and then the user agent provided stop button.)

  2. Set the object's ended attribute to true.

  3. Fire a simple event named ended at the object.

If the end of the stream was reached due to a user request, the task source for this task is the user interaction task source. Otherwise the task source for this task is the networking task source.

[Constructor (MediaStreamTrackList? audioTracks, MediaStreamTrackList? videoTracks)]
interface MediaStream {
    readonly attribute DOMString            label;
    readonly attribute MediaStreamTrackList audioTracks;
    readonly attribute MediaStreamTrackList videoTracks;
    MediaStreamRecorder record ();
             attribute boolean              ended;
             attribute Function?            onended;
};
3.2.1.1 Attributes
audioTracks of type MediaStreamTrackList, readonly

Returns a MediaStreamTrackList object representing the audio tracks that can be enabled and disabled.

The audioTracks attribute must return an array host object for objects of type MediaStreamTrack that is fixed length and read only. The same object must be returned each time the attribute is accessed.

ended of type boolean

The MediaStream.ended attribute must return true if the MediaStream has finished, and false otherwise.

When a MediaStream object is created, its ended attribute must be set to false, unless it is being created using the MediaStream() constructor whose arguments are lists of MediaStreamTrack objects that are all ended, in which case the MediaStream object must be created with its ended attribute set to true.

label of type DOMString, readonly

Returns a label that is unique to this stream, so that streams can be recognized after they are sent through the PeerConnection API.

When a LocalMediaStream object is created, the user agent must generate a globally unique identifier string, and must initialize the object's label attribute to that string. Such strings must only use characters in the ranges U+0021, U+0023 to U+0027, U+002A to U+002B, U+002D to U+002E, U+0030 to U+0039, U+0041 to U+005A, U+005E to U+007E, and must be 36 characters long.

TODO NOTE - I think we have this slightly wrong. It is the Track on the Stream that needs the label. Also, how do you set the label on a Track.

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

When a MediaStream is created from another using the MediaStream() constructor, the label attribute is initialized to a newly generated value.

The label attribute must return the value to which it was initialized when the object was created.

The label 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 to a remote peer using PeerConnection , and then sent back to the original user in the same manner, in which case the original user will have multiple streams with the same label (the locally-generated one and the one received from the remote peer).

onended of type Function, nullable
This event handler, of type ended , must be supported by all objects implementing the MediaStream interface.
videoTracks of type MediaStreamTrackList, readonly

Returns a MediaStreamTrackList object representing the video tracks that can be enabled and disabled.

The videoTracks attribute must return an array host object for objects of type MediaStreamTrack that is fixed length and read only. The same object must be returned each time the attribute is accessed.

3.2.1.2 Methods
record

Begins recording the stream. The returned MediaStreamRecorder object provides access to the recorded data.

When the record() method is invoked, the user agent must return a new MediaStreamRecorder object associated with the stream.

No parameters.
Return type: MediaStreamRecorder
MediaStream implements EventTarget;

3.2.2 LocalMediaStream

Before the web application can access the users media input devices it must let getUserMedia() [GETUSERMEDIA] create a LocalMediaStream . Once the application is done using, e.g., a webcam and a microphone, it may revoke its own access by calling stop() on the LocalMediaStream .

A web application may, once it has access to a LocalMediaStream , use the MediaStream() constructor to construct additional MediaStream objects. Since a derived MediaStream object is created from the tracks of an existing stream, it cannot use any media input devices that have not been approved by the user.

interface LocalMediaStream : MediaStream {
    void stop ();
};
3.2.2.1 Methods
stop

When a LocalMediaStream object's stop() method is invoked, the user agent must queue a task that runs the following steps on every track:

  1. Let track be the current MediaStreamTrack object.

  2. End track. The track start outputting only silence and/or blackness, as appropriate.

  3. Dereference track's underlying media source.

  4. If the reference count of track's underlying media source is greater than zero, then abort these steps.

  5. Permanently stop the generation of data for track's source. If the data is being generated from a live source (e.g. a microphone or camera), then the user agent should remove any active "on-air" indicator for that source. If the data is being generated from a prerecorded source (e.g. a video file), any remaining content in the file is ignored.

The task source for the tasks queued for the stop() method is the DOM manipulation task source.

No parameters.
Return type: void

3.2.3 MediaStreamTrack

A MediaStreamTrack object represents a media source in the user agent. Several MediaStreamTrack objects can represent the same media source, e.g., when the user chooses the same camera in the UI shown by two consecutive calls to getUserMedia() [GETUSERMEDIA].

A MediaStreamTrack object can reference its media source in two ways, either with a strong or a weak reference, depending on how the track was created. For example, a track in a MediaStream , derived from a LocalMediaStream with the MediaStream() constructor, has a weak reference to a local media source, while a track in a LocalMediaStream has a strong reference. This means that a track in a MediaStream , derived from a LocalMediaStream , will end if there is no non-ended track in a LocalMediaStream which references the same local media source. A reference to a non-local media source as, e.g., an RTP source, is always strong.

The concept with strong and weak references to media sources allows the web application to derive new MediaStream objects from LocalMediaStream objects (created via getUserMedia() [GETUSERMEDIA]), and still be able to revoke all given permissions with LocalMediaStream.stop() .

A MediaStreamTrack object is said to end when the user agent learns that no more data will ever be forthcoming for this track.

When a MediaStreamTrack object ends for any reason (e.g. because the user rescinds the permission for the page to use the local camera, or because the data comes from a finite file and the file's end has been reached and the user has not requested that it be looped, or because the track belongs to a MediaStream that comes from a remote peer and the remote peer has permanently stopped sending data, or because the UA has instructed the track to end for any reason, or because the reference count of the track's underlying media source has reached zero, it is said to be ended. When track instance track ends for any reason other than stop() method being invoked on the LocalMediaStream object that represents track, the user agent must queue a task that runs the following steps:

  1. If the track's readyState attribute has the value ENDED (2) already, then abort these steps.

  2. Set track's readyState attribute to ENDED (2).

  3. Fire a simple event named ended at the object.

interface MediaStreamTrack {
    readonly attribute DOMString      kind;
    readonly attribute DOMString      label;
             attribute boolean        enabled;
    const unsigned short LIVE = 0;
    const unsigned short MUTED = 1;
    const unsigned short ENDED = 2;
    readonly attribute unsigned short readyState;
             attribute Function?      onmute;
             attribute Function?      onunmute;
             attribute Function?      onended;
};
3.2.3.1 Attributes
enabled of type boolean

The MediaStreamTrack.enabled attribute, on getting, must return the last value to which it was set. On setting, it must be set to the new value, and then, if the MediaStreamTrack object is still associated with a track, must enable the track if the new value is true, and disable it otherwise.

Thus, after a MediaStreamTrack is disassociated from its track, its enabled attribute still changes value when set, it just doesn't do anything with that new value.

kind of type DOMString, readonly

The MediaStreamTrack.kind attribute must return the string "audio" if the object's corresponding track is or was an audio track, "video" if the corresponding track is or was a video track, and a user-agent defined string otherwise.

label of type DOMString, readonly

TODO - note - do we need the label from a Stream here. Do these labels need to be globally unique. If not what is the name scoping

User agents may label audio and video sources (e.g. "Internal microphone" or "External USB Webcam"). The MediaStreamTrack.label attribute must return the label of the object's corresponding track, if any. If the corresponding track has or had no label, the attribute must instead return the empty string.

Thus the kind and label attributes do not change value, even if the MediaStreamTrack object is disassociated from its corresponding track.

onended of type Function, nullable
This event handler, of type ended , must be supported by all objects implementing the MediaStreamTrack interface.
onmute of type Function, nullable
This event handler, of type muted , must be supported by all objects implementing the MediaStreamTrack interface.
onunmute of type Function, nullable
This event handler, of type unmuted , must be supported by all objects implementing the MediaStreamTrack interface.
readyState of type unsigned short, readonly

The readyState attribute represents the state of the track. It must return the value to which the user agent last set it (as defined below). It can have the following values: LIVE, MUTED or ENDED.

When a MediaStreamTrack object is created, its readyState is either LIVE (0) or MUTED (1), depending on the state of the track's underlying media source. For example, a track in a LocalMediaStream , created with getUserMedia() [GETUSERMEDIA] , must initially have its readyState attribute set to LIVE (1), while a track in a MediaStream , received with a PeerConnection , must have its readyState attribute set to MUTED (1) until media data arrives.

3.2.3.2 Constants
ENDED of type unsigned short

The track has ended (the track's underlying media source is no longer providing data, and will never provide more data for this track).

For example, a video track in a LocalMediaStream finishes if the user unplugs the USB web camera that acts as the track's media source.

LIVE of type unsigned short

The track is active (the track's underlying media source is making a best-effort attempt to provide data in real time).

The output of a track in the LIVE state can be switched on and off with the enabled attribute.

MUTED of type unsigned short

The track is muted (the track's underlying media source is temporarily unable to provide data).

For example, a track is muted on the B-side if the A-side disables the corresponding MediaStreamTrack in the MediaStream that is being sent. A MediaStreamTrack in a LocalMediaStream may be muted if the user temporarily revokes the web application's permission to use a media input device.

When the addstream event triggers on a PeerConnection , all MediaStreamTrack objects in the resulting MediaStream are muted until media data can be read from the RTP source.

3.2.4 AudioMediaStreamTrack

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);
};
3.2.4.1 Attributes
canInsertDTMF of type boolean, readonly

The canInsertDTMF attribute must indicate if the AudioMediaStreamTrack is capable of sending DTMF.

3.2.4.2 Methods
insertDTMF

When a 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 to 9, A to D, #, and * generated the associated DTMF tones. The characters a to d are equivalent to A to D. The character , indicates a an delay of 2 seconds before processing the next character in the tones parameter. Unrecognized characters are ignored.

The duration parameters indicates the duration in ms to play the each DTMF passed in the tones parameters. The duration can not 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.

If insertDTMF is called on the same object while an existing task for this object is 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 send.

Editor Note: We need to add a callback that is set on the object 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.

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.

ParameterTypeNullableOptionalDescription
tonesDOMString
durationlong
Return type: void

3.2.5 MediaStreamTrackList

A MediaStreamTrackList object's corresponding MediaStream refers to the MediaStream object which the current MediaStreamTrackList object is a property of.

interface MediaStreamTrackList {
    readonly attribute unsigned long length;
    MediaStreamTrack item (unsigned long index);
    void             add (MediaStreamTrack track);
    void             remove (MediaStreamTrack track);
             attribute Function?     onaddtrack;
             attribute Function?     onremovetrack;
};
3.2.5.1 Attributes
length of type unsigned long, readonly
Returns the number of tracks in the list.
onaddtrack of type Function, nullable
This event handler, of type addtrack , must be supported by all objects implementing the MediaStreamTrackList interface.
onremovetrack of type Function, nullable
This event handler, of type removetrack , must be supported by all objects implementing the MediaStreamTrackList interface.
3.2.5.2 Methods
add

Adds the given MediaStreamTrack to this MediaStreamTrackList according to the ordering rules for tracks.

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

  1. Let track be the MediaStreamTrack argument.

  2. Let stream be the MediaStreamTrackList object's corresponding MediaStream object.

  3. If stream is finished, throw an INVALID_STATE_ERR exception.

  4. If track is already in the MediaStreamTrackList , object's internal list, then abort these steps.

  5. Add track to the end of the MediaStreamTrackList object's internal list.

ParameterTypeNullableOptionalDescription
trackMediaStreamTrack
Return type: void
item
Returns the MediaStreamTrack object at the specified index.
ParameterTypeNullableOptionalDescription
indexunsigned long
Return type: MediaStreamTrack
remove

Removes the given MediaStreamTrack from this MediaStreamTrackList .

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

  1. Let track be the MediaStreamTrack argument.

  2. Let stream be the MediaStreamTrackList object's corresponding MediaStream object.

  3. If stream is finished, throw an INVALID_STATE_ERR exception.

  4. If track is not in the MediaStreamTrackList , object's internal list, then abort these steps.

  5. Remove track from the MediaStreamTrackList object's internal list.

ParameterTypeNullableOptionalDescription
trackMediaStreamTrack
Return type: void

3.2.6 MediaStreamRecorder

The MediaStreamRecorder needs to be able to handle the case that arises when changes are made to the MediaStreamTrackList objects of the MediaStream being recorded; e.g., a new track is added as a result of the add() method being invoked.

interface MediaStreamRecorder {
    voice getRecordedData (BlobCallback? callBack);
};
3.2.6.1 Methods
getRecordedData

Creates a Blob of the recorded data, and invokes the provided callback with that Blob.

When the getRecordedData() method is called, the user agent must run the following steps:

  1. Let callBack be the callback indicated by the method's first argument.

  2. If callBack is null, abort these steps.

  3. Let data be the data that was streamed by the MediaStream object from which the MediaStreamRecorder was created since the creation of the MediaStreamRecorder object.

  4. Return, and run the remaining steps asynchronously.

  5. Generate a file that containing data in a format supported by the user agent for use in audio and video elements.

  6. Let blob be a Blob object representing the contents of the file generated in the previous step. [FILE-API]

  7. Queue a task to invoke callBack with blob as its argument.

The getRecordedData() method can be called multiple times on one MediaStreamRecorder object; each time, it will create a new file as if this was the first time the method was being called. In particular, the method does not stop or reset the recording when the method is called.

ParameterTypeNullableOptionalDescription
callBackBlobCallback
Return type: voice

3.2.7 BlobCallback

[Callback, NoInterfaceObject]
interface BlobCallback {
    void handleEvent (Blob blob);
};
3.2.7.1 Methods
handleEvent
Def TBD
ParameterTypeNullableOptionalDescription
blobBlob
Return type: void

3.2.8 URL

partial interface URL {
    static DOMString createObjectURL (MediaStream stream);
};
3.2.8.1 Methods
createObjectURL

Mints a Blob URL to refer to the given MediaStream .

When the createObjectURL() method is called with a MediaStream argument, the user agent must return a unique Blob URL for the given MediaStream . [FILE-API]

For audio and video streams, the data exposed on that stream must be in a format supported by the user agent for use in audio and video elements.

A Blob URL is the same as what the File API specification calls a Blob URI, except that anything in the definition of that feature that refers to File and Blob objects is hereby extended to also apply to MediaStream and LocalMediaStream objects.

ParameterTypeNullableOptionalDescription
streamMediaStream
Return type: static DOMString

4. Peer-to-peer connections

A PeerConnection allows two users to communicate directly, browser to browser. Communications are coordinated via a signaling channel provided by script in the page via the server, e.g. using XMLHttpRequest.

Calling new PeerConnection(configuration ) creates a PeerConnection object.

The configuration is a array of pairs where each pair is an array where the first element is a stun or turn URIs as defined in [STUN-URI] and [TURN-URI]. The if the first element of the pair is TURN URI, then the second element of the pair is the credential to use with that TURN server. This configuration array give the addresses of STUN and TURN server to use to establish the connection. [STUN] [TURN]

An example configuration array is:

[ ["stun:stun.example.org"] , ["turn:user@turn.example.org","myPassword"] ]

A PeerConnection object has an associated a PeerConnection ICE Agent, and a PeerConnection readiness state. These are initialized when the object is created.

When the PeerConnection() 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). Steps in the synchronous section are marked with ⌛.

  1. Create an ICE Agent and let connection’s PeerConnection ICE Agent be that ICE Agent and provide it the STUN and TURN servers from the configuration array. [ICE]

  2. Set connection’s PeerConnection readiness state to NEW (0).

  3. Set connection’s PeerConnection ice state to NEW (0).

  4. Let connection’s localStreams attribute be an empty read-only MediaStream array.

  5. Let connection’s remoteStreams attribute be an empty read-only MediaStream array.

  6. Return connection, but continue these steps asynchronously.

  7. Await a stable state. The synchronous section consists of the remaining steps of this algorithm.

  8. If the ice state is set to NEW, it must queue a task to start gathering ICE address and set the ice state to ICE_GATHERING.

During the lifetime of the PeerConnection object, the following procedures are followed:

  1. If the ICE Agent finds a candidates that forms a valid connection, the ICE state is changed to ICE_CONNECTED

  2. If the ICE Agent finishes checking all candidates, if a connection has been found, the ice state is changed to ICE_COMPLETED and if not connection has been found it is changed to ICE_FAILED.

  3. If the iceState is ICE_CONNECTED or ICE_COMPLETED and the SDP stat is SDP_IDLE, the readyState is set to ACTIVE.

  4. If the iceState is ICE_FAILED, a task is queued to calls the close method.

  5. The close method will stop all ICE process and change the iceState to ICE_CLOSED.

User agents may negotiate any codec and any resolution, bitrate, or other quality metric. User agents are encouraged to initially negotiate for the native resolution of the stream. For streams that are then rendered (using a video element), user agents are encouraged to renegotiate for a resolution that matches the rendered display size.

Starting with the native resolution means that if the Web application notifies its peer of the native resolution as it starts sending data, and the peer prepares its video element accordingly, there will be no need for a renegotiation once the stream is flowing.

All SDP media descriptions for streams represented by MediaStream objects must include a label attribute ("a=label:") whose value is the value of the MediaStream object's label attribute. [SDP] [SDPLABEL]

PeerConnections must not generate any candidates for media streams whose media descriptions do not have a label attribute ("a=label:"). [ICE] [SDP] [SDPLABEL]

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

  1. Let connection be the PeerConnection expecting this media.

  2. Create a MediaStream object to represent the media stream. Set its label attribute to the value of the SDP Label attribute for that component's media stream.

  3. Run the following steps for each component in the media stream.

    1. Create a MediaStreamTrack object track to represent the component.

    2. If track's kind attribute equals "audio", add it to the MediaStream object's audioTracks MediaStreamTrackList object.

    3. If track's kind attribute equals "video", add it to the MediaStream object's videoTracks MediaStreamTrackList object.

    The internal order in the MediaStreamTrackList objects on the receiving side should reflect the order on the sending side. One way to enforce this is to specify the order in the SDP.

  4. Queue a task to run the following substeps:

    1. If the connection’s PeerConnection readiness state is CLOSED (3), abort these steps.

    2. Add the newly created MediaStream object to the end of connection’s remoteStreams array.

    3. Fire a stream event named addstream with the newly created MediaStream object 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 a PeerConnection finds that a stream from the remote peer has been removed (its port has been set to zero in a media description sent on the signaling channel), the user agent must follow these steps:

  1. Let connection be the PeerConnection associated with the stream being removed.

  2. Let stream be the MediaStream object that represents the media stream being removed, if any. If there isn't one, then abort these steps.

  3. By definition, stream is now finished.

    A task is thus queued to update stream and fire an event.

  4. Queue a task to run the following substeps:

    1. If the connection’s PeerConnection readiness state is CLOSED (3), 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 a PeerConnection object is consuming a MediaStream and a track is added to one of the stream's MediaStreamTrackList objects, by, e.g., the add() method being invoked, the PeerConnection object must add a media component for that track the next time the user agent provides a stable state. The user agent must also remove a media component in same way.

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.1 PeerConnection

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

typedef SdpType DomString; //enum SdpType { "offer", "pranswer", "answer" }

The SdpType enums serve as arguments to setLocalDescription and setRemoteDescription. They provide information as to how the SDP should be handled.

"offer"

An SdpType of "offer" indicates that a description should be treated as an [SDP] offer. A description used as a SDP offer may be applied anytime the PeerConnection is in a stable state, or as an update to a previously sent but unanswered SDP offer.

"pranswer"

An SdpType of "pranswer" indicates that a description should be treated as an [SDP] answer, but not a final answer. A description used as a SDP "pranswer" may be applied as a response to a SDP offer, or an update to a previously sent SDP "answer".

"answer"

An SdpType 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 a SDP answer may be applied as a response to a SDP offer, or an update to a previously send SDP "pranswer".

typedef PeerState DomString; //enum PeerState { "new" "opening", "active", "closing", "closed" }
"new"
The object was just created, and no networking has yet occurred.
"opening"
The user agent is attempting to establish an connection with the ICE Agent and waiting for local and remote SDP to be set.
"active"
The ICE Agent has found a connection both the local and remote SDP have been set. It is possible for media to flow.
"closing"
The PeerConnection object is terminating all media and is in the process of closing the connection.
"closed"
The connection is closed.
typedef IceState DomString; //enum IceState { "new" "gathering", "waiting", "checking", "connected", "completed","failed", "closed" }

The IceState can take the following values:

"new"
The PeerConnection object was just created, and no networking has yet occurred.
"gathering"
The ICE Agent is attempting to gather addresses.
"waiting"
The ICE Agent is not gathering any addresses and is waiting for candidates from the other side before it can start checking.
"checking"
The ICE Agent is checking candidates but has not yet found a connection.
"connected"
The ICE Agent has found a connection but is still checking other candidates to see if there is a better connection.
"completed"
The ICE Agent has finished checking and found a connection.
"failed"
The ICE Agent is finished checking all candidates and failed to find a connection.
"closed"
The ICE Agent has shut down and is no longer responding to STUN requests.
typedef Configuration DomString[][];

TODO

[Constructor (Configuration configuration)]
interface PeerConnection {
    DOMString createAnswer (DOMString offer, optional MediaConstraints constraints);
    DOMString createOffer (MediaConstraints constraints);
    readonly attribute DOMString     localDescription;
    void      setLocalDescription (SdpType action, DOMString sdp);
    void      setRemoteDescription (SdpType action, DOMString sdp);
    readonly attribute DOMString     remoteDescription;
    readonly attribute PeerState     readyState;
    void      startIce (optional MediaConstraints constraints);
    void      addIceCandidate (IceCandidate candidate);
    readonly attribute IceState      iceState;
    readonly attribute MediaStream[] localStreams;
    readonly attribute MediaStream[] remoteStreams;
    void      addStream (MediaStream stream, optional MediaConstraints constraints);
    void      removeStream (MediaStream stream);
    void      close ();
             attribute Function?     onconnecting;
             attribute Function?     onopen;
             attribute Function?     onstatechange;
             attribute Function?     onaddstream;
             attribute Function?     onremovestream;
             attribute Function?     onicechange;
};

4.1.1 Attributes

iceState of type IceState, readonly

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

localDescription of type DOMString, readonly

The localDescription method returns a copy of the current local configuration, i.e. the answer 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 with an answer.

localStreams of type array of MediaStream, readonly

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

onaddstream of type Function, nullable
This event handler, of event handler event type addstream , must be supported by all objects implementing the PeerConnection interface.
onconnecting of type Function, nullable
This event handler, of event handler event type connecting , must be supported by all objects implementing the PeerConnection interface.
onicechange of type Function, nullable
This event handler, of event handler event type icechange , must be supported by all objects implementing the PeerConnection interface. It is called any time the iceState changes.
onopen of type Function, nullable
This event handler, of event handler event type open , must be supported by all objects implementing the PeerConnection interface.
onremovestream of type Function, nullable
This event handler, of event handler event type removestream , must be supported by all objects implementing the PeerConnection interface.
onstatechange of type Function, nullable
This event handler, of event handler event type open , must be supported by all objects implementing the PeerConnection interface. It is called any time the readyState changes.
readyState of type PeerState, readonly

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

remoteDescription of type DOMString, readonly

The remoteDescription method returns a copy of the current remote configuration, i.e. the answer 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 with an answer.

remoteStreams of type array of MediaStream, readonly

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

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

4.1.2 Methods

addIceCandidate

The addIceCandidate method provides a remote candidate to the ICE Agent, which will be added to the remote description. If startIce has been called, connectivity checks will be sent to the new candidates (as long as they would not be restricted by the "media-enum-relay-only" constraint. 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 connectivity being established.

The format of the candidate is TODO (same as line with ICE info in SDP)

A TBD exception will be thrown if candidate parameter is malformed.

ParameterTypeNullableOptionalDescription
candidateIceCandidate
Return type: void
addStream

Attempts to starting sending the given stream to the remote peer.

When the other peer starts sending a stream in this manner, an addstream event is fired at the PeerConnection object.

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

  1. If the PeerConnection object's PeerConnection readiness state is CLOSED (3), throw an INVALID_STATE_ERR exception.

  2. If stream is already in the PeerConnection object's localStreams object, then abort these steps.

  3. Add stream to the end of the PeerConnection object's localStreams object.

  4. Return from the method.

  5. Parse the constraints provided by the application and apply them to the MediaStream, if possible. NOTE - need to deal with throwing an exception here.

  6. Have the PeerConnection add a media stream for stream the next time the user agent provides a stable state. Any other pending stream additions and removals must be processed at the same time.

ParameterTypeNullableOptionalDescription
streamMediaStream
constraintsMediaConstraints
Return type: void
close

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

  1. If the PeerConnection object's PeerConnection readiness state is CLOSED (3), throw an INVALID_STATE_ERR exception.

  2. Destroy the PeerConnection ICE Agent, abruptly ending any active ICE processing and any active streaming, and releasing any relevant resources (e.g. TURN permissions).

  3. Set the object's PeerConnection readiness state to CLOSED (3).

The localStreams and remoteStreams objects remain in the state they were in when the object was closed.

No parameters.
Return type: void
createAnswer

The createAnswer method generates a [SDP] answer with the supported configuration for the session that is compatible with the parameters supplied in offer. Like createOffer, the returned blob contains descriptions of the local MediaStreams attached to this PeerConnection, 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 specifies how the media plane should be established. For each SDP line, 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; like createOffer, the returned description should reflect the current state of the system. Calling this method is not required.

A TBD exception is thrown if the constraints parameter is malformed, or the offer parameter is malformed.

ParameterTypeNullableOptionalDescription
offerDOMString
constraintsMediaConstraints
Return type: DOMString
createOffer

The createOffer method generates a blob of SDP that contains a RFC offer with the supported configurations for the session, including descriptions of the local MediaStreams attached to this PeerConnection, 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.

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 be include the capabilities of the current local description.

Session descriptions generated by createOffer must be immediately usable by setLocalDescription without causing an error; if a system has limited resources (e.g. a finite number of decoders), createOffer should return an offer that reflects the current state of the system, so that setLocalDescription will succeed when it attempts to acquire those resources. Calling this method is not required.

ParameterTypeNullableOptionalDescription
constraintsMediaConstraints
Return type: DOMString
removeStream

Stops sending the given stream to the remote peer.

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

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

  1. If the PeerConnection object's PeerConnection readiness state is CLOSED (3), throw an INVALID_STATE_ERR exception.

  2. If stream is not in the PeerConnection object's localStreams object, then abort these steps.

  3. Remove stream from the PeerConnection object's localStreams object.

  4. Return from the method.

  5. Have the PeerConnection remove the media stream for stream the next time the user agent provides a stable state. Any other pending stream additions and removals must be processed at the same time.

ParameterTypeNullableOptionalDescription
streamMediaStream
Return type: void
setLocalDescription

The setLocalDescription method instructs the PeerConnection to apply the supplied [SDP] blob as the local offer or answer. The type parameter indicates whether the blob should be processed as an offer, provisional answer, or final answer.

This API changes the local media state; among other things, it sets up local resources for receiving and decoding media. In order to successfully handle scenarios where the application wants to offer to change from one media format to a different, incompatible format, the PeerConnection 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 PeerConnection can fully adopt the new local description, or roll back to the old description if the remote side denied the change.

Changes to the state of media transmission will occur when a final answer is successfully applied.

A TBD exception is thrown if sdp is invalid. A TBD exception is thrown if there are insufficient local resources to apply the sdp.

ParameterTypeNullableOptionalDescription
actionSdpType
sdpDOMString
Return type: void
setRemoteDescription

The setRemoteDescription method instructs the PeerConnection to apply the supplied [SDP]. As in setLocalDescription, the action parameter indicates how the blob should be processed. This API changes the local media state; among other things, it sets up local resources for sending and encoding media.

Changes to the state of media transmission will occur when a final answer is successfully applied.

A TBD exception is thrown if the sdp parameter is invalid. A TBD exception is thrown if there are insufficient local resources to apply the SDP.

ParameterTypeNullableOptionalDescription
actionSdpType
sdpDOMString
Return type: void
startIce

The startIce method starts or updates the ICE Agent process of gathering local candidates and pinging remote candidates. If there is a mandatory constraint called "media-enum-relay-only" and it is set to true, the ICE engine must only use candidates that are thought a relay servers such as a TURN server. 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.

A TBD exception will be thrown if constraints is malformed.

ParameterTypeNullableOptionalDescription
constraintsMediaConstraints
Return type: void
PeerConnection implements EventTarget;

4.2 SignalingCallback

[Callback, NoInterfaceObject]
interface SignalingCallback {
    void handleEvent (DOMString message, PeerConnection source);
};

4.2.1 Methods

handleEvent
Def TBD
ParameterTypeNullableOptionalDescription
messageDOMString
sourcePeerConnection
Return type: void

4.3 Examples

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.

TODO

5. The data stream

Although progress is being made, there is currently not enough agreement on the data channel to write it up. This section will be filled in as rough consensus is reached.

6. Garbage collection

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

7. Event definitions

7.1 MediaStreamTrackEvent

The addtrack and removetrack events use the MediaStreamTrackEvent interface.

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

[Constructor(DOMString type, optional MediaStreamTrackEventInit eventInitDict)]
interface MediaStreamTrackEvent : Event {
    readonly attribute MediaStreamTrack? track;
};
dictionary MediaStreamTrackEventInit : EventInit { MediaStreamTrack? track; };

7.1.1 Attributes

track of type MediaStreamTrack, readonly, nullable

The track attribute represents the MediaStreamTrack object associated with the event.

7.1.2 Dictionary MediaStreamTrackEventInit Members

track of type MediaStreamTrack, nullable

-

7.2 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, optional MediaStreamEventInit eventInitDict)]
interface MediaStreamEvent : Event {
    readonly attribute MediaStream? stream;
};
dictionary MediaStreamEventInit : EventInit { MediaStream? stream; };

7.2.1 Attributes

stream of type MediaStream, readonly, nullable

The stream attribute represents the MediaStream object associated with the event.

7.2.2 Dictionary MediaStreamEventInit Members

stream of type MediaStream, nullable

-

8. Event summary

This section is non-normative.

The following event fires on MediaStream objects:

Event name Interface Fired when...
ended Event The MediaStream finished as a result of all tracks in the MediaStream ending.

The following event fires on MediaStreamTrack objects:

Event name Interface Fired when...
muted Event The MediaStreamTrack object's source is temporarily unable to provide data.
unmuted Event The MediaStreamTrack object's source is live again after having been temporarily unable to provide data.
ended Event The MediaStreamTrack object's source will no longer provide any data, either because the user revoked the permissions, or because the source device has been ejected, or because the remote peer stopped sending data, or because the stop() method was invoked.

The following event fires on MediaStreamTrackList objects:

Event name Interface Fired when...
addtrack MediaStreamTrackEvent A new MediaStreamTrack has been added to this list.
removetrack MediaStreamTrackEvent A MediaStreamTrack has been removed from this list.

The following events fire on PeerConnection objects:

Event name Interface Fired when...
connecting Event The ICE Agent has begun negotiating with the peer. This can happen multiple times during the lifetime of the PeerConnection object.
open Event The ICE Agent has finished negotiating with the peer.
message MessageEvent A data UDP media stream message was received.
addstream MediaStreamEvent A new stream has been added to the remoteStreams array.
removestream MediaStreamEvent A stream has been removed from the remoteStreams array.

9. IANA Registrations

9.1 Constraints Registrations

IANA is requested to register the following constraints as specified in [RTCWEB-CONSTRAINTS]:

media-enum-relay-only

This constraints indicat4es if the ICE engine is restricted to only using 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 constraint can be set to true or false. Defaults is false.

9.2 application/html-peer-connection-data

This registration is for community review and will be submitted to the IESG for review, approval, and registration with IANA.

Type name:
application
Subtype name:
html-peer-connection-data
Required parameters:
No required parameters
Optional parameters:
No optional parameters
Encoding considerations:
This MIME type defines a binary protocol format which uses UTF-8 for text encoding.
Security considerations:

This format is used for encoding UDP packets transmitted by potentially hostile Web page content via a trusted user agent to a destination selected by a potentially hostile remote server. To prevent this mechanism from being abused for cross-protocol attacks, all the data in these packets is masked so as to appear to be random noise. The intent of this masking is to reduce the potential attack scenarios to those already possible previously.

However, this feature still allows random data to be sent to destinations that might not normally have been able to receive them, such as to hosts within the victim's intranet. If a service within such an intranet cannot handle receiving UDP packets containing random noise, it might be vulnerable to attack from this feature.

Interoperability considerations:
Rules for processing both conforming and non-conforming content are defined in this specification.
Published specification:
This document is the relevant specification.
Applications that use this media type:
This type is only intended for use with SDP. [SDP]
Additional information:
Magic number(s):
No sequence of bytes can uniquely identify data in this format, as all data in this format is intentionally masked to avoid cross-protocol attacks.
File extension(s):
This format is not for use with files.
Macintosh file type code(s):
This format is not for use with files.
Person & email address to contact for further information:
Daniel C. Burnett <dburnett@voxeo.com>
Intended usage:
Common
Restrictions on usage:
No restrictions apply.
Author:
Daniel C. Burnett <dburnett@voxeo.com>
Change controller:
W3C

Fragment identifiers cannot be used with application/html-peer-connection-data as URLs cannot be used to identify streams that use this format.

10. Change Log

This section will be removed before publication.

To Do Items

Need a way to indicate the type of the SDP when passing SDP strings.

Changes since 12 January 2012

  1. Clarified what relation of Stream, Track, and Channel.

Changes since 17 October 2011

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

Changes since 23 August 2011

  1. Separated the SDP and ICE Agent into separate agents and added explicit state attributes for each.
  2. Removed the send method from PeerConenction and associated callback function.
  3. Modified MediaStream() constructor to take a list of MediaStreamTrack objects instead of a MediaStream. Removed text about MediaStream parent and child relationship.
  4. Added abstract.
  5. Moved a few paragraphs from the MediaStreamTrack.label section to the MediaStream.label section (where they belong).
  6. Split MediaStream.tracks into MediaStream.audioTracks and MediaStream.videoTracks.
  7. Removed a sentence that implied that track access is limited to LocalMediaStream.
  8. Updated a few getUserMedia()-examples to use MediaStreamOptions.
  9. Replaced calls to URL.getObjectURL() with URL.createObjectURL() in example code.
  10. Fixed some broken getUserMedia() links.
  11. Introduced state handling on MediaStreamTrack (removed state handling from MediaStream).
  12. Reintroduced onended on MediaStream to simplify checking if all tracks are ended.
  13. Aligned the MediaStreamTrack ended event dispatching behavior with that of MediaStream.
  14. Updated the LocalMediaStream.stop() algorithm to implicitly use the end track algorithm.
  15. Replaced an occurrence the term finished track with ended track (to align with rest of spec).
  16. Moved (and extended) the explanation about track references and media sources from LocalMediaStream to MediaStreamTrack.
  17. Removed section "Obtaining local multimedia content".
  18. Updated getUserMedia() calls in examples (changes in Media Capture TF spec).
  19. Introduced MediaStreamTrackList interface with support for adding and removing tracks.
  20. Updated the algorithm that is run when PeerConnection receives a stream (create new stream when negotiated instead of when data arrives).

A. Acknowledgements

The editors wish to thank the Working Group chairs, Harald Alvestrand and Stefan Håkansson, for their support.

B. References

B.1 Normative references

[FILE-API]
Arun Ranganathan; Jonas Sicking. File API. 20 October 2011. W3C Working Draft. (Work in progress.) URL: http://www.w3.org/TR/2011/WD-FileAPI-20111020/
[GETUSERMEDIA]
D. Burnett, A. Narayanan. getusermedia: Getting access to local devices that can generate multimedia streams 22 December 2011. W3C Editors draft (Work in progress.) URL: http://dev.w3.org/2011/webrtc/editor/getusermedia.html
[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
[SDPLABEL]
O. Levin, G. Camarillo. The Session Description Protocol (SDP) Label Attribute. August 2006. Internet RFC 4574. URL: http://tools.ietf.org/html/rfc4574
[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/