Implement DataChannel

[ibc]

The lib: https://github.com/sctplab/usrsctp

[ibc]

Usage example: https://github.com/xhs/librtcdc

[ibc]

Regarding usrsctp being thread safe and a single-thread fork:

sctplab/usrsctp#37

[ibc]

This will be done in the future, but no need to keep an issue open for this task.

[Zubnix]

Do you have an estimate as to when datachannels are expected? The reason I'm asking is because Node.js land has no good (read 'one that actually works') webrtc library (except for this one), and I really need datachannels for my project to move forward.

[rektide]

It would be very helpful to have something to track. I'd like getting some kind of status update when DataChannels starts implementation or becomes available. I'd like seeing this issue opened and tagged, as it'd help close that loop.

Agreed with Zubnix that this issue is the best hope by far for getting a lot of really interesting Node.js webrtc projects going.

[ibc]

Hi guys, I reopen this issue to have it as feature tracker.
Yes, we want DataChannels in mediasoup and we'll start implementing it after 2.0.0 release.

[ibc]

More stuff:

• Upcall API and some examples (2 clients and 4 servers) sctplab/usrsctp#189
• https://github.com/NEAT-project/usrsctp-neat

[lgrahl]

The dedicated data channel lib based on RAWRTC is supposed to be ready at IETF 101. Just some info for anyone else interested since @ibc already knows. 😃

[ibc]

@lgrahl SHOW ME THE CODE! :)

[lgrahl]

@ibc I haven't started, yet. But since you can't wait: I'll start in roughly two weeks and you'll be the first to know about any progress. 😜

[ibc]

Cool :)

[Globik]

@lgrahl based on what loop? Libuv, libre?

[lgrahl]

@Globik I of course use libre utility functions (struct mbuf, etc.) but it's not bound to any event loop.

[mtltechtemp]

@lgrahl Hi, any news ?

[lgrahl]

This is off-topic but I'll answer anyway: Already done, see https://github.com/rawrtc/rawrtc-data-channel/
But I don't think @ibc plans on using it.

[ibc]

It's not lack of interest but just lack of time (plus not much knowledge of DataChannel at implementation level). It also comes to my mind whether we should implement DataChannel or wait wait for unordered/unreliable QUIC in browsers and implement a QuicTransport.cpp transport class in mediasoup.

[lgrahl]

No blame intended. And QUIC... let's wait and see... but I'm certain we will wait years.

[ibc]

Yeah, I don't have any strong preference. Nor time enough to integrate DataChannel for now :)

[ibc]

BTW @lgrahl, does rawrtc-data-channel really need both ninja and meson? I know C/C++ libraries distribution ecosystem is a pain, but requiring so much building stuff does not help much.

For example, in mediasoup all the external C/C++ libraries are included into the worker/deps/ folder and all them have a .gyp file that is included as GYP dependency in the main mediasoup-worker.gyp file and makes it possible things like having npm install mediasoup build all the libs. Having to also use ninja and meson looks like a no way for me at this point...

[lgrahl]

The world of build systems is fragmented. Therefore, a build system should allow to depend on other build systems. If GYP can't, then 🤷‍♀️. If it can, then, yes, you will need to apt install meson ninja but it's not going to kill you.

IMO, Meson brings the best compromise with the least amount of pain. So, I chose it. Meson configures, Ninja builds. Thus, Meson requires Ninja.

[ibc]

Yeah. I assume all of us want that others also use our preferred build system :)

[saghul]

GYP can use ninja too, so hey, there is that :-P

[ibc]

GYP can use ninja too, so hey, there is that :-P

Plz plz @saghul, elaborate that a bit more. So you mean that gyp (and I mean the gyp we already use in mediasoup) can be configured to generate ninja "configuration files", so after calling the ./scripts/configure.py (which uses gyp) we should run ninja foo and bar instead of make foo and bar, right?

If so, rawrtc-data-channel project would need a rawrtc-data-channel.gyp file, right? and whatever meson is would not be required, am I right?

And wait... why is ninja required at all? I'm not against ninja but AFAIU if there would be a rawrtc-data-channel.gyp file we can just use gyp to produce Makefile as now. I'm super wrong?

[lgrahl]

Yes, yes and yes.

But have fun writing GYP files for re, rew, usrsctp and rawrtc-data-channel (the easiest part of them all). If I compare that against invoking meson once... your choice. 😉

[ibc]

@lgrahl why does it depend on re and rew?

[lgrahl]

Quite a couple of helper functions. But I'm fine with optionally pulling those from re into rawrtc-common.

[ibc]

I've written this, which covers mediasoup DataChannel architecture and implementation approaches:

https://github.com/versatica/mediasoup/wiki/DataChannel

[ibc]

We are finally working in DataChannel implementation for mediasoup v3. Here the announcement:

https://mediasoup.discourse.group/t/working-in-datachannel-implementation/104

[lgrahl]

I think some criticism is appropriate, considering that you were one of the folks asking for a better-suited data channel library which is why I started writing it. Yet you're now going the DIY path as well. Just hoping you're not doing the same mistakes as all the other ones. 😜

Nevertheless, feedback understood that the API of rawrtc-data-channel is not ideal for forwarding and that there's a dependency issue.

[ibc]

Not entirely accurate:

Honestly we don't know if "the API of rawrtc-data-channel is not ideal for forwarding". Probably it is suitable since, anyway, we are constrained to full SCTP messages routing (we cannot do SCTP DATA or I-DATA forwarding due to limitations in usrsctp, usrsctp-neat and Chrome).

Agreed on the dependency issue. But more important (and not the first time we mention it):

• rawrtc-data-channel depends on usrsctp-neat.
• usrsctp-neat is not maintained at all (last commit 10 months ago).
• usrsctp-neat does not merge commits made in usrsctp main stream project.
• No idea (yet) about what those commits fix or improve, but usrsctp is used by libwebrtc so they may be relevant.

[lgrahl]

If the dependency towards usrsctp-neat were the only issue, it wouldn't make sense to go DIY as you're most likely going to link it statically anyway. The usrsctp folks made it absolutely clear (to me, in person) that they are going to merge the required changes eventually. Having worked with them for quite a while, I fully trust that they will as soon as they find the time to do so.

Your decision is your decision though and I don't want to publicly argue about this unless you're not 100% sure you want to do it the DIY way.

[ibc]

We need DataChannel in mediasoup within the next 2 months. If things change in the future we are 100% open for improvements and even new stacks. Basically all the SCTP code will be located into a single SctpAssociation.cpp file in mediasoup source and will expose a non usrsctp dependent interface. We can replace it with other implementation at any time if it makes sense.

[ibc]

And this is done!!:

Announcement: https://mediasoup.discourse.group/t/datachannel-implemented/139

Test it at https://v3demo.mediasoup.org (can type @bot xxxx to interact with a Node.js SCTP bot).

[ibc]

mediasoup and mediasoup-client 3.2.0 have been released in NPM with DataChannel support. Enjoy.