jbenet commented 10 years ago

WebRTC DataChannel Everywhere

(I realized this many months ago, documenting it here for discussion)

WebRTC is becoming the de-facto way to connect two peers in the web (thanks to @petar for pointing this out to me). While protocols like LEDBAT (uTP) work for most applications, those who would seek to interact with peers running in browsers must use webrtc for the foreseeable future.

We can get everyone (servers + browsers) talking over WebRTC. But to do that we need servers to speak WebRTC. AFAIK, only browsers have implementations. And this is because libwebrtc (https://code.google.com/p/webrtc/) is a behemoth. It has libjingle + DataChannel + lots of A/V magic + much more in it.

We need

a clean libwebrtc + language bindings.
a libwebdc - only the datachannel part.

(2.) is because many application use cases don't care at all about the A/V stuff, and only want to exchange data with peers. We only need WebRTC DataChannels (libjingle + datachannel implementation, SCTP, etc).

I propose

we rip out datachannel and make a standalone c lib, libwebdc
we build standard language bindings to it (node, Go, python, etc)
we experiment with (+ perhaps commit to) WebRTC DataChannel implementations in various languages.

Eventually, native language implementations may emerge, but frankly, rewriting libjingle, sctp, and whatever else on top of rewriting the DataChannel protocol, seems much harder than ripping out the code we need from libwebrtc into libwebdc. (Would love to be proved wrong).

I know many people are interested in this, so let's do it.

jbenet commented 10 years ago

Tagging people interested. @substack @mikolalysenko @mafintosh @feross @polvi @philips @petar

jbenet commented 10 years ago

WebRTC in node: https://www.npmjs.org/package/wrtc (HT @feross)

feross commented 10 years ago

/cc @modeswitch @DamonOehlman

DamonOehlman commented 10 years ago

Yep - @modeswitch has done awesome work with this, including getting prebuilt binaries available which makes installing the wrtc module feel much more accessible.

From a minamlistic build from scratch implementation I would recommend having a look at the way the Janus gateway from @meetecho approaches things. While I'm not 100% sure I think implementing a lighter node binding for pure SCTP data channels should be doable using just libnice and native SCTP implementation (Janus uses https://code.google.com/p/sctp-refimpl/). I'm sure @lminiero from meetecho would be able to provide more detail on this if people are interested :)

For more information on Janus, have a look below:

https://github.com/meetecho/janus-gateway

lminiero commented 10 years ago

Damon,

Funny you mentioned that, as just the other day I was talking with @helloIAmPau, who just joined our team, exactly about that!

Pasquale has been working on node.js and WebRTC for a while already, and was interested in evaluating how much effort extracting the related core stuff from Janus would be, to allow for a DataChannel only module in his projecys. In Janus, as you noticed, we make use of libnice, openssl and usrsctp for the purpose, which should allow for a minimalistic implementation.

jbenet commented 10 years ago

This is great news! Awesome work so far @modeswitch @DamonOehlman and @lminiero.

@lminiero @helloIAmPau sounds great! Extracting this out of Janus would make this all much easier. Let's figure out what needs to be done! Could someone very familiar with the Janus codebase give a quick sketch?

@lminiero am curious-- have you experienced connectivity problems with libnice in Janus? I.e. some random edge case that chromium's libwebrtc handles differently. AFAIK, +hangouts connects every peer, even in hyper restrictive NATs, but others report a few percent of "unconnectable nodes" (probably firewalls blocking UDP, so probably fails over to relaying over TCP, which AFAIK isn't covered by TURN). I wonder if chromium's impl is straight ICE or they do other stuff to connect the remaining few percent... (this may not be worth considering much, but the right time to consider it is earlier).

petar commented 10 years ago

Thanks for including me on this. Good to listen.

On Monday, June 9, 2014, Juan Batiz-Benet notifications@github.com wrote:

This is great news! Awesome work so far @modeswitch https://github.com/modeswitch @DamonOehlman https://github.com/DamonOehlman and @lminiero

https://github.com/lminiero.

@lminiero https://github.com/lminiero @helloIAmPau https://github.com/helloIAmPau sounds great! Extracting this out of Janus would make this all much easier. Let's figure out what needs to be done! Could someone very familiar with the Janus codebase give a quick

sketch?

@lminiero https://github.com/lminiero am curious-- have you experienced connectivity problems with libnice in Janus? I.e. some random edge case that chromium's libwebrtc handles differently. AFAIK, +hangouts connects every peer, even in hyper restrictive NATs, but others report a few percent of "unconnectable nodes" (probably firewalls blocking UDP, so probably fails over to relaying over TCP, which AFAIK isn't covered by TURN). I wonder if chromium's impl is straight ICE or they do other stuff to connect the remaining few percent... (this may not be worth considering much, but the right time to consider it is earlier).

— Reply to this email directly or view it on GitHub https://github.com/jbenet/random-ideas/issues/13#issuecomment-45542461.

lminiero commented 10 years ago

@jbenet we just discussed this briefly before I left to attend an event abroad, so we didn't actually brainstorm any detail. In principle, in Janus we have a core that takes care of the involved protocols (HTTP on one side, the whole WebRTC stack including SDP/ICE/DTLS/SRTP on the other) and, while this implementation currently takes into account the pluggable nature of Janus and the fact that you're going to need and feed data from/to plugins, most parts should be reusable outside of that context. As soon as time permits, we'll try design a way to do so. Besides, DataChannels support in Janus is currently limited to strings, so I'd have to take care of filling the binary gap as well in the meanwhile.

For what concerns your other question, to be honest I haven't done extensive testing in that regard. I made some tests interacting with Oleg Moskalenko's TURN server using different modes, and most of them (TURN over UDP, TURN over TCP, TURN over TCP 80/443) seemed to work fine, while I couldn't get it to work with TURN over TLS, apparently because of some certificates-related issues in Chrome. TURN over TLS on port 443 would help address most of the "unconnectable nodes" you talk about, as most of the places you can't use WebRTC in because of UDP/port filters, do filter HTTP but don't do DPI on HTTPS. Hangout AFAIK does the same fake-HTTPS tunneling stuff, but with the advantage of having complete control over the solution being a proprietary plugin.

Alternative proposals for WebRTC to cover even more edge cases where even TURN/TLS:443 doesn't work (like one I was involved in about tunneling RTP over WebSockets) didn't get much traction in the IETF because of security concerns: people basically don't like the idea of going behing a network admin's back, and our ideas for making this controllable didn't seem to change that.

jbenet commented 10 years ago

@lminiero

while this implementation currently takes into account the pluggable nature of Janus .... most parts should be reusable outside of that context. As soon as time permits, we'll try design a way to do so.

That sounds great!! What can we help with?

I haven't done extensive testing in that regard. I made some tests interacting with Oleg Moskalenko's TURN server using different modes, and most of them (TURN over UDP, TURN over TCP, TURN over TCP 80/443) seemed to work fine, while I couldn't get it to work with TURN over TLS, apparently because of some certificates-related issues in Chrome. TURN over TLS on port 443 would help address most of the "unconnectable nodes" you talk about, as most of the places you can't use WebRTC in because of UDP/port filters, do filter HTTP but don't do DPI on HTTPS. Hangout AFAIK does the same fake-HTTPS tunneling stuff, but with the advantage of having complete control over the solution being a proprietary plugin.

Haha!! This is great to hear! I suspected this use of TURN over TLS on :443 at: https://github.com/jbenet/random-ideas/issues/2 -- glad to hear that's being used. I wonder if the +hangout plugin does something like Fake TCP. And, they may not do DPI on HTTPS now, but they probably will... traffic patters are pretty detectable. Eventually, we'll have to start hiding patterns.

Alternative proposals for WebRTC to cover even more edge cases where even TURN/TLS:443 doesn't work (like one I was involved in about tunneling RTP over WebSockets) didn't get much traction in the IETF because of security concerns: people basically don't like the idea of going behing a network admin's back, and our ideas for making this controllable didn't seem to change that.

Tunneling RTP/WS sounds cool. What other ones? What do you think of making a standard outside of the IETF? IMO "code is law" (meaning, implementations rule what happens. Specs only suggest).

I'm of the position that network admins should not selectively alter/drop traffic. They should either provide access to the internet or not. Anything else gives rise to discrimination and censorship in a basic resource + serious abuse from less liberal governments. It's on "freedom of speech" level. Though, this is discussion is beyond the scope of this Issue -- happy discuss via another issue, or some other channel.

lminiero commented 10 years ago

2014-06-10 12:50 GMT+02:00 Juan Batiz-Benet notifications@github.com:

@lminiero https://github.com/lminiero

while this implementation currently takes into account the pluggable nature of Janus .... most parts should be reusable outside of that context. As soon as time permits, we'll try design a way to do so.

That sounds great!! What can we help with?

Good question, not sure right now, as we'd have to figure the easiest way to do so ourselves as well... Pasquale and I are currently busy on other stuff, but I hope we'll manage to sketch a project to start from in the next few weeks, and take it from there.

I haven't done extensive testing in that regard. I made some tests interacting with Oleg Moskalenko's TURN server using different modes, and most of them (TURN over UDP, TURN over TCP, TURN over TCP 80/443) seemed to work fine, while I couldn't get it to work with TURN over TLS, apparently because of some certificates-related issues in Chrome. TURN over TLS on port 443 would help address most of the "unconnectable nodes" you talk about, as most of the places you can't use WebRTC in because of UDP/port filters, do filter HTTP but don't do DPI on HTTPS. Hangout AFAIK does the same fake-HTTPS tunneling stuff, but with the advantage of having complete control over the solution being a proprietary plugin.

Haha!! This is great to hear! I suspected this use of TURN over TLS on :443 at: #2 https://github.com/jbenet/random-ideas/issues/2 -- glad to hear that's being used. I wonder if the +hangout plugin does something like Fake TCP. And, they may not do DPI on HTTPS now, but they probably will... traffic patters are pretty detectable. Eventually, we'll have to start hiding patterns.

Yes, that's why some people, myself included, have for a long time investigated alternatives to that, as we do know how difficult it is to get stuff like this to work in heavily protected environments like enterprises or even hotels. Even if you don't do DPI, tunneling TURN over HTTPS is indeed very different from HTTP, with the same amount of data coming back and forth. More on that in the next point.

Alternative proposals for WebRTC to cover even more edge cases where even TURN/TLS:443 doesn't work (like one I was involved in about tunneling RTP over WebSockets) didn't get much traction in the IETF because of security concerns: people basically don't like the idea of going behing a network admin's back, and our ideas for making this controllable didn't seem to change that.

Tunneling RTP/WS sounds cool. What other ones? What do you think of making a standard outside of the IETF? IMO "code is law" (meaning, implementations rule what happens. Specs only suggest).

Before being involved in the TURN/WS approach (TURN and not RTP, sorry for the mistake, you can find the draft here, http://tools.ietf.org/html/draft-chenxin-behave-turn-websocket-01) I proposed a plain HTTP encapsulation for RTP in a draft that has now expired (http://tools.ietf.org/html/draft-miniero-rtcweb-http-fallback-00). That approach also took into account the patterns you mentioned before, as it made use of two different/parallel HTTP requests for sending (POST) and receiving (GET) RTP packets. This allowed for a much more HTTP-like behaviour. My proposal came from a more generic approach we documented in a paper a few years ago and that tried several steps until it succeeded or failed for good ( http://link.springer.com/chapter/10.1007%2F978-3-642-14891-0_40#page-1).

Unfortunately none of this matters for WebRTC, as code might be the law, but standards matter there. If Chrome and Firefox don't implement your way of tunneling stuff, it will be useless... that's why for now the only reasonable solution is using TURN on 80/443/whatever-can-help.

I'm of the position that network admins should not selectively alter/drop traffic. They should either provide access to the internet or not. Anything else gives rise to discrimination and censorship in a basic resource + serious abuse from less liberal governments. It's on "freedom of speech" level. Though, this is discussion is beyond the scope of this Issue -- happy discuss via another issue https://github.com/jbenet/random-ideas/issues/new, or some other channel.

That's a different issue :-) I agree with you, but I also realize that's not going to change anytime soon, so the best we can do is propose solutions that allow for overcoming constraints wherever possible.

— Reply to this email directly or view it on GitHub https://github.com/jbenet/random-ideas/issues/13#issuecomment-45599005.

piranna commented 10 years ago

I have been working with WebRTC from almost beggining first as hobbyist and later for job and mostly focused on DataChannels, count with me please :-)

jbenet commented 10 years ago

Good question, not sure right now, as we'd have to figure the easiest way to do so ourselves as well... Pasquale and I are currently busy on other stuff, but I hope we'll manage to sketch a project to start from in the next few weeks, and take it from there.

Any news @lminiero ? How can we help?

jbenet commented 9 years ago

https://github.com/getlantern/natty is an example of this

DamonOehlman commented 9 years ago

Awesome - thanks for sharing the link :)

jbenet commented 9 years ago

Well, check this out: https://github.com/EricssonResearch/OpenWebRTC

cjb commented 9 years ago

@jbenet Sadly it's audio/video channels only, no data.

jbenet commented 9 years ago

@cjb ahh, tragic! i just found it.

jbenet commented 9 years ago

Hey everyone, check out this github org:

We are organizing an effort.

xhs commented 9 years ago

Hi everyone, I have implemented a WebRTC DataChannel library in C (along with a Python binding).

https://github.com/xhs/librtcdc

Just paste it here in case you were interested.

jbenet commented 9 years ago

@xhs this is great news! Will check it out post haste and make go bindings.

lminiero commented 9 years ago

@xhs excellent work, congratulations!

Just out of curiosity, does your code handle the splitting of DTLS messages in case of retransmissions caused by an MTU limit? In my implementation of Janus I've noticed that, in case a DTLS message exceeds the MTU, the packet is obviously lost somewhere in the path but is then not splitted by the DTLS stack in Openssl in following retransmissions, which is what, for instance, Chrome does instead. Looking around this may be blamed on the usage we make of BIOs to bridge a DTLS session to a generic transport, which hides the transport-related limitations (e.g., the MTU for UDP messages) since all happens in a virtual channel in memory. I did find some approaches that should allegedly help address this issue, but none seemed to work as expected.

This is not strictly a DataChannel related issue, as I mostly encountered this issue when involving big (e.g., 2048) certificates during a DTLS handshake, but my guess is that, unless the SCTP stack takes care of that, this may happen even during a consistent DataChannel usage.

xhs commented 9 years ago

Sorry, @lminiero, didn't meet this. I will look into it.

jbenet commented 9 years ago

@xhs considering using your implementation for https://github.com/jbenet/go-ipfs would love to ask you some questions. Mostly re robustness you've seen so far, maybe getting some large test cases setup (we can contribute and help do all of this) to ensure various cases work well (nat traversals, etc). If you use IRC, drop by #ipfs on freenode.net

xhs commented 9 years ago

@jbenet I'm glad to help. librtcdc is still in its early phase, and sometimes it crashes :(, issues/questions/help are welcome to make it better.

piranna commented 9 years ago

Do you have in mind to add Node.js bindings? Using the Python ones as basis should be easy to achieve...

2015-03-07 11:14 GMT+01:00 Xiaohan Song notifications@github.com:

@jbenet https://github.com/jbenet I'm glad to help. librtcdc is still in its early phase, and sometimes it crashes :(, issues/questions/help are welcome to make it better.

— Reply to this email directly or view it on GitHub https://github.com/jbenet/random-ideas/issues/13#issuecomment-77682689.

"Si quieres viajar alrededor del mundo y ser invitado a hablar en un monton de sitios diferentes, simplemente escribe un sistema operativo Unix." – Linus Tordvals, creador del sistema operativo Linux

jbenet commented 9 years ago

I think what we need to do is first construct a set of test cases to prove robustness of the library-- see https://github.com/webrtcftw/goals/issues/8 -- then we can move to bindings in various languages

jbenet commented 9 years ago

DataChannel support merged 8 days ago into openwebrtc. EricssonResearch/openwebrtc#3

xhs commented 9 years ago

Wonderful!

max-mapper commented 8 years ago

just wanted to bump this to say google is working on QUIC data channels, but i'm unsure when they will ship it

bfishman commented 8 years ago

Sorry for necro'ing a closed issue, but I was wondering if anyone is aware of a robust node.js implementation of the WebRTC dataChannel? I've used both https://github.com/js-platform/node-webrtc - which stalled out about 5 months ago - and more recently https://github.com/vmolsa/webrtc-native which has much more active development (although I'm currently experiencing some critical bugs, possibly in the chromium code on which webrtc-native is based). My use case is for a multiplayer game using solely datachannels, where browser peers connect to a node.js server "peer", and a 'pure' 'librtcdc' implementation is exactly what I'm looking for. Any leads would be greatly appreciated!!

feross commented 8 years ago

@bfishman You might consider electron-webrtc which is used by webtorrent-hybrid.

What type of datachannel bug are you encountering with webrtc-native?

modeswitch commented 8 years ago

@bfishman I'm in the process of bringing on another maintainer for node-webrtc, as my schedule has made it impossible for me to devote much time to it.

feross commented 8 years ago

@modeswitch Understandable. I imagine that's a really difficult package to maintain.

bfishman commented 8 years ago

@feross I will check out electron-webrtc, thanks!

Here's the issue I raised over at webrtc-native: https://github.com/vmolsa/webrtc-native/issues/30 Basically, it looks like a race condition with the signaling thread, seemingly caused at (dtlsidentitystore.cc:212): A free DTLS identity was saved.

@modeswitch I totally understand the need to prioritize other subjects, particularly the startup you mentioned elsewhere. Thank you for all the work you've done so far!!

notedit commented 8 years ago

anyone working on this?

philips commented 8 years ago

@notedit not that I know of.

lgrahl commented 8 years ago

Working on what exactly?

As part of our studies, we will implement a WebRTC (and possibly ORTC) library with a focus on Data Channel in C (in fact, we already have a working prototype that redirects WebRTC's SCTP packets to a kernel SCTP stack using dctt). I will keep you posted.

mafrost commented 8 years ago

@lgrahl any progress on your project? Sounds really interesting!

lgrahl commented 8 years ago

@mafrost Yes, recently we have conceived the C-API (which will be very similar to the JS-Spec defined by the ORTC community group). We'll start cleaning up the prototype and integrate it into the API skeleton as soon as we've writen our exams for the current semester. :)

notedit commented 7 years ago

webrtc will use quic with datachannel

genediazjr commented 7 years ago

any reference to this info? thanks!

daviddias commented 7 years ago

@genediazjr see: https://www.youtube.com/watch?v=mIvyOFu1c1Q

lgrahl commented 7 years ago

@mafrost I haven't forgotten this issue here. Our WebRTC and ORTC implementation is making good progress: ICE and DTLS is working already while SCTP and DCEP is underway (I'm waiting for usrsctp's event loop API). However, I'm certain we will have a working implementation at the end of this year. I'll keep you posted. And meanwhile, you can follow my progress here. The project will be moved to GitHub at the end of this year as well.

Edit: Updated project URL.

lgrahl commented 7 years ago

Hey everyone. I promised to move the project to GitHub at the end of last year, so I feel obliged to inform you why this hasn't happened, yet. My studies were quite intense and I encountered some very nasty bugs to debug in late 2016. However, the project is making great progress. The data channel implementation is nearly complete and might even be the first implementation that can handle messages of arbitrary size correctly (if you're interested in this topic, read my blog posting about this problem).

Once we have fixed these bugs and the project is working in alpha state, I'll move it to GitHub into this organisation. This will most likely happen in Q1 2017. I'll keep you posted.

lgrahl commented 7 years ago

Done, you can check it out here: https://github.com/rawrtc/rawrtc

Documentation is pretty bad at the moment, so please open issues if you are having trouble getting started. There are also tons of TODOs in the code if you want to help. :)

feross commented 6 years ago

Chrome 63 just announced:

Build WebRTC with DataChannel only

webrtc::CreateModularPeerConnectionFactory() is available and it can be used to build WebRTC with DataChannel support only. It accepts MediaEngineInterface, CallFactoryInterface and RtcEventLogFactoryInterface as arguments. If the application knows it won't use certain modules, it can pass in null pointers for specific modules and omit the corresponding modules from its build. See an example of usage in webrtc:7613.

https://groups.google.com/forum/?utm_medium=email&utm_source=footer&__s=obdrvn8g53z98ugdgkuz#!msg/discuss-webrtc/qDtSDxoNSII/69b6fAkxAQAJ

Just FYI

Sean-Der commented 5 years ago

Hey @jbenet

Just stumbled across this while searching for something else.

We wrote pion WebRTC it is Go implementation that has Datachannel and media support

Everything is in Go. We implemented SCTP, DTLS, SRTP, ICE and SDP all ourselves. So it super portable and no communication friction between libraries.
We have multiple active contributors and no 'private' issues. It has a been a big goal for the project, there is no 'BDFL' everyone can merge if one other developer in the org approves the PR.
We plan on building shared libraries so we can support other languages. All the benefits of C... but without having to spend our lives issuing CVEs and plugging leaks :)

jbenet / random-ideas