Chrome Version: (64.0.3282.24)
OS: (Any)

What steps will reproduce the problem?
(1) Connect from Chrome to an ICE-lite endpoint. For example, https://apollo-lt.bbcollab.com/guest/dbb7f65a323b4a5bb5694652a1b09d88
(2) After a while watching a spinning circle, connection attempt fails.  Upon further investigation, it appears the ICE negotiation is failing.

What is the expected result?

User joins conference room after successful ICE negotiation.
Since the Collaborate MCU uses an ICE-lite implementation, according to RFC5245 Chrome MUST take the ICE-CONTROLLING role (section 5.2), and should nominate a single candidate pair using the USE-CANDIDATE attribute (section 8.1.1).

What happens instead?

Chrome is advertising itself as ICE-CONTROLLED in STUN requests, and never nominating a candidate pair.  ICE negotiation fails after a timeout.

Corresponding WebRTC bug: https://bugs.chromium.org/p/webrtc/issues/detail?id=8531

And fix: https://webrtc-review.googlesource.com/26780

This is expected to affect all ICE-lite implementations, so it has a high severity. We'd like it to be merged to M64 if possible. Unfortunately I couldn't find statistics indicating how many sites are ICE-lite, but it's expected to be non-trivial.