ICE freeze dependency and sharing

[robin-raymond]

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.

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.

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.

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.

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 but have the usernameFrag/password reuse based upon an explicit API call.

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?

[robin-raymond]

http://lists.w3.org/Archives/Public/public-ortc/2014Apr/0035.html

[martinthomson]

I don't ever like to see static methods that have an instance of the enclosing class as the first argument. Try:

partial interface RtcIceListener {
   ICEListener createLinked();
};

Linked listeners can be frozen in the order that they are created, sure. It might be enough to say that they need to be created in a chain to guarantee order. I.e., A -> B -> C -> D rather than A -> B, A -> C, A -> D, where order between B and D might be non-deterministic.

[robin-raymond]

What about freezing non-linked listeners?

The point in this particular case about creating a "linked" IceListener was more about sharing same usernameFrag:password combination and less about freezing. RTP/RTCP will share usernameFrag:password but independent audio/video ports don't need to share the same usernameFrag:password but still require freezing.

That's why I proposed only making it about order of creation without foundation local:remote matching and not having to do with the chaining/linking of usernameFrag:password pairs.

[martinthomson]

So different m= sections don't need to share ufrag/pwd, but they can. I don't see any issue with overloading this so that only those lines with the same ufrag/pwd (i.e., linked listeners) are frozen together.

[robin-raymond]

Right. And yes, freezing is pretty clear when objects are linked. The trouble is we have to support freezing when the objects are not linked (e.g. audio port where video port does not share ufrag:password but still freezes upon audio). So to me, do we auto-freeze based upon a common local:remote foundation match, and base the freezing order upon object construction order? Or do we make the developer use the linkage of audio/video ports freezing more explicit by requiring a linkage of some sort (even if ufrag:password is not linked).

[martinthomson]

I think that you missed my point. Why do we need to have different ufrag/pwd AND freezing. I can't think of a reason.

[aboba]

Peter's proposal: http://lists.w3.org/Archives/Public/public-ortc/2014May/0003.html

[aboba]

I think there is an issue with the proposal. When RTP and RTCP aren't multiplexed don't you also need two ICE listeners?

[robin-raymond]

Hmm... yes, there's an issue. In the non muxed case you need two IceLIstener objects as you need a different set of candidates for RTCP. So the only way this could work is if the "associate" transport would get it's own IceListener implicitly. This IceListener would have to be implicitly shared should any other forked RTP transports also create their own associated IceTransports. I think this issue needs to be brought back to the list. There's a solution but it would be good to solicit feedback.

[aboba]

Comment from Shijun Sun: http://lists.w3.org/Archives/Public/public-ortc/2014May/0145.html

[aboba]

Peter's proposal added in the latest editor's draft:
http://ortc.org/wp-content/uploads/2014/06/ortc.html

[aboba]

Can we close this?