How to recover from "restoring" connectionStatus

Dear all,
We customize jitsi-meet to connect to JAAS infrastructure. Sometimes we see the black cameras. Such situation can persist for a long time so we have to refresh the page (press F5) to receive the camera image again. Checking the browser console, I can see that the black cameras all have the “restoring” connectionStatus (
Would you please tell me why some participants fall into such state, and how we can recover from such state automatically / quickly ?
Many thanks

This is strange, not sure why the video would not start again. So the status becomes inactive when the bandwidth estimation for the client is low and the bridge stops some videos for the client (informing the client by removing the ids from the lastN you can see that in the logs) and restoring is the state when the id enters back in lastN till the video is active …

@jallamsetty do you have an idea?

@mstran The clients will go into restoring state if the endpoint has entered last-n but the bridge hasn’t started forwarding the video yet. This state should last only up to 10 secs, after that the endpoints are marked as interrupted, i.e., the connection status is set to “Lost” in the UI. Are you sure the endpoints are stay in restoring state for longer than 10 secs ?

@damencho This appears to be an issue with the client not being able to set up the bridge channel properly. Therefore whenever the bridge drops some of the endpoints from last-n, they never recover since the client doesn’t get any last-n updates from the bridge.

:+1: thanks

Dear @damencho ,
Thank you for your info.
In fact, I set the channelLastN to -1, and expect that our clients will get all video streams from all participants (we have about 30 participants per room). So maybe I have to set this value explicitly to avoid the restoring problem?
Best regards

Dear @jallamsetty
As responding previously I set the channelLastN to -1. Does this ambiguity cause the problem? I will set it to 30 to verify.
You mentioned that “the client not being able to set up the bridge channel properly”. Would you please show me the steps to check please?. Indeed, from the browser console , I can see a lot of error messages: "Bridge Channel send: No opened channel ". As I understand from previous answer in the forum , such message just keeps me away from receiving high resolution images. So the black camera issue can be also a consequence, can’t it ?
Looking forward to hearing from you to get over these problems
Best regards

Dear @jallamsetty ,
Although already responding to your latest opinion, I still want to answer your previous mail. I also observed that when a participant quits a room, his camera remains in the room with the connectionStatus “restoring”, and probably after 10sec the camera disappears from the room.
It is also strangle that sometimes, a participant quits a room, immediately his camera disappears. But sometimes the camera remains long time enough in the room that I can even capture the console showing the connectionStatus.
I suspect that maybe the network condition causes such different behaviours. Then which network component I should improve/reinforce to ensure a coherent behaviours.
Best regards

What version of Prosody are you running?

Dear @Freddie ,
In fact I use the JAAS via low level API lib-jitsi-meet, so for sure, I have the latest version of prosody.
On our own platform we use jitsi-meet-prosody 1.0.4628-1. On this platform, it seems to me that the restoring status doesnot happen.
Best regard

@mstran The bridge channel has to be operational for the client and bridge to communicate what endpoints are being requested and received and all other constraints pertaining to call quality including the connection status updates. Changing channelLastN value will have no effect if the bridge channel is not setup, the bridge assumes a default value of -1 if the client doesn’t signal a last-n value which is happening in your case.
Once you are able to fix the bridge channel issue, I believe all other issues will be resolved.

Dear All,
I continue this thread with the connectionStatus equal to either interrupted or restoring.
I observe that sometimes a participant having interrupted connectionStatus still has normal camera, while other participant having restoring connectionStatus has no image at all in his camera. And the situation just remains like that for long time. If I refresh the page then thing may be in ordered.
Why are there such contradictory state? And especially how can I handle the camera correctly using these connectionStatus?
Many thanks