[kelnos]

TURN doesn't have anything to do with number of participants; it's there for when NAT hole-punching completely fails and you need a relay. TURN is application-protocol agnostic and just forwards packets; it does not need to decrypt whatever it's relaying. Now, one could run a malicious TURN server that MitMs connections, but I'm not sure how obvious that would be to the end-parties.

For more than two users, you mainly have three options:

* MCU (Multipoint Control Unit), which IIRC does need to decrypt your video, as it will post-process it and possibly re-encode it to send a single stream to the other participants.

* SFU (Selective Forwarding Unit), which in theory doesn't need to decrypt your video, but does need some metadata about it in order to make smart decisions as to what streams to forward to whom (for example, forwarding only the stream of the person who is talking). In practice, I believe some (many?) SFUs will do decryption, thought it's not a strict requirement.

* Dumb peer-to-peer-to-peer-to-... multi-forwarding. You can of course theoretically stream your video to each other participant, and they can all do the same, but that quickly fails to scale. It might be ok for three, maybe four participants, but even then there will likely be problems.