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

How to learn nominated candidate? #527

Closed
thomaseizinger opened this issue Jun 10, 2024 · 5 comments
Closed

How to learn nominated candidate? #527

thomaseizinger opened this issue Jun 10, 2024 · 5 comments

Comments

@thomaseizinger
Copy link
Collaborator

thomaseizinger commented Jun 10, 2024

This is a somewhat related problem to #525. Currently, NominatedSend event only includes the local source socket to send from.

In case a server-reflexive candidate gets nominated, the source address will be set to the server-reflexive candidate's base which is the same as a host candidate's address. So it is impossible to know whether the host or the server-reflexive candidate got nominated.

Would it make sense to emit the two candidates instead?

@algesten
Copy link
Owner

This is an abstraction. It deliberately does not try to tell you candidates. Instead it says "send to this IP from this IP". What candidates that might correspond to is an internal detail, since you would not have declared all of them (some are dynamically discovered).

Do you need to know the exact candidates?

@thomaseizinger
Copy link
Collaborator Author

Do you need to know the exact candidates?

Currently, we are still invalidating candidates to achieve a smooth roaming of sockets that does not rely on waiting for the ICE timeout. In order to invalidate them, I need to loop over local_candidates and find the candidate again that got nominated. But in the case of host and server-reflexive candidates, that is ambiguous.

@lolgesten
Copy link

Alright. So if you are going down the ICE restart route. Would that change things?

@thomaseizinger
Copy link
Collaborator Author

Alright. So if you are going down the ICE restart route. Would that change things?

A little bit. It would still be useful to know whether I am connected via a relay candidate or not. Sending from a relay candidate requires wrapping messages in channel data messages and sending them to an entirely different socket. To learn about that, I still need to search through the list of local candidates for the one I added.

I get the idea of the abstraction but I am not sure it makes much sense. If my input are candidates, then the output should maybe be as well? It is not like IceAgent can hide the concept of candidates from me.

@algesten
Copy link
Owner

I think this is "in spirit" with the spec (see other issue): #525 (comment)

@thomaseizinger thomaseizinger closed this as not planned Won't fix, can't repro, duplicate, stale Jun 10, 2024
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

No branches or pull requests

3 participants