Re: Towards a new charter for the WebRTC Working Group

Thank you Lennart, really interesting stuff!

Count me in for helping in development and testing.

Best regards
Sergio


El 13/1/2018 14:51, "Lennart Grahl" <lennart.grahl@gmail.com> escribió:

> (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
>
>