Initial Author of this Specification was Ian Hickson, Google Inc., with the following copyright statement:
© Copyright 2004-2011 Apple Computer, Inc., Mozilla Foundation, and Opera Software ASA. You are granted a license to use, reproduce and create derivative works of this document.
All subsequent changes since 26 July 2011 done by the W3C WebRTC Working Group are under the following Copyright:
© 2011-2012 W3C® (MIT, ERCIM, Keio), All Rights Reserved. Document use rules apply.
For the entire publication on the W3C site the liability and trademark rules apply.
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.
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.
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.
This section is non-normative.
There are a number of facets to video-conferencing in HTML covered by this specification:
video
or
audio
elements.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.
The
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.MediaStream
Each
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.MediaStream
Each track in a MediaStream object has a corresponding
object.MediaStreamTrack
A
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. MediaStreamTrack
A channel is the smallest atomic unit of media considered in this API specification.
A
object has an input and an output. The input depends on how
the object was created: a MediaStream
object generated by a LocalMediaStream
getUserMedia()
[GETUSERMEDIA] call, for instance, might take its input from the
user's local camera, while a
created by a MediaStream
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 PeerConnection
video
element, or indeed what is
transmitted to a remote peer if the object is used with a
object.PeerConnection
Each track in a
object can be disabled, meaning that it is muted in the
object's output. All tracks are initially enabled.MediaStream
A
can be finished, indicating that its inputs have
forever stopped providing data.MediaStream
The output of a
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.MediaStream
A new
object can be created from existing MediaStream
objects using the MediaStreamTrack
MediaStream()
constructor. The constructor takes two lists of
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 MediaStreamTrack
objects. MediaStream
The ability to duplicate a
, 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
MediaStream
objects with a single
MediaStreamRecorder
.
The
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).LocalMediaStream
When a
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.LocalMediaStream
The
MediaStream()
constructor takes two arguments. The arguments are two
lists with
objects which will be used to construct the audio and
video track lists of the new MediaStreamTrack
object. When the constructor is invoked, the UA must run
the following steps:MediaStream
Let audioTracks be the constructor's first argument.
Let videoTracks be the constructor's second argument.
Let stream be a newly constructed
object.MediaStream
Set stream's label attribute to a newly generated value.
If audioTracks is not null, then run the following sub steps for each element track in audioTracks:
If track is of any other kind than
"audio
", then throw a SyntaxError
exception.
If track has the same underlying source as another element in stream's audio track list, then abort these steps.
Add track to stream's audio track list.
If videoTracks is not null, then run the following sub steps for each element track in videoTracks:
If track is of any other kind than
"video
", then throw a SyntaxError
exception.
If track has the same underlying source as another element in stream's video track list, then abort these steps.
Add track to stream's video track list.
A
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.MediaStream
The tracks of a
are stored in two track lists represented by MediaStream
objects; one for audio tracks and one for video tracks.
The two track lists must contain the MediaStreamTrackList
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.MediaStreamTrack
An object that reads data from the output of a
is referred to as a MediaStream
consumer. The list of MediaStream
consumers currently include the media elements, MediaStream
and PeerConnection
.MediaStreamRecorder
consumers be able to handle tracks being added and
removed. This behavior is specifier per consumer.MediaStream
A new media component may be associated with an existing
. This happens, e.g., on the A-side when the B-side adds a
new MediaStream
object to one of the track lists of a MediaStreamTrack
that is being sent over a MediaStream
. If this happens for the reason exemplified, or for any
other reason than the PeerConnection
add()
method being invoked locally on a
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:MediaStreamTrackList
Create a
object track to represent the new media
component.MediaStreamTrack
If track's
kind
attribute equals "audio
", add it to the
object's MediaStream
audioTracks
object.MediaStreamTrackList
If track's
kind
attribute equals "video
", add it to the
object's MediaStream
videoTracks
object.MediaStreamTrackList
Fire a track event named
addtrack
with the newly created track at the
object.MediaStreamTrackList
An existing media component may also be disassociated from a
. If this happens for any other reason than the MediaStream
remove()
method being invoked locally on a
or the stream is being destroyed, the user agent must run
the following steps:MediaStreamTrackList
Let track be the
object representing the media component about to be
removed.MediaStreamTrack
Remove track from the
object.MediaStreamTrackList
Fire a track event named
removetrack
with track at the
object.MediaStreamTrackList
A
object is said to be finished when all tracks
belonging to the stream have ended. When this happens for any
reason other than the MediaStream
stop()
method being invoked, the user agent must queue a task
that runs the following steps:
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.)
Set the object's
ended
attribute to true.
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;
};
audioTracks
of type MediaStreamTrackList
, readonlyReturns a
object representing the audio tracks that can be
enabled and disabled.MediaStreamTrackList
The
audioTracks
attribute must return an array host object for objects
of type
that is fixed length and read only.
The same object must be returned each time the attribute is
accessed.MediaStreamTrack
ended
of type booleanThe
MediaStream.ended
attribute must return true if the
has finished, and false otherwise.MediaStream
When a
object is created, its MediaStream
ended
attribute must be set to false, unless it is being
created using the
MediaStream()
constructor whose arguments are lists of
objects that are all ended, in which case the
MediaStreamTrack
object must be created with its MediaStream
ended
attribute set to true.
label
of type DOMString, readonlyReturns 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
is created from another using the MediaStream
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
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 MediaStream
, 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).PeerConnection
onended
of type Function, nullable
ended
, must be supported by all objects implementing the
MediaStream
interface.videoTracks
of type MediaStreamTrackList
, readonlyReturns a
object representing the video tracks that can be
enabled and disabled.MediaStreamTrackList
The
videoTracks
attribute must return an array host object for objects
of type
that is fixed length and read only.
The same object must be returned each time the attribute is
accessed. MediaStreamTrack
record
Begins recording the stream. The returned
object provides access to the recorded data.MediaStreamRecorder
When the
record()
method is invoked, the user agent must return a new
object associated with the stream.MediaStreamRecorder
MediaStreamRecorder
MediaStream
implements EventTarget;
Before the web application can access the users media input
devices it must let getUserMedia()
[GETUSERMEDIA]
create a
. Once the application is done using, e.g., a webcam and a
microphone, it may revoke its own access by calling LocalMediaStream
stop()
on the
.
LocalMediaStream
A web application may, once it has access to a
, use the LocalMediaStream
MediaStream()
constructor to construct additional
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.MediaStream
interface LocalMediaStream : MediaStream
{
void stop ();
};
stop
When a
object's
LocalMediaStream
stop()
method is invoked, the user agent must queue a task
that runs the following steps on every track:
Let track be the current
object.MediaStreamTrack
End track. The track start outputting only silence and/or blackness, as appropriate.
Dereference track's underlying media source.
If the reference count of track's underlying media source is greater than zero, then abort these steps.
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.
void
A
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 MediaStreamTrack
getUserMedia()
[GETUSERMEDIA].
A
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 MediaStreamTrack
, derived from a MediaStream
with the LocalMediaStream
MediaStream()
constructor, has a weak reference to a local media source,
while a track in a
has a strong reference. This means that a track in a LocalMediaStream
, derived from a MediaStream
, 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.LocalMediaStream
The concept with strong and weak references to media
sources allows the web application to derive new
objects from MediaStream
objects (created via LocalMediaStream
getUserMedia()
[GETUSERMEDIA]), and still be able to revoke all given
permissions with
LocalMediaStream.stop()
.
A
object is said to end when the user agent learns
that no more data will ever be forthcoming for this track.MediaStreamTrack
When a
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 MediaStreamTrack
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 MediaStream
stop()
method being invoked on the
object that represents track, the user agent
must queue a task that runs the following steps:LocalMediaStream
If the track's
readyState
attribute has the value
ENDED
(2) already, then abort these steps.
Set track's
readyState
attribute to
ENDED
(2).
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;
};
enabled
of type booleanThe
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
object is still associated with a track, must enable
the track if the new value is true, and disable it
otherwise.MediaStreamTrack
Thus, after a
is disassociated from its track, its MediaStreamTrack
enabled
attribute still changes value when set, it just
doesn't do anything with that new value.
kind
of type DOMString, readonlyThe
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, readonlyTODO - 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
object is disassociated from its corresponding
track.MediaStreamTrack
onended
of type Function, nullable
ended
, must be supported by all objects implementing the
MediaStreamTrack
interface.onmute
of type Function, nullable
muted
, must be supported by all objects implementing the
MediaStreamTrack
interface.onunmute
of type Function, nullable
unmuted
, must be supported by all objects implementing the
MediaStreamTrack
interface.readyState
of type unsigned short, readonlyThe
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
object is created, its MediaStreamTrack
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
, created with LocalMediaStream
getUserMedia()
[GETUSERMEDIA] , must initially have its
readyState
attribute set to
LIVE
(1), while a track in a
, received with a MediaStream
, must have its PeerConnection
readyState
attribute set to
MUTED
(1) until media data arrives.
ENDED
of type unsigned shortThe 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
finishes if the user unplugs the USB web camera that
acts as the track's media source.LocalMediaStream
LIVE
of type unsigned shortThe 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 shortThe 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
in the MediaStreamTrack
that is being sent. A MediaStream
in a MediaStreamTrack
may be muted if the user temporarily revokes the web
application's permission to use a media input device.LocalMediaStream
When the addstream event triggers on a
, all PeerConnection
objects in the resulting MediaStreamTrack
are muted until media data can be read from the RTP
source.MediaStream
The
is a specialization of a normal AudioMediaStreamTrack
that only carries audio and is extended to have the
capability to send and/or receive DTMF codes.MediaStreamTrack
interface AudioMediaStreamTrack : MediaStreamTrack
{
readonly attribute boolean canInsertDTMF;
void insertDTMF (DOMString tones, optional long duration);
};
canInsertDTMF
of type boolean, readonlyThe
canInsertDTMF
attribute must indicate if the
is capable of sending DTMF. AudioMediaStreamTrack
insertDTMF
When a
object's
AudioMediaStreamTrack
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.
Parameter | Type | Nullable | Optional | Description |
---|---|---|---|---|
tones | DOMString | ✘ | ✘ | |
duration | long | ✘ | ✔ |
void
A
object's corresponding
MediaStreamTrackList
refers to the MediaStream
object which the current MediaStream
object is a property of.MediaStreamTrackList
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;
};
length
of type unsigned long, readonlyonaddtrack
of type Function, nullable
addtrack
, must be supported by all objects implementing the
MediaStreamTrackList
interface.onremovetrack
of type Function, nullable
removetrack
, must be supported by all objects implementing the
MediaStreamTrackList
interface.add
Adds the given
to this MediaStreamTrack
according to the ordering rules for tracks.MediaStreamTrackList
When the
add()
method is invoked, the user agent must run the
following steps:
Let track be the
argument.MediaStreamTrack
Let stream be the
object's corresponding
MediaStreamTrackList
object.MediaStream
If stream is finished, throw an
INVALID_STATE_ERR
exception.
If track is already in the
, object's internal list, then abort these
steps.MediaStreamTrackList
Add track to the end of the
object's internal list.MediaStreamTrackList
Parameter | Type | Nullable | Optional | Description |
---|---|---|---|---|
track |
| ✘ | ✘ |
void
item
MediaStreamTrack
object at the specified index.Parameter | Type | Nullable | Optional | Description |
---|---|---|---|---|
index | unsigned long | ✘ | ✘ |
MediaStreamTrack
remove
Removes the given
from this MediaStreamTrack
.MediaStreamTrackList
When the
remove()
method is invoked, the user agent must run the
following steps:
Let track be the
argument.MediaStreamTrack
Let stream be the
object's corresponding
MediaStreamTrackList
object.MediaStream
If stream is finished, throw an
INVALID_STATE_ERR
exception.
If track is not in the
, object's internal list, then abort these
steps.MediaStreamTrackList
Remove track from the
object's internal list.MediaStreamTrackList
Parameter | Type | Nullable | Optional | Description |
---|---|---|---|---|
track |
| ✘ | ✘ |
void
The
needs to be able to handle the case that arises when
changes are made to the MediaStreamRecorder
objects of the MediaStreamTrackList
being recorded; e.g., a new track is added as a result of
the MediaStream
add()
method being invoked.
interface MediaStreamRecorder {
voice getRecordedData (BlobCallback
? callBack);
};
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:
Let callBack be the callback indicated by the method's first argument.
If callBack is null, abort these steps.
Let data be the data that was streamed by the
object from which the MediaStream
was created since the creation of the MediaStreamRecorder
object.MediaStreamRecorder
Return, and run the remaining steps asynchronously.
Generate a file that containing data in a
format supported by the user agent for use in
audio
and video
elements.
Let blob be a Blob
object
representing the contents of the file generated in the
previous step. [FILE-API]
Queue a task to invoke callBack with blob as its argument.
The
getRecordedData()
method can be called multiple times on one
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.MediaStreamRecorder
Parameter | Type | Nullable | Optional | Description |
---|---|---|---|---|
callBack |
| ✔ | ✘ |
voice
[Callback, NoInterfaceObject]
interface BlobCallback {
void handleEvent (Blob blob);
};
partial interface URL {
static DOMString createObjectURL (MediaStream
stream);
};
createObjectURL
Mints a Blob URL to refer to the
given
.MediaStream
When the
createObjectURL()
method is called with a
argument, the user agent must return a unique Blob URL for the given MediaStream
. [FILE-API]MediaStream
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
and MediaStream
objects.LocalMediaStream
Parameter | Type | Nullable | Optional | Description |
---|---|---|---|---|
stream |
| ✘ | ✘ |
static DOMString
A
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
PeerConnection
XMLHttpRequest
.
Calling new
creates a PeerConnection
(configuration
)
object.PeerConnection
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
object has an associated a PeerConnection
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 ⌛.
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]
Set connection’s PeerConnection
readiness state to
NEW
(0).
Set connection’s PeerConnection
ice state to
NEW
(0).
Let connection’s
localStreams
attribute be an empty read-only
array. MediaStream
Let connection’s
remoteStreams
attribute be an empty read-only
array. MediaStream
Return connection, but continue these steps asynchronously.
Await a stable state. The synchronous section consists of the remaining steps of this algorithm.
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:
If the ICE Agent finds a candidates that forms a valid connection, the ICE state is changed to ICE_CONNECTED
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.
If the iceState is ICE_CONNECTED or ICE_COMPLETED and the SDP stat is SDP_IDLE, the readyState is set to ACTIVE.
If the iceState is ICE_FAILED, a task is queued to calls the close method.
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
objects must include a label attribute ("MediaStream
a=label:
") whose value is the value of the
object's MediaStream
label
attribute. [SDP] [SDPLABEL]
PeerConnection
s 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
can be created to represent incoming components, the user
agent must run the following steps:MediaStream
Let connection be the
expecting this media.PeerConnection
Create a
object to represent the media stream. Set its MediaStream
label
attribute to the value of the SDP Label attribute for that
component's media stream.
Run the following steps for each component in the media stream.
Create a
object track to represent the
component.MediaStreamTrack
If track's
kind
attribute equals "audio
", add it to the
object's MediaStream
audioTracks
object.MediaStreamTrackList
If track's
kind
attribute equals "video
", add it to the
object's MediaStream
videoTracks
object.MediaStreamTrackList
The internal order in the
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.MediaStreamTrackList
Queue a task to run the following substeps:
If the connection’s PeerConnection
readiness state is
CLOSED
(3), abort these steps.
Add the newly created
object to the end of connection’s MediaStream
remoteStreams
array.
Fire a stream event named
addstream
with the newly created
object at the connection
object.MediaStream
When a user agent has negotiated media for a component that belongs
to a media stream that is already represented by an existing
object, the user agent must associate the component with that
MediaStream
object.MediaStream
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:
Let connection be the
associated with the stream being removed.PeerConnection
Let stream be the
object that represents the media stream being removed, if
any. If there isn't one, then abort these steps.MediaStream
By definition, stream is now finished.
A task is thus queued to update stream and fire an event.
Queue a task to run the following substeps:
If the connection’s PeerConnection
readiness state is
CLOSED
(3), abort these steps.
Remove stream from connection’s
remoteStreams
array.
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
object is consuming a PeerConnection
and a track is added to one of the stream's MediaStream
objects, by, e.g., the MediaStreamTrackList
add()
method being invoked, the
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.PeerConnection
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.
The general operation of the PeerConnection is described in [RTCWEB-JSEP].
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".
"new"
"opening"
"active"
"closing"
PeerConnection
object is terminating all media and is in the process of
closing the connection.
"closed"
The IceState can take the following values:
"new"
"gathering"
"waiting"
"checking"
"connected"
"completed"
"failed"
"closed"
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;
};
iceState
of type IceState, readonlyThe
iceState
attribute must return the state of the PeerConnection
ICE
Agent ICE state.
localDescription
of type DOMString, readonlyThe 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
, readonlyReturns a live array containing the local streams (those that
were added with
addStream()
).
onaddstream
of type Function, nullable
addstream
, must be supported by all objects implementing the
PeerConnection
interface.onconnecting
of type Function, nullable
connecting
, must be supported by all objects implementing the
PeerConnection
interface.onicechange
of type Function, nullable
icechange
, must be supported by all objects implementing the
PeerConnection
interface. It is called any time the iceState
changes.onopen
of type Function, nullable
open
, must be supported by all objects implementing the
PeerConnection
interface.onremovestream
of type Function, nullable
removestream
, must be supported by all objects implementing the
PeerConnection
interface.onstatechange
of type Function, nullable
open
, must be supported by all objects implementing the
PeerConnection
interface. It is called any time the readyState changes.
readyState
of type PeerState, readonlyThe
readyState
attribute must return the
object's PeerConnection
PeerConnection
readiness state.
remoteDescription
of type DOMString, readonlyThe 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
, readonlyReturns 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.
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.
Parameter | Type | Nullable | Optional | Description |
---|---|---|---|---|
candidate | IceCandidate | ✘ | ✘ |
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
object.PeerConnection
When the
addStream()
method is invoked, the user agent must run the following
steps:
If the
object's PeerConnection
PeerConnection
readiness state is
CLOSED
(3), throw an INVALID_STATE_ERR
exception.
If stream is already in the
object's PeerConnection
localStreams
object, then abort these steps.
Add stream to the end of the
object's PeerConnection
localStreams
object.
Return from the method.
Parse the constraints provided by the application and apply them to the MediaStream, if possible. NOTE - need to deal with throwing an exception here.
Have the
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.PeerConnection
Parameter | Type | Nullable | Optional | Description |
---|---|---|---|---|
stream |
| ✘ | ✘ | |
constraints | MediaConstraints | ✘ | ✔ |
void
close
When the
close()
method is invoked, the user agent must run the following
steps:
If the
object's PeerConnection
PeerConnection
readiness state is
CLOSED
(3), throw an INVALID_STATE_ERR
exception.
Destroy the PeerConnection
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 PeerConnection
readiness state to
CLOSED
(3).
The
localStreams
and
remoteStreams
objects remain in the state they were in when the object
was closed.
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.
Parameter | Type | Nullable | Optional | Description |
---|---|---|---|---|
offer | DOMString | ✘ | ✘ | |
constraints | MediaConstraints | ✘ | ✔ |
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.
Parameter | Type | Nullable | Optional | Description |
---|---|---|---|---|
constraints | MediaConstraints | ✘ | ✘ |
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
object.PeerConnection
When the
removeStream()
method is invoked, the user agent must run the following
steps:
If the
object's PeerConnection
PeerConnection
readiness state is
CLOSED
(3), throw an INVALID_STATE_ERR
exception.
If stream is not in the
object's PeerConnection
localStreams
object, then abort these steps.
Remove stream from the
object's PeerConnection
localStreams
object.
Return from the method.
Have the
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.PeerConnection
Parameter | Type | Nullable | Optional | Description |
---|---|---|---|---|
stream |
| ✘ | ✘ |
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.
Parameter | Type | Nullable | Optional | Description |
---|---|---|---|---|
action | SdpType | ✘ | ✘ | |
sdp | DOMString | ✘ | ✘ |
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.
Parameter | Type | Nullable | Optional | Description |
---|---|---|---|---|
action | SdpType | ✘ | ✘ | |
sdp | DOMString | ✘ | ✘ |
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.
Parameter | Type | Nullable | Optional | Description |
---|---|---|---|---|
constraints | MediaConstraints | ✘ | ✔ |
void
PeerConnection
implements EventTarget;
[Callback, NoInterfaceObject]
interface SignalingCallback {
void handleEvent (DOMString message, PeerConnection
source);
};
handleEvent
Parameter | Type | Nullable | Optional | Description |
---|---|---|---|---|
message | DOMString | ✘ | ✘ | |
source |
| ✘ | ✘ |
void
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
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.
A Window
object has a strong reference to any
objects created from the constructor whose global object is
that PeerConnection
Window
object.
The
addtrack
and
removetrack
events use the
interface.MediaStreamTrackEvent
Firing a track event named
e with a
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 MediaStreamTrack
interface with the MediaStreamTrackEvent
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;
};
track
of type MediaStreamTrack
, readonly, nullableThe
track
attribute represents the
object associated with the event.MediaStreamTrack
MediaStreamTrackEventInit
Memberstrack
of type MediaStreamTrack
, nullable-
The
addstream
and
removestream
events use the
interface.MediaStreamEvent
Firing a
stream event named e with a
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 MediaStream
interface with the MediaStreamEvent
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;
};
stream
of type MediaStream
, readonly, nullableThe
stream
attribute represents the
object associated with the event.MediaStream
MediaStreamEventInit
Membersstream
of type MediaStream
, nullable-
This section is non-normative.
The following event fires on
objects:MediaStream
Event name | Interface | Fired when... |
---|---|---|
ended
|
Event
|
The
finished as a result of all tracks in the
ending. |
The following event fires on
objects:MediaStreamTrack
Event name | Interface | Fired when... |
---|---|---|
muted
|
Event
|
The
object's source is temporarily unable to provide
data. |
unmuted
|
Event
|
The
object's source is live again after having been
temporarily unable to provide data. |
ended
|
Event
|
The
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
objects:MediaStreamTrackList
Event name | Interface | Fired when... |
---|---|---|
addtrack
|
|
A new
has been added to this list. |
removetrack
|
|
A
has been removed from this list. |
The following events fire on
objects:PeerConnection
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
object. |
open
|
Event
|
The ICE Agent has finished negotiating with the peer. |
message
|
MessageEvent
|
A data UDP media stream message was received. |
addstream
|
|
A new stream has been added to the
remoteStreams
array. |
removestream
|
|
A stream has been removed from the
remoteStreams
array. |
IANA is requested to register the following constraints as specified in [RTCWEB-CONSTRAINTS]:
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.
This registration is for community review and will be submitted to the IESG for review, approval, and registration with IANA.
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.
Fragment identifiers cannot be used with
application/html-peer-connection-data
as URLs cannot be used to identify streams that use this
format.
This section will be removed before publication.
Need a way to indicate the type of the SDP when passing SDP strings.
The editors wish to thank the Working Group chairs, Harald Alvestrand and Stefan Håkansson, for their support.