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

Hey Robin,

On Sun, Apr 13, 2014 at 6:00 AM, Robin Raymond <robin@hookflash.com> wrote:
>
> ICE requires freezing for 'related' candidates between components. For
> example, should RTP and RTCP use different ports, you should unfreeze the
> RTCP candidate searches based upon the success of the RTP ports to avoid
> needless candidate searching.

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

> The question is to add an API call to make the freezing/unfreezing
> association explicit, or have some kind of magic under the hood that
> automatically freezes / unfreezes based upon foundation local:remote
> matching rules.

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?

> Freezing ICE candidate searches must be possible based on foundation /
> component pairing. The trouble is how to correctly know the sessions are
> related and which is the base ICE component and which is the derived ICE
> component.

For RTP, RFC5245 explicitly makes RTP the first one and the RTCP the
second (derived) one.

The same question however would also need an answer across multiple
media streams or non-RTP protocols.

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.

> If the local:remote ICE candidate foundation pairing match across
> `RtcIceTransport` sessions, you can automatically determine which
> `RtcIceTransport` candidate search is frozen based on a simple rule like
> "last constructed `RtcIceTransport` object candidate search is frozen based
> upon previously constructed `RtcIceTransport` where the local:remote
> foundations match".
>
> There's only one issue with these rules when freezing is used. While not
> technical required, a requirement has historically been that freezing
> components use the same usernameFrag / password across ICE components (e.g.
> RTP port and RTCP port must share the same usernameFrag/password). If we
> make the entire local:remote foundation pairing freezing automatic but fail
> to set the same usernameFrag/password we will not have the correct
> behaviour.

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.

> Making every `RtcIceTransport` constructed using the same
> usernameFrag/password to get around this problem is not a good solution.
>
> So the option I can see is make freezing/unfreezing automatic / implicit
> based upon foundations local:remote matching rules and base the freezing
> upon order of construction

+1

> but have the usernameFrag/password reuse based
> upon an explicit API call.

That's the part I don't understand.

> For example, to share usernameFrag/password add a factory method to the
> `RtcIceListener`:
>
> ````
> partial interface RtcIceListener {
>   static ICEListener createUsingCredentialsFrom(RtcIceListener
> existingListener);
> };
>
> e.g.:
> RtcIceListener rtpListener = RtcIceListener.create();
> RtcIceListener rtcpListener =
> RtcIceListener.createUsingCredentialsFrom(rtpListener);
> ````
>
>
> The question I have:
>
> Do people think implicit auto-freezing rules based upon foundation
> local:remote matching rules are a good idea? Should the freezing
> relationship be more explicit (e.g. explicit relationships between
> `RtcIceTransport` objects?

I think this should be automatically handled by an ORTC
implementation's ICE stack as much as possible and the application
should be able to live happily without bothering with it. (This should
be achievable for basic use cases).

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. I don't think we can do better. Getting things right would
impact the signalling in many cases and there's nothing we can do
about that.

Emil


-- 
https://jitsi.org

Received on Sunday, 13 April 2014 11:21:44 UTC