Re: Towards a new charter for the WebRTC Working Group

(I forgot to CC public-webrtc@w3.org, so I'm forwarding missing messages
of this thread for the sake of completeness.)


-------- Forwarded Message --------
Subject: Re: Towards a new charter for the WebRTC Working Group
Date: Thu, 11 Jan 2018 13:31:58 +0100
From: Lennart Grahl <lennart.grahl@gmail.com>
To: Lorenzo Miniero <lorenzo@meetecho.com>
CC: T H Panton <thp@westhawk.co.uk>, Iñaki Baz Castillo <ibc@aliax.net>,
Peter Thatcher <pthatcher@google.com>, Michael Tuexen
<Michael.Tuexen@lurchi.franken.de>, Martin Thomson
<martin.thomson@gmail.com>, Dominique Hazael-Massieux <dom@w3.org>

On 11.01.2018 10:20, Lorenzo Miniero wrote:
> On Thu, 11 Jan 2018 09:07:30 +0000
> T H Panton <thp@westhawk.co.uk> wrote:
> 
>>> On 10 Jan 2018, at 21:43, Iñaki Baz Castillo <ibc@aliax.net> wrote:
>>>
>>> On 10 January 2018 at 07:03, Peter Thatcher <pthatcher@google.com>
>>> wrote: 
>>>> - Ease of deployment.   No offense to usrsctplib, but I hear a lot
>>>> of complaints about having to use it to make a non-browser WebRTC
>>>> endpoint. It's one of the biggest complaints we hear about WebRTC
>>>> data channels: the pain of terminating SCTP (and DTLS).  That's a
>>>> big reason why people want QUIC. There will soon be many
>>>> implementations to choose from (if there aren't already) and you
>>>> only have to terminate one protocol, not two (DTLS and SCTP;
>>>> ignoring ICE).  
>>>
>>> Absolutely.
>>>
>>> QUESTION: How many DataChannel libs / stacks are out there after 6
>>> years of WebRTC?  
>>
>> I can think of 4. Unfortunately they are mostly tied up in products,
>> rather than packaged as libraries.

It took me a while to see this, too but it clicked when I basically
ported a lot of code from RAWRTC to Firefox. I'd be happy to pull out
RAWRTC's data channel implementation and make it possible to use this
outside of RAWRTC itself. RAWRTC is a good candidate for this as it has
very few dependencies. I guess this would be particularly interesting
for smaller projects that want data channels such as janus-gateway.
Please reach out to me if you're interested.

>> The best to-date is probably Janus - getting a datachannel as part of
>> a page is super easy. Jitsi has a datachannel library, but it isn't
>> easy to get at. Lennart has RAWRTC
>> and I'm working on |pipe|
>>
> Both Janus and (please correct me if I'm wrong Lennart) RAWRTC use
> usrsctp to implement datachannels, though, which is what I believe
> Iñaki was referring to: the lack of alternative libraries to implement
> the underlying transport. That said, I don't think it would be easier
> to find QUIC stack implementations: it would probably be just as hard.

I've seen a few other SCTP implementations used for data channels but
they're not used in widely known projects and I can't really tell much
about the quality. If you're interested, I can dig them up. Maybe
Michael knows a few more implementations.

>>> And no, usrsctplib is not the way to go. If, after 6 years, a
>>> technology has not produced community driven implementations with
>>> support for multiple languages, then something is just WRONG. How is
>>> it possible that, after 6 YEARS, we don't have ANY tinny library in
>>> ANY language to just run a simple script that connects via ICE +
>>> DTLS and establishes a DataChannel connection? Instead of that, we
>>> have "monster" projects (such as the wrongly called node-webrtc)
>>> that embeds the whole Google's libwebrtc (even if just the
>>> DataChannel feature is required).

I'm not really sure what you're referring to here:

- Alternative SCTP implementations? Yeah, it's true, there aren't many
that are open source or popular. (FWIW, I am itching to write one in Rust.)
- Standalone SCTP-based data channel implementations? I don't know of
any but as I said, we can make one.
- Bindings to other languages? Should be fairly easy for RAWRTC at least.

(Sorry this went a little bit off-topic.)

Cheers
Lennart

Received on Saturday, 13 January 2018 13:46:41 UTC