Does candidate order matter? #280
-
|
My signaling server does not guarantee the order of candidate messages due it's design. In this case I also do not mark the gathering done for the remote. Does the order matter here? Is it better to not use "trickle" and send them all at once for a scenario such as this? I did not see this mentioned in the RFC (https://www.rfc-editor.org/rfc/rfc5245) and assume libjuice uses it's own algorithm to obtain best pairs as candidates get added regardless of order. Thanks for the great work here and any advice. |
Beta Was this translation helpful? Give feedback.
Replies: 2 comments
-
|
Candidate order doesn't matter. ICE candidates have priorities to decide which candidate pair is the best one, and libjuice uses the suggested formula to calculate priorities. It is better to trickle candidates as it allows connectivity checks to start immediately for gathered candidates which can reduce the connection time. If candidates are sent all at once, a STUN or TURN server failure means connection will be delayed until that server times out. The gathering done event is not very useful, it only helps shorten the timeout to fail earlier if no other candidates are expected. You can safely ignore it. |
Beta Was this translation helpful? Give feedback.
-
|
Thanks for the clarity, I did not thoroughly read the specification enough. |
Beta Was this translation helpful? Give feedback.
Candidate order doesn't matter. ICE candidates have priorities to decide which candidate pair is the best one, and libjuice uses the suggested formula to calculate priorities.
It is better to trickle candidates as it allows connectivity checks to start immediately for gathered candidates which can reduce the connection time. If candidates are sent all at once, a STUN or TURN server failure means connection will be delayed until that server times out.
The gathering done event is not very useful, it only helps shorten the timeout to fail earlier if no other candidates are expected. You can safely ignore it.