WebRTC DataChannel Everywhere

[jbenet]

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

1. a clean libwebrtc + language bindings.
2. 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]

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

[jbenet]

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

[feross]

/cc @modeswitch @DamonOehlman

[DamonOehlman]

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]

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]

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]

Thanks for including me on this. Good to listen.

On Monday, June 9, 2014, Juan Batiz-Benet [email protected] 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
#13 (comment).

[lminiero]

@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]

@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: #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]

2014-06-10 12:50 GMT+02:00 Juan Batiz-Benet [email protected]:

@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 #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
#13 (comment).

[piranna]

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]

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]

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

[DamonOehlman]

Awesome - thanks for sharing the link :)

[jbenet]

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

[cjb]

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

[jbenet]

@cjb ahh, tragic! i just found it.

[jbenet]

Hey everyone, check out this github org:

• https://github.com/webrtcftw/
• https://github.com/webrtcftw/welcome
• Pure JS data channel implementation webrtcftw/goals#1

We are organizing an effort.

[xhs]

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]

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

[lminiero]

@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]

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

[jbenet]

@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]

@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]

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 [email protected]:

@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
#13 (comment).

"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]

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

[jbenet]

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

[xhs]

Wonderful!

[max-mapper]

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

[bfishman]

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]

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

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

[modeswitch]

@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]

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

[bfishman]

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

Here's the issue I raised over at webrtc-native: vmolsa/webrtc-native#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]

anyone working on this?

[philips]

@notedit not that I know of.

[lgrahl]

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]

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

[lgrahl]

@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]

webrtc will use quic with datachannel

[genediazjr]

any reference to this info? thanks!

[daviddias]

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

[lgrahl]

@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]

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]

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]

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]

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 :)