ICE Lite is not considered when determining ICE controlling/controlled

[OxleyS]

We currently set str0m unconditionally as the ICE controller when it is the initial offerer. However, according to RFC 5245 Section 5.2:

One agent full, one lite: The full agent MUST take the controlling role, and the lite agent MUST take the controlled role.

Assuming the other end is a full agent, str0m in lite mode must set itself as controlled, even as the initial offerer. If that's all there was to it, I'd just go straight to opening a PR 🙂 However, the RFC also says:

Both lite: The agent that generated the offer which started the ICE processing MUST take the controlling role, and the other MUST take the controlled role.

So in this instance, str0m would be doing the right thing, but it's not clear how we're supposed to tell whether the other side is ICE lite or not if we're the initial offerer (and thus have no remote ice-lite attribute to base it on). We would have to switch our role based on the answer, I think, but that might be too late?

Not entirely clear what the best approach here may be (other than utilizing direct API, of course). While I decided against using ICE Lite in my project, since I found this I thought it might be good to file anyway, at least.

[algesten]

Nice find!

That documentation about panic seems wrong. I can't see any reason this would panic. However changing the controlling after starting to form pairs of local-remote candidates would be wrong (since it affects candidate prio).

I think this is a simple fix, we can change the controlling mode given the response from the remote. So if we are ice-lite and remote answers ice-lite, we change controlling to true, since we were the offerer.

[OxleyS]

Ah, okay, I wasn't sure if it was okay to change the controlling mode at the point of receiving the answer, but I can see how it is. I might take a stab at this next week.