Multi-person conference p2p


#1

To reduce server bandwidth, I thought about how to change the code when the room is still in P2P mode when there are 3-6 people.


#2

This will not happen. The complexity of adding this is not worth it and also it brings high upload bandwidth to participant computers. We are trying to minimize bandwidth not to increase it, as normally the upload is a problem at various locations (asymmetrical Internet is very common).


#3

In this way, the bandwidth of the service end can be reduced. In our country, the price of purchasing the server will increase exponentially with the increase of bandwidth. The cost is very expensive and the cost is too high.


#4

I agree, but it will not be usable. Users will need to have very good internet, which is not usually the case.
For 6 people conference every user need to have 25mbit upload and download in oppose to 5 when using jvb.


#5

For a 6-person conference, 25M for each user, the server JVB needs to have 150M bandwidth, which is a very scary cost.In our country, the user bandwidth is more than 100M, easy to achieve.


#6

This is not correct, as jvb can do simulcast and layers switching.
So for the same conference jvb will need 30 MBit of bandwidth, where in p2p every peer is like jvb need to send to multiple people at the same time and receive the streams from multiple people.
Jitsi Desktop was working like that 6 years ago, and we came to the conclusion that this is not going to work well and this is how jvb was born and then webrtc came and we had already the SFU so jitsi-meet was born.


#7

Suppose there are 6 people in a meeting, and each audio and video stream is 5MB. How much bandwidth does JVB need to bear?How do we calculate this?


#8

So if every participant is sending around 5 Mb, then jvb is receiving 65=30 Mb. In case of simulcast, every participant is sending 3 resolutions in this 5 Mb, then jvb is signaled and knows what to send, knows which participant is on stage and which are the participants shown in thumbnails, and jvb chooses which stream to forward. So for every participant it forwards one high resolution and five 180p resolutions (for the thumbnails), which should be approximately 5 Mb, so 65=30 Mb outgoing traffic.

In case of p2p, every participant needs to receive the higher resolution from the others, 5 receive streams are 55= 25. And every participant needs to send its video the the rest of the participants it is 55=25 for outgoing.


#9

I see, so what strategies can be used to reduce the bandwidth load of JVB?


#10

which country u r from? dont u have aws or digital ocean in ur country?


#11

China,We’re using aliyun


#12

The only thing is to reduce resolution, to basically disable HD video. We have some config for that, not sure after some changes are those still working as expected (somebody reported a problem with reducing resolution).


#13

To reduce the bandwidth load I think you can enable Last-N feature (I’ve never used it)


#14

LastN will reduce bandwidth for the users, it can be used it will reduce outgoing traffic from the bridge. The goal is to reduce jvb traffic, so the only way I can think of for the incoming traffic is to reduce resolution on clients.