[jitsi-dev] Jitsi Meet and bandwidth requirements


#1

Hi all!

Investigating the bandwidth required based on the number of participants
in a conference, I found the table for WebRTC at the bottom of this [1]
document.

Do you believe that these values will also apply to Jitsi Meet? It would
also be good to know if you have any numbers calculated based on practice.

Thanks in advance.

Kind regards,
Daniel

[1] https://trueconf.com/support/communication-channels.html


#2

Hi again!

Investigating the bandwidth required based on the number of participants
in a conference, I found the table for WebRTC at the bottom of this [1]
document.

Do you believe that these values will also apply to Jitsi Meet? It would
also be good to know if you have any numbers calculated based on practice.

[1] https://trueconf.com/support/communication-channels.html

I was doing some bandwidth consumption tests in a conference with two
participants. Attached is the graph obtained. Is it expected that for
more participants consumption is directly proportional or depends on
other variables such as the camera capture resolution of each device
involved in the conference?

In this case I was using a notebook and the other person was using an
Android phone. The conference included audio and video from both sides.

Thanks in advance.

Kind regards,
Daniel

···

On 30/12/16 14:36, Daniel Bareiro wrote:


#3

Hi Daniel,

Hi again!

Investigating the bandwidth required based on the number of participants
in a conference, I found the table for WebRTC at the bottom of this [1]
document.

Do you believe that these values will also apply to Jitsi Meet? It would
also be good to know if you have any numbers calculated based on practice.

[1] https://trueconf.com/support/communication-channels.html

I was doing some bandwidth consumption tests in a conference with two
participants. Attached is the graph obtained. Is it expected that for
more participants consumption is directly proportional or depends on
other variables such as the camera capture resolution of each device
involved in the conference?

The actual bandwidth usage will depend on the available bandwidth between the senders and the bridge, as well as the resolution used, and whether simulcast is enabled or not.

With simulcast, it will not scale linearly. For 720p with simulcast and N participants, in perfect network conditions, the usage will be something like 3.15Mbps outgoing, (2.5 + N * 0.15) Mbps incoming.

Regards,
Boris

···

On 02/01/2017 09:34, Daniel Bareiro wrote:

On 30/12/16 14:36, Daniel Bareiro wrote:


#4

Hi Daniel,

Hi, Boris.

Investigating the bandwidth required based on the number of participants
in a conference, I found the table for WebRTC at the bottom of this [1]
document.

Do you believe that these values will also apply to Jitsi Meet? It would
also be good to know if you have any numbers calculated based on
practice.

[1] https://trueconf.com/support/communication-channels.html

I was doing some bandwidth consumption tests in a conference with two
participants. Attached is the graph obtained. Is it expected that for
more participants consumption is directly proportional or depends on
other variables such as the camera capture resolution of each device
involved in the conference?

The actual bandwidth usage will depend on the available bandwidth
between the senders and the bridge, as well as the resolution used, and
whether simulcast is enabled or not.

When you talk about "the resolution used", do you mean to the resolution
of the camera, right?

As for the "bandwidth available between the senders and the bridge", do
you mean the bandwidth of the server or the bandwidth of the Internet
connection of each of the participants?

At this point, a few days ago I was doing a test with another person and
in the statistics of Jitsi Meet I saw that the resolution used for me
and for the other part was (I think) 640x480. This seemed to me very
little. Also I note that eventually Jitsi Meet showed a message saying
that the other person had problems with their connection and the image
remained momentarily frozen and gray. Could it be that because of this
Jitsi Meet has decremented the resolution of both parts to 640x480?

With simulcast, it will not scale linearly. For 720p with simulcast and
N participants, in perfect network conditions, the usage will be
something like 3.15Mbps outgoing, (2.5 + N * 0.15) Mbps incoming.

I'm not sure if simulcast is now enabled. What parameter setting should
I check? Currently I'm doing tests with the standard installation,
without making big changes (I just added
org.jitsi.videobridge.NAT_HARVESTER_LOCAL_ADDRESS and
org.jitsi.videobridge.NAT_HARVESTER_PUBLIC_ADDRESS in
/etc/jitsi/videobridgesip-communicator.properties).

For optimum use of bandwidth without losing image and video quality, do
you recommend using simulcast?

Thanks for your reply.

Kind regards,
Daniel

···

On 02/01/17 15:32, Boris Grozev wrote:


#5

Hi,

Hi Daniel,

Hi, Boris.

Investigating the bandwidth required based on the number of participants
in a conference, I found the table for WebRTC at the bottom of this [1]
document.

Do you believe that these values will also apply to Jitsi Meet? It would
also be good to know if you have any numbers calculated based on
practice.

[1] https://trueconf.com/support/communication-channels.html

I was doing some bandwidth consumption tests in a conference with two
participants. Attached is the graph obtained. Is it expected that for
more participants consumption is directly proportional or depends on
other variables such as the camera capture resolution of each device
involved in the conference?

The actual bandwidth usage will depend on the available bandwidth
between the senders and the bridge, as well as the resolution used, and
whether simulcast is enabled or not.

When you talk about "the resolution used", do you mean to the resolution
of the camera, right?

Yes, kind of. The resolution that the browser gets from the camera. It could be that your camera supports 1080p, but jitsi-meet is configured to only use 720p (see config.resolution).

As for the "bandwidth available between the senders and the bridge", do
you mean the bandwidth of the server or the bandwidth of the Internet
connection of each of the participants?

The available bandwidth between the sending client and the server. This is calculated dynamically, and the sending bitrate (and as a result quality, and resolution) is adjusted accordingly.

At this point, a few days ago I was doing a test with another person and
in the statistics of Jitsi Meet I saw that the resolution used for me
and for the other part was (I think) 640x480. This seemed to me very
little. Also I note that eventually Jitsi Meet showed a message saying
that the other person had problems with their connection and the image
remained momentarily frozen and gray. Could it be that because of this
Jitsi Meet has decremented the resolution of both parts to 640x480?

Yes, that's a possibility. It could also be that 640x480 was obtained from the camera.

With simulcast, it will not scale linearly. For 720p with simulcast and
N participants, in perfect network conditions, the usage will be
something like 3.15Mbps outgoing, (2.5 + N * 0.15) Mbps incoming.

I'm not sure if simulcast is now enabled. What parameter setting should
I check? Currently I'm doing tests with the standard installation,
without making big changes (I just added
org.jitsi.videobridge.NAT_HARVESTER_LOCAL_ADDRESS and
org.jitsi.videobridge.NAT_HARVESTER_PUBLIC_ADDRESS in
/etc/jitsi/videobridgesip-communicator.properties).

Simulcast is enabled by default, but you can verify that it is used like this: in a conference of two check the remote party's resolution while they are shown on-stage, it should be 720p or similar. Then click your local video, you will be shown on-stage. Check the remote party resolution again, it should be 180p.

Note that simulcast is currently not supported on firefox.

For optimum use of bandwidth without losing image and video quality, do
you recommend using simulcast?

Yes, definitely.

Regards,
Boris

···

On 04/01/2017 08:56, Daniel Bareiro wrote:

On 02/01/17 15:32, Boris Grozev wrote:


#6

Hi,

Hi, Boris.

I was doing some bandwidth consumption tests in a conference with two
participants. Attached is the graph obtained. Is it expected that for
more participants consumption is directly proportional or depends on
other variables such as the camera capture resolution of each device
involved in the conference?

The actual bandwidth usage will depend on the available bandwidth
between the senders and the bridge, as well as the resolution used, and
whether simulcast is enabled or not.

When you talk about "the resolution used", do you mean to the resolution
of the camera, right?

Yes, kind of. The resolution that the browser gets from the camera. It
could be that your camera supports 1080p, but jitsi-meet is configured
to only use 720p (see config.resolution).

I see. I did not find any files with that name (config.resolution). I
also did not find any option with that name:

···

On 04/01/17 12:27, Boris Grozev wrote:

--------------------------------------------------------------------------
root@conference:/etc/jitsi/videobridge# ll
total 20
-rw-r--r-- 1 root root 183 dic 20 19:21 callstats-java-sdk.properties
-rw-r--r-- 1 root root 800 ene 2 13:16 config
-rw-r--r-- 1 root root 1068 dic 20 19:21 log4j2.xml
-rw-r--r-- 1 root root 997 dic 20 19:21 logging.properties
-rw-r--r-- 1 root root 125 ene 4 18:16 sip-communicator.properties

root@conference:/etc/jitsi/videobridge# grep resolution *
root@conference:/etc/jitsi/videobridge#
--------------------------------------------------------------------------
root@conference:/etc/jitsi/meet# ll
total 16
-rw-r--r-- 1 root root 4393 ene 4 18:16 conf.opcion-libre.com.ar-config.js
-rw-r--r-- 1 root root 2086 ene 2 13:17 conf.opcion-libre.com.ar.crt
-rw-r--r-- 1 root root 3272 ene 2 13:17 conf.opcion-libre.com.ar.key

root@conference:/etc/jitsi/meet# grep resolution
conf.opcion-libre.com.ar-config.js
root@conference:/etc/jitsi/meet#
--------------------------------------------------------------------------

As for the "bandwidth available between the senders and the bridge", do
you mean the bandwidth of the server or the bandwidth of the Internet
connection of each of the participants?

The available bandwidth between the sending client and the server. This
is calculated dynamically, and the sending bitrate (and as a result
quality, and resolution) is adjusted accordingly.

In the statistics shown by Jitsi for each participant I see:

* Bitrate.
* Packet loss.
* Resolution.
* Estimated Bandwidth.

What I am not clear is what is the difference between "bitrate" and
"Estimated Bandwidth". At first it seems the same, although I suppose
that each one would have a different point of view.

On the other hand, here "Resolution" is the one that the browser gets
from the camera? There is also other question related to it that I
mention in the following paragraph.

At this point, a few days ago I was doing a test with another person and
in the statistics of Jitsi Meet I saw that the resolution used for me
and for the other part was (I think) 640x480. This seemed to me very
little. Also I note that eventually Jitsi Meet showed a message saying
that the other person had problems with their connection and the image
remained momentarily frozen and gray. Could it be that because of this
Jitsi Meet has decremented the resolution of both parts to 640x480?

Yes, that's a possibility. It could also be that 640x480 was obtained
from the camera.

What caught my attention is that we both had the same value of
resolution, 640x480. Jitsi Videobridge delivers the same resolution to
all conference participants? In other words, Jitsi Videobridge adjusts
the resolution to the most optimum based on the network conditions of
that participant where these are the worst?

With simulcast, it will not scale linearly. For 720p with simulcast and
N participants, in perfect network conditions, the usage will be
something like 3.15Mbps outgoing, (2.5 + N * 0.15) Mbps incoming.

I'm not sure if simulcast is now enabled. What parameter setting should
I check? Currently I'm doing tests with the standard installation,
without making big changes (I just added
org.jitsi.videobridge.NAT_HARVESTER_LOCAL_ADDRESS and
org.jitsi.videobridge.NAT_HARVESTER_PUBLIC_ADDRESS in
/etc/jitsi/videobridgesip-communicator.properties).

Simulcast is enabled by default, but you can verify that it is used like
this: in a conference of two check the remote party's resolution while
they are shown on-stage, it should be 720p or similar. Then click your
local video, you will be shown on-stage. Check the remote party
resolution again, it should be 180p.

Note that simulcast is currently not supported on firefox.

In the test I mentioned I was using Firefox 45.6.0 ESR on Debian Jessie.
Then maybe I should try Chromium. The inability to use Firefox with
simulcast is because it does not yet support certain features of the
WebRTC? Do you know if this happens with any other browser?

For optimum use of bandwidth without losing image and video quality, do
you recommend using simulcast?

I am sorry. When I said "without losing image and video quality" I meant
"without losing sound and video quality"

Yes, definitely.

Thanks for confirm. I was reading in the introduction to this document
what is the idea behind simulcast:

https://github.com/jitsi/jitsi-videobridge/blob/master/doc/simulcast.md

If I understood this example correctly, the "sender" is a specific
participant in a four-member conference. Is it so?

Thanks for your reply and your time.

Kind regards,
Daniel


#7

Hi Daniel,

Hi,

Hi, Boris.

I was doing some bandwidth consumption tests in a conference with two
participants. Attached is the graph obtained. Is it expected that for
more participants consumption is directly proportional or depends on
other variables such as the camera capture resolution of each device
involved in the conference?

The actual bandwidth usage will depend on the available bandwidth
between the senders and the bridge, as well as the resolution used, and
whether simulcast is enabled or not.

When you talk about "the resolution used", do you mean to the resolution
of the camera, right?

Yes, kind of. The resolution that the browser gets from the camera. It
could be that your camera supports 1080p, but jitsi-meet is configured
to only use 720p (see config.resolution).

I see. I did not find any files with that name (config.resolution). I
also did not find any option with that name:

Sorry, it was a hasty reply and not very clear. I meant the "config.resolution" property in the java script code. You can usually set it in /etc/jitsi/meet/domain.config.js (or something similar). See e.g. https://meet.jit.si/config.js

--------------------------------------------------------------------------
root@conference:/etc/jitsi/videobridge# ll
total 20
-rw-r--r-- 1 root root 183 dic 20 19:21 callstats-java-sdk.properties
-rw-r--r-- 1 root root 800 ene 2 13:16 config
-rw-r--r-- 1 root root 1068 dic 20 19:21 log4j2.xml
-rw-r--r-- 1 root root 997 dic 20 19:21 logging.properties
-rw-r--r-- 1 root root 125 ene 4 18:16 sip-communicator.properties

root@conference:/etc/jitsi/videobridge# grep resolution *
root@conference:/etc/jitsi/videobridge#
--------------------------------------------------------------------------
root@conference:/etc/jitsi/meet# ll
total 16
-rw-r--r-- 1 root root 4393 ene 4 18:16 conf.opcion-libre.com.ar-config.js
-rw-r--r-- 1 root root 2086 ene 2 13:17 conf.opcion-libre.com.ar.crt
-rw-r--r-- 1 root root 3272 ene 2 13:17 conf.opcion-libre.com.ar.key

root@conference:/etc/jitsi/meet# grep resolution
conf.opcion-libre.com.ar-config.js
root@conference:/etc/jitsi/meet#
--------------------------------------------------------------------------

As for the "bandwidth available between the senders and the bridge", do
you mean the bandwidth of the server or the bandwidth of the Internet
connection of each of the participants?

The bandwidth of the path between the sender and the bridge -- whatever that happens to be.

The available bandwidth between the sending client and the server. This
is calculated dynamically, and the sending bitrate (and as a result
quality, and resolution) is adjusted accordingly.

In the statistics shown by Jitsi for each participant I see:

* Bitrate.
* Packet loss.
* Resolution.
* Estimated Bandwidth.

What I am not clear is what is the difference between "bitrate" and
"Estimated Bandwidth". At first it seems the same, although I suppose
that each one would have a different point of view.

The bitrate is just how much data it being sent or received. The "estimated bandwidth" is an estimation of how much we could send/receive to that endpoint.

On the other hand, here "Resolution" is the one that the browser gets
from the camera? There is also other question related to it that I
mention in the following paragraph.

For the local video this is the highest resolution that you are sending (highest, because with simulcast you may be sending more than one). It could be the resolution of the camera, or something lower.

For remote videos, this is the resolution that you are receiving.

At this point, a few days ago I was doing a test with another person and
in the statistics of Jitsi Meet I saw that the resolution used for me
and for the other part was (I think) 640x480. This seemed to me very
little. Also I note that eventually Jitsi Meet showed a message saying
that the other person had problems with their connection and the image
remained momentarily frozen and gray. Could it be that because of this
Jitsi Meet has decremented the resolution of both parts to 640x480?

Yes, that's a possibility. It could also be that 640x480 was obtained
from the camera.

What caught my attention is that we both had the same value of
resolution, 640x480. Jitsi Videobridge delivers the same resolution to
all conference participants? In other words, Jitsi Videobridge adjusts
the resolution to the most optimum based on the network conditions of
that participant where these are the worst?

Currently jitsi-videobridge sends the highest available resolution for the "selected" endpoint (the participant shown in full screen), and the lowest available resolution for everyone else. This is per-receiver, so you could be receiving high res for X, while someone else receives low res for X.

With simulcast, it will not scale linearly. For 720p with simulcast and
N participants, in perfect network conditions, the usage will be
something like 3.15Mbps outgoing, (2.5 + N * 0.15) Mbps incoming.

I'm not sure if simulcast is now enabled. What parameter setting should
I check? Currently I'm doing tests with the standard installation,
without making big changes (I just added
org.jitsi.videobridge.NAT_HARVESTER_LOCAL_ADDRESS and
org.jitsi.videobridge.NAT_HARVESTER_PUBLIC_ADDRESS in
/etc/jitsi/videobridgesip-communicator.properties).

Simulcast is enabled by default, but you can verify that it is used like
this: in a conference of two check the remote party's resolution while
they are shown on-stage, it should be 720p or similar. Then click your
local video, you will be shown on-stage. Check the remote party
resolution again, it should be 180p.

Note that simulcast is currently not supported on firefox.

In the test I mentioned I was using Firefox 45.6.0 ESR on Debian Jessie.
Then maybe I should try Chromium. The inability to use Firefox with
simulcast is because it does not yet support certain features of the
WebRTC? Do you know if this happens with any other browser?

We support simulcast only in Chrome and Chromium (we treat it the same way as Chrome). I don't know what the current state of simulcast support in firefox is in general.

For optimum use of bandwidth without losing image and video quality, do
you recommend using simulcast?

I am sorry. When I said "without losing image and video quality" I meant
"without losing sound and video quality"

Same answer, simulcast is definitely an improvement :slight_smile:

Yes, definitely.

Thanks for confirm. I was reading in the introduction to this document
what is the idea behind simulcast:

https://github.com/jitsi/jitsi-videobridge/blob/master/doc/simulcast.md

If I understood this example correctly, the "sender" is a specific
participant in a four-member conference. Is it so?

Yes. This document is quite low-level and full of technical details. This video may be more useful as an introduction, if this is what you are looking for (I can't find anything similar in a text document):
https://www.youtube.com/watch?v=cmzERa0bk0Y

Regards,
Boris

···

On 04/01/2017 18:18, Daniel Bareiro wrote:

On 04/01/17 12:27, Boris Grozev wrote:

Thanks for your reply and your time.

Kind regards,
Daniel

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev


#8

Hi Daniel,

Hi, Boris.

The actual bandwidth usage will depend on the available bandwidth
between the senders and the bridge, as well as the resolution used,
and whether simulcast is enabled or not.

When you talk about "the resolution used", do you mean to the
resolution of the camera, right?

Yes, kind of. The resolution that the browser gets from the camera. It
could be that your camera supports 1080p, but jitsi-meet is configured
to only use 720p (see config.resolution).

I see. I did not find any files with that name (config.resolution). I
also did not find any option with that name:

Sorry, it was a hasty reply and not very clear. I meant the
"config.resolution" property in the java script code. You can usually
set it in /etc/jitsi/meet/domain.config.js (or something similar). See
e.g. https://meet.jit.si/config.js

Ah, perfect. Thanks for the clarification. I do not see that property in
my config.js file. In this case a default resolution is used?

As for the "bandwidth available between the senders and the bridge", do
you mean the bandwidth of the server or the bandwidth of the Internet
connection of each of the participants?

The bandwidth of the path between the sender and the bridge -- whatever
that happens to be.

Good.

The available bandwidth between the sending client and the server. This
is calculated dynamically, and the sending bitrate (and as a result
quality, and resolution) is adjusted accordingly.

In the statistics shown by Jitsi for each participant I see:

* Bitrate.
* Packet loss.
* Resolution.
* Estimated Bandwidth.

What I am not clear is what is the difference between "bitrate" and
"Estimated Bandwidth". At first it seems the same, although I suppose
that each one would have a different point of view.

The bitrate is just how much data it being sent or received. The
"estimated bandwidth" is an estimation of how much we could send/receive
to that endpoint.

Mmmmmmm... This is an estimate of what could be sent/received under ideal
conditions because there are no bottlenecks for example on the client side?

On the other hand, here "Resolution" is the one that the browser gets
from the camera? There is also other question related to it that I
mention in the following paragraph.

For the local video this is the highest resolution that you are sending
(highest, because with simulcast you may be sending more than one). It
could be the resolution of the camera, or something lower.

For remote videos, this is the resolution that you are receiving.

Thanks for the explanation.

At this point, a few days ago I was doing a test with another person
and in the statistics of Jitsi Meet I saw that the resolution used for me
and for the other part was (I think) 640x480. This seemed to me very
little. Also I note that eventually Jitsi Meet showed a message saying
that the other person had problems with their connection and the image
remained momentarily frozen and gray. Could it be that because of this
Jitsi Meet has decremented the resolution of both parts to 640x480?

Yes, that's a possibility. It could also be that 640x480 was obtained
from the camera.

What caught my attention is that we both had the same value of
resolution, 640x480. Jitsi Videobridge delivers the same resolution to
all conference participants? In other words, Jitsi Videobridge adjusts
the resolution to the most optimum based on the network conditions of
that participant where these are the worst?

Currently jitsi-videobridge sends the highest available resolution for
the "selected" endpoint (the participant shown in full screen), and the
lowest available resolution for everyone else. This is per-receiver, so
you could be receiving high res for X, while someone else receives low
res for X.

Perfect. I think what I said before was wrong. The resolution shown by
Jitsi Meet for both parties was 640x360 (a somewhat strange resolution).
Yesterday I did another test and this same resolution was used for both
parties. We were both using Chrome/Chromium.

So in the case mentioned, this means that the selected person was shown
in a resolution of 640x360 and the resolution that I am sending to that
person was 640x360?

I was checking with Guvcview for the resolutions available for the
camera on my notebook. These were:

640x480
640x360
352x288
320x240
800x448
960x540
1280x720

With simulcast, it will not scale linearly. For 720p with simulcast
and N participants, in perfect network conditions, the usage will be
something like 3.15Mbps outgoing, (2.5 + N * 0.15) Mbps incoming.

I'm not sure if simulcast is now enabled. What parameter setting should
I check? Currently I'm doing tests with the standard installation,
without making big changes (I just added
org.jitsi.videobridge.NAT_HARVESTER_LOCAL_ADDRESS and
org.jitsi.videobridge.NAT_HARVESTER_PUBLIC_ADDRESS in
/etc/jitsi/videobridgesip-communicator.properties).

Simulcast is enabled by default, but you can verify that it is used like
this: in a conference of two check the remote party's resolution while
they are shown on-stage, it should be 720p or similar. Then click your
local video, you will be shown on-stage. Check the remote party
resolution again, it should be 180p.

Note that simulcast is currently not supported on firefox.

In the test I mentioned I was using Firefox 45.6.0 ESR on Debian Jessie.
Then maybe I should try Chromium. The inability to use Firefox with
simulcast is because it does not yet support certain features of the
WebRTC? Do you know if this happens with any other browser?

We support simulcast only in Chrome and Chromium (we treat it the same
way as Chrome). I don't know what the current state of simulcast support
in firefox is in general.

Thanks for confirm.

For optimum use of bandwidth without losing image and video quality, do
you recommend using simulcast?

I am sorry. When I said "without losing image and video quality" I meant
"without losing sound and video quality"

Same answer, simulcast is definitely an improvement :slight_smile:

Perfect :slight_smile:

I was reading in the introduction to this document what is the idea
behind simulcast:

https://github.com/jitsi/jitsi-videobridge/blob/master/doc/simulcast.md

If I understood this example correctly, the "sender" is a specific
participant in a four-member conference. Is it so?

Yes. This document is quite low-level and full of technical details.
This video may be more useful as an introduction, if this is what you
are looking for (I can't find anything similar in a text document):
https://www.youtube.com/watch?v=cmzERa0bk0Y

Interesting. Thanks for sharing this video.

In relation to this bandwidth topic, do you know if there is any tool
that can interact with Jitsi Videobridge to determine the open rooms and
the number of people who are participating in each room?

Thanks for your reply and your time.

Kind regards,
Daniel

P.S.: If you know of any way to restrict users that can connect to a
conference, as I consulted in the other email, I would appreciate any
comments :slight_smile:

···

On 05/01/17 12:27, Boris Grozev wrote:


#9

Hi Daniel,

[snip]

Ah, perfect. Thanks for the clarification. I do not see that property in
my config.js file. In this case a default resolution is used?

Yes, I think it defaults to 720p.

[snip]

The bitrate is just how much data it being sent or received. The
"estimated bandwidth" is an estimation of how much we could send/receive
to that endpoint.

Mmmmmmm... This is an estimate of what could be sent/received under ideal
conditions because there are no bottlenecks for example on the client side?

No, it's an estimate of what could be sent under the current conditions, taking into account bottlenecks along the way.

[snip]

Currently jitsi-videobridge sends the highest available resolution for
the "selected" endpoint (the participant shown in full screen), and the
lowest available resolution for everyone else. This is per-receiver, so
you could be receiving high res for X, while someone else receives low
res for X.

Perfect. I think what I said before was wrong. The resolution shown by
Jitsi Meet for both parties was 640x360 (a somewhat strange resolution).
Yesterday I did another test and this same resolution was used for both
parties. We were both using Chrome/Chromium.

So in the case mentioned, this means that the selected person was shown
in a resolution of 640x360 and the resolution that I am sending to that
person was 640x360?

You are probably sending 640x360 and also 320x180. This could be because of the bandwidth estimation, or because of the camera. You are shown in full-screen on the receiver's end (if I understand correctly), so the bridge forwards the highest higher of the available resolutions, i.e. 640x360.

[snip]

Yes. This document is quite low-level and full of technical details.
This video may be more useful as an introduction, if this is what you
are looking for (I can't find anything similar in a text document):
https://www.youtube.com/watch?v=cmzERa0bk0Y

Interesting. Thanks for sharing this video.

In relation to this bandwidth topic, do you know if there is any tool
that can interact with Jitsi Videobridge to determine the open rooms and
the number of people who are participating in each room?

I don't know of a way to get a list live, but you can get some useful statistics from the bridge. See here:
https://github.com/jitsi/jitsi-videobridge/blob/master/doc/statistics.md

For example, for load-balancing in jicofo we use the "videostreams", which is an estimate for the number of video streams that the bridge forwards for all of its conferences (taking into account conference size as much as possible).

Thanks for your reply and your time.

You are welcome. And thank you for your interest in the project.

Kind regards,
Daniel

P.S.: If you know of any way to restrict users that can connect to a
conference, as I consulted in the other email, I would appreciate any
comments :slight_smile:

One option is to manually lock a specific room. This way people joining will need a password specific for that room. You can lock it by clicking the "share the link" button in the menu on top, and then adding a password.

If this doesn't work for you, there are ways to require authentication from the XMPP server. But I'm afraid I don't know much of the details there, so someone else will have to chime in, if you have any questions about it.

Regards,
Boris

···

On 10/01/2017 13:34, Daniel Bareiro wrote:


#10

Hi, Boris.

[snip]

Ah, perfect. Thanks for the clarification. I do not see that property in
my config.js file. In this case a default resolution is used?

Yes, I think it defaults to 720p.

Thanks for the information.

[snip]

The bitrate is just how much data it being sent or received. The
"estimated bandwidth" is an estimation of how much we could send/receive
to that endpoint.

Mmmmmmm... This is an estimate of what could be sent/received under ideal
conditions because there are no bottlenecks for example on the client
side?

No, it's an estimate of what could be sent under the current conditions,
taking into account bottlenecks along the way.

Thanks. I will check these values in the next tests that I will do.

[snip]

Currently jitsi-videobridge sends the highest available resolution for
the "selected" endpoint (the participant shown in full screen), and the
lowest available resolution for everyone else. This is per-receiver, so
you could be receiving high res for X, while someone else receives low
res for X.

Perfect. I think what I said before was wrong. The resolution shown by
Jitsi Meet for both parties was 640x360 (a somewhat strange resolution).
Yesterday I did another test and this same resolution was used for both
parties. We were both using Chrome/Chromium.

So in the case mentioned, this means that the selected person was shown
in a resolution of 640x360 and the resolution that I am sending to that
person was 640x360?

You are probably sending 640x360 and also 320x180. This could be because
of the bandwidth estimation, or because of the camera. You are shown in
full-screen on the receiver's end (if I understand correctly), so the
bridge forwards the highest higher of the available resolutions, i.e.
640x360.

For what I was watching with guvcview, the lowest resolution of my camera
is 320x240 (did you mean to that?) and the highest is 1280x720.

If 720p (1280x720) is the default resolution when config.resolution is
not used, I would have to see why I would be sending such a low resolution.

[snip]

Yes. This document is quite low-level and full of technical details.
This video may be more useful as an introduction, if this is what you
are looking for (I can't find anything similar in a text document):
https://www.youtube.com/watch?v=cmzERa0bk0Y

Interesting. Thanks for sharing this video.

In relation to this bandwidth topic, do you know if there is any tool
that can interact with Jitsi Videobridge to determine the open rooms and
the number of people who are participating in each room?

I don't know of a way to get a list live, but you can get some useful
statistics from the bridge. See here:
https://github.com/jitsi/jitsi-videobridge/blob/master/doc/statistics.md

For example, for load-balancing in jicofo we use the "videostreams",
which is an estimate for the number of video streams that the bridge
forwards for all of its conferences (taking into account conference size
as much as possible).

Very interesting. Thank you for sharing this document. From what I can
see, among the statistics we have:

* conferences - The current number of conferences.
* participants - The current number of participants.

But these seem to be general values, or is there some way to know the
number of participants in each conference?

Thanks for your reply and your time.

You are welcome. And thank you for your interest in the project.

It is a very interesting project. Now I am trying to adapt some aspects.
Do you know if there is a way to disable the thumb-up button? This
button works in meet.jit.si, but it has no effect on the installation
made from Debian packages. And I would like to keep the interface as
clear as possible with only what users see useful.

P.S.: If you know of any way to restrict users that can connect to a
conference, as I consulted in the other email, I would appreciate any
comments :slight_smile:

One option is to manually lock a specific room. This way people joining
will need a password specific for that room. You can lock it by clicking
the "share the link" button in the menu on top, and then adding a password.

If this doesn't work for you, there are ways to require authentication
from the XMPP server. But I'm afraid I don't know much of the details
there, so someone else will have to chime in, if you have any questions
about it.

Yes. Thanks for the tip. I was referring to using authentication. I was
testing that by configuring Prosody + Jicofo. In this scenario I found
this behavior:

If all conferences are always started by the same organizer, there is no
problem. But suppose that conference A has a single organizer that is
A', and conference B has a single organizer that is B'. If B' wants to
be a participant in conference A, after B' joins to this conference, it
will show two organizers (A' and B') when only one organizer is
expected: A'. This would be a side effect of Chrome/Chromium (and
Firefox) when automatically cached the B' credentials.

It seems that this side effect is due to a cookie that Jitsi Meet saves
on localStorage. Is there any way to remove that cookie automatically
after end each conference to avoid this effect?

Thanks for your reply and your time.

Kind regards,
Daniel

···

On 10/01/17 17:19, Boris Grozev wrote:


#11

Hi Daniel,

···

On 25/01/2017 12:46, Daniel Bareiro wrote:

Hi, Boris.

On 10/01/17 17:19, Boris Grozev wrote:

[snip]

Ah, perfect. Thanks for the clarification. I do not see that property in
my config.js file. In this case a default resolution is used?

Yes, I think it defaults to 720p.

Thanks for the information.

[snip]

The bitrate is just how much data it being sent or received. The
"estimated bandwidth" is an estimation of how much we could send/receive
to that endpoint.

Mmmmmmm... This is an estimate of what could be sent/received under ideal
conditions because there are no bottlenecks for example on the client
side?

No, it's an estimate of what could be sent under the current conditions,
taking into account bottlenecks along the way.

Thanks. I will check these values in the next tests that I will do.

[snip]

Currently jitsi-videobridge sends the highest available resolution for
the "selected" endpoint (the participant shown in full screen), and the
lowest available resolution for everyone else. This is per-receiver, so
you could be receiving high res for X, while someone else receives low
res for X.

Perfect. I think what I said before was wrong. The resolution shown by
Jitsi Meet for both parties was 640x360 (a somewhat strange resolution).
Yesterday I did another test and this same resolution was used for both
parties. We were both using Chrome/Chromium.

So in the case mentioned, this means that the selected person was shown
in a resolution of 640x360 and the resolution that I am sending to that
person was 640x360?

You are probably sending 640x360 and also 320x180. This could be because
of the bandwidth estimation, or because of the camera. You are shown in
full-screen on the receiver's end (if I understand correctly), so the
bridge forwards the highest higher of the available resolutions, i.e.
640x360.

For what I was watching with guvcview, the lowest resolution of my camera
is 320x240 (did you mean to that?) and the highest is 1280x720.

If 720p (1280x720) is the default resolution when config.resolution is
not used, I would have to see why I would be sending such a low resolution.

[snip]

Yes. This document is quite low-level and full of technical details.
This video may be more useful as an introduction, if this is what you
are looking for (I can't find anything similar in a text document):
https://www.youtube.com/watch?v=cmzERa0bk0Y

Interesting. Thanks for sharing this video.

In relation to this bandwidth topic, do you know if there is any tool
that can interact with Jitsi Videobridge to determine the open rooms and
the number of people who are participating in each room?

I don't know of a way to get a list live, but you can get some useful
statistics from the bridge. See here:
https://github.com/jitsi/jitsi-videobridge/blob/master/doc/statistics.md

For example, for load-balancing in jicofo we use the "videostreams",
which is an estimate for the number of video streams that the bridge
forwards for all of its conferences (taking into account conference size
as much as possible).

Very interesting. Thank you for sharing this document. From what I can
see, among the statistics we have:

* conferences - The current number of conferences.
* participants - The current number of participants.

But these seem to be general values, or is there some way to know the
number of participants in each conference?

Not unless you do a get request for each conference. There is "conference_sizes" which will give you an array which has the current number of conferences with size 0, and the current number of conferences with size 1, etc.

Regards,
Boris


#12

Hi Daniel,

Hi, Boris.

Yes. This document is quite low-level and full of technical details.
This video may be more useful as an introduction, if this is what you
are looking for (I can't find anything similar in a text document):
https://www.youtube.com/watch?v=cmzERa0bk0Y

Interesting. Thanks for sharing this video.

In relation to this bandwidth topic, do you know if there is any tool
that can interact with Jitsi Videobridge to determine the open rooms
and
the number of people who are participating in each room?

I don't know of a way to get a list live, but you can get some useful
statistics from the bridge. See here:
https://github.com/jitsi/jitsi-videobridge/blob/master/doc/statistics.md

For example, for load-balancing in jicofo we use the "videostreams",
which is an estimate for the number of video streams that the bridge
forwards for all of its conferences (taking into account conference size
as much as possible).

Very interesting. Thank you for sharing this document. From what I can
see, among the statistics we have:

* conferences - The current number of conferences.
* participants - The current number of participants.

But these seem to be general values, or is there some way to know the
number of participants in each conference?

Not unless you do a get request for each conference. There is
"conference_sizes" which will give you an array which has the current
number of conferences with size 0, and the current number of conferences
with size 1, etc.

Thanks for the observation. I was reading the document you mentioned
about Jitsi Videobridge and the possibility of integrating these
statistics with callstats.io. I have registered an account as a
developer to do some testing.

I have made these changes:

···

On 25/01/17 18:07, Boris Grozev wrote:

----------------------------------------------------------------------------
/etc/jitsi/meet/domain-config.js:

callStatsID:"<AppID in the "My App" window>",
callStatsSecret:"<shared secret on "Application credentials">",
----------------------------------------------------------------------------
/etc/jitsi/videobridge/sip-communicator.properties:

org.jitsi.videobridge.ENABLE_STATISTICS=true
org.jitsi.videobridge.STATISTICS_TRANSPORT=callstats.io
org.jitsi.videobridge.STATISTICS_INTERVAL.callstats.io=30000
io.callstats.sdk.CallStats.appId=<AppID in the "My App" window>
io.callstats.sdk.CallStats.appSecret=<shared secret on "Application
credentials">
io.callstats.sdk.CallStats.bridgeId=<empty - I'm not sure what I should
put here>
----------------------------------------------------------------------------

Note: "<" and ">" are not in the original configuration. I just put them
here to indicate how I have replaced the values of these properties.

But it is not working. Maybe I'm forgetting something? In jvb.log I'm
seeing something like this:

----------------------------------------------------------------------------
JVB 2017-01-30 21:34:49.268 WARNING: [10]
org.jitsi.videobridge.stats.CallStatsIOTransport.init().268
KeyID/keyPath missing, will try using appSecret
----------------------------------------------------------------------------

Thanks in advance.

Kind regards,
Daniel


#13

Hi,

In callstats you need to create new credentials with endpoint type of
Middlebox and use those for jvb.

Regards
damencho

···

On Tue, Jan 31, 2017 at 1:53 PM, Daniel Bareiro <daniel-listas@gmx.net> wrote:

On 25/01/17 18:07, Boris Grozev wrote:

Hi Daniel,

Hi, Boris.

Yes. This document is quite low-level and full of technical details.
This video may be more useful as an introduction, if this is what you
are looking for (I can't find anything similar in a text document):
https://www.youtube.com/watch?v=cmzERa0bk0Y

Interesting. Thanks for sharing this video.

In relation to this bandwidth topic, do you know if there is any tool
that can interact with Jitsi Videobridge to determine the open rooms
and
the number of people who are participating in each room?

I don't know of a way to get a list live, but you can get some useful
statistics from the bridge. See here:
https://github.com/jitsi/jitsi-videobridge/blob/master/doc/statistics.md

For example, for load-balancing in jicofo we use the "videostreams",
which is an estimate for the number of video streams that the bridge
forwards for all of its conferences (taking into account conference size
as much as possible).

Very interesting. Thank you for sharing this document. From what I can
see, among the statistics we have:

* conferences - The current number of conferences.
* participants - The current number of participants.

But these seem to be general values, or is there some way to know the
number of participants in each conference?

Not unless you do a get request for each conference. There is
"conference_sizes" which will give you an array which has the current
number of conferences with size 0, and the current number of conferences
with size 1, etc.

Thanks for the observation. I was reading the document you mentioned
about Jitsi Videobridge and the possibility of integrating these
statistics with callstats.io. I have registered an account as a
developer to do some testing.

I have made these changes:

----------------------------------------------------------------------------
/etc/jitsi/meet/domain-config.js:

callStatsID:"<AppID in the "My App" window>",
callStatsSecret:"<shared secret on "Application credentials">",
----------------------------------------------------------------------------
/etc/jitsi/videobridge/sip-communicator.properties:

org.jitsi.videobridge.ENABLE_STATISTICS=true
org.jitsi.videobridge.STATISTICS_TRANSPORT=callstats.io
org.jitsi.videobridge.STATISTICS_INTERVAL.callstats.io=30000
io.callstats.sdk.CallStats.appId=<AppID in the "My App" window>
io.callstats.sdk.CallStats.appSecret=<shared secret on "Application
credentials">
io.callstats.sdk.CallStats.bridgeId=<empty - I'm not sure what I should
put here>
----------------------------------------------------------------------------

Note: "<" and ">" are not in the original configuration. I just put them
here to indicate how I have replaced the values of these properties.

But it is not working. Maybe I'm forgetting something? In jvb.log I'm
seeing something like this:

----------------------------------------------------------------------------
JVB 2017-01-30 21:34:49.268 WARNING: [10]
org.jitsi.videobridge.stats.CallStatsIOTransport.init().268
KeyID/keyPath missing, will try using appSecret
----------------------------------------------------------------------------

Thanks in advance.

Kind regards,
Daniel

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev


#14

Hi,

Hi, Damian.

In callstats you need to create new credentials with endpoint type of
Middlebox and use those for jvb.

I'm not sure where in the callstats I should create this type of
credentials.

What I did was create an application in "My App". Then go back to "My
App" and go to "Settings". Here I enter on the "Security" tab. Here I go
to "New credentials" to create a new "Shared secret" credential. The
other available type is "ECDSA public key". Did you mean to that?

Thanks for your reply.

Kind regards,
Daniel

···

On 31/01/17 17:15, Damian Minkov wrote:


#15

Hi,

Yep the same dialog of "Create a new application credential", there I
have an Endpoint type dropdown menu. If you are missing that, maybe
the bridge option is not available in developer account.

Regards
damencho

···

On Tue, Jan 31, 2017 at 3:22 PM, Daniel Bareiro <daniel-listas@gmx.net> wrote:

On 31/01/17 17:15, Damian Minkov wrote:

Hi,

Hi, Damian.

In callstats you need to create new credentials with endpoint type of
Middlebox and use those for jvb.

I'm not sure where in the callstats I should create this type of
credentials.

What I did was create an application in "My App". Then go back to "My
App" and go to "Settings". Here I enter on the "Security" tab. Here I go
to "New credentials" to create a new "Shared secret" credential. The
other available type is "ECDSA public key". Did you mean to that?

Thanks for your reply.

Kind regards,
Daniel

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev


#16

Hi,

Hi, Damian.

In callstats you need to create new credentials with endpoint type of
Middlebox and use those for jvb.

I'm not sure where in the callstats I should create this type of
credentials.

What I did was create an application in "My App". Then go back to "My
App" and go to "Settings". Here I enter on the "Security" tab. Here I go
to "New credentials" to create a new "Shared secret" credential. The
other available type is "ECDSA public key". Did you mean to that?

Yep the same dialog of "Create a new application credential", there I
have an Endpoint type dropdown menu. If you are missing that, maybe
the bridge option is not available in developer account.

I do not have that option available. Attached screenshot.

Reading another email [1], I thought this would be enough. But I seem to
be missing something because it is not working.

Thanks for your reply.

Kind regards,
Daniel

[1] http://lists.jitsi.org/pipermail/users/2016-October/011779.html

···

On 31/01/17 18:28, Damian Minkov wrote:


#17

Hi again.

In callstats you need to create new credentials with endpoint type of
Middlebox and use those for jvb.

I'm not sure where in the callstats I should create this type of
credentials.

What I did was create an application in "My App". Then go back to "My
App" and go to "Settings". Here I enter on the "Security" tab. Here I go
to "New credentials" to create a new "Shared secret" credential. The
other available type is "ECDSA public key". Did you mean to that?

Yep the same dialog of "Create a new application credential", there I
have an Endpoint type dropdown menu. If you are missing that, maybe
the bridge option is not available in developer account.

I do not have that option available. Attached screenshot.

Reading another email [1], I thought this would be enough. But I seem to
be missing something because it is not working.

Thanks for your reply.

[1] http://lists.jitsi.org/pipermail/users/2016-October/011779.html

I just confirmed with the callstats.io team what we spoke yesterday:

<quote>
Thanks for reaching out. To send us bridge stats, you need a PRO
account. For the time being, you should be able to send only end-point
stats with developer account.
</quote>

If I understood correctly, Jitsi Videobridge generates the statistics,
but then it should send them somewhere to be processed and visualized
(correct me if I am wrong, please).

What do you recommend? My idea is to keep track of the number of ongoing
conferences with users at each conference. The initial page of Jitsi
Meet mentions Piwik and Google Analitics. Is there something documented
to integrate with these tools to show at least number of conferences and
users in each conference?

Thanks in advance.

Kind regards,
Daniel

···

On 31/01/17 18:42, Daniel Bareiro wrote:


#18

Hi,

You can see number of conferences and stats per conference like number
of participants just by using the client statistics. Google Analytics
you can use for overall stats, like number of particular events,
number of mutes, number of desktop shares stuff like that, callstats
is more to check ongoing calls, debug media problems and stuff like
that.

Regards
damencho

···

On Wed, Feb 1, 2017 at 11:04 AM, Daniel Bareiro <daniel-listas@gmx.net> wrote:

Hi again.

On 31/01/17 18:42, Daniel Bareiro wrote:

In callstats you need to create new credentials with endpoint type of
Middlebox and use those for jvb.

I'm not sure where in the callstats I should create this type of
credentials.

What I did was create an application in "My App". Then go back to "My
App" and go to "Settings". Here I enter on the "Security" tab. Here I go
to "New credentials" to create a new "Shared secret" credential. The
other available type is "ECDSA public key". Did you mean to that?

Yep the same dialog of "Create a new application credential", there I
have an Endpoint type dropdown menu. If you are missing that, maybe
the bridge option is not available in developer account.

I do not have that option available. Attached screenshot.

Reading another email [1], I thought this would be enough. But I seem to
be missing something because it is not working.

Thanks for your reply.

[1] http://lists.jitsi.org/pipermail/users/2016-October/011779.html

I just confirmed with the callstats.io team what we spoke yesterday:

<quote>
Thanks for reaching out. To send us bridge stats, you need a PRO
account. For the time being, you should be able to send only end-point
stats with developer account.
</quote>

If I understood correctly, Jitsi Videobridge generates the statistics,
but then it should send them somewhere to be processed and visualized
(correct me if I am wrong, please).

What do you recommend? My idea is to keep track of the number of ongoing
conferences with users at each conference. The initial page of Jitsi
Meet mentions Piwik and Google Analitics. Is there something documented
to integrate with these tools to show at least number of conferences and
users in each conference?

Thanks in advance.

Kind regards,
Daniel

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev


#19

If I understood correctly, Jitsi Videobridge generates the statistics,
but then it should send them somewhere to be processed and visualized
(correct me if I am wrong, please).

What do you recommend? My idea is to keep track of the number of ongoing
conferences with users at each conference. The initial page of Jitsi
Meet mentions Piwik and Google Analitics. Is there something documented
to integrate with these tools to show at least number of conferences and
users in each conference?

Hi,

Hi, Damian.

You can see number of conferences and stats per conference like number
of participants just by using the client statistics. Google Analytics
you can use for overall stats, like number of particular events,
number of mutes, number of desktop shares stuff like that, callstats
is more to check ongoing calls, debug media problems and stuff like
that.

Could you please tell me how to visualize these client statistics to see
number of conferences and stats per conference like number of participants?

The only documentation I saw so far was the one [1] provided by Boris
which mentioned making some changes in
/etc/jitsi/videobridge/sip-communicator.properties.

Thanks for your answer.

Kind regards,
Daniel

[1] https://github.com/jitsi/jitsi-videobridge/blob/master/doc/statistics.md

···

On 01/02/17 14:33, Damian Minkov wrote:


#20

I thought we were talking about callstats here, just login there and
on the dashboard there is ongoing conferences and more info, you can
than list all ongoing confs and see the participants for particular
conference.

···

On Wed, Feb 1, 2017 at 12:00 PM, Daniel Bareiro <daniel-listas@gmx.net> wrote:

Could you please tell me how to visualize these client statistics to see
number of conferences and stats per conference like number of participants?