Media change during P2P leads to JVB routing stream it's not supposed to (bandwidth leak)

[jusquiame]

Description

While in a 1to1 conference one or both navigating on Chrome and P2P working, switching media (camera, screen-share, plugging a camera when none was) leads to the JVB receiving and/or sending the new media stream. I think it's a merely redundant artefact, see remark (1) below.

This doesn't happen when both attendees use Firefox.

Current behavior

JVB gets loaded while in P2P connection

Expected Behavior

switching media while in P2P doesn't load the videobridge.

Possible Solution

????

Possible ugly patch to save those whose P2P is 100% use and bandwidth usage vital

renegotiating P2P connection from scratch upon any streamed media change.

Steps to reproduce

Note : I worked on a dev instance on which I was alone, thus the following method. Another user reproduced the problem on last unstable, observing transceiver/endpointConnectionStats in debug mode.

• On the instance with JVB you're the only one to use, start nload or any traffic monitoring tool you like.

• Start a 1to1 conference on Chrome, makes sure P2P works properly. You should see no or near zero traffic on your instance, but a short burst upon connexions of course.

• Start screen sharing. Traffic rises to correlation with screen-sharing stream

• Stop screen sharing, traffic on the bridge is correlated to resumed camera video stream.

• mute/unmute the camera and observe it stops/resumes the traffic on JVB.

Additional remarks :

1. Sometime, the load on JVB follows the following pattern : After outgoing traffic went back to near zero, the conference was still live, with neither interruption in audio or video, nor change in quality or framerate. But incoming traffic on server stayed correlated to video stream. Suggests that this is a ghost stream, routed for nothing.

2. I think this behavior is linked to recent (and mandatory) switch to unified plan.

3. As mentioned, Chrome seems to be part of the problem as when both users are on FF - that has always used Unified Plan - the problem is not observed.

Environment details

• Navigating with Chrome 96

observed on :

• last unstable
• 2 different self-hosted instances having slightly different settings but common versions : Ubuntu 18.04 jitsi-meet 2.0.6689-1, prosody, tokens, turnserver, web, web-config 1.0.5638-1
  videobridge2 2.1-592-g1e2879e0-1

[jusquiame]

Still the same with Chrome 97

[damencho]

When this happens what do you see for remote address in the connection popup?

Is it p2p?

[jusquiame]

Thanks @damencho. it comes like this :

[bgrozev]

This is a jitsi-meet issue. The bridge connection is always available and the bridge will route whenever it receives packets. It's up to clients to decide whether to use it or not. Can you please move the issue to jitsi/jitsi-meet?

[damencho]

Can you upload your js console logs from such a session?

[jusquiame]

Here it is.

Screen-sharing and JVB weird load start @ : Logger.js:154 2022-01-11T04:53:50.317Z

jitsiMeetP2PBandwidthLeak-jsConsole-1641876882835.log

[damencho]

You are running jitsi-meet with modifications, right? Is ljm changed? What are the versions running?

[jusquiame]

Indeed I modified jitsi-meet, but just a bit. Here are the little customization I made :

• Added a LUA Script that hooks the participants connections / disconnections , so that my Jitsi instances can notify my front server, for timestamping purpose. (done 1 year + ago, removing it changes nothing to described problem)

• Also added : document.domain="myMainDomain.com"; at the beginning of app.bundle.min.js, for my main web app to be able and access the jitsi-meet iFrame.

That's it.

external-api is untouched, just the version shipped with configuration mentioned above :

jitsi-meet 2.0.6689-1, prosody, tokens, turnserver, web, web-config 1.0.5638-1 videobridge2 2.1-592-g1e2879e0-1

Once again, this is a jitsi + Chrome issue.

[jusquiame]

And many thanks for investigating on this. I use Jitsi in a P2P only context, and I find myself in a situation where an instance that was good for a thousand users or more can now break with only 30 for bandwidth reasons. As server costs are running those days, that's hurting a bit.

[jusquiame]

Hi, and thanks for the patch ! One last question : It's not packed in jan 17 2022 Jitsi version, or is it ? What version to install in order to test it ? Or when will it be in stable version ?

Thanks for your great job anyway. Jitsi is truly amazing.

[damencho]

Or when will it be in stable version ?

No ETA as there was a stable 2 days ago.

This had been merged into lib-jitsi-meet, and hasn't reached jitsi-meet. Once that is done, you can get the version from the unstable debian repo or you can test it on alpha jitsi net or beta meet jit si.

[jusquiame]

Thanks !

[jusquiame]

It works !!! Bug fixed !!! Thanks again and again. (tested and monitored in prod)