-
Notifications
You must be signed in to change notification settings - Fork 160
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
Only switch to failed after all candidates are exhausted? #271
Comments
@Sean-Der just clarifying, it should only fail if Cause it would break this test (potentially implementation). Line 1307 in 62d1c40
|
Hey @scorpionknifes Sorry for the confusion, but I don't think we can move forward on this. Behavior between browsers is inconsistent. I am afraid to implement something and then have browsers diverge. I am sorry I didn't do more research before recommending this issue :( |
We should love your PR though, and maybe engage with webrtc-pc on what is the proper behavior? |
Small timeout when eoc is received, larger timeout if it isn't? |
@jech cool idea. idk if this is a feature people want? |
There's a tradeoff here: on the one hand, we don't want to give up too early, on the other hand, we want to switch to failed as early as possible so as to give the user timely feedback and possibly trigger an ICE restart. Question: would using the end-of-candidates indication allow us to fail faster without breaking connectivity in cases where it currently works? |
Allow a user to pass a nil Candidate. We perform no actions off of this currently. Until browsers implement end-of-candidates consistently it isn't something we can do. Relates to pion/webrtc#1212 and #271
There is some related discussion at https://tools.ietf.org/html/draft-ietf-ice-trickle-21#section-14. |
As pointed out in pion/webrtc#1212 (comment) , Pion's handling of the
failed
state is somewhat naive: Pion will switch tofailed
if connectivity cannot be established even if it hasn't received an end-of-candidates indication.There's a tradeoff here: the current behaviour works well enough in practice, and it gracefully handles the case when the peer never sends an end-of-candidates indication. On the other hand, it means that if the peer is performing expensive gathering (e.g. because a TURN server is overloaded), we might spuriously switch into
failed
.The text was updated successfully, but these errors were encountered: