I'm sorry for nor responding on this sooner.
> I think the way to disable this behavior with the latest versions is to set this property in jitsi-videobridge's config file:
Alright, I definitely want the congestion control in the long run, but it would be good just as a sanity check for what I am seeing.
Is the suspend option required for congestion control to operate, or does it just happen that this flag disabled all congestion control, and thus this option as well?
The flag effectively disables taking any action for congestion control on the bridge->receiver leg, which results in the sending of all configured streams (highest resolution for the selected endpoint, 180p if available for anyone else).
I have generated a recording of the case of 2.5% packet loss in both directions with Jitsi-Meet, which I will send to you directly.
It seems to be able to handle the loss with NACK, but it is continually halting the video on both ends, eventually permanently.
In the long run, would FEC be able to handle the above situation by erasing the packet loss?
I'm not sure what version of the bridge you were using, but 1019 introduced a bug which we suspect brakes NACK/RTX (the bug is fixed in master). I don't expect 2.5% packet loss to cause much freezing, so I suspect you might be running with the bug.
For repair with NACK and retransmissions the RTT is very important. If you are running locally with an RTT of ~1ms, you can repair a lot of missing packets quickly, but it isn't realistic. So testing with a realistic delay is important.
FEC will help with this, especially in high RTT scenarios.
> The issue is the remote end (With no simulated packet loss) continually
> sees 'Fellow Vuer is having connectivity issues,' and the transmitted
> video pauses over and over again.
This is also consistent with the bug with NACKs.
> JVB 2018-01-12 22:52:10.337 WARNING: 
> org.jitsi.videobridge.cc.SimulcastController.log() A jump was detected
> in the picture IDs.
I don't think we are seeing this one, and I don't know how to interpret it. Perhaps George will know.
> So, commenting out the following lines of code in the videobridge seemed
> to fix the continuous freezing and 'Fellow User is having connectivity
> issues.' message on the remote end.
> Is it possible the logic calculating the new dstPictureID could be wrong
I don't know. If you want to experiment with disabling the rewriting of PictureID, you can use this property:
Since the freezing problem that you see is consistent with the bug that we recently fixed, I would suggest to update the bridge and see if that helps. If it doesn't, check if disabling PictureID rewriting makes a difference.
On 12/01/2018 12:42, Jason Thomas wrote:
On 12/01/2018 13:12, Jason Thomas wrote:
On 12/01/2018 16:58, Jason Thomas wrote:
On 12/01/2018 17:18, Jason Thomas wrote: