WebRTC for communicating

Hello Heiko,

While WebRTC allows full blown communication features as real time video/audio it has one weak place: one have to use some STUN/ICE server, so devices can exchanges with IPs to be able to find each other and this would create dependency on this server.

Who will run this STUN server and take financial responsibility to pay for it?

We use the stun servers of tilio (tilio.com). Stun server need only low bandwidth and low traffic. We do not use turn server, because than the traffic will be higher.

We have nearly no traffic on the stun server of tilio. We have an own stun server, too. I’ld sponsor a stun server for delta.chat. If traffic would be high so that tilio will close the free access and maybe our server is too small, then the webrtc feature would turn of until end of month.

Audio / video will work, too. And that’s no extra traffic for the stun server (it could be for a turn server, but I’ld prefer not to use one for financial issues).

I’ld see the WebRTC feature as addon. It’s nice, if it works and not necessary, if it doesn’t work.

We could use open stun servers, too: https://gist.github.com/zziuni/3741933
Maybe this has to be discussed, because the stun server will know who is talking with whom, but not more.

We use the tilio list and our stun server right now. You can ask different stun servers on the same time and fetch the first result. So a list with open stun servers shouldn’t be a problem.

You can ask different stun servers each time, so that not one server knows all connections.

hi Heiko,

welcome aboard :slight_smile:

in fact, we’re also thinking about webrtc in various ways, how they can be used and shared in a decentral way, and, of course, audio and video calls and file sharing. routing messages over this channel also sounds interesting, indeed.

currently, there is just no webrtc in delta chat at all, so every progress and contributions on this is welcome :slight_smile:

at least for the ui, the signal-messenger (also open source) might be a good start at least for android.



Hello Heiko, agree with bjoern, sounds interesting and welcome :slight_smile: Our tentative ide was to allow configuring a WebRTC server for a Delta Chat app and to introduce UX to “share” (post) a webrtc config with chat partners so that they can also “use” it. Once configured one could perform WebRTC audio/video calls with chat partners even if the other side does not have webrtc configured. One could also setup a call with regular e-mail users (say someone using webmail), which would simply arrive as a webrtc link. If you want to start on this we could see if you could join one of our dev gatherings that we regularly do in Freiburg.

The topic of routing messages over WebRTC instead of e-mail i’d leave for later. There are several open questions (multi-device, device-to-device sync, …) and it’d be a somewhat major refactoring on the deltachat-core side which is also currently changing quite a bit in other ways.

cheers holger


Hello Holger,

I’ll try to have a look on your code on weekend to see, if can contribute on the code.
Is see the WebRTC channel as an additional channel. So if it’s open, messages will be send with WebRTC and e-mail and the client shows the message it first gets. That’s how we do it on Helper.World. There must be an unique id for the messages so that now message is shown double.

Starting a WebRTC connection is no big deal for a web application. You just have to create an ICE per client (stun server) and send the ICE to the partner (as delta.chat message) and the rest is done by the webrtc library.

So. I’ll try to understand the current delta.chat code and see if I can do something about it.


Are you using something like the jitsi Meet SDK in you app? It says the TURN server can be configured.

Here is some debian discussion about running a (decentral) TURN server behind a NAT https://salsa.debian.org/freedombox-team/plinth/issues/685

And it will ruin two important unique features: everybody with an email can take part in conversation, all messages are in your email folder.

If we would do it we would only do it opportunistically anyway to increase message delivery speed. So it wouldn’t affect that feature. So no worries :wink:

1 Like

If all received messages ends up in DeltaChat folder, than it’s cool! )

That’s my idea.


I was just trying Delta Chat yesterday and wondering about a WebRTC video call button, too. Right now, I can type something like https://meet.jit.si/WHATEVER, send that, and everyone on the email list will be able to join a WebRTC video call by clicking that link as long as their browser supports WebRTC or they proceed to install the Jitsi Meet app when prompted on iOS and Android.
Why not make a button that does that? A preference could allow the user to enter any Jitsi server. Another preference could allow supporting other types of WebRTC servers. The button could:

  1. Create a random Jitsi conference room link or allow the user to type their own. (Maybe random by default to make it easier?)
  2. Send the link to all recipients
  3. Auto-deep-link into the Jitsi Meet app so you’ll join the video conference room right away.

Is there any advantage to integrating video calling within the Delta chat app versus deep linking to a separate dedicated app like Jitsi Meet? I suppose it would mean one less app to download, but having it separate means you can switch video call providers more easily.


For a first and quick start, I’ld prefer your idea.

The advantage of an own WebRTC channel would be, to transfer the whole chat over this channel as well. And you could do this without audio/video as well.


I’m sorry for paranoia, but usually everything that provided at huge scale as open/free - it is a “mouse trap”. Stun server - it is dependency on 3rd party server(s) that providing stun service for free just to be able to get connections graph and be in control of this graph IMHO.

I really don’t want to be a party pooper, but what the point to duplicate functionality that already exists in Signal ?
Besides of forking Signal’s UI (that used by DeltaChat), you offering to implement the same Signal’s functionality. I probably missed something, but I can’t see any advantage of implementing WebRTC since this technology can not be decentralized and attempts to reinventing things that are already exists and well supported in other apps. Chat isn’t a missile’s control center that requires lightning speed communication, so WebRTC imo won’t bring any advantage to chat application. Real time Video/Audio? It is just a matter of go to https://meet.jit.si on any devices and start communication or use referenced above Signal.

What is uniqueness of your proposal to implement WebRTC, that doesn’t exists in other, well supported apps ?

Hello Alex,

I see your point. And I’m a friend of doing one thing good as well. So forget about the proposal. I wasn’t aware of meet.jit.si. Maybe some features or plugins to integrate those things soomthly.


You could give the user the choice to choose another STUN server, which sounds pretty decentralized to me.

indeed, that’s the idea: to make the webrtc server configurable and allow an easy way to share configurations. eg “attach+callprovider” on the sending side and “use callprovider” on the receiving side. This way you can easily offer a service to a chat group, and each member can “use it” (which means setting the webrtc-server settings accordingly) for setting up phone calls with others.

Hm, maybe the goal could be even higher - i.e. no servers at all, but just purely decentralized video conferencing.

Guys from PeerTube seem to be trying to implement it - see my comment Video chat integration .

1 Like

I guess the way to achieve LiveStreaming is to encrypt and to send data from one device, and the others shall receive and decrypt it. For P2P, video calls require “all in one” instead: encrypting, sending <-> receiving, decrypting.

While I think it could be possible for all-time powered devices, e.g. PC systems, it would not be suitable for charged handheld devices now: First, a device driven by a high-end SoC with enough memory to do the tremendous work fast and efficiently is absolutely necessary, still giving other apps enough “air to breathe” and to work acceptable with short UI/UX response times. And second, low power consumption (or a huge battery). Performing such video calls will discharge a battery within a couple of hours using todays high-end technology.

Please do not get me wrong, I would love to see this technology succeed on any device, even for P2P video chats, but the time has not come, yet. For now, a (one way) LiveStreaming solution seems to be a more realistic goal to achieve.

Best, Gerry