Skip to content

ICE freeze dependency and sharing  #57

Closed
@robin-raymond

Description

@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?

Metadata

Metadata

Assignees

No one assigned

    Labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions