ice
ice copied to clipboard
Wrong remote candidate is selected
Unnamed SFU using Pion running on remote host. Client is Chromium on Linux and is multihomed: has both an Ethernet and a Wifi connection. The client offers four host candidates, IPv4+IPv6 for each of the two interfaces.
When Chomium is the controlling agent, then the Ethernet interface is chosen. When Pion is the controlling agent, on the other hand, the WiFI interface is chosen deterministically.
A few other elements:
- Chromium sets the candidate priorities correctly (Ethernet higher than WiFi);
- Chromium sets the
network-costto 10 for the WiFi candidates; I believe this is described in https://tools.ietf.org/html/draft-thatcher-ice-network-cost (expired).
It is my understanding that Pion does not use the network cost, but that the candidate priority should be enough to do the right thing. This may be related to https://github.com/pion/ice/issues/82.
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 Ethernet interface;
- 2122131711 for the IPv6 address of the WiFi interface; and
- 2122063615 for the IPv4 address of the WiFi interface.
So it definitely looks like there's something wrong with Pion's candidate selection.
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 Pion switches to the right candidate. So this might very well be a timing issue: the WiFi candidate is chosen before the Ethernet candidate is received. Perhaps delaying ICE by a fraction of a second would help?
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.
@Sean-Der has suggested that the wrong selection might be due to defaultHostAcceptanceMinWait in agent_config.go being 0.
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.
@jech Were you able to find a solution for this? I'm facing a similar problem at the moment. Pion seems to choose a Relay candidate with higher priority while a srflx candidate with lower priority is available
No, I never did. I tried tweaking all sorts of constants in the code, and I still got randomly wrong choices.