search

w3c / webrtc-extensions

A repository for experimental additions to the WebRTC API
https://w3c.github.io/webrtc-extensions/
Other
58 stars 19 forks source link

Support ICE Continuous Gathering flag in RTCConfiguration #121

Open bdrtc opened 2 years ago

bdrtc commented 2 years ago

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 commented 2 years ago

Cross linking the issue from the WebRTC repo: https://github.com/w3c/webrtc-pc/issues/2791

alvestrand commented 2 years ago

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 commented 2 years ago

Trickle ICE is specified in RFC 8838.

bdrtc commented 2 years ago

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 commented 2 years ago

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

ketsebum commented 2 years ago

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 commented 2 years ago

This would be great!

lgrahl commented 2 months ago

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 commented 2 months ago

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