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

[Rob Taylor]

Kai Vehmanen wrote:
> Hello all,

Hey Kai, thanks for taking the time to look thought it :)

<snip stuff I agree with, but need to think a bit about :) >

> * 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
>   round of offer/answer is needed to active media flow in both
>   directions, although in some cases media can flow already
>   before that. This is perhaps specific to SIP, but would require
>   support in the S-E API. Basicly new things needed are:
>   1) information whether we are offerer or answerer, and 2) enabling to
>   set and query the local and remote In-use Candidates (also a new
>   concept in -10 draft).

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.

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

> * The priority scheme has changed radically and the pref values are now
>   represented as 32+bit integers. The TP interface currently uses a double
>   value for the candidate pref, which should be enough.

I was actually thinking about changing it from a double to an INT64 (or
INT32 if the problem of >32bit long prefs is fixed)

> * API for S-E to report new discovered remote candidates (peer derived).
>   Unlike with JEP176, ICE requires the signaling to be aware of the
>   discovered remote candidates (for the second offer/answer round).

Yep, this wasn't added to the current spec we just weren't sure whether
it was staying or not =)

> * If the offer has 'remote-candidates' list, this has to be
>   delivered to S-E so it can act according to the spec (sect:9.2).

Yep, ditto above

> * 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.

> Some notes:
>  - ICE -10 is still a draft and is still subject to change; but changes
>    are expected to be minor (between -10 and the eventual RFC)
>  - this mail covers just the interface changes -- an actual ICE-10
>    implementation (farsight plugin) is a separate issue
> 

I was recently pointed at this project:
http://developer.berlios.de/projects/sice/ It seems pretty early days
for it yet, but it might be worth investigating and helping them out :)


Thanks,
Rob Taylor