[Telepathy] list of S-E changes needed for ICE-10
robtaylor at floopily.org
Wed Sep 6 08:56:20 PDT 2006
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
> * 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 :)
More information about the Telepathy