[Telepathy] list of S-E changes needed for ICE-10

[Kai Vehmanen]

Hi,

On Wed, 6 Sep 2006, Rob Taylor wrote:

>> * Unlike in JEP-176, ICE-10 has strict rules when an endpoint can
>>   send media (finding a valid candidate pair is not sufficient). A second
> Yeah, the second round is certainly something that's SIP specific - as
> stated in ICE-10, this round is required so the m/c line has the correct
> values to support legacy infrastructure. I'd hope for updates to JEP-176
> we can drop that.

true, although similar needs (adding passive on path components that need 
to know which candidate-pair was selected) might turn up for Jabber as 
well some time in the future (there has been a clear market demand for 
these devices in SIP). Also the second o-a round has the benefit of 
avoiding unnecessary swapping between different network paths for RTP 
traffic that can cause trouble to jitter buffers (nasty if happens 
systematically during every call).

> I'm a little confused about what's insufficient about using
> NewActiveCandidatePair, though :/ (apart from it currently being
> unimplemented...)

The In-Use-Candidate concept is somewhat different:

- you need to set one when initiating a session (i.e. when information
   about remote candidates is not yet available)
- ICE mechanism has come up with an "active" pair of candidates that
   are different from the current "In use" candidate pair

And the semantics of SetActiveCandidatePair need to be carefully defined. 
>From ICE POV, this call does not make sense as it's the ICE engine that 
finds a candidate pair - not a set up possible pair, but one pair (this is 
where the preferences come into play).

So I'd interpret SetActiveCandidatePair as a kind of forced override 
method, but it's not obvious what the semantics are. My vote would go for 
defining SetActiveCandidatePair as a "disable ICE and just use these 
transports" method (not to be used unless the stream-engine client wants 
to stop using ICE).

>> * The priority scheme has changed radically and the pref values are now
>>   represented as 32+bit integers. The TP interface currently uses a double
> I was actually thinking about changing it from a double to an INT64 (or
> INT32 if the problem of >32bit long prefs is fixed)

It's now going to be a INT64, which might cause some headaches as a double 
has less significant bits we can use.

>> * API for S-E to report new discovered remote candidates (peer derived).
> Yep, this wasn't added to the current spec we just weren't sure whether
> it was staying or not =)

I also was expecting this to go away, but still seems to be there. There 
is a race condition related to the two-rounds-of-offer-answer that seems 
unsolvable without the remote-candidates attribute (see sect A.8 of 
draft-ietf-mmusic-ice-10.txt).

>> * OPEN: whether the 'frozen' candidate attribute needs to be exposed
>>   to S-E API -- probably not.
> yeah, I think candidate types can pretty much stay within the ICE
> implementation - it doesn't seem to be needed in any signalling.

True. Although the type info (not 'frozen', but native 
derived/server-reflexive, or relayed information is useful in case the 
clients wants to override the ICE process with SetActiveCandidatePair).

-- 
  under work: Sofia-SIP at http://sofia-sip.sf.net