Skip to content
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

Closed
juberti opened this issue Apr 18, 2019 · 9 comments · Fixed by #17
Closed

Should ICE agents wait for all prflx candidates before sending USE-CANDIDATE? #7

juberti opened this issue Apr 18, 2019 · 9 comments · Fixed by #17

Comments

@juberti
Copy link
Collaborator

juberti commented Apr 18, 2019

[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.

@cdh4u
Copy link
Owner

cdh4u commented Apr 19, 2019

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?

@juberti
Copy link
Collaborator Author

juberti commented Apr 19, 2019

I think that scenario is in scope. Basically, the agent should wait for prflx candidates, and not prematurely finish or fail ICE.

@cdh4u
Copy link
Owner

cdh4u commented Apr 20, 2019

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.

@juberti
Copy link
Collaborator Author

juberti commented Apr 20, 2019

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.

@cdh4u
Copy link
Owner

cdh4u commented Apr 20, 2019

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.

@juberti
Copy link
Collaborator Author

juberti commented Apr 21, 2019

There's no text preventing it, but this is a non-obvious finding, so I think it is worth calling out in this doc.

@cdh4u
Copy link
Owner

cdh4u commented Apr 21, 2019

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.

@juberti
Copy link
Collaborator Author

juberti commented Jul 8, 2019

This wouldn't be a mandate, it would be a (at most) SHOULD-strength recommendation.

@cdh4u
Copy link
Owner

cdh4u commented Jul 8, 2019

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants