[jitsi-users] "Video turned off to save bandwidth" on meet.jit.si


#1

Hi,
We have noticed when we started using the latest jitsi that it is very sensitive to connection speed. The video goes black screen and it does not recover. We tested it on meet.jit.si <http://meet.jit.si/> and found the same experience. Basically, it says video is shut off to reduce bandwidth use. Included is a snapshot.
In the previous version we are using, this behavior does not occur. We get freezes here and there but not complete shut down.
Are there settings to disable this?
Is it a know issue?

Here is what we see: https://www.screencast.com/t/k0LQwEne

Thanks,
Osama


#2

Hi Osama,

You can disable it by adding this line in your /etc/jitsi/videobridge/sip-communicator.properties file:

    org.jitsi.videobridge.TRUST_BWE=false

This will disable adaptivity in the bridge. What’s the bandwidth of your connections? Do you think this is a problem with the bridge where it’s not able to detect the available bandwidth?

Best,
George

···

On Jun 19, 2017, at 7:07 AM, Osama Alshaykh <osama.alshaykh@gmail.com> wrote:

Hi,
We have noticed when we started using the latest jitsi that it is very sensitive to connection speed. The video goes black screen and it does not recover. We tested it on meet.jit.si <http://meet.jit.si/> and found the same experience. Basically, it says video is shut off to reduce bandwidth use. Included is a snapshot.
In the previous version we are using, this behavior does not occur. We get freezes here and there but not complete shut down.
Are there settings to disable this?
Is it a know issue?

Here is what we see: https://www.screencast.com/t/k0LQwEne

Thanks,
Osama
_______________________________________________
users mailing list
users@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/users


#3

Hi George,

Please find what we see in the

We also see the following of our data connection which is really good connection. Upload: 26.66Mbps, Download 40.62 and ping 137msec. It is in a corporate network. So there are the normal firewalls. This is capture is using meet.jit.si <http://meet.jit.si/>.

We see it in our own installation too.

Any hint will be of great help.

We prefer to use adaptivity. We also prefer to use simulcast off because most of our clients are mobile on tough connections.

Thanks,
Osama

···

On Jun 19, 2017, at 12:01 PM, George Politis <gp@jitsi.org> wrote:

Hi Osama,

You can disable it by adding this line in your /etc/jitsi/videobridge/sip-communicator.properties file:

    org.jitsi.videobridge.TRUST_BWE=false

This will disable adaptivity in the bridge. What’s the bandwidth of your connections? Do you think this is a problem with the bridge where it’s not able to detect the available bandwidth?

Best,
George

On Jun 19, 2017, at 7:07 AM, Osama Alshaykh <osama.alshaykh@gmail.com <mailto:osama.alshaykh@gmail.com>> wrote:

Hi,
We have noticed when we started using the latest jitsi that it is very sensitive to connection speed. The video goes black screen and it does not recover. We tested it on meet.jit.si <http://meet.jit.si/> and found the same experience. Basically, it says video is shut off to reduce bandwidth use. Included is a snapshot.
In the previous version we are using, this behavior does not occur. We get freezes here and there but not complete shut down.
Are there settings to disable this?
Is it a know issue?

Here is what we see: https://www.screencast.com/t/k0LQwEne

Thanks,
Osama
_______________________________________________
users mailing list
users@jitsi.org <mailto:users@jitsi.org>
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/users

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


#4

That looks bad.. I’m wondering whether you guys are connected through TCP which is broken in certain versions of Chrome (can’t recall which, but it was in recent versions).

How does your local info bar look like? Can you take a screenshot of that too?

Best,
George

···

On Jun 19, 2017, at 11:50 AM, Osama Alshaykh <osama.alshaykh@gmail.com> wrote:

Hi George,

Please find what we see in the

We also see the following of our data connection which is really good connection. Upload: 26.66Mbps, Download 40.62 and ping 137msec. It is in a corporate network. So there are the normal firewalls. This is capture is using meet.jit.si <http://meet.jit.si/>.

We see it in our own installation too.

Any hint will be of great help.

We prefer to use adaptivity. We also prefer to use simulcast off because most of our clients are mobile on tough connections.

Thanks,
Osama

<IMG_19062017_192041_0.png>

<PastedGraphic-2.tiff>

On Jun 19, 2017, at 12:01 PM, George Politis <gp@jitsi.org <mailto:gp@jitsi.org>> wrote:

Hi Osama,

You can disable it by adding this line in your /etc/jitsi/videobridge/sip-communicator.properties file:

    org.jitsi.videobridge.TRUST_BWE=false

This will disable adaptivity in the bridge. What’s the bandwidth of your connections? Do you think this is a problem with the bridge where it’s not able to detect the available bandwidth?

Best,
George

On Jun 19, 2017, at 7:07 AM, Osama Alshaykh <osama.alshaykh@gmail.com <mailto:osama.alshaykh@gmail.com>> wrote:

Hi,
We have noticed when we started using the latest jitsi that it is very sensitive to connection speed. The video goes black screen and it does not recover. We tested it on meet.jit.si <http://meet.jit.si/> and found the same experience. Basically, it says video is shut off to reduce bandwidth use. Included is a snapshot.
In the previous version we are using, this behavior does not occur. We get freezes here and there but not complete shut down.
Are there settings to disable this?
Is it a know issue?

Here is what we see: https://www.screencast.com/t/k0LQwEne

Thanks,
Osama
_______________________________________________
users mailing list
users@jitsi.org <mailto:users@jitsi.org>
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/users

_______________________________________________
users mailing list
users@jitsi.org <mailto:users@jitsi.org>
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/users

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


#5

Hi George,

I apologize for the delay. We can reproduce the issue easily in our European office so I could not send it yesterday. Please check the information you asked for in the images attached. Basically, at some point the estimated downlink goes to 200kbps and it removes the video and it never recovers. The signal bandwidth is really good using speediest.

Speed Test:

All users videos are removed.

user 1 info:

Another user info:

It is all UDP. The upload speed is estimated pretty good. it is the download speed that is estimated low and it gets stuck there.

I hope this sis helpful.

Thanks,
Osama

PS: the session is qwerty123 and it was done around 9AM EST.

···

On Jun 19, 2017, at 2:00 PM, George Politis <gp@jitsi.org> wrote:

That looks bad.. I’m wondering whether you guys are connected through TCP which is broken in certain versions of Chrome (can’t recall which, but it was in recent versions).

How does your local info bar look like? Can you take a screenshot of that too?

Best,
George

On Jun 19, 2017, at 11:50 AM, Osama Alshaykh <osama.alshaykh@gmail.com <mailto:osama.alshaykh@gmail.com>> wrote:

Hi George,

Please find what we see in the

We also see the following of our data connection which is really good connection. Upload: 26.66Mbps, Download 40.62 and ping 137msec. It is in a corporate network. So there are the normal firewalls. This is capture is using meet.jit.si <http://meet.jit.si/>.

We see it in our own installation too.

Any hint will be of great help.

We prefer to use adaptivity. We also prefer to use simulcast off because most of our clients are mobile on tough connections.

Thanks,
Osama

<IMG_19062017_192041_0.png>

<PastedGraphic-2.tiff>

On Jun 19, 2017, at 12:01 PM, George Politis <gp@jitsi.org <mailto:gp@jitsi.org>> wrote:

Hi Osama,

You can disable it by adding this line in your /etc/jitsi/videobridge/sip-communicator.properties file:

    org.jitsi.videobridge.TRUST_BWE=false

This will disable adaptivity in the bridge. What’s the bandwidth of your connections? Do you think this is a problem with the bridge where it’s not able to detect the available bandwidth?

Best,
George

On Jun 19, 2017, at 7:07 AM, Osama Alshaykh <osama.alshaykh@gmail.com <mailto:osama.alshaykh@gmail.com>> wrote:

Hi,
We have noticed when we started using the latest jitsi that it is very sensitive to connection speed. The video goes black screen and it does not recover. We tested it on meet.jit.si <http://meet.jit.si/> and found the same experience. Basically, it says video is shut off to reduce bandwidth use. Included is a snapshot.
In the previous version we are using, this behavior does not occur. We get freezes here and there but not complete shut down.
Are there settings to disable this?
Is it a know issue?

Here is what we see: https://www.screencast.com/t/k0LQwEne

Thanks,
Osama
_______________________________________________
users mailing list
users@jitsi.org <mailto:users@jitsi.org>
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/users

_______________________________________________
users mailing list
users@jitsi.org <mailto:users@jitsi.org>
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/users

_______________________________________________
users mailing list
users@jitsi.org <mailto:users@jitsi.org>
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/users

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


#6

Hi Osama,

Thanks for the info. It looks like there’s a problem with our CC implementation, but I’m not really sure what could it be.

Can you use “iperf” to determine the available bandwidth to your JVB? Also, I’m wondering whether there are any other competing TCP flows.

Also, could you please post your sip-communicator.properties file? I’d like to double check it, just in case there’s any old setting that prevents bandwidth probing from working.

Thanks,
George

···

On Jun 20, 2017, at 8:32 AM, Osama Alshaykh <osama.alshaykh@gmail.com> wrote:

Hi George,

I apologize for the delay. We can reproduce the issue easily in our European office so I could not send it yesterday. Please check the information you asked for in the images attached. Basically, at some point the estimated downlink goes to 200kbps and it removes the video and it never recovers. The signal bandwidth is really good using speediest.

Speed Test:
<PastedGraphic-3.tiff>

All users videos are removed.

<IMG_20062017_160623_0.png>

user 1 info:
<PastedGraphic-7.tiff>

Another user info:

<PastedGraphic-6.tiff>

It is all UDP. The upload speed is estimated pretty good. it is the download speed that is estimated low and it gets stuck there.

I hope this sis helpful.

Thanks,
Osama

PS: the session is qwerty123 and it was done around 9AM EST.

On Jun 19, 2017, at 2:00 PM, George Politis <gp@jitsi.org <mailto:gp@jitsi.org>> wrote:

That looks bad.. I’m wondering whether you guys are connected through TCP which is broken in certain versions of Chrome (can’t recall which, but it was in recent versions).

How does your local info bar look like? Can you take a screenshot of that too?

Best,
George

On Jun 19, 2017, at 11:50 AM, Osama Alshaykh <osama.alshaykh@gmail.com <mailto:osama.alshaykh@gmail.com>> wrote:

Hi George,

Please find what we see in the

We also see the following of our data connection which is really good connection. Upload: 26.66Mbps, Download 40.62 and ping 137msec. It is in a corporate network. So there are the normal firewalls. This is capture is using meet.jit.si <http://meet.jit.si/>.

We see it in our own installation too.

Any hint will be of great help.

We prefer to use adaptivity. We also prefer to use simulcast off because most of our clients are mobile on tough connections.

Thanks,
Osama

<IMG_19062017_192041_0.png>

<PastedGraphic-2.tiff>

On Jun 19, 2017, at 12:01 PM, George Politis <gp@jitsi.org <mailto:gp@jitsi.org>> wrote:

Hi Osama,

You can disable it by adding this line in your /etc/jitsi/videobridge/sip-communicator.properties file:

    org.jitsi.videobridge.TRUST_BWE=false

This will disable adaptivity in the bridge. What’s the bandwidth of your connections? Do you think this is a problem with the bridge where it’s not able to detect the available bandwidth?

Best,
George

On Jun 19, 2017, at 7:07 AM, Osama Alshaykh <osama.alshaykh@gmail.com <mailto:osama.alshaykh@gmail.com>> wrote:

Hi,
We have noticed when we started using the latest jitsi that it is very sensitive to connection speed. The video goes black screen and it does not recover. We tested it on meet.jit.si <http://meet.jit.si/> and found the same experience. Basically, it says video is shut off to reduce bandwidth use. Included is a snapshot.
In the previous version we are using, this behavior does not occur. We get freezes here and there but not complete shut down.
Are there settings to disable this?
Is it a know issue?

Here is what we see: https://www.screencast.com/t/k0LQwEne

Thanks,
Osama
_______________________________________________
users mailing list
users@jitsi.org <mailto:users@jitsi.org>
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/users

_______________________________________________
users mailing list
users@jitsi.org <mailto:users@jitsi.org>
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/users

_______________________________________________
users mailing list
users@jitsi.org <mailto:users@jitsi.org>
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/users

_______________________________________________
users mailing list
users@jitsi.org <mailto:users@jitsi.org>
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/users


#7

I am experiencing the same issue, however, at some point the video actually returns. Still it’s annoying since it affects the user experience.

Best,
Jose

···

On 20 Jun 2017, at 10:32, Osama Alshaykh <osama.alshaykh@gmail.com> wrote:

Hi George,

I apologize for the delay. We can reproduce the issue easily in our European office so I could not send it yesterday. Please check the information you asked for in the images attached. Basically, at some point the estimated downlink goes to 200kbps and it removes the video and it never recovers. The signal bandwidth is really good using speediest.

Speed Test:
<PastedGraphic-3.tiff>

All users videos are removed.

<IMG_20062017_160623_0.png>

user 1 info:
<PastedGraphic-7.tiff>

Another user info:

<PastedGraphic-6.tiff>

It is all UDP. The upload speed is estimated pretty good. it is the download speed that is estimated low and it gets stuck there.

I hope this sis helpful.

Thanks,
Osama

PS: the session is qwerty123 and it was done around 9AM EST.

On Jun 19, 2017, at 2:00 PM, George Politis <gp@jitsi.org <mailto:gp@jitsi.org>> wrote:

That looks bad.. I’m wondering whether you guys are connected through TCP which is broken in certain versions of Chrome (can’t recall which, but it was in recent versions).

How does your local info bar look like? Can you take a screenshot of that too?

Best,
George

On Jun 19, 2017, at 11:50 AM, Osama Alshaykh <osama.alshaykh@gmail.com <mailto:osama.alshaykh@gmail.com>> wrote:

Hi George,

Please find what we see in the

We also see the following of our data connection which is really good connection. Upload: 26.66Mbps, Download 40.62 and ping 137msec. It is in a corporate network. So there are the normal firewalls. This is capture is using meet.jit.si <http://meet.jit.si/>.

We see it in our own installation too.

Any hint will be of great help.

We prefer to use adaptivity. We also prefer to use simulcast off because most of our clients are mobile on tough connections.

Thanks,
Osama

<IMG_19062017_192041_0.png>

<PastedGraphic-2.tiff>

On Jun 19, 2017, at 12:01 PM, George Politis <gp@jitsi.org <mailto:gp@jitsi.org>> wrote:

Hi Osama,

You can disable it by adding this line in your /etc/jitsi/videobridge/sip-communicator.properties file:

    org.jitsi.videobridge.TRUST_BWE=false

This will disable adaptivity in the bridge. What’s the bandwidth of your connections? Do you think this is a problem with the bridge where it’s not able to detect the available bandwidth?

Best,
George

On Jun 19, 2017, at 7:07 AM, Osama Alshaykh <osama.alshaykh@gmail.com <mailto:osama.alshaykh@gmail.com>> wrote:

Hi,
We have noticed when we started using the latest jitsi that it is very sensitive to connection speed. The video goes black screen and it does not recover. We tested it on meet.jit.si <http://meet.jit.si/> and found the same experience. Basically, it says video is shut off to reduce bandwidth use. Included is a snapshot.
In the previous version we are using, this behavior does not occur. We get freezes here and there but not complete shut down.
Are there settings to disable this?
Is it a know issue?

Here is what we see: https://www.screencast.com/t/k0LQwEne

Thanks,
Osama
_______________________________________________
users mailing list
users@jitsi.org <mailto:users@jitsi.org>
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/users

_______________________________________________
users mailing list
users@jitsi.org <mailto:users@jitsi.org>
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/users

_______________________________________________
users mailing list
users@jitsi.org <mailto:users@jitsi.org>
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/users

_______________________________________________
users mailing list
users@jitsi.org <mailto:users@jitsi.org>
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/users

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


#8

Hi George,

The tests I posted were directly with meet.jit.si <http://meet.jit.si/> so we did them on the meer.jit.si <http://meer.jit.si/> deployment. All the results I gave you were connecting to meet.jit.si <http://meet.jit.si/>. We thought if we do it this way, you have more control of the logs.

But our own deployment configuration are:
sip-communicator properties:

org.jitsi.impl.neomedia.transform.srtp.SRTPCryptoContext.checkReplay=false
org.jitsi.videobridge.NAT_HARVESTER_LOCAL_ADDRESS=x.x.x.x
org.jitsi.videobridge.NAT_HARVESTER_PUBLIC_ADDRESS=x.x.x.x

# the callstats credentials
io.callstats.sdk.CallStats.appId=xxxxxxxxxxxxxx
io.callstats.sdk.CallStats.appSecret=xxxxxxxxxxxxxxxxxxxxxxxxxxxxx=

# the id of the videobridge
io.callstats.sdk.CallStats.bridgeId=dervio-2

# enable statistics and callstats statistics and the report interval
org.jitsi.videobridge.STATISTICS_INTERVAL.callstats.io <http://org.jitsi.videobridge.statistics_interval.callstats.io/>=10000
org.jitsi.videobridge.STATISTICS_INTERVAL.pubsub=10000
org.jitsi.videobridge.ENABLE_STATISTICS=true
org.jitsi.videobridge.STATISTICS_TRANSPORT=pubsub,callstats.io <http://callstats.io/>
org.jitsi.videobridge.PUBSUB_SERVICE=piona.xxxxx.xxxx
org.jitsi.videobridge.PUBSUB_NODE=sharedStatsNode

Are you looking for JBV performance on our deployment or run iperf on our own pc’s for testing?

Thanks,
Osama

···

On Jun 20, 2017, at 11:19 AM, George Politis <gp@jitsi.org> wrote:

Hi Osama,

Thanks for the info. It looks like there’s a problem with our CC implementation, but I’m not really sure what could it be.

Can you use “iperf” to determine the available bandwidth to your JVB? Also, I’m wondering whether there are any other competing TCP flows.

Also, could you please post your sip-communicator.properties file? I’d like to double check it, just in case there’s any old setting that prevents bandwidth probing from working.

Thanks,
George

On Jun 20, 2017, at 8:32 AM, Osama Alshaykh <osama.alshaykh@gmail.com <mailto:osama.alshaykh@gmail.com>> wrote:

Hi George,

I apologize for the delay. We can reproduce the issue easily in our European office so I could not send it yesterday. Please check the information you asked for in the images attached. Basically, at some point the estimated downlink goes to 200kbps and it removes the video and it never recovers. The signal bandwidth is really good using speediest.

Speed Test:
<PastedGraphic-3.tiff>

All users videos are removed.

<IMG_20062017_160623_0.png>

user 1 info:
<PastedGraphic-7.tiff>

Another user info:

<PastedGraphic-6.tiff>

It is all UDP. The upload speed is estimated pretty good. it is the download speed that is estimated low and it gets stuck there.

I hope this sis helpful.

Thanks,
Osama

PS: the session is qwerty123 and it was done around 9AM EST.

On Jun 19, 2017, at 2:00 PM, George Politis <gp@jitsi.org <mailto:gp@jitsi.org>> wrote:

That looks bad.. I’m wondering whether you guys are connected through TCP which is broken in certain versions of Chrome (can’t recall which, but it was in recent versions).

How does your local info bar look like? Can you take a screenshot of that too?

Best,
George

On Jun 19, 2017, at 11:50 AM, Osama Alshaykh <osama.alshaykh@gmail.com <mailto:osama.alshaykh@gmail.com>> wrote:

Hi George,

Please find what we see in the

We also see the following of our data connection which is really good connection. Upload: 26.66Mbps, Download 40.62 and ping 137msec. It is in a corporate network. So there are the normal firewalls. This is capture is using meet.jit.si <http://meet.jit.si/>.

We see it in our own installation too.

Any hint will be of great help.

We prefer to use adaptivity. We also prefer to use simulcast off because most of our clients are mobile on tough connections.

Thanks,
Osama

<IMG_19062017_192041_0.png>

<PastedGraphic-2.tiff>

On Jun 19, 2017, at 12:01 PM, George Politis <gp@jitsi.org <mailto:gp@jitsi.org>> wrote:

Hi Osama,

You can disable it by adding this line in your /etc/jitsi/videobridge/sip-communicator.properties file:

    org.jitsi.videobridge.TRUST_BWE=false

This will disable adaptivity in the bridge. What’s the bandwidth of your connections? Do you think this is a problem with the bridge where it’s not able to detect the available bandwidth?

Best,
George

On Jun 19, 2017, at 7:07 AM, Osama Alshaykh <osama.alshaykh@gmail.com <mailto:osama.alshaykh@gmail.com>> wrote:

Hi,
We have noticed when we started using the latest jitsi that it is very sensitive to connection speed. The video goes black screen and it does not recover. We tested it on meet.jit.si <http://meet.jit.si/> and found the same experience. Basically, it says video is shut off to reduce bandwidth use. Included is a snapshot.
In the previous version we are using, this behavior does not occur. We get freezes here and there but not complete shut down.
Are there settings to disable this?
Is it a know issue?

Here is what we see: https://www.screencast.com/t/k0LQwEne

Thanks,
Osama
_______________________________________________
users mailing list
users@jitsi.org <mailto:users@jitsi.org>
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/users

_______________________________________________
users mailing list
users@jitsi.org <mailto:users@jitsi.org>
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/users

_______________________________________________
users mailing list
users@jitsi.org <mailto:users@jitsi.org>
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/users

_______________________________________________
users mailing list
users@jitsi.org <mailto:users@jitsi.org>
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/users


#9

Thanks Osama. The sip-communicator.properties file looks okay. I would iperf the UDP upload speed from one of the client machines to your JVB server.

···

On Jun 20, 2017, at 3:13 PM, Osama Alshaykh <osama.alshaykh@gmail.com> wrote:

Hi George,

The tests I posted were directly with meet.jit.si <http://meet.jit.si/> so we did them on the meer.jit.si <http://meer.jit.si/> deployment. All the results I gave you were connecting to meet.jit.si <http://meet.jit.si/>. We thought if we do it this way, you have more control of the logs.

But our own deployment configuration are:
sip-communicator properties:

org.jitsi.impl.neomedia.transform.srtp.SRTPCryptoContext.checkReplay=false
org.jitsi.videobridge.NAT_HARVESTER_LOCAL_ADDRESS=x.x.x.x
org.jitsi.videobridge.NAT_HARVESTER_PUBLIC_ADDRESS=x.x.x.x

# the callstats credentials
io.callstats.sdk.CallStats.appId=xxxxxxxxxxxxxx
io.callstats.sdk.CallStats.appSecret=xxxxxxxxxxxxxxxxxxxxxxxxxxxxx=

# the id of the videobridge
io.callstats.sdk.CallStats.bridgeId=dervio-2

# enable statistics and callstats statistics and the report interval
org.jitsi.videobridge.STATISTICS_INTERVAL.callstats.io <http://org.jitsi.videobridge.statistics_interval.callstats.io/>=10000
org.jitsi.videobridge.STATISTICS_INTERVAL.pubsub=10000
org.jitsi.videobridge.ENABLE_STATISTICS=true
org.jitsi.videobridge.STATISTICS_TRANSPORT=pubsub,callstats.io <http://callstats.io/>
org.jitsi.videobridge.PUBSUB_SERVICE=piona.xxxxx.xxxx
org.jitsi.videobridge.PUBSUB_NODE=sharedStatsNode

Are you looking for JBV performance on our deployment or run iperf on our own pc’s for testing?

Thanks,
Osama

On Jun 20, 2017, at 11:19 AM, George Politis <gp@jitsi.org <mailto:gp@jitsi.org>> wrote:

Hi Osama,

Thanks for the info. It looks like there’s a problem with our CC implementation, but I’m not really sure what could it be.

Can you use “iperf” to determine the available bandwidth to your JVB? Also, I’m wondering whether there are any other competing TCP flows.

Also, could you please post your sip-communicator.properties file? I’d like to double check it, just in case there’s any old setting that prevents bandwidth probing from working.

Thanks,
George

On Jun 20, 2017, at 8:32 AM, Osama Alshaykh <osama.alshaykh@gmail.com <mailto:osama.alshaykh@gmail.com>> wrote:

Hi George,

I apologize for the delay. We can reproduce the issue easily in our European office so I could not send it yesterday. Please check the information you asked for in the images attached. Basically, at some point the estimated downlink goes to 200kbps and it removes the video and it never recovers. The signal bandwidth is really good using speediest.

Speed Test:
<PastedGraphic-3.tiff>

All users videos are removed.

<IMG_20062017_160623_0.png>

user 1 info:
<PastedGraphic-7.tiff>

Another user info:

<PastedGraphic-6.tiff>

It is all UDP. The upload speed is estimated pretty good. it is the download speed that is estimated low and it gets stuck there.

I hope this sis helpful.

Thanks,
Osama

PS: the session is qwerty123 and it was done around 9AM EST.

On Jun 19, 2017, at 2:00 PM, George Politis <gp@jitsi.org <mailto:gp@jitsi.org>> wrote:

That looks bad.. I’m wondering whether you guys are connected through TCP which is broken in certain versions of Chrome (can’t recall which, but it was in recent versions).

How does your local info bar look like? Can you take a screenshot of that too?

Best,
George

On Jun 19, 2017, at 11:50 AM, Osama Alshaykh <osama.alshaykh@gmail.com <mailto:osama.alshaykh@gmail.com>> wrote:

Hi George,

Please find what we see in the

We also see the following of our data connection which is really good connection. Upload: 26.66Mbps, Download 40.62 and ping 137msec. It is in a corporate network. So there are the normal firewalls. This is capture is using meet.jit.si <http://meet.jit.si/>.

We see it in our own installation too.

Any hint will be of great help.

We prefer to use adaptivity. We also prefer to use simulcast off because most of our clients are mobile on tough connections.

Thanks,
Osama

<IMG_19062017_192041_0.png>

<PastedGraphic-2.tiff>

On Jun 19, 2017, at 12:01 PM, George Politis <gp@jitsi.org <mailto:gp@jitsi.org>> wrote:

Hi Osama,

You can disable it by adding this line in your /etc/jitsi/videobridge/sip-communicator.properties file:

    org.jitsi.videobridge.TRUST_BWE=false

This will disable adaptivity in the bridge. What’s the bandwidth of your connections? Do you think this is a problem with the bridge where it’s not able to detect the available bandwidth?

Best,
George

On Jun 19, 2017, at 7:07 AM, Osama Alshaykh <osama.alshaykh@gmail.com <mailto:osama.alshaykh@gmail.com>> wrote:

Hi,
We have noticed when we started using the latest jitsi that it is very sensitive to connection speed. The video goes black screen and it does not recover. We tested it on meet.jit.si <http://meet.jit.si/> and found the same experience. Basically, it says video is shut off to reduce bandwidth use. Included is a snapshot.
In the previous version we are using, this behavior does not occur. We get freezes here and there but not complete shut down.
Are there settings to disable this?
Is it a know issue?

Here is what we see: https://www.screencast.com/t/k0LQwEne

Thanks,
Osama
_______________________________________________
users mailing list
users@jitsi.org <mailto:users@jitsi.org>
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/users

_______________________________________________
users mailing list
users@jitsi.org <mailto:users@jitsi.org>
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/users

_______________________________________________
users mailing list
users@jitsi.org <mailto:users@jitsi.org>
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/users

_______________________________________________
users mailing list
users@jitsi.org <mailto:users@jitsi.org>
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/users


#10

I think there could be some problem with bandwidth estimation. I had
the same issue on our standups, but the situation seems to have
improved in the last few days.
Maybe the problems will go away after new release to meet.jit.si...

···

On Tue, Jun 20, 2017 at 3:16 PM, George Politis <gp@jitsi.org> wrote:

Thanks Osama. The sip-communicator.properties file looks okay. I would iperf
the UDP upload speed from one of the client machines to your JVB server.

On Jun 20, 2017, at 3:13 PM, Osama Alshaykh <osama.alshaykh@gmail.com> > wrote:

Hi George,

The tests I posted were directly with meet.jit.si so we did them on the
meer.jit.si deployment. All the results I gave you were connecting to
meet.jit.si. We thought if we do it this way, you have more control of the
logs.

But our own deployment configuration are:
sip-communicator properties:

org.jitsi.impl.neomedia.transform.srtp.SRTPCryptoContext.checkReplay=false
org.jitsi.videobridge.NAT_HARVESTER_LOCAL_ADDRESS=x.x.x.x
org.jitsi.videobridge.NAT_HARVESTER_PUBLIC_ADDRESS=x.x.x.x

# the callstats credentials
io.callstats.sdk.CallStats.appId=xxxxxxxxxxxxxx
io.callstats.sdk.CallStats.appSecret=xxxxxxxxxxxxxxxxxxxxxxxxxxxxx=

# the id of the videobridge
io.callstats.sdk.CallStats.bridgeId=dervio-2

# enable statistics and callstats statistics and the report interval
org.jitsi.videobridge.STATISTICS_INTERVAL.callstats.io=10000
org.jitsi.videobridge.STATISTICS_INTERVAL.pubsub=10000
org.jitsi.videobridge.ENABLE_STATISTICS=true
org.jitsi.videobridge.STATISTICS_TRANSPORT=pubsub,callstats.io
org.jitsi.videobridge.PUBSUB_SERVICE=piona.xxxxx.xxxx
org.jitsi.videobridge.PUBSUB_NODE=sharedStatsNode

Are you looking for JBV performance on our deployment or run iperf on our
own pc’s for testing?

Thanks,
Osama

On Jun 20, 2017, at 11:19 AM, George Politis <gp@jitsi.org> wrote:

Hi Osama,

Thanks for the info. It looks like there’s a problem with our CC
implementation, but I’m not really sure what could it be.

Can you use “iperf” to determine the available bandwidth to your JVB? Also,
I’m wondering whether there are any other competing TCP flows.

Also, could you please post your sip-communicator.properties file? I’d like
to double check it, just in case there’s any old setting that prevents
bandwidth probing from working.

Thanks,
George

On Jun 20, 2017, at 8:32 AM, Osama Alshaykh <osama.alshaykh@gmail.com> > wrote:

Hi George,

I apologize for the delay. We can reproduce the issue easily in our
European office so I could not send it yesterday. Please check the
information you asked for in the images attached. Basically, at some point
the estimated downlink goes to 200kbps and it removes the video and it never
recovers. The signal bandwidth is really good using speediest.

Speed Test:
<PastedGraphic-3.tiff>

All users videos are removed.

<IMG_20062017_160623_0.png>

user 1 info:
<PastedGraphic-7.tiff>

Another user info:

<PastedGraphic-6.tiff>

It is all UDP. The upload speed is estimated pretty good. it is the
download speed that is estimated low and it gets stuck there.

I hope this sis helpful.

Thanks,
Osama

PS: the session is qwerty123 and it was done around 9AM EST.

On Jun 19, 2017, at 2:00 PM, George Politis <gp@jitsi.org> wrote:

That looks bad.. I’m wondering whether you guys are connected through TCP
which is broken in certain versions of Chrome (can’t recall which, but it
was in recent versions).

How does your local info bar look like? Can you take a screenshot of that
too?

Best,
George

On Jun 19, 2017, at 11:50 AM, Osama Alshaykh <osama.alshaykh@gmail.com> > wrote:

Hi George,

Please find what we see in the

We also see the following of our data connection which is really good
connection. Upload: 26.66Mbps, Download 40.62 and ping 137msec. It is in
a corporate network. So there are the normal firewalls. This is capture is
using meet.jit.si.

We see it in our own installation too.

Any hint will be of great help.

We prefer to use adaptivity. We also prefer to use simulcast off because
most of our clients are mobile on tough connections.

Thanks,
Osama

<IMG_19062017_192041_0.png>

<PastedGraphic-2.tiff>

On Jun 19, 2017, at 12:01 PM, George Politis <gp@jitsi.org> wrote:

Hi Osama,

You can disable it by adding this line in your
/etc/jitsi/videobridge/sip-communicator.properties file:

    org.jitsi.videobridge.TRUST_BWE=false

This will disable adaptivity in the bridge. What’s the bandwidth of your
connections? Do you think this is a problem with the bridge where it’s not
able to detect the available bandwidth?

Best,
George

On Jun 19, 2017, at 7:07 AM, Osama Alshaykh <osama.alshaykh@gmail.com> > wrote:

Hi,
We have noticed when we started using the latest jitsi that it is very
sensitive to connection speed. The video goes black screen and it does not
recover. We tested it on meet.jit.si and found the same experience.
Basically, it says video is shut off to reduce bandwidth use. Included is a
snapshot.
In the previous version we are using, this behavior does not occur. We get
freezes here and there but not complete shut down.
Are there settings to disable this?
Is it a know issue?

Here is what we see: https://www.screencast.com/t/k0LQwEne

Thanks,
Osama
_______________________________________________
users mailing list
users@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/users

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

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

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

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


#11

Can you give it a try on https://beta.meet.jit.si/ ?

···

On Thu, Jun 22, 2017 at 3:42 PM, Paweł Domas <pawel.domas@jitsi.org> wrote:

I think there could be some problem with bandwidth estimation. I had
the same issue on our standups, but the situation seems to have
improved in the last few days.
Maybe the problems will go away after new release to meet.jit.si...

On Tue, Jun 20, 2017 at 3:16 PM, George Politis <gp@jitsi.org> wrote:

Thanks Osama. The sip-communicator.properties file looks okay. I would iperf
the UDP upload speed from one of the client machines to your JVB server.

On Jun 20, 2017, at 3:13 PM, Osama Alshaykh <osama.alshaykh@gmail.com> >> wrote:

Hi George,

The tests I posted were directly with meet.jit.si so we did them on the
meer.jit.si deployment. All the results I gave you were connecting to
meet.jit.si. We thought if we do it this way, you have more control of the
logs.

But our own deployment configuration are:
sip-communicator properties:

org.jitsi.impl.neomedia.transform.srtp.SRTPCryptoContext.checkReplay=false
org.jitsi.videobridge.NAT_HARVESTER_LOCAL_ADDRESS=x.x.x.x
org.jitsi.videobridge.NAT_HARVESTER_PUBLIC_ADDRESS=x.x.x.x

# the callstats credentials
io.callstats.sdk.CallStats.appId=xxxxxxxxxxxxxx
io.callstats.sdk.CallStats.appSecret=xxxxxxxxxxxxxxxxxxxxxxxxxxxxx=

# the id of the videobridge
io.callstats.sdk.CallStats.bridgeId=dervio-2

# enable statistics and callstats statistics and the report interval
org.jitsi.videobridge.STATISTICS_INTERVAL.callstats.io=10000
org.jitsi.videobridge.STATISTICS_INTERVAL.pubsub=10000
org.jitsi.videobridge.ENABLE_STATISTICS=true
org.jitsi.videobridge.STATISTICS_TRANSPORT=pubsub,callstats.io
org.jitsi.videobridge.PUBSUB_SERVICE=piona.xxxxx.xxxx
org.jitsi.videobridge.PUBSUB_NODE=sharedStatsNode

Are you looking for JBV performance on our deployment or run iperf on our
own pc’s for testing?

Thanks,
Osama

On Jun 20, 2017, at 11:19 AM, George Politis <gp@jitsi.org> wrote:

Hi Osama,

Thanks for the info. It looks like there’s a problem with our CC
implementation, but I’m not really sure what could it be.

Can you use “iperf” to determine the available bandwidth to your JVB? Also,
I’m wondering whether there are any other competing TCP flows.

Also, could you please post your sip-communicator.properties file? I’d like
to double check it, just in case there’s any old setting that prevents
bandwidth probing from working.

Thanks,
George

On Jun 20, 2017, at 8:32 AM, Osama Alshaykh <osama.alshaykh@gmail.com> >> wrote:

Hi George,

I apologize for the delay. We can reproduce the issue easily in our
European office so I could not send it yesterday. Please check the
information you asked for in the images attached. Basically, at some point
the estimated downlink goes to 200kbps and it removes the video and it never
recovers. The signal bandwidth is really good using speediest.

Speed Test:
<PastedGraphic-3.tiff>

All users videos are removed.

<IMG_20062017_160623_0.png>

user 1 info:
<PastedGraphic-7.tiff>

Another user info:

<PastedGraphic-6.tiff>

It is all UDP. The upload speed is estimated pretty good. it is the
download speed that is estimated low and it gets stuck there.

I hope this sis helpful.

Thanks,
Osama

PS: the session is qwerty123 and it was done around 9AM EST.

On Jun 19, 2017, at 2:00 PM, George Politis <gp@jitsi.org> wrote:

That looks bad.. I’m wondering whether you guys are connected through TCP
which is broken in certain versions of Chrome (can’t recall which, but it
was in recent versions).

How does your local info bar look like? Can you take a screenshot of that
too?

Best,
George

On Jun 19, 2017, at 11:50 AM, Osama Alshaykh <osama.alshaykh@gmail.com> >> wrote:

Hi George,

Please find what we see in the

We also see the following of our data connection which is really good
connection. Upload: 26.66Mbps, Download 40.62 and ping 137msec. It is in
a corporate network. So there are the normal firewalls. This is capture is
using meet.jit.si.

We see it in our own installation too.

Any hint will be of great help.

We prefer to use adaptivity. We also prefer to use simulcast off because
most of our clients are mobile on tough connections.

Thanks,
Osama

<IMG_19062017_192041_0.png>

<PastedGraphic-2.tiff>

On Jun 19, 2017, at 12:01 PM, George Politis <gp@jitsi.org> wrote:

Hi Osama,

You can disable it by adding this line in your
/etc/jitsi/videobridge/sip-communicator.properties file:

    org.jitsi.videobridge.TRUST_BWE=false

This will disable adaptivity in the bridge. What’s the bandwidth of your
connections? Do you think this is a problem with the bridge where it’s not
able to detect the available bandwidth?

Best,
George

On Jun 19, 2017, at 7:07 AM, Osama Alshaykh <osama.alshaykh@gmail.com> >> wrote:

Hi,
We have noticed when we started using the latest jitsi that it is very
sensitive to connection speed. The video goes black screen and it does not
recover. We tested it on meet.jit.si and found the same experience.
Basically, it says video is shut off to reduce bandwidth use. Included is a
snapshot.
In the previous version we are using, this behavior does not occur. We get
freezes here and there but not complete shut down.
Are there settings to disable this?
Is it a know issue?

Here is what we see: https://www.screencast.com/t/k0LQwEne

Thanks,
Osama
_______________________________________________
users mailing list
users@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/users

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

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

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

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