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

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?

Issue filed as: https://github.com/openpeer/ortc/issues/57

-Robin

Received on Sunday, 13 April 2014 04:01:02 UTC