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

[Kai Vehmanen]

Hello all,

a new draft of IETF ICE (-10) was published last week:
- http://tools.ietf.org/wg/mmusic/draft-ietf-mmusic-ice/
- http://www.jdrosen.net/ice-10.pdf

Here's some of the possible changes that are required for StreamEngine 
interface to support connection managers that require ICE (at least SIP, but 
might also affect upcoming revisions of Jabber JEP-176):

* The semantics of username and password arguments need finetuning (but
   the API itself is sufficient I believe). See ICE draft sect 4.4.

* The username/passwords are no longer per candidate. This does not
   however impact the S-E interface.

* The relay, server-reflexive (stun) and peer-derived candidates should
   have a link to their base candidate (from which candidate they were
   derived from). Affects TP candidate/transport structs.

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

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

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

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

* OPEN: whether the 'frozen' candidate attribute needs to be exposed
   to S-E API -- probably not.

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

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