[ta-webrtc]

Latency is as good as you can do when doing peer to peer calls, the trade off is bandwidth (and CPU, but mostly bandwidth).

Latency and non-terminated encryption (end-to-end, not point-to-point) is great, and for calls with 3 or fewer peers the stability is fine. More peers than that and you probably want a media router in the mix, which adds some latency (all the calls have to route through a central server) and the server typically has done termination of the encrypted call streams as it does its routing.

[larma]

> server typically has done termination of the encrypted call streams as it does its routing.

Dino already supports some kind of "double encryption", where even if DTLS-SRTP is terminated at a media routig or bridging server, there is another SRTP encryption layer. This allows for end-to-end encryption even when DTLS-SRTP is terminated by a server for WebRTC compliance (as WebRTC requires to encrypt using DTLS-SRTP even if transported media was already encrypted through other means).

[astrobe_]

I didn't find a meaningful difference between "end-to-end" and "point-to-point", except for a not-sourced stackoverflow post [1] and definitions for payment services standards. What is the terminology you use?

[1] https://stackoverflow.com/questions/10202143/what-is-the-dif...

[southerntofu]

I think the parent was referring to all participants encrypting stream for the video router, who then would reencrypt to its final destination. End-to-end means the video doesn't get decrypted in the middle.

[southerntofu]

It's definitely possible to route encrypted streams, see also how Jitsi does it:

https://jitsi.org/blog/e2ee/

[app4soft]

> This is what end-to-end encryption should look like!

> Published on: April 12, 2020 by Emil

> Work in Progress!