Migration of calls between bridges (is enableForcedReload intended to be temporary or permanent?)

The setting enableForcedReload (true by default) forces the frontend to reconnect “from scratch” if the bridge it’s connected to goes down, rather than just getting re-invited to the new bridge. According to the commit message, this “mitigates issues seen on the bridge because of a client re-joining the call with the same endpointId, BWE issues, etc.”

Is this intended to be a temporary workaround until those issues are resolved, or is this seen as the fix for those issues?

On our platform, if we test shutting down a bridge during a call, the actual interruption to the call is only ~3 seconds, but it’s much more noticeable because a) there is an obvious interface reload, and b) Jitsi Meet displays a message (almost too briefly to read!) saying that it is reloading due to a bridge failure.

If the interface didn’t reload but the call was just re-invited to another bridge, the interruption would probably be even shorter than 3s, and might barely be noticeable in a lot of contexts.

We’d be happy to contribute to any improvements to this, but would like to better understand the issues referred to in the commit message first. Bridge failures are extremely rare in our experience, but anything that can be done to reduce the impact is worthwhile.

1 Like

The issues are in the bridge about TCC reset and some bandwidth estimations reset … I don’t have the full picture there, but those are complicated problems and we are working on them to have it not reload, but there is no ETA.

1 Like