New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

A small proposal to cleanup DataChannel construction #60

aboba opened this Issue Apr 15, 2014 · 1 comment


None yet
2 participants
Copy link

aboba commented Apr 15, 2014

From: Peter Thatcher
Date: Tue, 15 Apr 2014 10:04:54 -0700
To: ""

I've noticed that createDataChannel and the RTCDataChannel contructor
overlap in functionality. And since almost all of the current API is based
around using constructors instead of factory methods, I think we can
cleanup the overlap and make it consistent with the rest of the API by
doing the following:

[Constructor(RTCDataTransport transport,
RTCDataChannelParameters parameters)]
interface RTCDataChannel : EventTarget {
readonly attribute RTCDataTransport transport;
readonly attribute RTCDataChannelParameters parameters;
void send (Object data);
attribute EventHandler ondata;

interface RTCDataTransport {

interface RTCSctpTransport : RTCDataTransport {
// ...

The difference is basically that:

  1. We no longer have a createDataChannel method, and just call the
    constructor instead.
  2. RTCDataChannel no longer relies directly on SctpTransport. In the
    future, we could have a different kind of DataTransport and have
    DataChannels that work with it (we aren't as tightly coupled to SCTP).

This comment has been minimized.

Copy link

aboba commented Apr 25, 2014

Looking over the RTCDataChannel interface and comparing this against WebRTC 1.0, there are a bunch of differences whose justifications aren't clear to me. As an example, the Editor's draft didn't include the readyState, bufferedAmount and binaryType attributes, nor did it include several of the EventHandlers, such as onerror.

To improve compatibility with WebRTC 1.0, I'd like to propose that we keep many of the WebRTC 1.0 constructs, while at the same time incorporating Peter's suggestions. Here is what things would look like:

[Constructor(RTCDataTransport transport, RTCDataChannelParameters parameters)]
interface RTCDataChannel : EventTarget {
readonly attribute RTCDataTransport transport;
readonly attribute RTCDataChannelParameters parameters;
readonly attribute RTCDataChannelState readyState;
readonly attribute unsigned long bufferedAmount;
attribute DOMString binaryType;
void close ();
void send (Object data);
attribute EventHandler onopen;
attribute EventHandler onerror;
attribute EventHandler onclose;
attribute EventHandler onmessage;

dictionary RTCDataChannelParameters {
DOMString? label = "";
boolean ordered = true;
unsigned short? maxPacketLifetime = null;
unsigned short? maxRetransmits = null;
DOMString? protocol = "";
boolean negotiated = false;
unsigned short? id = null;

interface RTCDataTransport {

enum RTCDataChannelState {

interface RTCSctpTransport : RTCDataTransport {
attribute RTCDtlsTransport transport;
static RTCSctpCapabilities getCapabilities ();
void start (RTCSctpCapabilities remoteCaps);
void stop ();
attribute EventHandler ondatachannel;

One more thing: In WebRTC 1.0, (see send is defined as follows:

void send (DOMString data);
void send (Blob data);
void send (ArrayBuffer data);
void send (ArrayBufferView data);

Is there a good reason why we need to do things differently in ORTC API? And yes, I agree that this is handled more cleanly in the Editor's draft and that the above is clumsy, but...

robin-raymond pushed a commit to robin-raymond/ortc that referenced this issue Apr 29, 2014

Robin Raymond
- Fixes for error handling, as described in w3c#26
- Support for contributing sources removed (re-classified as a 1.2 feature), as described in w3c#27
- Cleanup of DataChannel construction, as described in w3c#60
- Separate proposal on simulcast/layering, as described in w3c#61
- Separate proposal on quality, as described in w3c#62
- Fix for TCP candidate type, as described in w3c#63
- Fix to the fingerprint attribute, as described in w3c#64
- Fix to RTCRtpFeatures, as described in w3c#65
- Support for retrieval of remote certificates, as described in w3c#67
- Support for ICE error handling, described in w3c#68
- Support for Data Channel send rate control, as described in w3c#69
- Support for capabilities and settings, as described in w3c#70
- Removal of duplicate RTCRtpListener functionality, as described in w3c#71
- ICE gathering state added, as described in w3c#72
- Removed ICE role from the ICE transport constructor, as described in w3c#73
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment