Support ICE Continuous Gathering flag in RTCConfiguration

[bdrtc]

Background
The feature request is to change how browsers complete their ICE Gathering. Currently, after a short period after establishing the call, we stop gathering new candidates and move to a completed state. However, due to an event that changes network conditions for the worse, the client may disconnect from the call prematurely. While, ICE Restart solves this problem it is a slower response than preferred, and could be solved if we continued to gather new ICE candidates throughout the call.

The "walk-out-the-door" problem explains the issue that continuous ICE gathering would solve, described by these slides: https://www.ietf.org/proceedings/94/slides/slides-94-ice-6.pdf

Other Implementations
Chromium has this implemented for their native implementations, and they use a flag to enable this:
https://chromium.googlesource.com/external/webrtc/+/b6760f9e4442410f2bcb6090b3b89bf709e2fce2/webrtc/api/android/java/src/org/webrtc/PeerConnection.java#126

Request
The request here is to be able to turn on continuous ICE gathering through a similar config flag in RTCConfiguration during the creation of the peer connection.

Practice
we open this feature in mobile native sdk(wifi/4g/5g toggle) ,and it proved useful in practice.

[ketsebum]

Cross linking the issue from the WebRTC repo:
w3c/webrtc-pc#2791

[alvestrand]

There was an IETF draft related to this some time ago: https://datatracker.ietf.org/doc/html/draft-oreland-dispatch-ice-nicer-00
There's still interest in doing something like this, but the NICER draft specifically hasn't been followed up on.

[alvestrand]

Trickle ICE is specified in RFC 8838.

[bdrtc]

the flag currently exist （ContinualGatheringPolicy ）in native code and it resolve the scenario：faster reconnected when pc/mobile network exchange during call than ICE Restart, Trickle ICE can not resolve such problem.

[danjenkins]

I'd love to see this available in the web platform

[ketsebum]

Yeah, at least from my understanding Trickle ICE is great for speeding up initial connection. However, the essential problem is that Trickle ICE will still enter into the complete state for ICE Gathering. This is problematic if there is any network changes that a new ICE Candidate would be able to connect better.

ICE Restart does solve this problem, but it is up to the individual clients to implement and is likely to be a slower response to network change, than a continually ICE gathering policy.

[bbaldino]

This would be great!

[lgrahl]

It seems it would be more or less trivial to expose this, at least for Chromium-based browsers. And it would be really useful considering that an ICE restart requires an O/A exchange that is unnecessary with many SFU implementations (they care about the correct certificate fingerprint and that's about it).

[alvestrand]

@sam-vi and @jonasoreland may have more to say here.