ICE improvements: select a candidate pair

[sam-vi]

Background: Issue #166 proposes a mechanism with which applications can prevent candidate pairs from being pruned by the ICE agent. This allows applications to maintain multiple candidate pairs for connection redundancy and quick switchover.

Problem: Redundant connections are only useful when applications have a way to switch the transport to another candidate pair, for which no API exists today.

Proposal: Introduce a new API to allow applications to select a specific candidate pair for transport

partial interface RTCIceTransport {
  Promise<undefined> setSelectedCandidatePair(RTCIceCandidatePair pair);
}

Calling the method on the ICE controlling peer causes the ICE agent to begin selecting the candidate pair for transport using the procedure described in section 7.2.5.3.4 of RFC 8445. The returned promise settles once the nomination concludes.

The promise is rejected if the method is called in an invalid context (eg. on the ICE controlled peer, or from an event handler for prune proposal), with an invalid argument (eg. discarded candidate pair), or if the nomination fails (eg. if the STUN request fails).

[jan-ivar]

Calling the method on the ICE controlling peer causes the ICE agent to begin selecting the candidate pair for transport using the procedure described in section 7.2.5.3.4 of RFC 8445.

Does RFC 8445 allows this? Reading through that section there seems to be rules that govern when the nomination flag is supposed to be set, that are not entirely up to the user agent. With https://github.com/w3c/webrtc-extensions/issues/166 we only enabled apps to intervene in user agent decisions, whereas here it's less clear to me what the rules must be followed in order to not violate RFC 8445. Can you clarify?

It seems to me that one way around it is to only allow app choices where the a user agent has discretion in the process. This might resolve any conflict between the user agent and the IETF spec.

But there's perhaps a more basic question between the app and the user agent here: who's in charge now?

Here I confess a level of ignorance wrt ICE, but let's say hypothetically that a user agent is allowed to change the selected pair in response to changing network conditions (is it?) — would/should it act any differently based on whether this method as been called (once) or not? I.e. would any of these methods switch the agent from automatic to manual? If not, what is the scope of these application-initiated actions?

[dontcallmedom-bot]

This issue was discussed in WebRTC June 2023 meeting – 27 June 2023 (Issue #170 #171 - candidate pairs management)

[oanguenot]

How application knows the list of existing candidate pairs (except getStats) ?

• Should the application relies on this new event oncandidatepairadded ?
• Is there a new API at Transport level that lists the current available candidate pairs (not pruned)?

[sam-vi]

Does RFC 8445 allows this?

RFC 8445 does seem to require an ICE restart to achieve this. From section 8.1.1:

Once the controlling agent has successfully nominated a candidate pair (Section 7.2.5.3.4), the agent MUST NOT nominate another pair for same component of the data stream within the ICE session. Doing so requires an ICE restart.

ICE renomination attempted to extend ICE in this regard, but isn't a standard yet.

@pthatcherg are you aware of another standard that describes renomination? Neither RFC 8838 nor 8863 addresses this, from what I can tell.

would any of these methods switch the agent from automatic to manual?

The cancelable switch event would be able to disambiguate this, and it makes sense to include it with (or prior to) this change.

partial interface RTCIceTransport {
  attribute EventHandler onicecandidatepairswitch;
};

interface RTCIceCandidatePairSwitchEvent : Event {
  readonly attribute RTCIceCandidatePair candidatePair;
  readonly attribute RTCIceCandidatePairSwitchReason reason;
};

enum RTCIceCandidatePairSwitchReason {
  ...
  "selected-connection-destroyed",
  "application-requested"
};

How application knows the list of existing candidate pairs? Should the application relies on this new event oncandidatepairadded ?

Correct.

Is there a new API at Transport level that lists the current available candidate pairs (not pruned)?

Not at the moment. If I recall correctly, a proposal for it is suggested further along in the ICE controller improvements.

[dontcallmedom-bot]

This issue was discussed in WebRTC July 2023 meeting – (Ice Controller API: ICE candidate pair selection and nomination)

[dontcallmedom-bot]

This issue had an associated resolution in WebRTC TPAC 2023 meeting – 12 September 2023 (Issue 171 ICE candidate pair selection):

RESOLUTION: consensus to move on with a PR for that API.