> 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