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.
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).
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
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.
@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:
ICE: STUN (hole punching through NATs), TURN (when STUN fails and all traffic is relayed through a 3rd aprty)
Media stuff (which I know nothing about)
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 ?