Elixir webrtc data channels libs?

I know about https://www.membraneframework.org/ but am wondering if there is something lighter weight if all I need is just web rtc data channels. No audio . No video.

There is an related thread at Elixir server for WebRTC data channels (or other UDP-like channels) ; but no obvious conclusion.

Suggestions ?

I remember there was something like that, but I can’t find it right now.

You might have some luck searching for sctp language:Elixir and dtls language:Elixir on github, since these are the building blocks of a data channel.

Here’s what I’ve been able to find with these queries:

If nothing suitable is found, It might make sense to use some of the libraries from membrane like ex_dtls instead of :dtls from stdlib to make things easier (the last time I tried :dtls, it wasn’t suitable for webrtc communication due to chrome sending stun requests over it, I guess membrane libraries account for that).

2 Likes

It’s going to be hard to find a lightweight WebRTC implementation because this standard is heavy-weight by design - whatever you’d like to achieve, you need quite a lot of stuff. Here are the building blocks for data channels and some low-level membrane libraries that may be helpful

  • SDP offer-answer exchange - ex_sdp | Hex provides basic SDP handling
  • ICE - ex_libnice | Hex - a wrapper over C library
  • DTLS - Membrane’s ex_dtls only handles DTLS handshake, so it’s not suitable for data channels yet
  • SCTP

Erlang’s DTLS and SCTP implementations may be problematic to use, as their API doesn’t allow communication via ICE socket AFAIK. Even SCTP over DTLS may be not supported.

Not sure how is QUIC integration going, but it seems to be the future of unreliable data exchange with browsers.

3 Likes

@mat-hek : Thank you for the detailed response. I have great respect for the technical expertise of the membrane project. Let is take this apart piece by piece. The WebRTC standard, i my limited understanding, has 3 components:

  1. ICE: STUN (hole punching through NATs), TURN (when STUN fails and all traffic is relayed through a 3rd aprty)

  2. Media stuff (which I know nothing about)

  3. Data channels = DTLS + SCTP

[1] does not apply to us because we are doing client <-> server WebRTC instead of client <-> client WebRTC, and the ip of the esrver is always public.

[2] does not apply to us because we are not doing audio / video.

All we need is ‘just’ DTLS (while many TLS impls already exist) and SCTP right ?

That’s not true, unfortunately. Browsers use ICE and assume the other peer also uses ICE, no matter if it’s a publicly available sever or not… There exists the ICE-lite version, which is much simpler than the full ICE and intended for exactly this use case, but I haven’t found any place where it’s described in detail or any implementation supporting ICE-lite only. See RFC 5245 - Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols and webrtc - Is there any reliable document or RFC on ICE Lite implementation? - Stack Overflow. We’re now experimenting with related things, more about that in our blog https://blog.swmansion.com/how-we-made-membrane-sfu-less-ice-y-34ac8ce8d97c

You also need to handle SDP exchange, though it may be not too hard when using data channels only. And then SCTP over DTLS over ICE should do the job :wink:

2 Likes