Tracking Participant connectivity issues in lib-jitsi-meet

Hello,
Would anyone know how to track participant connectivity issues when using lib-jitsi-meet?
I could not find any EVENT emitted or track status that could refer to that in documentation…
Thank you
Fabrice

Checkout this: https://github.com/jitsi/lib-jitsi-meet/blob/25ca5cbd2a93150e74f029075bc7ac734ed97a2f/modules/connectivity/ParticipantConnectionStatus.js#L48

Listen for JitsiConferenceEvents.PARTICIPANT_CONN_STATUS_CHANGED. These are already used in jitsi-meet.

Thanks a lot @damencho for your quick reply!! :slight_smile:
I have been then implemenging it and it works fine!!

What would you suggest to do when retrieving such Event?
in P2P mode, should the end user wait for bandwidth to come back to normal state and when this happens try to re-attach the previously lost remote track to the DOM element?

Thank you
Fabrice

Yes.

There is nothing to do with the tracks, bandwidth estimations had decided to suspend video, if bandwidth changes it will recover …

Hi @damencho
In P2P mode, we have been then simulating bandwidth issue with participant starting a big download in parallel. Issue we have seen is that when download is stopped, video never gets back even if bandwidth is back to normal on such user side.
Video is retrieved only if remote participant for which video was lost, start sharing his screen and then stop sharing. At this point only , remote video track is retrieved.
Because of that, would you know about any way to force the retrieval of video track?
Thank you
Fabrice

Have you testes same scenario with meet.jit.si, what is the behaviour there?

Yes we just tried then.
Same behavior there, in P2P mode (2 people), video get frozen and we never get it back, even when download is stopped and bandwidth is better back again.
When video is frozen, if I add a 3rd particpant (so we ll move to Bridge mode), then the video tracks get back suddenly (even if download is still running).
This means that P2P is asking for much more bandwidth I believe than Bridge mode… and retrieval does not work in P2P mode neither.

I was thinking that, when such video frozen issue is detected in P2P, to add a fake 3rd participant, so everyone move to Bridge mode and get these connections issues fixed…
What do you think?

Thank you
Fabrice

I will report that and we probably need to fix it… cannot give you any valuable advice at the moment.

Okay, Thank you!

@damencho
Last question,
I see that we cannot really rely on “connectionQuality” field of RemoteStats to understand quality of remote Tracks (at least in P2P mode), should I better use LocalStats.frameRate[userID] to really get participant network quality?
Thank you
Fabrice

This is a report from remote point of view of the connection.

@damencho
For info, I can confirm that automated retrieval in case of video freeze (in case of network connection issues) do work in “Bridge” mode. It does not work in “P2P” mode only.
Thanks
Fabrice

Hello @damencho
Do you think I should raise a GitHub Issue then?
Such issue is happening very frequently in P2P mode then and this makes conversations losing video on many different calls a kind of bad behavior.
Thank you
Fabrice

Can you test same with https://appr.tc/, do you see a difference? Yes create an issue.

Hello @damencho
We just tried and it works fine in https://appr.tc/:
In a P2P session, when video is lost on one side, we are able to retrieve it when connectivity is back.

So we tried again on https://meet.jit.si/ and still same behaviour there (as we have on our side with jitsi docker images), in P2P mode, when video is lost on one side (due to connection issues) we DO NOT retrieve video even if connection gets better.

I hope that knowing that https://appr.tc/ works fine will help in finding the issue then.
I will create Ticket then.
Could you please suggest in which module I should create it? lib-jitsi-meet, videobridge,…?

Thanks
Fabrice

I would say lib-jitsi-meet, post and a link to this thread, thanks.

ok Done, https://github.com/jitsi/lib-jitsi-meet/issues/930

1 Like

Hi @damencho
Looks like nobody is looking at this P2P issue and retrieval of video.
Do you know what I should do to have someone helping on that?
Than you
Fabrice

We have priorities and a lot is going on, and there is nobody free to look at it. Probably one day we will come to it.
I heard suspicion about googEnableVideoSuspendBelowMinBitrate: {exact: true} which is enabled only on the p2p connection, if you can remove it and test it again, does it change something?

1 Like

Thank you @damencho
Sorry for time it took to do proper testing but I have then implemented googEnableVideoSuspendBelowMinBitrate: {exact: false} in conference-config.js and did not notice any improvement when trying to recover video lost in P2P mode. We lose it and enevr retrieve it as before.
Should I update the Issue accordingly?
Thank you
Fabrice