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.
> 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).
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?
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.
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.