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

[RR] see inline comments

> Emil Ivov <mailto:emcho@jitsi.org>
> April 13, 2014 at 10:35 AM
> [...]
> [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).
>
> I don't think this is true. There are a number of gatwaying scenarios
> where we may want to have media-level compatibility between a web
> application and something else.

[RR] Not really relevant to the issue but just as a point of clarity, 
because web apps don't do implicit signaling, and you are in control of 
signaling and what devices / services you interact with so therefor you 
are in control over how you interact. As you aren't randomly interacting 
with unknown systems, you know what you are going to get and expect. 
However, if you chose to signal with unknown / uncontrolled systems, 
that's still your choice and your pain on how to handle all the bizarre 
odd cases that arise. ORTC should just provide the tools so that you can 
be compliant with most reasonable deployments. You have full control 
over what happens and how you choose to meld those systems together.

>> 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
>
> You mean that as a restriction only for RTCP right? I don't see how
> the reasons are security-related but I agree that setting a separate
> password for RTCP is entirely unnecessary.
[RR] It's not just unnecessary, it's actually required they be the same. 
The API does not allow changing of the ufrag:password. There's been past 
discussion about legality of changing ufrag:password to prevent various 
attacks and moving the agreement to Dtls. I've not heard any conclusion 
to that argument so as far as I'm aware the ufrag:password is still not 
allowed to be set by the web application.
>> 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
>
> Given how different streams can use the same or different ICE
> credentials, I don't see how this could be achieved.
[RR] Agreed, which is why even though the majority of the use cases, it 
works. It doesn't alway work which is why I prefer a different rule.

>> 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.
>
> Copying from where to where? Sorry, I guess I am still confused by
> what password and ufrags could possibly have to do with freezing.
[RR] The RtcIceListener contains the ufrag:password. All 
RtcIceTransports that derive from the same RtcIceListener must share the 
same ufrag:password because they share the same physical socket ports. 
If you want to create a different listener (i.e. different port like an 
RTCP port), you need to be able to copy the ufrag:password from the 
existing RtcIceListener since the web application is not allowed to 
manually change the ufrag:password. The freezing has nothing to do with 
this at all. It's just that freezing is mostly used in the RTP/RTCP port 
scenarios where the ufrag/password are shared.

>> [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).
>
> I think it could always be made to work but the application would have
> to "recall" order of creation. This could be bug-prone in cases where
> streams are continuously added and removed. Given that the API would
> have this order anyway and that it will rely on it, it might as well
> make it available to the application for convenience.
[RR] I'm trying to avoid needless APIs (especially confusing ones like 
"freezing"). However, if people think order of construction is not 
sufficient because it's too complicated to handle more complex scenarios 
then we can expose an explicit method to 'tweak' the order. Although I'm 
not sure what that would be... a straight integer, and what to do if 
it's set wrong (e.g. all RtcIceTransports have the freeze order set to "1").
> [...]
>
>