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

Hey Robin,

On Sun, Apr 13, 2014 at 4:07 PM, Robin Raymond <robin@hookflash.com> wrote:
> [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).

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.

> [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.

That's true. Just as it is true that very often the same ufrag and
password are used for all RTP/RTCP streams.

> 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.

> 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.

> 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.

> [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.

Emil

-- 
https://jitsi.org

Received on Sunday, 13 April 2014 14:36:01 UTC