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.

Sign up for GitHub

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

Jump to bottom

Question: Candidate Gathering #2

Open
4ydx opened this issue Oct 14, 2016 · 1 comment
Open

Question: Candidate Gathering #2

4ydx opened this issue Oct 14, 2016 · 1 comment

Comments

@4ydx
Copy link

4ydx commented Oct 14, 2016 •
edited

How difficult would you consider adding this feature to be?

Local candidate gathering is based on local interfaces and tunnels according to the rfc. I'm not sure how tunnel discovery would work. As for other possible candidates, this is where STUN and TURN come in correct? So this really only requires writing a method that gathers candidates using the STUN server you have already created? In the simple form; expanding to TURN later.
@pixelbender
Copy link
Owner

pixelbender commented Oct 14, 2016 •
edited

@4ydx Yes, exactly, ICE may use candidates discovered by STUN (server reflexive) and TURN (relayed) candidates. Right now I am working on multiplexed STUN transport. It allows usage of ICE or other protocols (such as RTP, RTCP, DTLS) over the same net.Conn. Gathering ICE candidates is pretty simple. But there are other procedures to implement: prioritizing, selecting pairs, restarting, etc.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@pixelbender @4ydx