Currently a feature is that all media is sent directly from peer to peer, without visibility or storage by the server.
This is fine for people hosting the service on networks with limited bandwidth, but when peer count rises the client sends a copy of each stream to multiple users, thus leaving the bottleneck on large chats as "peer with worst upload".... This is not a good bet to be making.
One option is simply to implement a broadcaster in the server. This would accept the video/audio streams from the client and rebroadcast to each viewing peer. It shifts the bottleneck on upload to the server connection, and adds unknown CPU load. It might be worth making this a policy choice for server owners. For small enough groups of people using a very low powered device to host the server this should be disabled and current code path kept.
Currently a feature is that all media is sent directly from peer to peer, without visibility or storage by the server.
This is fine for people hosting the service on networks with limited bandwidth, but when peer count rises the client sends a copy of each stream to multiple users, thus leaving the bottleneck on large chats as "peer with worst upload".... This is not a good bet to be making.
One option is simply to implement a broadcaster in the server. This would accept the video/audio streams from the client and rebroadcast to each viewing peer. It shifts the bottleneck on upload to the server connection, and adds unknown CPU load. It might be worth making this a policy choice for server owners. For small enough groups of people using a very low powered device to host the server this should be disabled and current code path kept.