ICE freeze dependency and sharing #57

Closed
robin-raymond opened this Issue Apr 13, 2014 · 13 comments

Projects

None yet

3 participants

@robin-raymond
Contributor

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?

@martinthomson
Member

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
Contributor

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
Member

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
Contributor

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
Member

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.

@robin-raymond robin-raymond added the 1.1 label Apr 30, 2014
@aboba
Contributor
aboba commented May 7, 2014

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
Contributor

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.

@robin-raymond robin-raymond pushed a commit to robin-raymond/ortc that referenced this issue Jun 15, 2014
Robin Raymond - Added support for non-multiplexed RTP/RTCP and ICE freezing, as des…
…cribed in Issue 57


w3c#57

- Added support for getRemoteCertificates(), as described in Issue 67
w3c#67

- Removed filterParameters and createParameters functions, as described in Issue 80
w3c#80

- Partially addressed capabilities issues, as described in Issue 84
w3c#84

Addressed WebIDL type issues described in Issue 88
w3c#88

- Addressed Overview section issues described in Issue 91
w3c#91

- Address readonly attribute issues described in Issue 92
w3c#92

- Added ICE restart method to address the issue described in Issue 93
w3c#93

- Added onerror eventhandler to sender and receiver objects as described in Issue 95
w3c#95
f74b889
@aboba
Contributor
aboba commented Jun 15, 2014

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

@aboba
Contributor
aboba commented Jun 20, 2014

Can we close this?

@robin-raymond
Contributor

Yes.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment