ice icon indicating copy to clipboard operation
ice copied to clipboard

Wrong remote candidate is selected

Open jech opened this issue 5 years ago • 7 comments

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-cost to 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.

jech avatar Nov 28 '20 14:11 jech

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.

jech avatar Nov 28 '20 22:11 jech

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.

jech avatar Dec 05 '20 17:12 jech

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?

jech avatar Dec 06 '20 22:12 jech

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.

jech avatar Dec 09 '20 21:12 jech

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 avatar Dec 12 '20 19:12 jech

@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

aziztitu avatar Mar 19 '22 07:03 aziztitu

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

jech avatar Mar 19 '22 12:03 jech