feat: Request an in-place ICE restart when the network changes - #17720
Merged
Conversation
Fires an in-place ICE restart on its own when the mobile OS reports a network change, instead of waiting for ICE to actually fail. This is a proactive make-before-break: the bridge keeps carrying media on the established path while the new one comes up, so it is safe to request whenever the local address the session was set up on may have gone stale. Wired into base/conference/middleware.native.ts on SET_NETWORK_INFO. New config flag enableIceRestartOnNetworkChange (on by default, has no effect unless enableIceRestart is also on). Treats a reconnect after an offline gap as a network change, even when the address ends up identical to the pre-outage baseline (for example the same DHCP lease on the same wifi network). Without this, a device that goes offline and reconnects to the same network would look unchanged to a plain address comparison, even though the interface genuinely went down and came back up, and any ICE candidates gathered on it are stale regardless of whether the address string still matches. Verified end to end on a real device against a boris3 standalone: wifi off for about 20 seconds, then back on to the same network and address. JVB completed the resulting in-place restart (generation 2, cutover in 801ms). See ~/claude/ice-restart/mobile-test-2026-08-13-wifi-toggle.md for the full transcript.
jitsi-ci Bot
pushed a commit
to jitsi/jitsi-pr-tests-pages
that referenced
this pull request
Aug 13, 2026
jallamsetty1
approved these changes
Aug 14, 2026
| // another restart. | ||
| lastRequestTime = Date.now(); | ||
|
|
||
| conference.restartJvbIce('network-change') |
Member
There was a problem hiding this comment.
Seems like the reason string is only used in the log message, the IQ sent has 'ice-restart' irrespective of the reason passed. Looks like that is intentional. Should we create a enum for the restart reasons?
…ange trigger Follow-up from a review comment on this PR. lib-jitsi-meet now exposes IceRestartReason (jitsi/lib-jitsi-meet#3089) on JitsiMeetJS.constants (jitsi/lib-jitsi-meet#3090, since this package ships no types and every other enum jitsi-meet consumes goes through JitsiMeetJS.constants/ .errors/.events rather than a direct module import). Re-export it as JitsiIceRestartReason and pass JitsiIceRestartReason.NETWORK_CHANGE instead of the bare string 'network-change'. Also tighten IJitsiConference.restartJvbIce's signature to the known reason values, since the shim interface still can't import lib-jitsi-meet's real type.
jitsi-ci Bot
pushed a commit
to jitsi/jitsi-pr-tests-pages
that referenced
this pull request
Aug 18, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
enableIceRestartOnNetworkChange(on by default, has no effect unlessenableIceRestartis also on).Verified end to end on a real device against a stage standalone: wifi off for about 20 seconds, then back on to the same network and address. The bridge completed the resulting in-place restart (generation 2, cutover in 801ms).