Support for ICE Forking

[aboba]

ICE forking is supported in the ORTC API, but is not yet in the WebRTC-ICE specification. We talked about potential ICE forking designs at TPAC 2019, and now ICE forking has been implemented. Should we add this to the specification?

[vmx]

Are there any news? I've found several discussions on that topic that seem to have stopped around 2020.

I'm interested in the use case of being able to connect several peers in a pure in browser environment, where all peers are within the same network. They would share their connection information (fingerprint, ICE candidates) via e.g. a QR code. As I understand it, the ICE forking would help as the one creating the offer, cannot know which peer would connect to it. So it would create an offer, with the same ICE candidates, for each peer that might want to connect.

[aboba]

@vmx At the February 21, 2023 virtual interim, we had a presentation on a proposed ICE Controller API:

The GitHub repo for the proposal is here.

[vmx]

Thanks a lot for the link! After reading the ICE Constroller API proposal, do I understand it correctly that in order to get a forking like behaviour you would do:

1. Create a connection with its local ICE candidates.
2. Extract the local candidate pairs via the getSelectedCandidatePair() call.
3. Create a second connection and call switchToCandidatePair() with the extracted candidates from the first connection.
4. Now the second connection has the same local candidates as the first one.