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
Should ICE agents wait for all prflx candidates before sending USE-CANDIDATE? #7
Comments
If an agent sends USE-CANDIDATE it means that it has found a working pair, so it won't trigger a premature failure. Sure, the agent might receive prflx candidates after it has sent USE-CANDIDATE, but that is not the focus of the draft, is it? |
I think that scenario is in scope. Basically, the agent should wait for prflx candidates, and not prematurely finish or fail ICE. |
As stated in 8445, once an agent has one or more working candidate pairs, it is an implementation issue when it decides to send USE-CANDIDATE. I don't think PAC should change that. The scope of PAC is when an agent does not have any working candidate pairs - it shall then wait for peer reflexive candidates before declaring ICE failure. |
My point is that I think it might make sense to increase the scope somewhat and include a comment that the delay in discovering prflx candidates may also be relevant to when USE-CANDIDATE is sent. I'll write up some text and see where it could go. |
But, in the case we also need to extend the text on when the timer is used to begin with. Currently it is used when there are no more pairs to test, or when all have failed. IF the agent would be able to send USE-CANDIDATE it means that is has at least one non-failed pair. Also, is there any current text preventing an agent from waiting for prflx candidates before sending USE-CANDIDATE? I think 8445 says that it is an implementation issue when an agent does the nomination. |
There's no text preventing it, but this is a non-obvious finding, so I think it is worth calling out in this doc. |
We can add text for whatever we think needs to be clarified - this is our chance :) But, I don't want to mandate an agent to wait for the timer to expire if it already has working candidate(s) and want to send USE-CANDIDATE. Also keep in mind that the controlling agent has no clue (unless we implement some indicator) whether the peer supports PAC (and, if it does, what timer expiration value it uses), so we need to make sure the peer won't terminate ICE for not receiving USE-CANDIDATE. I don't think 8445 says anything about that - it assumes that the controlling agent will send USE-CANDIDATE at some point, and I guess it is an implementation issue for how long the controlled agent will wait for it. |
This wouldn't be a mandate, it would be a (at most) SHOULD-strength recommendation. |
The suggested text in PR #14 says that an endpoint can finalize ICE processing before the timer times out, if the endpoint has has working pairs in all checklists. |
[from the list]
... I think this implies that one shouldn't be too hasty to declare ICE completion either.
Since some implementations may malfunction if they don't get a USE-CANDIDATE quickly, I am not sure if we can wait the full STUN timeout interval, but perhaps a somewhat shorter delay (e.g. a few seconds) could be recommended before sending USE-CANDIDATE.
The text was updated successfully, but these errors were encountered: