diff --git a/archives/20140127/images/camera-names-exp.svg b/archives/20140127/images/camera-names-exp.svg new file mode 100644 index 000000000..2e20c9357 --- /dev/null +++ b/archives/20140127/images/camera-names-exp.svg @@ -0,0 +1,29 @@ + + + + +left +user +right +environment + + + + + + + + + + + + + + + + + +person +Top down view + diff --git a/archives/20140127/images/change_states_after.png b/archives/20140127/images/change_states_after.png new file mode 100644 index 000000000..7440ebd79 Binary files /dev/null and b/archives/20140127/images/change_states_after.png differ diff --git a/archives/20140127/images/change_states_after2.png b/archives/20140127/images/change_states_after2.png new file mode 100644 index 000000000..dcf6332a4 Binary files /dev/null and b/archives/20140127/images/change_states_after2.png differ diff --git a/archives/20140127/images/change_states_before.png b/archives/20140127/images/change_states_before.png new file mode 100644 index 000000000..7f51976e9 Binary files /dev/null and b/archives/20140127/images/change_states_before.png differ diff --git a/archives/20140127/images/change_states_before2.png b/archives/20140127/images/change_states_before2.png new file mode 100644 index 000000000..6897e47ed Binary files /dev/null and b/archives/20140127/images/change_states_before2.png differ diff --git a/archives/20140127/images/icestates.svg b/archives/20140127/images/icestates.svg new file mode 100644 index 000000000..5a738b5c6 --- /dev/null +++ b/archives/20140127/images/icestates.svg @@ -0,0 +1,589 @@ + + + +image/svg+xml + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +new +disconnected +failed +checking +connected +completed +closed(reachable fromany state) + \ No newline at end of file diff --git a/archives/20140127/images/ladder-2party-full.svg b/archives/20140127/images/ladder-2party-full.svg new file mode 100644 index 000000000..6cbf8bb17 --- /dev/null +++ b/archives/20140127/images/ladder-2party-full.svg @@ -0,0 +1,168 @@ + +Call showing all callback - this is far from complete +Alice's Turn + +Alice's Turn +Alice's Browser + +Alice's Browser +Alice's App + +Alice's App +Alice + +Alice +Web Server + +Web Server +Bob + +Bob +Bob's App + +Bob's App +Bob's Browse + +Bob's Browse +Bob's Turn + +Bob's Turn + +1. Load Page + +2. Authenticate + +3. create PeerConnection() + +4. Alloc (pair 1) + +5. Alloc (pair 2) + +6. Alloc (pair 3) + +7. IPs and Ports (pair 1) + +8. onIceCandiate + +9. IPs and Ports (pair 2) + +10. onIceCandiate + +11. IPs and Ports (pair 3) + +12. onIceCandiate + +13. Load Page + +14. Authenticate + +15. create PeerConnection() + +16. Alloc + +17. Alloc + +18. Alloc + +19. IPs and Ports + +20. IPs and Ports + +21. IPs and Ports + +22. Call Bob + +23. addStream( data ) + +24. onRenegotationNeeed + +25. addStream( audio/video ) + +26. onRenegotationNeeed + +27. createOffer + +28. offer + +29. setLocal + +30. Offer to Bob + +31. Offer + +32. SetRemote + +33. TBD Remote has audio, video, and data + +34. Phones Ringing Dude + +35. addStream( data ) + +36. createAnswer( Provisional, RelayOnly ) + +37. PR_Answer + +38. setLocal + +39. PR_Answer to Alice + +40. Permission + +41. De-Alloc (RTCP port of pair1) + +42. De-Alloc (pair 2) + +43. De-Alloc (pair 3) + +44. onRemoteStream( data ) + +45. ICE Check + +46. ICE Check + +47. DTLS + +48. DTLS + +49. SCTP/Data + +50. SCTP/Data + +51. onRemoteStream( data ) + +52. time passes - remove later + +53. PR_Answer + +54. setRemote + +55. Permission + +56. Accept Audio and Video + +57. addStream( audio/video ) + +58. createAnswer + +59. Answer + +60. setLocal + +61. Answer to Alice + +62. onRemoteStream( audio/video ) + +63. RTP/Data + +64. RTP/Data + +65. ICE Check + +66. RTP/Data + +67. time passes - remove later + +68. Answer + +69. setRemote + \ No newline at end of file diff --git a/archives/20140127/images/ladder-2party-simple.svg b/archives/20140127/images/ladder-2party-simple.svg new file mode 100644 index 000000000..f8e1e7d00 --- /dev/null +++ b/archives/20140127/images/ladder-2party-simple.svg @@ -0,0 +1,177 @@ + +Simple Call Flow +Alice's Turn + +Alice's Turn +Alice's Browser + +Alice's Browser +Alice's App + +Alice's App +Alice + +Alice +Alice's Web Server + +Alice's Web Server +Bob's Web Server + +Bob's Web Server +Bob + +Bob +Bob's App + +Bob's App +Bob's Browser + +Bob's Browser +Bob's Turn + +Bob's Turn + +1. Load Page + +2. Authenticate + +3. Load Page + +4. Authenticate + +5. Call Bob + +6. new RTCPeerConnection() + +7. createDataChannel() + +8. addStream(stream) + +9. event: "negotiationneeded" + +10. createOffer(gotOffer) + +11. Alloc + +12. IPs and Ports + +13. callback: gotOffer(offer) + +14. setLocalDescription(offer) + +15. offer + +16. offer + +17. offer + +18. new RTCPeerConnection() + +19. setRemoteDescription(offer) + +20. event: "addstream" with remoteStream + +21. Phones Ringing Dude + +22. constr = {iceTransports: "relay"} + +23. createAnswer(gotAnswer, constr) + +24. Alloc + +25. IPs and Ports + +26. callback: gotAnswer(answer) + +27. answer.type = "pranswer"; pranswer = answer + +28. setLocalDescription(pranswer) + +29. pranswer + +30. Permission + +31. pranswer + +32. pranswer + +33. setRemoteDescription(pranswer) + +34. Permission + +35. ICE Check + +36. ICE Check + +37. DTLS + +38. DTLS + +39. SCTP/Data + +40. SCTP/Data + +41. event: "datachannel" + +42. Accept Audio and Video + +43. addStream(stream) + +44. createAnswer(gotAnswer) + +45. callback: gotAnswer(answer) + +46. setLocalDescription(answer) + +47. answer + +48. SRTP + +49. SRTP + +50. ICE Check + +51. SRTP without relay + +52. answer + +53. answer + +54. setRemoteDescription(answer) + +55. event: "addstream" with remoteStream + +56. Add document camera + +57. addStream(docStream) + +58. event: "negotationneeded" + +59. createOffer(gotOffer) + +60. callbakc: gotOffer(offer) + +61. setLocalDescription(offer) + +62. offer + +63. offer + +64. offer + +65. setRemoteDescription(offer) + +66. event: "addstream" with docStream + +67. createAnswer(gotAnswer) + +68. callback: gotAnswer(answer) + +69. answer + +70. answer + +71. answer + +72. setRemoteDescription(answer); + \ No newline at end of file diff --git a/archives/20140127/images/ladder-mcu-simple.svg b/archives/20140127/images/ladder-mcu-simple.svg new file mode 100644 index 000000000..9a38de954 --- /dev/null +++ b/archives/20140127/images/ladder-mcu-simple.svg @@ -0,0 +1,77 @@ + +Simple hangout where media set is overlapped with hair check +Alice + +Alice +Alice's Browser + +Alice's Browser +Alice's App + +Alice's App +Alice's Turn + +Alice's Turn +Web Server Browse + +Web Server Browse +Media Switch + +Media Switch + +1. Load Page + +2. Authenticate + +3. stuff + +4. Offer + +5. Check Hair + +6. create PeerConnection() + +7. Alloc + +8. SetRemote( Offer ) + +9. createAnswer( Provisional ) + +10. IPs and Ports + +11. answer + +12. setLocal + +13. onRemoteStream main + +14. onRemoteStream thumbnail one + +15. onRemoteStream thumbnail two + +16. ICE + +17. stuff + +18. answer + +19. DTLS + +20. SRTP + +21. Hair is fluffy + +22. addStream audio/video + +23. createAnswer + +24. answer + +25. setLocal + +26. stuff + +27. answer + +28. SRTP + \ No newline at end of file diff --git a/archives/20140127/images/media-stream-1.png b/archives/20140127/images/media-stream-1.png new file mode 100644 index 000000000..5b43e1c37 Binary files /dev/null and b/archives/20140127/images/media-stream-1.png differ diff --git a/archives/20140127/images/media-stream-2.png b/archives/20140127/images/media-stream-2.png new file mode 100644 index 000000000..da957deb2 Binary files /dev/null and b/archives/20140127/images/media-stream-2.png differ diff --git a/archives/20140127/images/media-stream.png b/archives/20140127/images/media-stream.png new file mode 100644 index 000000000..1d7689d20 Binary files /dev/null and b/archives/20140127/images/media-stream.png differ diff --git a/archives/20140127/images/overconstrained_after.png b/archives/20140127/images/overconstrained_after.png new file mode 100644 index 000000000..4853639f4 Binary files /dev/null and b/archives/20140127/images/overconstrained_after.png differ diff --git a/archives/20140127/images/overconstrained_before.png b/archives/20140127/images/overconstrained_before.png new file mode 100644 index 000000000..fdb58b1cd Binary files /dev/null and b/archives/20140127/images/overconstrained_before.png differ diff --git a/archives/20140127/images/peerstates.svg b/archives/20140127/images/peerstates.svg new file mode 100644 index 000000000..f34ec22b0 --- /dev/null +++ b/archives/20140127/images/peerstates.svg @@ -0,0 +1,1284 @@ + + + + + + +have-local-offer + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +stable +have-remote-offer +have-local-pranswer +have-remote-pranswer + + diff --git a/archives/20140127/webrtc.css b/archives/20140127/webrtc.css new file mode 100644 index 000000000..34e660fdd --- /dev/null +++ b/archives/20140127/webrtc.css @@ -0,0 +1,52 @@ + +@media screen { + html { background: #eeeeee; } + body { margin-bottom: 30%; border-bottom: thin solid #3c790a; } +} + +pre { margin-left: 2em; white-space: pre-wrap; } +dt, dfn { font-weight: bold; font-style: normal; } +i, em, dt dfn { font-style: italic; } +pre, code { font-size: inherit; font-family: monospace, Droid Sans Fallback, sans-serif; font-variant: normal; } +pre strong { color: black; font: inherit; font-weight: bold; background: yellow; } +pre em { font-weight: bolder; font-style: normal; } +@media screen { code { color: orange; } } +var sub { vertical-align: bottom; font-size: smaller; position: relative; top: 0.1em; } +table { border-collapse: collapse; border-style: hidden hidden none hidden; } +table thead, table tbody { border-bottom: solid; } +table tbody th { text-align: left; } +table tbody th:first-child { border-left: solid; } +table td, table th { border-left: solid; border-right: solid; border-bottom: solid thin; vertical-align: top; padding: 0.2em; } + +ins { background: green; color: white; /* color: green; border: solid thin lime; padding: 0.3em; line-height: 1.6em; */ text-decoration: none; } +del { background: maroon; color: white; /* color: maroon; border: solid thin red; padding: 0.3em; line-height: 1.6em; */ text-decoration: line-through; } +body ins, body del { display: block; } +body * ins, body * del { display: inline; } + + +p > span:not([title=""]):not([class="XXX"]):not([class="impl"]):not([class="note"]), +li > span:not([title=""]):not([class="XXX"]):not([class="impl"]):not([class="note"]) { border-bottom: solid #99CC99; } + +.note { color: green; background: transparent; font-family: sans-serif, Droid Sans Fallback; } +.warning { color: red; background: transparent; } +.note, .warning { font-weight: bolder; font-style: italic; } +.note em, .warning em, .note i, .warning i { font-style: normal; } +p.note, div.note { padding: 0.5em 2em; } +span.note { padding: 0 2em; } +.note p:first-child, .warning p:first-child { margin-top: 0; } +.note p:last-child, .warning p:last-child { margin-bottom: 0; } +.warning:before { font-style: normal; } +p.note:before { content: 'Note: '; } +p.warning:before { content: '\26A0 Warning! '; } + +.bookkeeping:before { display: block; content: 'Bookkeeping details'; font-weight: bolder; font-style: italic; } +.bookkeeping { font-size: 0.8em; margin: 2em 0; } +.bookkeeping p { margin: 0.5em 2em; display: list-item; list-style: square; } +.bookkeeping dt { margin: 0.5em 2em 0; } +.bookkeeping dd { margin: 0 3em 0.5em; } + +.critical { margin: 1em; border: double thick red; padding: 1em; background: #FFFFCC; } +.critical > :first-child { margin-top: 0; } + +.example { display: block; color: #222222; background: #FCFCFC; border-left: double; margin-left: 2em; padding-left: 1em; } +td > .example:only-child { margin: 0 0 0 0.1em; } diff --git a/archives/20140127/webrtc.html b/archives/20140127/webrtc.html new file mode 100644 index 000000000..d1af31217 --- /dev/null +++ b/archives/20140127/webrtc.html @@ -0,0 +1,5466 @@ + + + + WebRTC 1.0: Real-time Communication Between Browsers + + + + + + +

Abstract

+

This document defines a set of ECMAScript APIs in WebIDL to allow media + to be sent to and received from another browser or device implementing the + appropriate set of real-time protocols. 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 neither complete nor stable, and as such is not yet + suitable for commercial implementation. However, early experimentation is + encouraged. 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 an Editor's Draft. + + + If you wish to make comments regarding this document, please send them to + public-webrtc@w3.org + (subscribe, + archives). + + + + + All comments are welcome. + +

+ + +

+ Publication as an Editor's Draft 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. 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.

+
+ + +

2. Conformance

+

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

+

+ The key words MUST, MUST NOT, REQUIRED, SHOULD, SHOULD NOT, RECOMMENDED, MAY, + and OPTIONAL in this specification are to be interpreted as described in [RFC2119]. +

+ +

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

+ + +

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

+
+ + +
+

3. Terminology

+ + +

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

+ + +

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

+ + +

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

+ + +

The terms MediaStream, MediaStreamTrack, + Constraints, and Consumer are defined in + [GETUSERMEDIA].

+
+ + +
+

4. Peer-to-peer connections

+ + +
+

4.1 Introduction

+ + +

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

+
+ + +
+

4.2 Configuration

+ + +
+

4.2.1 RTCConfiguration Type

+ + +
dictionary RTCConfiguration {
+    sequence<RTCIceServer> iceServers;
+    RTCIceTransports       iceTransports = "all";
+    RTCIdentityOption      requestIdentity = "ifconfigured";
+};
4.2.1.1 Dictionary RTCConfiguration Members
iceServers of type sequence<RTCIceServer>
+

An array containing URIs of servers available to be used + by ICE, such as STUN and TURN server.

+
iceTransports of type RTCIceTransports, defaulting to "all"
+

Indicates which candidates the ICE engine is allowed to use. +

+
requestIdentity of type RTCIdentityOption, defaulting to "ifconfigured"
+

See the requestIdentity member of + the RTCOfferAnswerOptions dictionary.

+
+
+ + +
+

4.2.2 RTCIceServer Type

+ + +
dictionary RTCIceServer {
+    (DOMString or sequence<DOMString>) urls;
+    DOMString                          username;
+    DOMString                          credential;
+};
4.2.2.1 Dictionary RTCIceServer Members
credential of type DOMString
+

If this RTCIceServer object represents a + TURN server, then this attribute specifies the credential to use + with that TURN server.

+
urls of type (DOMString or sequence<DOMString>)
+

STUN or TURN URI(s) as defined in [STUN-URI] and + [TURN-URI] or other URI types.

+
username of type DOMString
+

If this RTCIceServer object represents a + TURN server, then this attribute specifies the username to use with + that TURN server.

+
+ + +

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

+ + +

An example array of RTCIceServer objects is:

+ + +

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

+
+ +
+

4.2.3 RTCIceTransports Enum

+ + +
enum RTCIceTransports {
+    "none",
+    "relay",
+    "all"
+};
Enumeration description
noneThe ICE engine MUST not send or receive any packets at this + point.
relayThe ICE engine MUST only use media relay candidates such as + candidates passing through a TURN server. This can be used to reduce + leakage of IP addresses in certain use cases.
allThe ICE engine may use any type of candidates when this value is + specified.
+ +
+ +
+

4.2.4 Offer/Answer Options

+ +

These dictionaries describe the options that can be used to + control the offer/answer creation process.

+ + +
dictionary RTCOfferAnswerOptions {
+    RTCIdentityOption requestIdentity = "ifconfigured";
+};
4.2.4.1 Dictionary RTCOfferAnswerOptions Members
requestIdentity of type RTCIdentityOption, defaulting to "ifconfigured"
+

The requestIdentity + option indicates whether an identity should be requested. The option + may be used with either of the createOffer() or + createAnswer() calls, but also with the + RTCPeerConnection constructor. Note that as long as + DTLS-SRTP is in used, fingerprints will be sent regardless of the + value of this option.

+
+ + +
dictionary RTCOfferOptions : RTCOfferAnswerOptions {
+    long    offerToReceiveVideo;
+    long    offerToReceiveAudio;
+    boolean voiceActivityDetection = true;
+    boolean iceRestart = false;
+};
4.2.4.2 Dictionary RTCOfferOptions Members
iceRestart of type boolean, defaulting to false
+

When the value of this dictionary member is true, the + generated description will have ICE credentials that are different + from the current credentials (as visible in the + localDescription attribute's SDP). Applying the + generated description will restart ICE.

+ + +

When the value of this dictionary member is false, and the + localDescription attribute has valid ICE + credentials, the generated description will have the same ICE + credentials as the current value from the + localDescription attribute.

+
offerToReceiveAudio of type long
+

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

+
offerToReceiveVideo of type long
+

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

+
voiceActivityDetection of type boolean, defaulting to true
+

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

+
+ + +
enum RTCIdentityOption {
+    "yes",
+    "no",
+    "ifconfigured"
+};
Enumeration description
yesAn identity MUST be requested.
noNo identity is to be requested.
ifconfiguredThe value "ifconfigured" means that an identity will be requested + if either the user has configured an identity in the browser or if the + setIdentityProvider() call has been made in JavaScript. + As this is the default value, an identity will be requested if and + only if the user has configured an IdP in some way.
+
+
+ + +
+

4.3 RTCPeerConnection Interface

+ + +

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

+ + +
+

4.3.1 Operation

+ + +

Calling new RTCPeerConnection(configuration + ) creates an RTCPeerConnection object.

+ + +

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

+ + +

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

+ + +

An RTCPeerConnection object has two associated + stream sets. A local streams set, + representing streams that are currently sent, and a remote streams set, representing streams + that are currently received with this + RTCPeerConnection object. The stream sets are + initialized to empty sets when the + RTCPeerConnection object is created.

+ + +

When the RTCPeerConnection() constructor + is invoked, the user agent MUST run the following steps:

+ + +
    +
  1. +

    Validate the RTCConfiguration argument by + running the steps defined by the updateIce() method.

    +
  2. + + +
  3. +

    Create an ICE Agent as defined in [ICE] and let + connection's RTCPeerConnection ICE Agent be + that ICE Agent and provide it the the ICE servers list. The ICE Agent will proceed + with gathering as soon as the ICE + transports setting is not set to none. At this + point the ICE Agent does not know how many ICE components it needs + (and hence the number of candidates to gather), but it can make a + reasonable assumption such as 2. As the + RTCPeerConnection object gets more information, the + ICE Agent can adjust the number of components.

    +
  4. + + +
  5. +

    Set connection's RTCPeerConnection + signalingState to stable.

    +
  6. + + +
  7. +

    Set connection's RTCPeerConnection + ice connection state to new.

    +
  8. + + +
  9. +

    Set connection's RTCPeerConnection + ice gathering state to new.

    +
  10. + + +
  11. +

    Initialize an internal variable to represent a queue of + operations with an empty set.

    +
  12. + + +
  13. +

    Return connection.

    +
  14. +
+ + +

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

+ + +
    +
  1. +

    Append an object representing the current call being handled + (i.e. function name and corresponding arguments) to the + operations array.

    +
  2. + + +
  3. +

    If the length of the operations array is exactly 1, + execute the function from the front of the queue + asynchronously.

    +
  4. + + +
  5. +

    When the asynchronous operation completes (either successfully + or with an error), remove the corresponding object from the + operations array. After removal, if the array is + non-empty, execute the first object queued asynchronously and + repeat this step on completion.

    +
  6. +
+ + +

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

+ + +

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

+ + +
    +
  1. +

    If the RTCPeerConnection + ice gathering state is new and the ICE transports setting is not + set to none, the user agent MUST + queue a task to start gathering ICE addresses and set the ice gathering state + to gathering.

    +
  2. + + +
  3. +

    If the ICE Agent has found one or more candidate pairs for each + MediaStreamTrack that forms a valid connection, the ICE connection + state is changed to "connected".

    +
  4. + + +
  5. +

    When the ICE Agent finishes checking all candidate pairs, if at + least one connection has been found for each MediaStreamTrack, the + iceConnectionState is changed to "completed"; else the + iceConnectionState is changed to "failed".

    +
  6. +
+ + +

When the ICE Agent needs to notify the script about the candidate + gathering progress, the user agent must queue a task to run the + following steps:

+ + +
    +
  1. +

    Let connection be the + RTCPeerConnection object associated with this + ICE Agent.

    +
  2. + + +
  3. +

    If connection's RTCPeerConnection + signalingState is closed, abort these steps.

    +
  4. + + +
  5. +

    If the intent of the ICE Agent is to notify the script that:

    + + +
      +
    • +

      A new candidate is available.

      + + +

      Add the candidate to connection's + localDescription and create a + RTCIceCandidate object to represent the + candidate. Let newCandidate be that object.

      +
    • + + +
    • +

      The gathering process is done.

      + + +

      Set connection's ice gathering + state to completed and let + newCandidate be null.

      +
    • +
    +
  6. + + +
  7. +

    Fire a icecandidate event named icecandidate with + newCandidate at connection.

    +
  8. +
+ + +

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

+ + +

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

+ + +

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

+ + +
    +
  1. +

    Let connection be the + RTCPeerConnection expecting this media.

    +
  2. + + +
  3. +

    Create a MediaStream object + stream, to represent the incoming media stream.

    +
  4. + + +
  5. +

    Run the algorithm + to represent an incoming component with a track for each incoming + component.

    + + +
    Note

    The creation of new incoming + MediaStreams may be triggered either by SDP + negotiation or by the receipt of media on a given flow. +

    +
  6. + + +
  7. +

    Queue a task to run the following substeps:

    + + +
      +
    1. +

      If the connection's RTCPeerConnection + signalingState is closed, abort these + steps.

      +
    2. + + +
    3. +

      Add stream to connection's remote streams set.

      +
    4. + + +
    5. +

      Fire a stream event named + addstream with + stream at the connection + object.

      +
    6. +
    +
  8. +
+ + +

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

+ + +

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

+ + +
    +
  1. +

    Let connection be the + RTCPeerConnection associated with the stream + being removed.

    +
  2. + + +
  3. +

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

    +
  4. + + +
  5. +

    By definition, stream is now ended.

    + + +
    Note

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

    +
  6. + + +
  7. +

    Queue a task to run the following substeps:

    + + +
      +
    1. +

      If the connection's RTCPeerConnection + signalingState is closed, abort these + steps.

      +
    2. + + + +
    3. +

      Remove stream from connection's + remote streams set.

      +
    4. + + +
    5. +

      Fire a stream event named + removestream with + stream at the connection + object.

      +
    6. +
    +
  8. +
+ + +

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

+ + +

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

+ + +

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

+ + +

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

+
+ + +
+

4.3.2 Interface Definition

+ + +
[ Constructor (RTCConfiguration configuration)]
+interface RTCPeerConnection : EventTarget  {
+    void                  createOffer (RTCSessionDescriptionCallback successCallback, RTCPeerConnectionErrorCallback failureCallback, optional RTCOfferOptions options);
+    void                  createAnswer (RTCSessionDescriptionCallback successCallback, RTCPeerConnectionErrorCallback failureCallback, optional RTCOfferAnswerOptions options);
+    void                  setLocalDescription (RTCSessionDescription description, VoidFunction successCallback, RTCPeerConnectionErrorCallback failureCallback);
+    readonly    attribute RTCSessionDescription? localDescription;
+    void                  setRemoteDescription (RTCSessionDescription description, VoidFunction successCallback, RTCPeerConnectionErrorCallback failureCallback);
+    readonly    attribute RTCSessionDescription? remoteDescription;
+    readonly    attribute RTCSignalingState      signalingState;
+    void                  updateIce (RTCConfiguration configuration);
+    void                  addIceCandidate (RTCIceCandidate candidate, VoidFunction successCallback, RTCPeerConnectionErrorCallback failureCallback);
+    readonly    attribute RTCIceGatheringState   iceGatheringState;
+    readonly    attribute RTCIceConnectionState  iceConnectionState;
+    RTCConfiguration      getConfiguration ();
+    sequence<MediaStream> getLocalStreams ();
+    sequence<MediaStream> getRemoteStreams ();
+    MediaStream?          getStreamById (DOMString streamId);
+    void                  addStream (MediaStream stream);
+    void                  removeStream (MediaStream stream);
+    void                  close ();
+                attribute EventHandler           onnegotiationneeded;
+                attribute EventHandler           onicecandidate;
+                attribute EventHandler           onsignalingstatechange;
+                attribute EventHandler           onaddstream;
+                attribute EventHandler           onremovestream;
+                attribute EventHandler           oniceconnectionstatechange;
+};
4.3.2.1 Constructors
RTCPeerConnection
+ See the RTCPeerConnection constructor + algorithm. +
ParameterTypeNullableOptionalDescription
configurationRTCConfiguration
4.3.2.2 Attributes
iceConnectionState of type RTCIceConnectionState, readonly
+

The iceConnectionState + attribute MUST return the state of the RTCPeerConnection ICE + Agent ICE state.

+
iceGatheringState of type RTCIceGatheringState, readonly
+

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

+
localDescription of type RTCSessionDescription, readonly , nullable
+

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

+ + +

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

+
onaddstream of type EventHandler,
This event handler, of event handler event type addstream, MUST be fired by + all objects implementing the RTCPeerConnection + interface. It is called any time a MediaStream is added + by the remote peer. This will be fired only as a result of + setRemoteDescription. Onnaddstream happens as early as + possible after the setRemoteDescription. This callback + does not wait for a given media stream to be accepted or rejected via + SDP negotiation.
onicecandidate of type EventHandler,
This event handler, of event handler event type icecandidate, MUST be supported by + all objects implementing the RTCPeerConnection + interface.
oniceconnectionstatechange of type EventHandler,
This event handler, of event handler event type iceconnectionstatechange, + MUST be fired by all objects implementing the + RTCPeerConnection interface. It is called any + time the iceConnectionState changes.
onnegotiationneeded of type EventHandler,
This event handler, of event handler event type negotiationneeded , MUST be supported + by all objects implementing the RTCPeerConnection + interface.
onremovestream of type EventHandler,
This event handler, of event handler event type removestream, MUST be + fired by all objects implementing the + RTCPeerConnection interface. It is called any + time a MediaStream is removed by the remote peer. This + will be fired only as a result of + setRemoteDescription.
onsignalingstatechange of type EventHandler,
This event handler, of event handler event type signalingstatechange, MUST + be supported by all objects implementing the + RTCPeerConnection interface. It is called any + time the readyState changes, i.e., from a call to + setLocalDescription, a call to + setRemoteDescription, or code. It does not fire for the + initial state change into new.
remoteDescription of type RTCSessionDescription, readonly , nullable
+

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

+ + +

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

+
signalingState of type RTCSignalingState, readonly
+

The signalingState + attribute MUST return the RTCPeerConnection + object's RTCPeerConnection + signaling state.

+
4.3.2.3 Methods
addIceCandidate
+

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

+ + +

If the candidate parameter is malformed, throw a + SyntaxError exception and abort these steps.

+ + +

If the candidate is successfully applied, the user agent MUST + queue a task to invoke successCallback.

+ + +

If the candidate could not be successfully applied, the user + agent MUST queue a task to invoke failureCallback with a + DOMError object whose name attribute has + the value TBD (TODO InvalidCandidate and InvalidMidIndex).

+ + +
Note
+ What errors do we need here? Should we reuse the + *SessionDescriptionError names or invent new ones for candidates? + Should this method be queued? +
+
ParameterTypeNullableOptionalDescription
candidateRTCIceCandidate
successCallbackVoidFunction
failureCallbackRTCPeerConnectionErrorCallback
Return type: void
addStream
+

Adds a new stream to the RTCPeerConnection.

+ + +

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

+ + +
    +
  1. +

    Let connection be the + RTCPeerConnection object on which the + MediaStream, stream, is to be + added.

    +
  2. + + +
  3. +

    If connection's RTCPeerConnection + signalingState is closed, throw an + InvalidStateError exception and abort these + steps.

    +
  4. + + +
  5. +

    If stream is already in connection's + local streams set, then abort + these steps.

    +
  6. + + +
  7. +

    Add stream to connection's local streams set.

    +
  8. + + + +
  9. +

    If connection's RTCPeerConnection + signalingState is stable, then fire a negotiationneeded event at + connection.

    +
  10. +
+
ParameterTypeNullableOptionalDescription
streamMediaStream
Return type: void
close
+

When the RTCPeerConnection close() method is invoked, the + user agent MUST run the following steps:

+ + +
    + +
  1. + If the RTCPeerConnection object's RTCPeerConnection + signalingState is closed, abort these steps. +
  2. + +
  3. +

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

    +
  4. + + +
  5. +

    Set the object's RTCPeerConnection + signalingState to closed.

    +
  6. +
+
No parameters.
Return type: void
createAnswer
+

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

+ + +

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

+ + +

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

+ + +

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

+ + +

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

+ + +

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

+ + +

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

+ + +

If the SDP generation process failed for any reason, the user + agent MUST queue a task to invoke failureCallback with + an DOMError object of type TBD as its argument.

+
ParameterTypeNullableOptionalDescription
successCallbackRTCSessionDescriptionCallback
failureCallbackRTCPeerConnectionErrorCallback
optionsRTCOfferAnswerOptions
Return type: void
createOffer
+

The createOffer method generates a blob of SDP that contains an + RFC 3264 offer with the supported configurations for the session, + including descriptions of the local MediaStreams + attached to this RTCPeerConnection, the codec/RTP/RTCP + options supported by this implementation, and any candidates that + have been gathered by the ICE Agent. The options 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 + include the capabilities of the current local description as well + as any additional capabilities that could be negotiated in an + updated offer.

+ + +

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

+ + +

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

+ + +

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

+ + +

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

+ + +

If the SDP generation process failed for any reason, the user + agent MUST queue a task to invoke failureCallback with + an DOMError object of type TBD as its argument.

+ + +

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

+
ParameterTypeNullableOptionalDescription
successCallbackRTCSessionDescriptionCallback
failureCallbackRTCPeerConnectionErrorCallback
optionsRTCOfferOptions
Return type: void
getConfiguration
+

Returns a RTCConfiguration object representing the current configuration of this RTCPeerConnection object.

+ + +

When this method is call, the user agent MUST construct new RTCConfiguration object to be returned, and initialize it using the ICE Agent's ICE transports setting and ICE servers list.

+
No parameters.
Return type: RTCConfiguration
getLocalStreams
+

Returns a sequence of MediaStream objects + representing the streams that are currently sent with this + RTCPeerConnection object.

+ + +

The getLocalStreams() + method MUST return a new sequence that represents a snapshot of all + the MediaStream objects in this + RTCPeerConnection object’s local streams set. The conversion from the + streams set to the sequence, to be returned, is user agent defined + and the order does not have to stable between calls.

+
No parameters.
Return type: sequence<MediaStream>
getRemoteStreams
+

Returns a sequence of MediaStream objects + representing the streams that are currently received with this + RTCPeerConnection object.

+ + +

The getRemoteStreams() + method MUST return a new sequence that represents a snapshot of all + the MediaStream objects in this + RTCPeerConnection object’s remote streams set. The conversion from + the streams set to the sequence, to be returned, is user agent + defined and the order does not have to stable between calls.

+
No parameters.
Return type: sequence<MediaStream>
getStreamById
+

If a MediaStream object, with an + id + equal to streamId, exists in this + RTCPeerConnection object’s stream sets + (local streams set or remote streams set), then the getStreamById() + method MUST return that MediaStream object. The + method MUST return null if no stream matches the + streamId argument.

+ + +
Note
+

For this method to make sense, we need to make sure that ids + are unique within the two stream sets of a RTCPeerConnection. + This is not the case today when a peer re-adds a stream that is + received. Two different stream instances will now have the same + id at both peers; one in the remote stream set and one in the + local stream set.

+ + +

One way to resolve this is to not allow re-adding a stream + instance that is received (guard on id). If an application really + needs this functionality it's really easy to make a clone of the + stream, which will give it a new id, and send the clone.

+
+
ParameterTypeNullableOptionalDescription
streamIdDOMString
Return type: MediaStream, nullable
removeStream
+

Removes the given stream from the + RTCPeerConnection.

+ + +

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

+ + +

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

+ + +
    +
  1. +

    Let connection be the + RTCPeerConnection object on which the + MediaStream, stream, is to be + removed.

    +
  2. + + +
  3. +

    If connection's RTCPeerConnection + signalingState is closed, throw an + InvalidStateError exception.

    +
  4. + + +
  5. +

    If stream is not in connection's + local streams set, then abort + these steps.

    +
  6. + + +
  7. +

    Remove stream from connection's + local streams set.

    +
  8. + + +
  9. +

    If connection's RTCPeerConnection + signalingState is stable, then fire a negotiationneeded event at + connection.

    +
  10. +
+
ParameterTypeNullableOptionalDescription
streamMediaStream
Return type: void
setLocalDescription
+

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

+ + +

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

+ + +
Issue 1

ISSUE: how to indicate to rollback?

+ + +

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

+ + +

When the method is invoked, the user agent must follow the + processing model described by + the following list:

+ + +
    +
  • +

    If this RTCPeerConnection object's + signaling + state is closed, the user agent MUST throw an + InvalidStateError exception and abort this + operation.

    +
  • + + +
  • +

    If a local description contains a different set of ICE + credentials, then the ICE Agent MUST trigger an ICE restart. + When ICE restarts, the gathering state will be changed back to + "gathering", if it was not already gathering. If the + IceConnectionState was "completed", it will be changed back to + "connected".

    +
  • + + +
  • +

    If the process to apply the + RTCSessionDescription argument fails for + any reason, then user agent must queue a task runs the + following steps:

    + + +
      +
    1. +

      Let connection be the + RTCPeerConnection object on with this + method was invoked.

      +
    2. + + +
    3. +

      If connection's signaling state + is closed, then abort these steps.

      +
    4. + + +
    5. +

      If the reason for the failure is:

      + + +
        +
      • +

        The content of the + RTCSessionDescription argument is + invalid or the type is + wrong for the current signaling + state of connection.

        + + +

        Let errorType be + InvalidSessionDescriptionError.

        +
      • + + +
      • +

        The RTCSessionDescription is a + valid description but cannot be applied at the media + layer.

        + + +

        TODO ISSUE - next few points are probably wrong. + Make sure to check this in setRemote too.

        + + +

        This can happen, e.g., if there are insufficient + resources to apply the SDP. The user agent MUST then + rollback as necessary if the new description was + partially applied when the failure occurred.

        + + +

        If rollback was not necessary or was completed + successfully, let errorType be + IncompatibleSessionDescriptionError. If + rollback was not possible, let errorType be + InternalError and set + connection's signaling + state to closed.

        +
      • +
      +
    6. + + +
    7. +

      Invoke the failureCallback with an + DOMError object, whose name + attribute is errorType, as its argument.

      +
    8. +
    +
  • + + +
  • +

    If the RTCSessionDescription argument is + applied successfully, then user agent must queue a task runs + the following steps:

    + + +
      +
    1. +

      Let connection be the + RTCPeerConnection object on with this + metod was invoked.

      +
    2. + + +
    3. +

      If connection's signaling state + is closed, then abort these steps.

      +
    4. + + +
    5. +

      Set connection's description attribute + (localDescription or + remoteDescription depending on the + setting operation) to the + RTCSessionDescription argument.

      +
    6. + + +
    7. +

      If the local description was set, + connection's ice gathering + state is new, and the local description + contains media, then set connection's ice gathering + state to gathering.

      +
    8. + + +
    9. +

      If the local description was set with content that + caused an ICE restart, then set connection's + ice + gathering state to gathering.

      +
    10. + + +
    11. +

      Set connection's signalingState + accordingly.

      +
    12. + + +
    13. +

      Fire a simple event named signalingstatechange + at connection.

      +
    14. + + +
    15. +

      Queue a new task that, if connection's + signalingState is + not closed, invokes the + successCallback.

      +
    16. +
    +
  • +
+
ParameterTypeNullableOptionalDescription
descriptionRTCSessionDescription
successCallbackVoidFunction
failureCallbackRTCPeerConnectionErrorCallback
Return type: void
setRemoteDescription
+

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

+ + +

If a=identity attributes are present, the browser + verifies the identity following the procedures in [TODO REF to + SECTION ACTION MARTIN TO GO DO THIS + sec.identity-proxy-assertion-request].

+ + +

If any tracks on the RTCPeerConnection have a + peerIdentity constraint and either the RTCPeerConnection + connection has no peer identity or that identity is not equal to + the specified peerIdentity, the user agent MUST queue a + task to invoke failureCallback with a + DOMError object whose name attribute has + the value IncompatibleConstraintsError. Media must not + be transmitted to the other side in this case.

+ +
Note

Open Issue: + Waiting for Martin to see if the above should send black instead of + doing what is above.

+ + +

When the method is invoked, the user agent must follow the + processing model of + setLocalDescription() + .

+
ParameterTypeNullableOptionalDescription
descriptionRTCSessionDescription
successCallbackVoidFunction
failureCallbackRTCPeerConnectionErrorCallback
Return type: void
updateIce
+

The updateIce method updates the ICE Agent process of gathering + local candidates and pinging remote candidates.

+ + +

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.

+ + +

When the updateIce() + method is invoked, the user MUST run the following steps to + process the RTCConfiguration dictionary:

+ + +
    +
  1. +

    If the iceTransports member + is present, let its value be the ICE Agent's ICE transports setting.

    +
  2. + + +
  3. +

    If the iceTransports member + was omitted and the ICE Agent's ICE transports setting is unset, + set the ICE Agent's ICE transports setting to the iceTransports + dictionary member default value.

    +
  4. + + +
  5. +

    If the iceServers dictionary + member is present, but its value is an empty list, then throw + an InvalidAccessError and abort these steps. If + the list, on the other hand, has elements, each element must be + validated by running the following sub-steps:

    + + +
      +
    1. +

      Let server be the current list element.

      +
    2. + + +
    3. +

      If the server.urls dictionary member is + omitted or an empty list, then throw an + InvalidAccessError and abort these steps.

      +
    4. + + +
    5. +

      If server.urls is a string, let + urls be a list consisting of just that string. + Otherwise, let urls refer to the + server.urls list.

      +
    6. + + +
    7. +

      For each url in urls, parse the url and + obtain scheme name. If the parsing fails or if + scheme name is not implemented by the browser, + throw a SyntaxError and abort these steps.

      +
    8. + + +
    9. +

      If scheme name is "turn" and either of the + dictionary members server.username or + server.credential are omitted, then throw an + InvalidAccessError and abort these steps.

      +
    10. + + +

      After passing the validation, let the iceServers + dictionary member be the ICE Agent's ICE servers list.

      + +

      If a new list of servers replaces the ICE Agent's existing + ICE servers list, no action will taken until the + RTCPeerConnection's ice gathering + state transitions to gathering. If a script + wants this to happen immediately, it should do an ICE restart. + + +

    11. +

      If the iceServers dictionary + member was omitted, and the ICE Agent's ICE servers list is unset, throw an + InvalidAccessError and abort these steps.

      +
    12. +
    + + +
    Note
    + The exception types throw in the above algorithm are provisional + (until we decide what to do in each case). +
    +
ParameterTypeNullableOptionalDescription
configurationRTCConfiguration
Return type: void
+
+ + +
+

4.3.3 Garbage collection

+ + +

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

+ +
+
+ + +
+

4.4 State Definitions

+ + +
+

4.4.1 RTCPeerState Enum

+ + +
enum RTCSignalingState {
+    "stable",
+    "have-local-offer",
+    "have-remote-offer",
+    "have-local-pranswer",
+    "have-remote-pranswer",
+    "closed"
+};
Enumeration description
stableThere is no offer­answer exchange in progress. This is also the + initial state in which case the local and remote descriptions are + empty.
have-local-offerA local description, of type "offer", has been successfully + applied.
have-remote-offerA remote description, of type "offer", has been successfully + applied.
have-local-pranswerA remote description of type "offer" has been successfully + applied and a local description of type "pranswer" has been + successfully applied.
have-remote-pranswerA local description of type "offer" has been successfully applied + and a remote description of type "pranswer" has been successfully + applied.
closedThe connection is closed.
+ + +

The non-normative peer state transitions are: The non-normative peer state transition diagram

+ + +

An example set of transitions might be:

+ + +

Caller transition:

+ + +
    +
  • new RTCPeerConnection(): stable
  • + + +
  • setLocal(offer): have-local-offer
  • + + +
  • setRemote(pranswer): have-remote-pranswer
  • + + +
  • setRemote(answer): stable
  • + + +
  • close(): closed
  • +
+ + +

Callee transition:

+ + +
    +
  • new RTCPeerConnection(): stable
  • + + +
  • setRemote(offer): have-remote-offer
  • + + +
  • setLocal(pranswer): have-local-pranswer
  • + + +
  • setLocal(answer): stable
  • + + +
  • close(): closed
  • +
+
+ + +
+

4.4.2 RTCIceGatheringState Enum

+ + +
enum RTCIceGatheringState {
+    "new",
+    "gathering",
+    "complete"
+};
Enumeration description
newThe object was just created, and no networking has occurred + yet.
gatheringThe ICE engine is in the process of gathering candidates for this + RTCPeerConnection.
completeThe ICE engine has completed gathering. Events such as adding a + new interface or a new TURN server will cause the state to go back to + gathering.
+
+ + +
+

4.4.3 RTCIceConnectionState Enum

+ + +
enum RTCIceConnectionState {
+    "new",
+    "checking",
+    "connected",
+    "completed",
+    "failed",
+    "disconnected",
+    "closed"
+};
Enumeration description
newThe ICE Agent is gathering addresses and/or waiting for remote + candidates to be supplied.
checkingThe ICE Agent has received remote candidates on at least one + component, and is checking candidate pairs but has not yet found a + connection. In addition to checking, it may also still be + gathering.
connectedThe ICE Agent has found a usable connection for all components + but is still checking other candidate pairs to see if there is a + better connection. It may also still be gathering.
completedThe ICE Agent has finished gathering and checking and found a + connection for all components. Open issue: it is not clear how the + non controlling ICE side knows it is in the state.
failedThe ICE Agent is finished checking all candidate pairs and failed + to find a connection for at least one component. Connections may have + been found for some components.
disconnectedLiveness checks have failed for one or more components. This is + more aggressive than failed, and may trigger + intermittently (and resolve itself without action) on a flaky + network.
closedThe ICE Agent has shut down and is no longer responding to STUN + requests.
+ + +

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

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

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

+ + +

An example transition might look like:

+ + +
    +
  • new RTCPeerConnection(): new
  • + + +
  • (new, remote candidates received): + checking
  • + + +
  • (checking, found usable connection): + connected
  • + + +
  • (checking, gave up): failed
  • + + +
  • (connected, finished all checks): + completed
  • + + +
  • (completed, lost connectivity): + disconnected
  • + + +
  • (any state, ICE restart occurs): new
  • + + +
  • close(): closed
  • +
+ + +

The non-normative ICE state transitions are: The non-normative ICE state transition diagram

+
+
+ + +
+

4.5 Callback Definitions

+ + +
+

4.5.1 RTCPeerConnectionErrorCallback

+ + +
callback RTCPeerConnectionErrorCallback = void (DOMError error);
4.5.1.1 Callback RTCPeerConnectionErrorCallback Parameters
error of type DOMError
An error object encapsulating information about what went + wrong.
+
+
+ + +
+

4.6 Error Handling

+ + +
+

4.6.1 General Principles

+ + +

Errors are indicated in two ways: exceptions and objects passed to + error callbacks. Exceptions are thrown to indicate invalid state and + other programming errors. For example when a method is called when the + RTCPeerConnection is in an invalid state, or a + state in which that particular method is not allowed to be executed. In + all other cases, an error object MUST be provided to the error + callback.

+
+ + +
+

4.6.2 RTCSdpError

+ + +
interface RTCSdpError : DOMError {
+    readonly    attribute long sdpLineNumber;
+};
4.6.2.1 Attributes
sdpLineNumber of type long, readonly
The line number of an RTCSessionDescription + at which the error was encountered.
+ + +
Note
+

Ask the DOM team to extend their list with the following errors. + The error names and their descriptions are directly copied from the + old RTCErrorName enum and might need some adjustment before being + added to the public list of errors.

+ + +
    +
  • InvalidSessionDescriptionError: The provided + RTCSessionDescription contained invalid SDP, or the type was wrong + for the current state of the RTCPeerConnection. User agents SHOULD + provide as much additional information in the error message as + possible, including the sdpLineNumber, if appropriate.
  • + + +
  • IncompatibleSessionDescriptionError: The provided + RTCSessionDescription contained SDP that could not be correctly + applied to the RTCPeerConnection due to its current state. User + agents SHOULD provide as much additional information in the error + message as possible, including the sdpLineNumber, if + appropriate.
  • + + +
  • IncompatibleConstraintsError: The provided MediaConstraints + could not be correctly applied to the RTCPeerConnection due to its + current state. User agents SHOULD provide as much additional + information in the error message as possible.
  • + + +
  • IncompatibleMediaStreamTrackError: The provided + MediaStreamTrack is not an element of a MediaStream that is + currently in the RTCPeerConnection's localStreams attribute.
  • + + +
  • InternalError: The RTCPeerConnection encountered an error that + it could not recover from.
  • +
+
+
+
+ + +
+

4.7 Session Description Model

+ + +
+

4.7.1 RTCSdpType

+ + +

The RTCSdpType enum describes the type of an + RTCSessionDescription instance.

+ + +
enum RTCSdpType {
+    "offer",
+    "pranswer",
+    "answer"
+};
Enumeration description
offer +

An RTCSdpType of "offer" indicates that a description should be + treated as an [SDP] offer.

+
pranswer +

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

+
answer +

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

+
+
+ + +
+

4.7.2 RTCSessionDescription Class

+ + +
dictionary RTCSessionDescriptionInit {
+    RTCSdpType type;
+    DOMString  sdp;
+};

[ Constructor (optional RTCSessionDescriptionInit descriptionInitDict)] +interface RTCSessionDescription { + attribute RTCSdpType? type; + attribute DOMString? sdp; + serializer = {attribute}; +};
4.7.2.1 Constructors
RTCSessionDescription
The RTCSessionDescription() + constructor takes an optional dictionary argument, + descriptionInitDict, whose content is used to initialize + the new RTCSessionDescription object. If a + dictionary key is not present in descriptionInitDict, the + corresponding attribute will be initialized to null. If the + constructor is run without the dictionary argument, all attributes + will be initialized to null. This class is a future extensible + carrier for the data contained in it and does not perform any + substantive processing.
ParameterTypeNullableOptionalDescription
descriptionInitDictRTCSessionDescriptionInit
4.7.2.2 Attributes
sdp of type DOMString, , nullable
The string representation of the SDP [SDP]
type of type RTCSdpType, , nullable
The type of SDP this RTCSessionDescription represents.
4.7.2.3 Serializer

Instances of this interface are serialized as a map with entries for each of the serializable attributes.

+ + +
4.7.2.4 Dictionary RTCSessionDescriptionInit Members
sdp of type DOMString
type of type RTCSdpType
DOMString sdp
+
+ + +
+

4.7.3 RTCSessionDescriptionCallback

+ + +
callback RTCSessionDescriptionCallback = void (RTCSessionDescription sdp);
4.7.3.1 Callback RTCSessionDescriptionCallback Parameters
sdp of type RTCSessionDescription
The object containing the SDP [SDP].
+
+
+ + +
+

4.8 Interfaces for Connectivity Establishment

+ + +
+

4.8.1 RTCIceCandidate Type

+ + +

This class is a future extensible carrier for the data contained in + it and does not perform any substantive processing.

+ + +
dictionary RTCIceCandidateInit {
+    DOMString      candidate;
+    DOMString      sdpMid;
+    unsigned short sdpMLineIndex;
+};

[ Constructor (optional RTCIceCandidateInit candidateInitDict)] +interface RTCIceCandidate { + attribute DOMString? candidate; + attribute DOMString? sdpMid; + attribute unsigned short? sdpMLineIndex; + serializer = {attribute}; +};
4.8.1.1 Constructors
RTCIceCandidate
The RTCIceCandidate() constructor + takes an optional dictionary argument, candidateInitDict, + whose content is used to initialize the new + RTCIceCandidate object. If a dictionary key is + not present in candidateInitDict, the corresponding + attribute will be initialized to null. If the constructor is run + without the dictionary argument, all attributes will be initialized + to null.
ParameterTypeNullableOptionalDescription
candidateInitDictRTCIceCandidateInit
4.8.1.2 Attributes
candidate of type DOMString, , nullable
This carries the candidate-attribute as defined in section 15.1 + of [ICE].
sdpMLineIndex of type unsigned short, , nullable
This indicates the index (starting at zero) of the m-line in the + SDP this candidate is associated with.
sdpMid of type DOMString, , nullable
If present, this contains the identifier of the "media stream + identification" as defined in [RFC 3388] for the m-line this + candidate is associated with.
4.8.1.3 Serializer

Instances of this interface are serialized as a map with entries for each of the serializable attributes.

+ + +
4.8.1.4 Dictionary RTCIceCandidateInit Members
candidate of type DOMString
DOMString sdpMid
sdpMLineIndex of type unsigned short
sdpMid of type DOMString
unsigned short sdpMLineIndex
+
+ + +
+

4.8.2 RTCPeerConnectionIceEvent

+ + +

The icecandidate event of the RTCPeerConnection uses + the RTCPeerConnectionIceEvent interface.

+ + +

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

+ + +
dictionary RTCPeerConnectionIceEventInit : EventInit {
+    RTCIceCandidate candidate;
+};

[ Constructor (DOMString type, RTCPeerConnectionIceEventInit eventInitDict)] +interface RTCPeerConnectionIceEvent : Event { + readonly attribute RTCIceCandidate candidate; +};
4.8.2.1 Constructors
RTCPeerConnectionIceEvent
readonly attribute RTCIceCandidate candidate
ParameterTypeNullableOptionalDescription
typeDOMString
eventInitDictRTCPeerConnectionIceEventInit
4.8.2.2 Attributes
candidate of type RTCIceCandidate, readonly
+

The candidate attribute is the + RTCIceCandidate object with the new ICE + candidate that caused the event.

+
+ + +
4.8.2.3 Dictionary RTCPeerConnectionIceEventInit Members
candidate of type RTCIceCandidate
+

TODO

+
+
+
+
+ + +
+

5. Peer-to-peer Data API

+ + +

The Peer-to-peer Data API lets a web application send and receive + generic application data peer-to-peer. The API for sending and receiving + data models the behavior of WebSockets [WEBSOCKETS-API].

+ + +
+

5.1 RTCPeerConnection Interface Extensions

+ + +

The Peer-to-peer data API extends the + RTCPeerConnection interface as described below.

+ + +
partial interface RTCPeerConnection {
+    RTCDataChannel createDataChannel ([TreatNullAs=EmptyString] DOMString label, optional RTCDataChannelInit dataChannelDict);
+                attribute EventHandler ondatachannel;
+};

5.1.1 Attributes

ondatachannel of type EventHandler,
This event handler, of type datachannel, MUST be supported by all + objects implementing the RTCPeerConnection + interface.

5.1.2 Methods

createDataChannel
+

Creates a new RTCDataChannel object with the + given label. The RTCDataChannelInit dictionary + can be used to configure properties of the underlying channel such as + data reliability.

+ + +

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

+ + +
    +
  1. +

    If the RTCPeerConnection object’s RTCPeerConnection + signalingState is closed, throw an + InvalidStateError exception and abort these + steps.

    +
  2. + + +
  3. +

    Let channel be a newly created + RTCDataChannel object.

    +
  4. + + +
  5. +

    Initialize channel's label attribute to the value + of the first argument.

    +
  6. + + +
  7. +

    If the second (dictionary) argument is present, set + channel's ordered, maxRetransmitTime, + maxRetransmits, + protocol, + negotiated + and id attributes + to the values of their corresponding dictionary members (if + present in the dictionary).

    +
  8. + + +
  9. +

    If both the maxRetransmitTime + and maxRetransmits + attributes are set (not null), then throw a + SyntaxError exception and abort these steps.

    +
  10. + + +
  11. +

    If an attribute, either maxRetransmitTime + or maxRetransmits, has + been set to indicate unreliable mode, and that value exceeds the + maximum value supported by the user agent, the value must be set + to the user agents maximum value.

    +
  12. + + +
  13. +

    If id attribute + is uninitialized (not set via the dictionary), initialize it to a + value generated by the user agent, according to the WebRTC + DataChannel Protocol specification, and skip to the next step. + Otherwise, if the value of the id attribute is taken by an + existing RTCDataChannel, throw a + ResourceInUse exception and abort these steps.

    +
  14. + + +
  15. +

    Return channel and continue the following steps in + the background.

    +
  16. + + +
  17. +

    Create channel's associated underlying data + transport and configure it according to the relevant + properties of channel.

    +
  18. +
+
ParameterTypeNullableOptionalDescription
labelDOMString
dataChannelDictRTCDataChannelInit
Return type: RTCDataChannel
+
+ + +
+

5.2 RTCDataChannel

+ + +

The RTCDataChannel interface represents a + bi-directional data channel between two peers. A + RTCDataChannel is created via a factory method on an + RTCPeerConnection object.

+ + +

There are two ways to establish a connection with + RTCDataChannel. The first way is to simply create a + RTCDataChannel at one of the peers with the + negotiated + RTCDataChannelInit dictionary member unset or set to + its default value false. This will announce the new channel in-band and + trigger a RTCDataChannelEvent with the corresponding + RTCDataChannel object at the other peer. The second + way is to let the application negotiate the + RTCDataChannel. To do this, create a + RTCDataChannel object with the negotiated + RTCDataChannelInit dictionary member set to true, and + signal out-of-band (e.g. via a web server) to the other side that it + should create a corresponding RTCDataChannel with the + negotiated + RTCDataChannelInit dictionary member set to true and + the same id. This will + connect the two separately created RTCDataChannel + objects. The second way makes it possible to create channels with + asymmetric properties and to create channels in a declarative way by + specifying matching ids.

+ + +

Each RTCDataChannel has an associated + underlying data transport that is used to transport actual + data to the other peer. The transport properties of the underlying + data transport, such as in order delivery settings and reliability + mode, are configured by the peer as the channel is created. The + properties of a channel cannot change after the channel has been created. + The actual wire protocol between the peers is specified by the WebRTC + DataChannel Protocol specification (TODO: reference needed).

+ + +

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

+ + +

A RTCDataChannel, created with createDataChannel() or + dispatched via a RTCDataChannelEvent, MUST initially + be in the connecting state. When the + RTCDataChannel object’s underlying data + transport is ready, the user agent MUST announce the RTCDataChannel as + open.

+ + +

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

+ + +
    +
  1. +

    If the associated RTCPeerConnection object's + RTCPeerConnection + signalingState is closed, abort these steps.

    +
  2. + + +
  3. +

    Let channel be the RTCDataChannel + object to be announced.

    +
  4. + + +
  5. +

    Set channel's readyState attribute to + open.

    +
  6. + + +
  7. +

    Fire a simple event named open at channel.

    +
  8. +
+ + +

When an underlying data transport is to be announced (the other + peer created a channel with negotiated unset or set + to false), the user agent of the peer that did not initiate the creation + process MUST queue a task to run the following steps:

+ + +
    +
  1. +

    If the associated RTCPeerConnection object's + RTCPeerConnection + signalingState is closed, abort these steps.

    +
  2. + + +
  3. +

    Let channel be a newly created + RTCDataChannel object.

    +
  4. + + +
  5. +

    Let configuration be an information bundle received + from the other peer as a part of the process to establish the + underlying data transport described by the WebRTC DataChannel + Protocol specification.

    +
  6. + + +
  7. +

    Initialize channel's label, ordered, maxRetransmitTime, + maxRetransmits, + protocol, + negotiated and + id attributes to their + corresponding values in configuration.

    +
  8. + + +
  9. +

    Set channel's readyState attribute to + connecting.

    +
  10. + + +
  11. +

    Fire a datachannel event named datachannel with channel + at the RTCPeerConnection object.

    +
  12. +
+ + +

An RTCDataChannel object's underlying data + transport may be torn down in a non-abrupt manner by running the + closing procedure. When + that happens the user agent MUST, unless the procedure was initiated by + the close() method, + queue a task that sets the object's readyState attribute to + closing. This will eventually render the data transport closed.

+ + +
Note
+ References to protocol specification are needed. +
+ + +

When a RTCDataChannel object's underlying data + transport has been closed, the + user agent MUST queue a task to run the following steps:

+ + +
    +
  1. +

    Let channel be the RTCDataChannel + object whose transport + was closed.

    + + +
    Note
    + The data transport protocol will specify what happens to, e.g. + buffered data, when the data transport is closed. +
    +
  2. + + +
  3. +

    Set channel's readyState attribute to + closed.

    +
  4. + + +
  5. +

    If the transport was + closed with an error, + fire an NetworkError event at channel.

    +
  6. + + +
  7. +

    Fire a simple event named close at + channel.

    +
  8. +
+ + +
dictionary RTCDataChannelInit {
+    boolean        ordered = true;
+    unsigned short maxRetransmitTime;
+    unsigned short maxRetransmits;
+    DOMString      protocol = "";
+    boolean        negotiated = false;
+    unsigned short id;
+};

interface RTCDataChannel : EventTarget { + readonly attribute DOMString label; + readonly attribute boolean ordered; + readonly attribute unsigned? maxRetransmitTime; + readonly attribute unsigned? maxRetransmits; + readonly attribute DOMString protocol; + readonly attribute boolean negotiated; + readonly attribute unsigned short id; + readonly attribute RTCDataChannelState readyState; + readonly attribute unsigned long bufferedAmount; + attribute EventHandler onopen; + attribute EventHandler onerror; + attribute EventHandler onclose; + void close (); + attribute EventHandler onmessage; + attribute DOMString binaryType; + void send (DOMString data); + void send (Blob data); + void send (ArrayBuffer data); + void send (ArrayBufferView data); +};

5.2.1 Attributes

binaryType of type DOMString,
+

The binaryType attribute + MUST, on getting, return the value to which it was last set. On + setting, the user agent must set the IDL attribute to the new value. + When a RTCDataChannel object is created, the + binaryType + attribute MUST be initialized to the string "blob".

+ + +

This attribute controls how binary data is exposed to scripts. See + the [WEBSOCKETS-API] for more information.

+
bufferedAmount of type unsigned long, readonly
+

The bufferedAmount + attribute MUST return the number of bytes of application data (UTF-8 + text and binary data) that have been queued using send() but that, as of the last + time the event loop started executing a task, had not yet been + transmitted to the network. (This thus includes any text sent during + the execution of the current task, regardless of whether the user + agent is able to transmit text asynchronously with script execution.) + This does not include framing overhead incurred by the protocol, or + buffering done by the operating system or network hardware. If the + channel is closed, this attribute's value will only increase with + each call to the send() method (the attribute does + not reset to zero once the channel closes).

+
id of type unsigned short, readonly
+

The RTCDataChannel.id attribute + returns the id for this RTCDataChannel . The id + was either assigned by the user agent at channel creation time or + selected by the script. The attribute MUST return the value to which + it was set when the RTCDataChannel was + created.

+
label of type DOMString, readonly
+

The RTCDataChannel.label + attribute represents a label that can be used to distinguish this + RTCDataChannel object from other + RTCDataChannel objects. The attribute MUST return + the value to which it was set when the + RTCDataChannel object was created.

+
maxRetransmitTime of type unsigned, readonly , nullable
+

The RTCDataChannel.maxRetransmitTime + attribute returns the length of the time window (in milliseconds) + during which retransmissions may occur in unreliable mode, or null if + unset. The attribute MUST be initialized to null by default and MUST + return the value to which it was set when the + RTCDataChannel was created.

+
maxRetransmits of type unsigned, readonly , nullable
+

The RTCDataChannel.maxRetransmits + attribute returns the maximum number of retransmissions that are + attempted in unreliable mode, or null if unset. The attribute MUST be + initialized to null by default and MUST return the value to which it + was set when the RTCDataChannel was created.

+
negotiated of type boolean, readonly
+

The RTCDataChannel.negotiated + attribute returns true if this RTCDataChannel was + negotiated by the application, or false otherwise. The attribute MUST + be initialized to false by default and MUST return the value to which + it was set when the RTCDataChannel was + created.

+
onclose of type EventHandler,
This event handler, of type close, MUST be supported by all + objects implementing the RTCDataChannel + interface.
onerror of type EventHandler,
This event handler, of type error, MUST be supported by all + objects implementing the RTCDataChannel + interface.
onmessage of type EventHandler,
This event handler, of type message ,MUST be supported by + all objects implementing the RTCDataChannel + interface.
onopen of type EventHandler,
This event handler, of type open, MUST be supported by all + objects implementing the RTCDataChannel + interface.
ordered of type boolean, readonly
+

The RTCDataChannel.ordered + attribute returns true if the RTCDataChannel is + ordered, and false if other of order delivery is allowed. The + attribute MUST be initialized to true by default and MUST return the + value to which it was set when the RTCDataChannel + was created.

+
protocol of type DOMString, readonly
+

The RTCDataChannel.protocol + attribute returns the name of the sub-protocol used with this + RTCDataChannel if any, or the empty string + otherwise. The attribute MUST be initialized to the empty string by + default and MUST return the value to which it was set when the + RTCDataChannel was created.

+
readyState of type RTCDataChannelState, readonly
+

The RTCDataChannel.readyState + attribute represents the state of the RTCDataChannel + object. It MUST return the value to which the user agent last set it + (as defined by the processing model algorithms).

+

5.2.2 Methods

close
+

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

+ + +

When the RTCDataChannel + close() method is called, the user agent MUST run the + following steps:

+ + +
    +
  1. +

    Let channel be the + RTCDataChannel object which is about to be + closed.

    +
  2. + + +
  3. +

    If channel's readyState is + closing or closed, then abort these + steps.

    +
  4. + + +
  5. +

    Set channel's readyState attribute to + closing.

    +
  6. + + +
  7. +

    If the closing procedure + has not started yet, start it.

    +
  8. +
+
No parameters.
Return type: void
send
+

Run the steps described by the send() algorithm with argument + type string object.

+
ParameterTypeNullableOptionalDescription
dataDOMString
Return type: void
send
+

Run the steps described by the send() algorithm with argument + type Blob object.

+
ParameterTypeNullableOptionalDescription
dataBlob
Return type: void
send
+

Run the steps described by the send() algorithm with argument + type ArrayBuffer object.

+
ParameterTypeNullableOptionalDescription
dataArrayBuffer
Return type: void
send
+

Run the steps described by the send() algorithm with argument + type ArrayBufferView object.

+
ParameterTypeNullableOptionalDescription
dataArrayBufferView
Return type: void
+ + +

5.2.3 Dictionary RTCDataChannelInit Members

id of type unsigned short
+

Overrides the default selection of id for this channel.

+
maxRetransmitTime of type unsigned short
+

Limits the time during which the channel will retransmit data if + not successfully delivered. This value may be clamped if it exceeds + the maximum value supported by the user agent.

+
maxRetransmits of type unsigned short
+

Limits the number of times a channel will retransmit data if not + successfully delivered. This value may be clamped if it exceeds the + maximum value supported by the user agent..

+
negotiated of type boolean, defaulting to false
+

The default value of false tells the user agent to announce the + channel in-band and instruct the other peer to dispatch a + corresponding RTCDataChannel object. If set to + true, it is up to the application to negotiate the channel and create + a RTCDataChannel object with the same + id at the other + peer.

+
ordered of type boolean, defaulting to true
+

If set to false, data is allowed to be delivered out of order. The + default value of true, guarantees that data will be delivered in + order.

+
protocol of type DOMString, defaulting to ""
+

Subprotocol name used for this channel.

+
+ + +

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

+ + +
    +
  1. +

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

    +
  2. + + +
  3. +

    If channel’s readyState attribute + is connecting, throw an InvalidStateError + exception and abort these steps.

    +
  4. + + +
  5. +

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

    + + +
      +
    • +

      string object:

      + + +

      Let data be the result of converting the argument + object to a sequence of Unicode characters and increase the + bufferedAmount + attribute by the number of bytes needed to express + data as UTF-8.

      +
    • + + +
    • +

      Blob object:

      + + +

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

      +
    • + + +
    • +

      ArrayBuffer object:

      + + +

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

      +
    • + + +
    • +

      ArrayBufferView object:

      + + +

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

      +
    • +
    +
  6. + + +
  7. +

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

    +
  8. + + +
  9. +

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

    +
  10. +
+ + +
enum RTCDataChannelState {
+    "connecting",
+    "open",
+    "closing",
+    "closed"
+};
Enumeration description
connecting +

The user agent is attempting to establish the underlying data + transport. This is the initial state of a + RTCDataChannel object created with createDataChannel() + .

+
open +

The underlying data transport is established and + communication is possible. This is the initial state of a + RTCDataChannel object dispatched as a part of a + RTCDataChannelEvent .

+
closing +

The procedure to close + down the underlying data transport has started.

+
closed +

The underlying data transport has been closed or could not be + established.

+
+ +
+ + +
+

5.3 RTCDataChannelEvent

+ + +

The datachannel event + uses the RTCDataChannelEvent interface.

+ + +

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

+ + +
dictionary RTCDataChannelEventInit : EventInit {
+    RTCDataChannel channel;
+};

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

5.3.1 Constructors

RTCDataChannelEvent
readonly attribute RTCDataChannel channel
ParameterTypeNullableOptionalDescription
typeDOMString
eventInitDictRTCDataChannelEventInit

5.3.2 Attributes

channel of type RTCDataChannel, readonly
+

The channel attribute + represents the RTCDataChannel object associated + with the event.

+
+ + +

5.3.3 Dictionary RTCDataChannelEventInit Members

channel of type RTCDataChannel
+

TODO

+
+
+ + +
+

5.4 Garbage Collection

+ + +

A RTCDataChannel object MUST not be garbage + collected if its

+ + + +
+
+ + +
+

6. Peer-to-peer DTMF

+ + +

In order to send DTMF (phone keypad) values across an + RTCPeerConnection, the user agent needs to know which + MediaStreamTrack on which + RTCPeerConnection will carry the DTMF. This section + describes an interface on RTCPeerConnection to + associate DTMF capability with a MediaStreamTrack for + that RTCPeerConnection.

+ + +
+

6.1 RTCPeerConnection Interface Extensions

+ + +

The Peer-to-peer DTMF API extends the + RTCPeerConnection interface as described below.

+ + +
partial interface RTCPeerConnection {
+    RTCDTMFSender createDTMFSender (MediaStreamTrack track);
+};

6.1.1 Methods

createDTMFSender
+

The createDTMFSender() method creates an RTCDTMFSender + that references the given MediaStreamTrack. The MediaStreamTrack MUST + be an element of a MediaStream that's currently in the + RTCPeerConnection object's local streams set; if not, throw an + InvalidParameter exception and abort these steps.

+
ParameterTypeNullableOptionalDescription
trackMediaStreamTrack
Return type: RTCDTMFSender
+
+ + +
+

6.2 RTCDTMFSender

+ + +

An RTCDTMFSender is created by calling the + createDTMFSender() method on an + RTCPeerConnection. This constructs an object that + exposes the functions required to send DTMF on the given + MediaStreamTrack.

+ + +
[NoInterfaceObject]
+interface RTCDTMFSender {
+    readonly    attribute boolean          canInsertDTMF;
+    void insertDTMF (DOMString tones, optional long duration, optional long interToneGap);
+    readonly    attribute MediaStreamTrack track;
+                attribute EventHandler     ontonechange;
+    readonly    attribute DOMString        toneBuffer;
+    readonly    attribute long             duration;
+    readonly    attribute long             interToneGap;
+};

6.2.1 Attributes

canInsertDTMF of type boolean, readonly
+

The canInsertDTMF + attribute MUST indicate if the RTCDTMFSender is + capable of sending DTMF.

+
duration of type long, readonly
+

The duration attribute + MUST return the current tone duration value. This value will be the + value last set via the insertDTMF() method, or + the default value of 100 ms if insertDTMF() was + called without specifying the duration.

+
interToneGap of type long, readonly
+

The interToneGap + attribute MUST return the current value of the between-tone gap. This + value will be the value last set via the + insertDTMF() method, or the default value of 50 + ms if insertDTMF() was called without specifying + the interToneGap.

+
ontonechange of type EventHandler,
+

This event handler uses the + RTCDTMFToneChangeEvent interface to return the + character for each tone as it is played out. See + RTCDTMFToneChangeEvent for details.

+
toneBuffer of type DOMString, readonly
+

The toneBuffer + attribute MUST return a list of the tones remaining to be played out. + For the syntax, content, and interpretation of this list, see + insertDTMF.

+
track of type MediaStreamTrack, readonly
+

The track attribute MUST return the + MediaStreamTrack given as argument to the + createDTMFSender() method.

+

6.2.2 Methods

insertDTMF
+

An RTCDTMFSender object’s insertDTMF() method + is used to send DTMF tones.

+ + +

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

+ + +

The duration parameter indicates the duration in ms to use for + each character passed in the tones parameters. The duration cannot be + more than 6000 ms or less than 40 ms. The default duration is 100 ms + for each tone.

+ + +

The interToneGap parameter indicates the gap between tones. It + MUST be at least 30 ms. The default value is 70 ms.

+ + +

The browser MAY increase the duration and interToneGap times to + cause the times that DTMF start and stop to align with the boundaries + of RTP packets but it MUST not increase either of them by more than + the duration of a single RTP audio packet.

+ + +
Issue 2

ISSUE: How are invalid values handled?

+ + +

When the insertDTMF() method is invoked, the + user agent MUST run the following steps:

+ + +
    +
  1. If the associated MediaStreamTrack is not + connected to the associated RTCPeerConnection, + return.
  2. + + +
  3. If the canInsertDTMF + attribute is false, return.
  4. + + +
  5. Set the value of the toneBuffer attribute to + the value of the tones argument, the value of the + duration + attribute to the duration argument if specified, and the + value of the interToneGap to the + interToneGap argument, if specified.
  6. + + +
  7. If toneBuffer is an empty + string, return.
  8. + + +
  9. If a Playout task is scheduled to be run; abort these + steps; otherwise queue a task that runs the following steps + (Playout task): + +
      +
    1. If toneBuffer is an + empty string, fire an event named tonechange with an + empty string at the RTCDTMFSender object + and abort these steps.
    2. + + +
    3. Remove the first character from toneBuffer and let + that character be tone.
    4. + + +
    5. Start playout of tone for duration ms on the + associated RTP media stream, using the appropriate codec.
    6. + + +
    7. Queue a task to be executed in duration + + interToneGap ms + from now that runs the steps labelled Playout + task.
    8. + + +
    9. Fire an event named tonechange with a + string consisting of tone at the + RTCDTMFSender object.
    10. +
    +
  10. +
+ + +

Calling insertDTMF() with an empty + tones parameter can be used to cancel all tones queued to play after + the currently playing tone.

+
ParameterTypeNullableOptionalDescription
tonesDOMString
durationlong
interToneGaplong
Return type: void
+
+ + +
+

6.3 RTCDTMFToneChangeEvent

+ + +

The tonechange event uses the + RTCDTMFToneChangeEvent interface.

+ + +

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

+ + +
dictionary RTCDTMFToneChangeEventInit : EventInit {
+    DOMString tone;
+};

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

6.3.1 Constructors

RTCDTMFToneChangeEvent
readonly attribute DOMString tone
ParameterTypeNullableOptionalDescription
typeDOMString
eventInitDictRTCDTMFToneChangeEventInit

6.3.2 Attributes

tone of type DOMString, readonly
+

The tone + attribute contains the character for the tone that has just begun + playout (see insertDTMF()). If the value is the + empty string, it indicates that the previous tone has completed + playback.

+
+ + +

6.3.3 Dictionary RTCDTMFToneChangeEventInit Members

tone of type DOMString
+

TODO

+
+
+
+ + +
+

7. Statistics Model

+ + +
+

7.1 Introduction

+ + +

The basic statistics model is that the browser maintains a set of + statistics referenced by a selector. The + selector may, for example, be a MediaStreamTrack. For a + track to be a valid selector, it must be a member of a + MediaStream that is sent or received by the + RTCPeerConnection object on which the stats request + was issued. The calling Web application provides the selector to the + getStats() method + and the browser emits (in the JavaScript) a set of statistics that it + believes is relevant to the selector.

+ + +
Note
+ Evaluate the need for other selectors than MediaStreamTrack. +
+ + +

The statistics returned are designed in such a way that repeated + queries can be linked by the RTCStats id dictionary member. Thus, a Web application can + make measurements over a given time period by requesting measurements at + the beginning and end of that period.

+
+ + +
+

7.2 RTCPeerConnection Interface Extensions

+ + +

The Statistics API extends the RTCPeerConnection + interface as described below.

+ + +
partial interface RTCPeerConnection {
+    void getStats (MediaStreamTrack? selector, RTCStatsCallback successCallback, RTCPeerConnectionErrorCallback failureCallback);
+};

7.2.1 Methods

getStats
+

Gathers stats for the given selector + and reports the result asynchronously.

+ + +

When the getStats() method is + invoked, the user agent MUST queue a task to run the following + steps:

+ + +
    +
  1. +

    If the RTCPeerConnection object's RTCPeerConnection + signalingState is closed, throw an + InvalidStateError exception.

    +
  2. + + +
  3. +

    Return, but continue the following steps in the + background.

    +
  4. + + +
  5. +

    Let selectorArg be the methods first argument.

    +
  6. + + +
  7. +

    If selectorArg is an invalid selector, the user agent MUST queue a task + to invoke the failure callback (the method's third argument).

    +
  8. + + +
  9. +

    Start gathering the stats indicated by selectorArg. + In case selectorArg is null, stats MUST be gathered + for the whole RTCPeerConnection object.

    +
  10. + + +
  11. +

    When the relevant stats have been gathered, queue a task to + invoke the success callback (the method's second argument) with a + new RTCStatsReport object, representing the + gathered stats, as its argument.

    +
  12. +
+
ParameterTypeNullableOptionalDescription
selectorMediaStreamTrack
successCallbackRTCStatsCallback
failureCallbackRTCPeerConnectionErrorCallback
Return type: void
+
+ + +
+

7.3 RTCStatsCallback

+ + +
callback RTCStatsCallback = void (RTCStatsReport report);

7.3.1 Callback RTCStatsCallback Parameters

report of type RTCStatsReport
+

A RTCStatsReport representing the gathered + stats.

+
+
+ + +
+

7.4 RTCStatsReport Object

+ + +

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

+ + +

An RTCStatsReport may be composed of several + RTCStats objects, each reporting stats for one + underlying object that the implementation thinks is relevant for the + selector. One achieves the total for the + selector by summing over all the stats of a + certain type; for instance, if a MediaStreamTrack is carried + by multiple SSRCs over the network, the + RTCStatsReport may contain one RTCStats + object per SSRC (which can be distinguished by the value of the "ssrc" + stats attribute).

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

7.4.1 Methods

RTCStats
+

Getter to retrieve the RTCStats objects that + this stats report is composed of.

+ + +

The set of supported property names [WEBIDL] is defined as the + ids of all the RTCStats objects that has been + generated for this stats report. The order of the property names is + left to the user agent.

+
ParameterTypeNullableOptionalDescription
idDOMString
Return type: getter
+
+ + +
+

7.5 RTCStats Dictionary

+ + +

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

+ + +

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

+ + +
Note
+ OPEN ISSUE: Need to define an IANA registry for this and populate with + pointers to existing things such as the RTCP statistics. +
+ + +

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

+ + +
dictionary RTCStats {
+    DOMHiResTimeStamp timestamp;
+    RTCStatsType      type;
+    DOMString         id;
+};

7.5.1 Dictionary RTCStats Members

id of type DOMString
+

A unique id that is + associated with the object that was inspected to produce this + RTCStats object. Two RTCStats + objects, extracted from two different + RTCStatsReport objects, MUST have the same id if + they were produced by inspecting the same underlying object. User + agents are free to pick any format for the id as long as it meets the + requirements above.

+ + +
Note
+ Consider naming id something that indicates that the id refers to + the underlying object that was inspected to produce the stats, + instead of being an id for the JavaScript object. Suggestions: + statsObjectId, reporterId, srcId. +
+
timestamp of type DOMHiResTimeStamp
+

The timestamp, + of type DOMHiResTimeStamp [HIGHRES-TIME], associated + with this object. The time is relative to the UNIX epoch (Jan 1, + 1970, UTC).

+
type of type RTCStatsType
+

The type of this object.

+ + +

The type attribute + MUST be initialized to the name of the most specific type this + RTCStats dictionary represents.

+
+ + +
enum RTCStatsType {
+    "inbound-rtp",
+    "outbound-rtp"
+};
Enumeration description
inbound-rtpInbound RTP.
outbound-rtpOutbund RTP.
+
+ + +
+

7.6 Derived Stats Dictionaries

+ + +
dictionary RTCRTPStreamStats : RTCStats {
+    DOMString ssrc;
+    DOMString remoteId;
+};

7.6.1 Dictionary RTCRTPStreamStats Members

remoteId of type DOMString
+

The remoteId can be used to look up the corresponding + RTCStats object that represents stats reported by + the other peer.

+
ssrc of type DOMString
+

...

+
+ + +
dictionary RTCInboundRTPStreamStats : RTCRTPStreamStats {
+    unsigned long packetsReceived;
+    unsigned long bytesReceived;
+};

7.6.2 Dictionary RTCInboundRTPStreamStats Members

bytesReceived of type unsigned long
+

...

+
packetsReceived of type unsigned long
+

...

+
+ + +
dictionary RTCOutboundRTPStreamStats : RTCRTPStreamStats {
+    unsigned long packetsSent;
+    unsigned long bytesSent;
+};

7.6.3 Dictionary RTCOutboundRTPStreamStats Members

bytesSent of type unsigned long
+

...

+
packetsSent of type unsigned long
+

...

+
+
+ + +
+

7.7 Example

+ + +

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

+ +
Example 1
var baselineReport, currentReport;
+var selector = pc.getRemoteStreams()[0].getAudioTracks()[0];
+
+pc.getStats(selector, function (report) {
+    baselineReport = report;
+});
+
+// ... wait a bit
+setTimeout(function () {
+    pc.getStats(selector, function (report) {
+        currentReport = report;
+        processStats();
+    });
+}, aBit);
+
+function processStats() {
+    // compare the elements from the current report with the baseline
+    for each (var now in currentReport) {
+        if (now.type != "outbund-rtp")
+            continue;
+
+        // get the corresponding stats from the baseline report
+        base = baselineReport[now.id];
+
+        if (base) {
+            remoteNow = currentReport[now.remoteId];
+            remoteBase = baselineReport[base.remoteId];
+
+            var packetsSent = now.packetsSent - base.packetsSent;
+            var packetsReceived = remoteNow.packetsReceived - remoteBase.packetsReceived;
+
+            // if fractionLost is > 0.3, we have probably found the culprit
+            var fractionLost = (packetsSent - packetsReceived) / packetsSent;
+        }
+    }
+}
+
+
+ + +
+

8. Identity

+ + +
+

8.1 Identity Provider Interaction

+ + +

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

+ + +

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

+ + +
+

8.1.1 Peer-Connection/IdP + Communications

+ + +

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

+ + +

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

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

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

+
+ + +
+

8.1.2 Instantiating an IdP Proxy

+ + +

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

+ + +

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

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

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

+ +
+
+ + +
+

8.2 Requesting Assertions

+ + +

The identity assertion request process involves the following + steps.

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

8.3 Verifying Assertions

+ + +

The identity assertion request process involves the following + steps.

+ + +
    +
  1. The RTCPeerConnection instantiates an IdP context as + described in the previous section.
  2. + + +
  3. The IdP serves up the IdP JavaScript code to the IdP context.
  4. + + +
  5. Once the IdP is loaded and ready to receive messages it sends a + "READY" message [RTCWEB-SECURITY-ARCH]. Note that this + does not imply that the user is logged in, merely that enough IdP state + is booted up to be ready to handle PostMessage calls.
  6. + + +
  7. The IdP sends a "VERIFY" message to the IdP + proxy context. This message includes assertion from the offer/answer + which is to be verified.
  8. + + +
  9. The IdP proxy verifies the identity assertion (depending on the + authentication protocol this may involve interacting with the IDP + server).
  10. + + +
  11. Once the assertion is verified the IdP proxy sends a response + containing the verified assertion results to the + RTCPeerConnection over the message channel.
  12. + + +
  13. If an incoming stream is associated with an identity assertion, + implementations SHOULD still allow sites access to the stream (i.e., + they should not taint it) but MUST NOT display the browser chrome + identity indications if the site maps it onto a modifiable or viewable + object. If the site performs such a mapping after the chrome + indications have been displayed, the browser MUST change the identity + indicators appropriately and MAY wish to ask for user consent prior to + allowing the mapping.
  14. + + +
  15. The RTCPeerConnection displays the assertion + information in the browser UI and stores the assertion in the + peerIdentity + attribute for availability to the JavaScript application. The assertion + information to be displayed shall contain the domain name of the IdP + and the identity returned by the IdP and must be displayed via some + mechanism which cannot be spoofed by content. [[OPEN ISSUE: The + identity information should also be available in the inspector + interface defined in [RTCWEB-SECURITY-ARCH].
  16. +
+
+ + +
+

8.4 RTCPeerConnection Interface Extensions

+ + +

The Identity API extends the RTCPeerConnection + interface as described below.

+ + +
partial interface RTCPeerConnection {
+    void setIdentityProvider (DOMString provider, optional DOMString protocol, optional DOMString username);
+    void getIdentityAssertion ();
+    readonly    attribute RTCIdentityAssertion? peerIdentity;
+                attribute EventHandler          onidentityresult;
+};

8.4.1 Attributes

onidentityresult of type EventHandler,
This event handler, of event handler event type identityresult, MUST be fired by all + objects implementing the RTCPeerConnection + interface. It is called any time an identity verification succeeds or + fails.
peerIdentity of type RTCIdentityAssertion, readonly , nullable
+

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

+

8.4.2 Methods

getIdentityAssertion
+

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

+ + +

Queue a task to run the following substeps.

+ + +
    +
  1. +

    If the connection's RTCPeerConnection + signalingState is closed, abort these steps.

    +
  2. + + + +
  3. +

    Instantiate a new IdP proxy and request an identity + assertion.

    +
  4. +
+
No parameters.
Return type: void
setIdentityProvider
+

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

+ + +

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

+ + +
    +
  1. +

    Set the current identity values to the triplet + (provider, protocol, + username).

    +
  2. + + +
  3. +

    If the RTCPeerConnection object's RTCPeerConnection + signalingState is stable, and any of the + identity settings have changed, queue a task to run the following + substeps:

    + + +
      +
    1. +

      If the connection's RTCPeerConnection + signalingState is closed, throw an + InvalidStateError exception and abort these + steps.

      +
    2. + + +
    3. +

      Instantiate a new IdP proxy and request an identity + assertion.

      +
    4. + + +
    5. +

      If/when the assertion is obtained, fire a negotiationneeded event.

      +
    6. +
    +
  4. +
+
ParameterTypeNullableOptionalDescription
providerDOMString
protocolDOMString
usernameDOMString
Return type: void
+
+ + +
+

8.5 RTCIdentityAssertion Type

+ + +
dictionary RTCIdentityAssertion {
+    DOMString idp;
+    DOMString name;
+};

8.5.1 Dictionary RTCIdentityAssertion Members

idp of type DOMString
+

A domain name representing the identity provider.

+
name of type DOMString
+

An RFC822-conformant [TODO: REF] representation of the verified + peer identity. This identity will have been verified via the + procedures described in [RTCWEB-SECURITY-ARCH].

+
+
+ + +
+

8.6 Examples

+ + +

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

+ + +
+

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

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

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

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

9. Media Stream API Extensions for Network Use

+ + +
+

9.1 Introduction

+ + +

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

+ + +

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

+ + +

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

+ + +

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

+ + +

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

+ + +
Note

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

+
+ + +
+

9.2 MediaStream

+ + +
+

9.2.1 id

+ + +

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

+ + +

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

+ + +
Note

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

+
+ + +
+

9.2.2 Events on MediaStream

+ + +

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

+ + +
    +
  1. +

    Let stream be the target + MediaStream object.

    +
  2. + + +
  3. +

    Represent component + with track: Run the following steps to create a track + representing the incoming component:

    + + +
      +
    1. +

      Create a MediaStreamTrack object + track to represent the component.

      +
    2. + + +
    3. +

      Initialize track’s kind + attribute to "audio" or "video" + depending on the media type of the incoming component.

      +
    4. + + +
    5. +

      Initialize track’s id + attribute to the component track id.

      +
    6. + + +
    7. +

      Initialize track’s label + attribute to "remote audio" or "remote + video" depending on the media type of the incoming + component.

      +
    8. + + +
    9. +

      Initialize track’s readyState + attribute to muted.

      +
    10. + + +
    11. +

      Add track to stream’s track set.

      +
    12. +
    +
  4. + + +
  5. +

    Fire a track event named addtrack + with the newly created MediaStreamTrack object + at stream.

    +
  6. +
+ + +

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

+ + +
    +
  1. +

    Let stream be the target + MediaStream object.

    +
  2. + + +
  3. +

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

    +
  4. + + +
  5. +

    Remove track from stream’s track set.

    +
  6. + + +
  7. +

    Fire a track event named removetrack + with track at stream.

    +
  8. +
+ + +

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

+
+
+ + +
+

9.3 MediaStreamTrack

+ + +

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

+ + +

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

+ + +
Issue 3

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

+ + +

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

+ + +

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

+ + +
Issue 4

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

+
+ + +
+

9.4 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.

+ + +
dictionary MediaStreamEventInit : EventInit {
+    MediaStream stream;
+};

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

9.4.1 Constructors

MediaStreamEvent
readonly attribute MediaStream? stream
ParameterTypeNullableOptionalDescription
typeDOMString
eventInitDictMediaStreamEventInit

9.4.2 Attributes

stream of type MediaStream, readonly , nullable
+

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

+
+ + +

9.4.3 Dictionary MediaStreamEventInit Members

stream of type MediaStream
+

TODO

+
+
+
+ + +
+

10. Examples and Call Flows

This section is non-normative.

+ + +
+

10.1 Simple Peer-to-peer Example

+ + +
+

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

+ +
Example 4
var signalingChannel = new SignalingChannel();
+var configuration = { "iceServers": [{ "url": "stun:stun.example.org" }] };
+var pc;
+
+// call start() to initiate
+function start() {
+    pc = new RTCPeerConnection(configuration);
+
+    // send any ice candidates to the other peer
+    pc.onicecandidate = function (evt) {
+        if (evt.candidate)
+            signalingChannel.send(JSON.stringify({ "candidate": evt.candidate }));
+    };
+
+    // let the "negotiationneeded" event trigger offer generation
+    pc.onnegotiationneeded = function () {
+        pc.createOffer(localDescCreated, logError);
+    }
+
+    // once remote stream arrives, show it in the remote video element
+    pc.onaddstream = function (evt) {
+        remoteView.src = URL.createObjectURL(evt.stream);
+    };
+
+    // get a local stream, show it in a self-view and add it to be sent
+    navigator.getUserMedia({ "audio": true, "video": true }, function (stream) {
+        selfView.src = URL.createObjectURL(stream);
+        pc.addStream(stream);
+    }, logError);
+}
+
+function localDescCreated(desc) {
+    pc.setLocalDescription(desc, function () {
+        signalingChannel.send(JSON.stringify({ "sdp": pc.localDescription }));
+    }, logError);
+}
+
+signalingChannel.onmessage = function (evt) {
+    if (!pc)
+        start();
+
+    var message = JSON.parse(evt.data);
+    if (message.sdp)
+        pc.setRemoteDescription(new RTCSessionDescription(message.sdp), function () {
+            // if we received an offer, we need to answer
+            if (pc.remoteDescription.type == "offer")
+                pc.createAnswer(localDescCreated, logError);
+        }, logError);
+    else
+        pc.addIceCandidate(new RTCIceCandidate(message.candidate));
+};
+
+function logError(error) {
+    log(error.name + ": " + error.message);
+}
+
+
+ + +
+

10.2 Advanced Peer-to-peer Example

+ + +
+

This example shows the more complete functionality.

+ +
Example 5
TODO
+
+
+ + +
+

10.3 Peer-to-peer Data Example

+ + +
+

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

+ + +
Note

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

+ +
Example 6
var signalingChannel = new SignalingChannel();
+var configuration = { "iceServers": [{ "url": "stun:stun.example.org" }] };
+var pc;
+var channel;
+
+// call start(true) to initiate
+function start(isInitiator) {
+    pc = new RTCPeerConnection(configuration);
+
+    // send any ice candidates to the other peer
+    pc.onicecandidate = function (evt) {
+        if (evt.candidate)
+            signalingChannel.send(JSON.stringify({ "candidate": evt.candidate }));
+    };
+
+    // let the "negotiationneeded" event trigger offer generation
+    pc.onnegotiationneeded = function () {
+        pc.createOffer(localDescCreated, logError);
+    }
+
+    if (isInitiator) {
+        // create data channel and setup chat
+        channel = pc.createDataChannel("chat");
+        setupChat();
+    } else {
+        // setup chat on incoming data channel
+        pc.ondatachannel = function (evt) {
+            channel = evt.channel;
+            setupChat();
+        };
+    }
+}
+
+function localDescCreated(desc) {
+    pc.setLocalDescription(desc, function () {
+        signalingChannel.send(JSON.stringify({ "sdp": pc.localDescription }));
+    }, logError);
+}
+
+signalingChannel.onmessage = function (evt) {
+    if (!pc)
+        start(false);
+
+    var message = JSON.parse(evt.data);
+    if (message.sdp)
+        pc.setRemoteDescription(new RTCSessionDescription(message.sdp), function () {
+            // if we received an offer, we need to answer
+            if (pc.remoteDescription.type == "offer")
+                pc.createAnswer(localDescCreated, logError);
+        }, logError);
+    else
+        pc.addIceCandidate(new RTCIceCandidate(message.candidate));
+};
+
+function setupChat() {
+    channel.onopen = function () {
+        // e.g. enable send button
+        enableChat(channel);
+    };
+
+    channel.onmessage = function (evt) {
+        showChatMessage(evt.data);
+    };
+}
+
+function sendChatMessage(msg) {
+    channel.send(msg);
+}
+
+function logError(error) {
+    log(error.name + ": " + error.message);
+}
+
+ +
+ + +
+

10.4 Call Flow Browser to Browser

+ + +
Note

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

+ + +

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

+ + +

A message sequence chart detailing a call flow between two browsers +

+ +
+ + +
+

10.5 DTMF Example

+ + +

Examples assume that pc is a connected RTCPeerConnection, + and track is an audio track on that connection.

+ + +

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

+ +
Example 7
var sender = pc.createDTMFSender(track);
+if (sender.canInsertDTMF) {
+    var duration = 500;
+    sender.insertDTMF("1234", duration);
+} else
+    log("DTMF function not available");
+ +

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

+ +
Example 8
var sender = pc.createDTMFSender(track);
+sender.ontonechange = function (e) {
+    if (!e.tone)
+        return;
+    // light up the key when playout starts
+    lightKey(e.tone);
+    // turn off the light after tone duration
+    setTimeout(lightKey, sender.duration, "");
+};
+sender.insertDTMF("1234");
+ +

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

+ +
Example 9
var sender = pc.createDTMFSender(track);
+sender.ontonechange = function (e) {
+    if (e.tone == "1")
+        sender.insertDTMF("2", 2000);
+};
+sender.insertDTMF("1", 1000);
+ +

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

+ +
Example 10
var sender = pc.createDTMFSender(track);
+sender.insertDTMF("123");
+// append more tones to the tone buffer before playout has begun
+sender.insertDTMF(sender.toneBuffer + "456");
+
+sender.ontonechange = function (e) {
+    if (e.tone == "1")
+        // append more tones when playout has begun
+        sender.insertDTMF(sender.toneBuffer + "789");
+};
+ +

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

+ +
Example 11
var sender = pc.createDTMFSender(track);
+sender.ontonechange = function (e) {
+    if (e.tone == "2")
+        // empty the buffer to not play any tone after "2"
+        sender.insertDTMF("");
+};
+sender.insertDTMF("123");
+
+ +
+ + +
+

11. Event summary

This section is non-normative.

+ + +

The following events fire on RTCDataChannel + objects:

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

The following events fire on RTCPeerConnection + objects:

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Event nameInterfaceFired when...
connecting + Event + TODO
addstream + MediaStreamEvent + + A new stream has been added to the remote streams set. +
removestream + MediaStreamEvent + + A stream has been removed from the remote streams set. +
negotiationneeded + Event + The browser wishes to inform the application that session + negotiation needs to be done at some point in the near future.
signalingstatechange + Event + + The RTCPeerConnection + signalingState has changed. This state change is the result of + either setLocalDescription() + or setRemoteDescription() + being invoked. +
iceconnectionstatechange + Event + + The RTCPeerConnection + ice connection state has changed. +
icecandidate + RTCPeerConnectionIceEvent + A new RTCIceCandidate is made available to + the script.
datachannel + RTCDataChannelEvent + A new RTCDataChannel is dispatched to the + script in response to the other peer creating a channel.
identityresult + RTCIdentityEvent + TODO - define RTCIdentityEvent.
+ + +

The following events fire on RTCDTMFSender + objects:

+ + + + + + + + + + + + + + + + + + + + + +
Event nameInterfaceFired when...
tonechange + Event + The RTCDTMFSender object has either just + begun playout of a tone (returned as the tone + attribute) or just ended playout of a tone (returned as an empty + value in the tone attribute).
+
+ + +
+

12. Security Considerations

+ + +

TBD

+
+ + + + + +
+

13. Change Log

+ + +

This section will be removed before publication.

+ + + +

Changes since August 30, 2013

+ + +
    + +
  1. Make RTCPeerConnection close method be idempotent.
  2. + +
  3. Clarified ICE server configuration could contain URI types other than STUN and TURN.
  4. + +
  5. Changed the DTMF timing values.
  6. + +
  7. Allow offerToReceiveAudio/video indicate number of streams to offer.
  8. + +
  9. ACTION-98: Added text about clamping of maxRetransmitTime and + maxRetransmits.
  10. + + +
  11. ACTION-88: Removed nullable types from dictionaries (added attribute + default values for attributes that would be left uninitialized without + the init dictionary present.
  12. + + +
  13. InvalidMediaStreamTrackError changed to InvalidParameter.
  14. + + +
  15. Fire NetworkError when the data transport is closed with an + error.
  16. + + +
  17. Add an exception for data channel with trying to use existing + code.
  18. + + +
  19. Change maxRetransmits to be an unsigned type.
  20. + + +
  21. Clarify state changes when ICE restarts.
  22. + + +
  23. Added InvalidStateError exception for operations on a + RTCPeerConnection that is closed.
  24. + +
  25. Major changes to Identity Proxy section.
  26. + + +
  27. (ACTION: 95) Moved IceTransports (constraint) to RTCConfiguration + dictionary.
  28. + + +
  29. (ACTION: 95) Introduced RTCOfferAnswerOptions and RTCOfferOptions + dictionaries.
  30. + + +
  31. (ACTION: 95) Removed constraints argument from addStream() (and + removed IANA Constraints section).
  32. + + +
  33. Added validation of the RTCConfiguration dictionary argument(s).
  34. + + +
  35. Added getConfiguration() on RTCPeerConnection.
  36. +
+ + +

Changes since June 3, 2013

+ + +
    +
  1. Removed synchronous section left-overs.
  2. + + +
  3. RTCIceServer now accepts multiple URLs.
  4. + + +
  5. Redefined the meaning of negotiated for DataChannel.
  6. + + +
  7. Made iceServers a sequence (instead of an Array).
  8. + + +
  9. Updated error reporting (to use DOMError and camel cased names).
  10. + + +
  11. Added success and failure callbacks to addIceCandidate().
  12. + + +
  13. Made local/remoteDescription attributes nullable.
  14. + + +
  15. Added username member to RTCIceServer dictionary.
  16. +
+ + +

Changes since March 22, 2013

+ + +
    +
  1. Added IceRestart constraint.
  2. + + +
  3. Big updates on DataChannel API to use new channel setup + procedures.
  4. +
+ + +

Changes since Feb 22, 2013

+ + +
    +
  1. Example review: Updated DTMF and Stats examples. Added text about + when to fire "negotiationneeded" event to align with examples.
  2. + + +
  3. Updated RTCPeerConnection state machine. Added a shared processing + model for setLocalDescription()/setRemoteDescription().
  4. + + +
  5. Updated simple callflow to match the current API.
  6. +
+ + +

Changes since Jan 16, 2013

+ + +
    +
  1. Initial import of Statistics API to version 2.
  2. + + +
  3. Integration of Statistics API version 2.5 started.
  4. + + +
  5. Updated Statistics API to match Boston/list discussions.
  6. + + +
  7. Extracted API extensions introduced by features, such as the P2P Data + API, from the RTCPeerConnection API.
  8. + + +
  9. Updated DTMF algorithm to dispatch an event when insertDTMF() is + called with an empty string to cancel future tones.
  10. + + +
  11. Updated DTMF algorithm to not cancel and reschedule if a playout task + is running (only update toneBuffer and other values).
  12. +
+ + +

Changes since Dec 12, 2012

+ + +
    +
  1. Changed AudioMediaStreamTrack to RTCDTMFSender and gave it its own + section. Updated text to reflect most recent agreements. Also added + examples section.
  2. + + +
  3. Replaced the localStreams and remoteStreams attributes with functions + returning sequences of MediaStream objects.
  4. + + +
  5. Added spec text for attributes and methods adopted from the WebSocket + interface.
  6. + + +
  7. Changed the state ENUMs and transition diagrams.
  8. + + +
  9. Aligned the data channel processing model a bit more with WebSockets + (mainly closing the underlying transport).
  10. +
+ + +

Changes since Nov 13, 2012

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

Changes since Nov 03, 2012

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

Changes since Oct 19, 2012

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

Changes since Sept 23, 2012

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

Changes since Aug 16, 2012

+ + +
    +
  1. Replaced stringifier with serializer on RTCSessionDescription and + RTCIceCandidate (used when JSON.stringify() is called).
  2. + + +
  3. Removed offer and createProvisionalAnswer arguments from the + createAnswer() method.
  4. + + +
  5. Removed restart argument from the updateIce() method.
  6. + + +
  7. Made RTCDataChannel an EventTarget
  8. + + +
  9. Updated simple RTCPeerConnection example to match spec changes.
  10. + + +
  11. Added section about RTCDataChannel garbage collection.
  12. + + +
  13. Added stuff for identity proxy.
  14. + + +
  15. Added stuff for stats.
  16. + + +
  17. Added stuff peer and ice state reporting.
  18. + + +
  19. Minor changes to sequence diagrams.
  20. + + +
  21. Added a more complete RTCDataChannel example
  22. + + +
  23. Various fixes from Dan's Idp API review.
  24. + + +
  25. Patched the Stats API.
  26. +
+ + +

Changes since Aug 13, 2012

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

Changes since Jul 20, 2012

+ + +
    +
  1. Added RTC Prefix to names (including the notes below).
  2. + + +
  3. Moved to new definition of configuration and ice servers object.
  4. + + +
  5. Added correlating lines to candidate structure.
  6. + + +
  7. Converted setLocalDescription and setRemoteDescription to be + asynchronous.
  8. + + +
  9. Added call flows.
  10. +
+ + +

Changes since Jul 13, 2012

+ + +
    +
  1. Removed peer attribute from RTCPeerConnectionIceEvent (duplicates + functionality of Event.target attribute).
  2. + + +
  3. Removed RTCIceCandidateCallback (no longer used).
  4. + + +
  5. Removed RTCPeerConnectionEvent (we use a simple event instead).
  6. + + +
  7. Removed RTCSdpType argument from setLocalDescription() and + setRemoteDescription(). Updated simple example to match.
  8. +
+ + +

Changes since May 28, 2012

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

Changes since April 27, 2012

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

Changes since 21 April 2012

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

Changes since 12 January 2012

+ + +
    +
  1. Clarified the relation of Stream, Track, and Channel.
  2. +
+ + +

Changes since 17 October 2011

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

Changes since 23 August 2011

+ + +
    +
  1. Separated the SDP and ICE Agent into separate agents and added + explicit state attributes for each.
  2. + + +
  3. Removed the send method from PeerConenction and associated callback + function.
  4. + + +
  5. Modified MediaStream() constructor to take a list of MediaStreamTrack + objects instead of a MediaStream. Removed text about MediaStream parent + and child relationship.
  6. + + +
  7. Added abstract.
  8. + + +
  9. Moved a few paragraphs from the MediaStreamTrack.label section to the + MediaStream.label section (where they belong).
  10. + + +
  11. Split MediaStream.tracks into MediaStream.audioTracks and + MediaStream.videoTracks.
  12. + + +
  13. Removed a sentence that implied that track access is limited to + LocalMediaStream.
  14. + + +
  15. Updated a few getUserMedia()-examples to use MediaStreamOptions.
  16. + + +
  17. Replaced calls to URL.getObjectURL() with URL.createObjectURL() in + example code.
  18. + + +
  19. Fixed some broken getUserMedia() links.
  20. + + +
  21. Introduced state handling on MediaStreamTrack (removed state handling + from MediaStream).
  22. + + +
  23. Reintroduced onended on MediaStream to simplify checking if all + tracks are ended.
  24. + + +
  25. Aligned the MediaStreamTrack ended event dispatching behavior with + that of MediaStream.
  26. + + +
  27. Updated the LocalMediaStream.stop() algorithm to implicitly use the + end track algorithm.
  28. + + +
  29. Replaced an occurrence the term finished track with ended track (to + align with rest of spec).
  30. + + +
  31. Moved (and extended) the explanation about track references and media + sources from LocalMediaStream to MediaStreamTrack.
  32. +
+
+ + +
+

A. Acknowledgements

+ + +

The editors wish to thank the Working Group chairs and Team Contact, + Harald Alvestrand, Stefan Håkansson and Dominique Hazaël-Massieux, for + their support. Substantial text in this specification was provided by many + people including Martin Thomson, Harald Alvestrand, Justin Uberti, and Eric + Rescorla.

+
+ + +

B. References

B.1 Normative references

[GETUSERMEDIA]
Daniel Burnett; Adam Bergkvist; Cullen Jennings; Anant Narayanan. Media Capture and Streams. 3 September 2013. W3C Working Draft. URL: http://www.w3.org/TR/mediacapture-streams/ +
[HIGHRES-TIME]
Jatinder Mann. High Resolution Time Specification. 18 October 2012. W3C Editor's Draft. URL: http://dvcs.w3.org/hg/webperf/raw-file/tip/specs/HighResolutionTime/Overview.html +
[HTML5]
Robin Berjon; Steve Faulkner; Travis Leithead; Erika Doyle Navara; Edward O'Connor; Silvia Pfeiffer. HTML5. 6 August 2013. W3C Candidate Recommendation. URL: http://www.w3.org/TR/html5/ +
[ICE]
J. Rosenberg. Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols. April 2010. RFC. URL: http://www.ietf.org/rfc/rfc5245.txt +
[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-SECURITY-ARCH]
Eric Rescorla. WebRTC Security Architecture. 22 January 2014. Active Internet-Draft. URL: http://datatracker.ietf.org/doc/draft-ietf-rtcweb-security-arch/ +
[SDP]
J. Rosenberg; H. Schulzrinne. An Offer/Answer Model with the Session Description Protocol (SDP). June 2002. RFC 3264. URL: http://tools.ietf.org/html/rfc3264 +
[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-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. 19 April 2012. W3C Candidate Recommendation. URL: http://www.w3.org/TR/WebIDL/ +
[WEBSOCKETS-API]
Ian Hickson. The WebSocket API. 20 September 2012. W3C Candidate Recommendation. URL: http://www.w3.org/TR/websockets/ +
[webmessaging]
Ian Hickson. HTML5 Web Messaging. 1 May 2012. W3C Candidate Recommendation. URL: http://www.w3.org/TR/webmessaging/ +

B.2 Informative references

[RTCWEB-JSEP]
Justin Uberti; Cullen Jennings. Javascript Session Establishment Protocol. 22 October 2013. Active Internet-Draft. URL: http://http://datatracker.ietf.org/doc/draft-ietf-rtcweb-jsep/ +
diff --git a/archives/20140127/webrtc.js b/archives/20140127/webrtc.js new file mode 100644 index 000000000..3bb5029d2 --- /dev/null +++ b/archives/20140127/webrtc.js @@ -0,0 +1,73 @@ + +var respecConfig = { + // specification status (e.g. WD, LCWD, NOTE, etc.). If in doubt use ED. + specStatus: "ED", + + // the specification's short name, as in http://www.w3.org/TR/short-name/ + shortName: "webrtc", + + // if your specification has a subtitle that goes below the main + // formal title, define it here + // subtitle : "an excellent document", + + // if you wish the publication date to be other than today, set this + publishDate: "2014-01-27", + + // new ability to override the copyright completely + overrideCopyright: " ", + + + // if the specification's copyright date is a range of years, specify + // the start date here: + // copyrightStart: "2005", + + // if there is a previously published draft, uncomment this and set its YYYY-MM-DD + prevED: "http://dev.w3.org/2011/webrtc/editor/archives/20130830/webrtc.html", + + // if there a publicly available Editor's Draft, this is the link + edDraftURI: "http://dev.w3.org/2011/webrtc/editor/webrtc.html", + + // if this is a LCWD, uncomment and set the end of its review period + // lcEnd: "2009-08-05", + + // if you want to have extra CSS, append them to this list + // it is RECOMMENDED that the respec.css stylesheet be kept + // extraCSS: ["ReSpec.js/css/respec.css"], + // extraCSS: ["../../../2009/dap/ReSpec.js/css/respec.css"], + + // editors, add as many as you like + // only "name" is REQUIRED + editors: [ + // { name: "Your Name", url: "http://example.org/", + // company: "Your Company", companyURL: "http://example.com/" }, + { name: "Adam Bergkvist", company: "Ericsson" }, + { name: "Daniel C. Burnett", company: "Voxeo" }, + { name: "Cullen Jennings", company: "Cisco" }, + { name: "Anant Narayanan", company: "Mozilla (until November 2012)" } + ], + + // authors, add as many as you like. + // This is optional, uncomment if you have authors as well as editors. + // only "name" is REQUIRED. Same format as editors. + + //authors: [ + // { name: "Your Name", url: "http://example.org/", + // company: "Your Company", companyURL: "http://example.com/" } + //], + + // name of the WG + wg: "Web Real-Time Communications Working Group", + + // URI of the public WG page + wgURI: "http://www.w3.org/2011/04/webrtc/", + + // name (without the @w3c.org) of the public mailing to which comments are due + wgPublicList: "public-webrtc", + + // URI of the patent status for this WG, for Rec-track documents + // !!!! IMPORTANT !!!! + // This is important for Rec-track documents, do not copy a patent URI from a random + // document unless you know what you're doing. If in doubt ask your friendly neighbourhood + // Team Contact. + wgPatentURI: "http://www.w3.org/2004/01/pp-impl/47318/status", +}; diff --git a/webrtc.js b/webrtc.js index f9bc3c718..3bb5029d2 100644 --- a/webrtc.js +++ b/webrtc.js @@ -11,7 +11,7 @@ var respecConfig = { // subtitle : "an excellent document", // if you wish the publication date to be other than today, set this - // publishDate: "2012-05-28", + publishDate: "2014-01-27", // new ability to override the copyright completely overrideCopyright: " ", @@ -22,7 +22,7 @@ var respecConfig = { // copyrightStart: "2005", // if there is a previously published draft, uncomment this and set its YYYY-MM-DD - prevED: "http://dev.w3.org/2011/webrtc/editor/archives/20130603/webrtc.html", + prevED: "http://dev.w3.org/2011/webrtc/editor/archives/20130830/webrtc.html", // if there a publicly available Editor's Draft, this is the link edDraftURI: "http://dev.w3.org/2011/webrtc/editor/webrtc.html",