WebRTC for communicating

Feature Proposal
25

Delta Chat currently has integration with Jitsi Meet and basicWebRTC.

I did an experiment inspired by Serverless WebRTC: ~link2xt/webrtc-clipboard-call - WebRTC call-via-clipboard application using React and TypeScript - sourcehut git It is basically the same but the code is written from scratch without all the cruft required to support older browsers. All the code is in ~200 lines long index.tsx. I wrote this at the time when we explored various approaches to WebRTC calls for DC, as a proof of concept.

Instead of clipboard, SDP can be exchanged via email. RFC 4566 even has a section 3.3 dedicated to publishing SDP offer on WWW and exchanging it via email, reserving application/sdp MIME type.

This is experimental, because some problems remain unsolved:

  1. All platforms need code to do WebRTC. For Desktop it is easy, because it uses Electron, but for Android and iOS something native is needed. Preferably something secure.
  2. Because sending emails is more expensive than signaling over WebSocket, I have to wait until all ICE candidates are collected. Not really a problem, it takes “only” a few seconds, but see the next item.
  3. When users are mobile, they may change their IP during the call. In this case, you need a way to send additional ICE candidates for renegotiation, as described in the section about ICE rollbacks and restarts in MDN. Doing such signaling via email is slow. I have not really explored how this mechanism works, but maybe the problem can be solved by establishing WebRTC data channel in addition to media channel and send ICE candidates over it when you detect that connection is lost. User who has a new IP will still be able to send data to user who has old IP, because data channels are unidirectional, and update its IP. This is how Wireguard and Mosh do roaming, and it should work as long as both clients don’t change their address at the same time.
  4. Users still need to have STUN/TURN server configured within a client. STUN servers normally don’t require authentication, but TURN servers are like an email servers, you need a login and password to use them. And for this to work reliably at least one user is better use TURN so it can be used as a relay if direct connection can’t be established.
3 Likes