Re:Dino 0.3: Video calls and conferences – encrypted and pee...
by larma on Sunday February 13, 2022 @04:01AM
(#30320385)
> 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).
Re:Dino 0.3: Video calls and conferences – encrypted and pee...
by astrobe_ on Sunday February 13, 2022 @03:43AM
(#30320302)
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...
Re:Dino 0.3: Video calls and conferences – encrypted and pee...
by southerntofu on Sunday February 13, 2022 @07:58AM
(#30321447)
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.
Re:Dino 0.3: Video calls and conferences – encrypted and pee...
by southerntofu on Sunday February 13, 2022 @08:00AM
(#30321459)
It's definitely possible to route encrypted streams, see also how Jitsi does it:
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.