W3C home > Mailing lists > Public > public-webrtc@w3.org > January 2018

Re: Towards a new charter for the WebRTC Working Group

From: T H Panton <thp@westhawk.co.uk>
Date: Thu, 11 Jan 2018 09:42:04 +0000
Message-Id: <3AA8EE30-232E-4E56-9496-663250060FA7@westhawk.co.uk>
Cc: 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>, "public-webrtc@w3.org" <public-webrtc@w3.org>
To: Lorenzo Miniero <lorenzo@meetecho.com>


> On 11 Jan 2018, at 09:20, Lorenzo Miniero <lorenzo@meetecho.com> wrote:
> 
> On Thu, 11 Jan 2018 09:07:30 +0000
> T H Panton <thp@westhawk.co.uk <mailto: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.
>> 
>> 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.


SCTP is hardly the worst offender, everyone uses the same Opus code.
Almost everyone uses the same SRTP code.

But I basically agree - hence I wrote https://github.com/steely-glint/srtplight <https://github.com/steely-glint/srtplight>
and https://github.com/pipe/sctp4j <https://github.com/pipe/sctp4j>
and arranged to have the DTLS part of https://github.com/bcgit/bc-java <https://github.com/bcgit/bc-java> sponsored
All of which are independent re-implementations of standards.

T.
Received on Thursday, 11 January 2018 09:43:05 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 11 January 2018 09:43:06 UTC