Browser selects different candidate pair than alohacam

[jwgcarlson]

Noticed this happening semi-regularly on my sister's wifi network (about 50% of the time).

Firefox's about:webrtc says it selected the IPv4 candidate pair:

But the alohacam debug logs show it selecting an IPv6 pair: alohacam-debug-logs.txt

[jwgcarlson]

I think what we're seeing is a case of "aggressive nomination", where the browser is nominating multiple candidate pairs. When multiple candidate pairs are valid and nominated, there's a chance that the browser will select a different pair from alohartc, which seems to be what's happening.

Aggressive nomination was deprecated in RFC 8445, which is what our implementation follows. However, I overlooked the parts where it says most implementations will likely continue to follow RFC 5245. Setting a=ice-options:ice2 is supposed to disable the aggressive nomination algorithm, even in controlling agents that are unaware of RFC 8445, but it doesn't seem to have any effect in either Chrome or Firefox.

Supporting aggressive nomination shouldn't be hard. We just need to be able to replace the selected candidate pair when a higher-priority, nominated-and-valid pair is found.

[jwgcarlson]

As I was looking at this more closely, I noticed something else troubling. Somehow, the first couple ICE candidates that the browser advertises are not being received by alohacam. You can see an example in the logs attached above. Both the IPv4 candidate (10.0.0.185 port 59380) and the IPv6 candidate (2601:1c0:5b80:5b3f:1e1b:b5ff:fedf:84e6 port 38126) are discovered as peer-reflexive candidates (i.e. in response to a browser STUN request), not through the normal signaling channel. This suggests some kind of race condition in how we pass ICE candidates from the browser, through the API server, to alohacam.