stub out RTCDataChannel attributes and methods

[nickdesaulniers]

No description provided.

[nickdesaulniers]

and events

[feross]

What's the status of the data channel in this package? I'd love to use this in WebTorrent on the server, and in the CLI.

[nickdesaulniers]

it'll be a while.

Working on the ICE handshake, then DTLS handshake, then SCTP handshake.

[nickdesaulniers]

The ice handshake is in good shape. I've been able to work it out in false_client.js. I'm taking some time now to read through all of the specs and make something that exposes the same interface as RTCPeerConnection, that way you can have "isomorphic" js make calls to from node and/or the browser. While this front loads a bit of work, it will pay off later.

See the list of milestones and let me know your thoughts.

[nickdesaulniers]

I'm looking for more contributors though if you have the time, or know some other folks that might be interested.

[feross]

Nice work on this so far! I'm actually not super familiar with the low level spec stuff at the moment, but I'll share this on Twitter and with interested friends to see if anyone's interested in helping out. I might have time later on, once I catch up on WebTorrent issues, to contribute to this.

Btw, just to be clear, your goal is only to implement the necessary components to get data channels working? No video/audio stuff, right?

[nickdesaulniers]

your goal is only to implement the necessary components to get data channels working? No video/audio stuff, right?

For now, yes. Do you know of any node modules that can capture from the system web cam and mic?

[nickdesaulniers]

but I'll share this on Twitter

Awesome! Thanks for helping spread awareness, that helps too!

[feross]

One of the most challenging issues for data channel users is that all existing WebRTC libraries tightly couple audio/video into their implementations, adding a lot of bulk and extra OS dependencies. This makes the installation much more fragile, take longer, and work on fewer systems. It also makes the library suitable in fewer situations (for example, most people won't accept https://npmjs.com/package/wrtc as a dependency in their project because it makes installs fail for lots of users)

See webrtcftw/goals#1 for additional discussion.

When/if we get around to doing video/audio, can we offer it as a separate package? Ideally, data channel users wouldn't need to compile any video/audio libraries.

Thoughts?

[nickdesaulniers]

That makes sense, thanks for the guiding use case.

The absolute goal is no native dependencies. 100% JavaScript.

This library itself will probably already be split up; most of the code is the ICE negotiation which was spec'd to not depend on SDP or SIP as the session description, so all those things can be decoupled. This repo will simply serve as the RTCPeerConnection interface.

Right now, I'm building the RTCPeer to support one media format (which will be a data channel). If it makes sense to add audio/video later than that can be added, but is not the priority for me.

[nickdesaulniers]

I'm not sure yet about the higher levels of the stack. Once I have ICE done, I need to take a look at DTLS and SCTP. I think there's an existing module for DTLS that only uses Node's crypto lib. I'm not sure about SCTP, but I'll probably have to write something that handles that.

[feross]

@nickdesaulniers Nice, thanks for explaining your plans. Very happy about the 100% JavaScript goal! 👍