- From: Iñaki Baz Castillo <ibc@aliax.net>
- Date: Wed, 10 Jan 2018 22:43:43 +0100
- To: Peter Thatcher <pthatcher@google.com>
- Cc: 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>
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? 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ñaki Baz Castillo <ibc@aliax.net>
Received on Wednesday, 10 January 2018 21:44:43 UTC