New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
ICE improvements: select a candidate pair #171
Comments
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 #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? |
This issue was discussed in WebRTC June 2023 meeting – 27 June 2023 (Issue #170 #171 - candidate pairs management) |
How application knows the list of existing candidate pairs (except getStats) ?
|
RFC 8445 does seem to require an ICE restart to achieve this. From section 8.1.1:
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.
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"
};
Correct.
Not at the moment. If I recall correctly, a proposal for it is suggested further along in the ICE controller improvements. |
This issue was discussed in WebRTC July 2023 meeting – (Ice Controller API: ICE candidate pair selection and nomination) |
This issue had an associated resolution in WebRTC TPAC 2023 meeting – 12 September 2023 (Issue 171 ICE candidate pair selection):
|
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
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).
The text was updated successfully, but these errors were encountered: