Comments (12)
@masterada You made the original change so I am just tagging you here to make sure you are aware of the fix proposal. In case you have ideas or opinions. I would love to take in as much information as possible.
from ice.
Thanks. Currently i think we collect reflexive candidates sequentially, meaning if 10 interfaces time out that's 30 sec total. Instead we should do that parallel so we can bring that time down to 3 sec. I think we should wait for all candidates though, because waiting for the first only might break some setup. Whats worse, it might result in some setups occasionally not working (if 1 interface works as server reflexive, but it's not always retuned).
If we need to do better than 3 sec, that's what trickle ice is for (not waiting for server reflexive candidates at all, but sending them over signaling whenever they are ready).
I will have some time tomorrow (had a busy 2 weeks :( ), i can do this (parallel gathering) if you would like.
from ice.
@masterada I would prefer if we maybe work towards trickle?! I am doing "get default and continue, the rest collect in goroutine" right now. Maybe we could merge that and then hook up some kind of callback to get the trickle notify the OnIceCandidate?! Sort of a midway solution towards properly working trickle?
from ice.
Wihout trickle gathering the rest of server reflexive candidates is useless, as server reflexive candidates are ignored as local candidates when creating the checklist. They are only used by the other peer as its remote candidates, but only if he gets them (aka trickle). Once trickle is implemented there will be no point is handling default interface specially.
So if you want a quick fix i think you should simply only use the default interface only, no need for the background gathering as its results cant be used.
from ice.
With trickle, is the peerConnection responsible for notifying the remote peer (and initiating re-negotiations and so on) or all we have to make sure is that OnIceCandidate is invoked every time there is a new candidate and nil when the gathering is complete? If it's the former, I can implement that. Should be fairly simple. I would just add callbacks to the Agent and hook up peer connection to those callbacks.
from ice.
- OnIceCandidate must be called when new candidate is discovered
- there must be a method for adding new remote candidates (not sure of the method name)
- there should be an option for disabling trickle alltogether and waiting for all candidates
At least thats what i remember, but will have to read some more to be sure.
from ice.
sending the candidates between the peers must be solved by the user (via signaling)
from ice.
Okay. Thank you for your help. I will mess around with this tomorrow and try to get all three parts working.
from ice.
@masterada sleeping on this one thought.
Is it worth sending a request if we know it isn't route-able? I think in the 'worst case' we are using a bunch of interfaces that don't have a gateway (so just blocking for nothing)
Trickle ICE is awesome though! I assume it is going to take us some time, I can't do anything but TURN for the next few days (user has a June 1st deadline)
but thank you for contributing, and just work on what you enjoy/find interesting. Don't want to burn anyone out!
from ice.
@Sean-Der would you be okay with getting trickle in with a default flag as false. This way, for the next forseeable whatever, It will solve my issue because I will set the trickle flag to on but will not influence any other users. I will make the false flag cause the operation to work sync as it does now. Will just add the custom flag inside of the api
object.
from ice.
Is it worth sending a request if we know it isn't route-able
The whole point of ice is not to make such assumptions. For example, an aws ec2 instance may have tens of network interfaces, and even though usually the primary interface is the one facing the internet, there is no guarantee for that. You can for example add an elastic ip address to it which is not the default interface, or you may want your pion server to work inside a lan with a non-default interface (with the STUN server also running inside lan), or you might be running multiple softwares on it and don't want the default interface to be reachable from the outside word, or any other number of reasons.
So in the long run we should definietly iterate all interfaces (or all host candidates to be exact, because if the server reflexive candidates base address is the same as a host address, it can be eliminated during ice pairing which save time when selecting the working candidate pair, see: https://tools.ietf.org/html/rfc8445#section-6.1.2.4 ).
That said, using only the primary interface will probably cover 99% of usecases, so until we have trickle i think we can just go back to using the primary interface as you suggested.
from ice.
@masterada I am almost done with trickle. With complete asynchronous gathering. I am just fixing up the existing unittests to "wait" until gathering is complete to pass connection establishment. Let me make a PR in a few and we can go from there.
from ice.
Related Issues (20)
- Rename Agent.startOnConnectionStateChangeRoutine() to Agent.startRoutines() HOT 1
- Simplify Agent.updateConnectionState() HOT 1
- Reenable IPv6 UDPMux tests in i386
- Active TCP candidates? HOT 7
- Support server reflexive TCP candidate type HOT 13
- Fix type of CandidatePairState enum
- TestAgentActiveTCP test is failing due to data race
- Active TCP performs network operations in main thread HOT 7
- Connection failing to TCP candidate when listening on multiple interfaces using `MultiTCPMux` and `NAT1To1IPs` HOT 5
- Noisy warnings if TURN/STUN host is not reachable via IPv6
- Panic when adding candidate HOT 6
- bug(log): webrtc using ice will print wrong log HOT 1
- ice v2 depends on transport v2.2.2, which had a breaking change HOT 1
- Candidate type is not changed from peer-reflexive to host HOT 1
- Allow users to pass custom 'CandidateSelectorControlling` and `CandidateSelectorControlled` HOT 3
- ConnectionState changes may be reported incorrectly HOT 4
- Please add a new release tag HOT 2
- Android 11 ListenUDP permission denine
- Support ipv6 for mDNS Server HOT 3
- Start the listening port by default above 1024 HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from ice.