Re: ICE candidate search freezing and reuse of usernameFrag/password for components

[EI] Just to be clear, by "searching" you mean performing connectivity checks, right?  

[RR] Yes.

[EI] Do you have any use cases in mind where the application would need to
know about the "frozen" state of candidate pairs? Or is this just
about how to make sure that stacks interoperate properly?

[RR] To make sure the stacks operate properly. Getting the order wrong means connectivity check failures.

[EI] RFC5245 handles this by basically using the order in which streams appear in SDP. This obviously wouldn't work here but I think your suggestion of using order of creation is a good way to do it. The only problem with this is that there is no way to guarantee the order will be the same on both sides. I don't think ORTC can solve that in any other way than providing its component order and documentary guidelines to users.

[RR] Web application is in control of both sides, therefor it can use the same logic to control construction order (or ensure at least one side constructs the order respective to the other side).

[EI]I am afraid I lost you here. I don't see any requirement (technical or historical) that would make freezing dependent on ufrag:pwd distribution. Maybe I am missing something.

[RR] There's no direct dependency. However, the majority of freezing use cases are directly related to RTP vs RTCP port pairings. In SDP, the ufrag:password for SDP must be the same for RTP / RTCP. So while not technically related, in practice they go hand in hand for most use cases. The ufrag:password for RTCP must be copied from RTP and since the web app isn't allowed to set a custom ufrag:password for security reasons thus the only way to make sure the ufrag:password match is via copying the credentials from an existing RtcIceListener. In theory you could tie some of the freezing behaviour based on that association but I was suggesting we do it exclusively based on construction order and local:remote foundation matches and leave the ufrag:password copying as an independent and unrelated operation.

[EI]I think we could still add some sort of a component order indication however (e.g. getFreezeOrder() ) that would help with the less obvious cases.

[RR] I don't really see a reason to ever need anything more than construction order and local:remote foundation matches. Can you layout any use cases where this would not work? Remember, the web app is in control of both sides (even when the other side is not a web app).


-Robin