Juliusz Chroboczek

There is some related discussion at https://tools.ietf.org/html/draft-ietf-ice-trickle-21#section-14.

I can confirm that the priorities of Chromium's host candidates are reasonable: * 2122262783 for the IPv6 address of the Ethernet interface; * 2122194687 for the IPv4 address of the...

I am no longer able to reproduce this — it looks like Pion is choosing the candidate with the highest priority, as it should. Closing for now.

The issue cannot be reproduced locally, but it is definitely there when the server is remote. Interestingly enough, if I trigger an ICE restart after the connection is established, then...

After investigation, it looks like Pion's ICE code does the right thing wrt. priorities — the code that selects the highest priority candidate pair looks correct to my untrained eyes....

After adding ``` s.SetHostAcceptanceMinWait(2000 * time.Millisecond) s.SetSrflxAcceptanceMinWait(2000 * time.Millisecond) s.SetSrflxAcceptanceMinWait(2000 * time.Millisecond) s.SetPrflxAcceptanceMinWait(2000 * time.Millisecond) ``` Pion still chooses the wrong candidate. Still trying to understand the issue.

No, I never did. I tried tweaking all sorts of constants in the code, and I still got randomly wrong choices.

Interesting. Race here? https://github.com/pion/ice/blob/master/gather.go#L71

I don't think that's correct. If `gatherCandidates` is being called twice, your code would only close the channel once, leading to a hung goroutine somewhere. We need to understand the...

Could you please try this? (It's not wholly correct, but it should fix your immediate issue. We really should clean up the locking in gather.go, it's way too fine-grained, and...