- From: Lennart Grahl <lennart.grahl@gmail.com>
- Date: Sat, 13 Jan 2018 14:46:15 +0100
- To: public-webrtc@w3.org
(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