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: Fri, 12 Jan 2018 01:58:01 +0100
From: Lennart Grahl <lennart.grahl@gmail.com>
To: Iñaki Baz Castillo <ibc@aliax.net>
CC: Lorenzo Miniero <lorenzo@meetecho.com>, T H Panton
<thp@westhawk.co.uk>, 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 12.01.2018 00:22, Iñaki Baz Castillo wrote:
> On 11 January 2018 at 13:31, Lennart Grahl <lennart.grahl@gmail.com> wrote:
>> 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.
> 
> Is it C/C++ and does not assume multi-threading?

C. No multi-threading.

> I cannot use usrsctplib because it uses different threads internally,
> mandating the app (that integrates it) to also be multi-thread. So I
> cannot use it.
> A good C library should not run a separate thread by itself to just
> run a timer. Instead, provide a mechanism to tell the app when to pull
> data from the lib (even openssl allows that).

I use usrsctp-neat which has a function I need to call every 20ms
instead of a timer thread. But I remember that there was at least a bug
with a thread idling - we'll need to ping them if this is still the case
and an issue for you (it didn't really matter to me at the time of
writing and I had other stuff on my mind). The features from
usrsctp-neat I'm using will also be merged back into usrsctp at some
point (this is already in progress, see
https://github.com/sctplab/usrsctp/pull/189).

> Also, does your lib manage UDP/TCP ports by itself? or does it expose
> a proper I/O API + events? I don't want/need a datachannel library
> that manages ports, ICE or even DTLS. I already do that so just need a
> layer on top of what I've already that.

Yeah, of course RAWRTC does ICE, STUN, TURN and DTLS right now. But if
we pull out the data channel implementation only, we'll need to define
some API that roughly includes passing inbound data, a callback function
for outbound data, some timer functions that needs to be called in a
specific interval and possibly some other functionality that includes
setting the MTU for SCTP, retrieving some information from the DTLS
transport (such as whether the role is client or server), etc. This way,
we're able to use it in RAWRTC but you are able to use it in your
implementation, too.

Cheers
Lennart

Received on Saturday, 13 January 2018 13:49:55 UTC