[Bug 30972] Add NewActiveCandidatePairWithInfo to StreamHandler

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=30972

--- Comment #3 from Louis-Francis Ratté-Boulianne <louis-francis.ratte-boulianne at collabora.co.uk> 2010-10-28 08:53:34 PDT ---
(In reply to comment #2)

Ok, so first, let me explain an important detail:

 1- The signal is emitted each time a new pair is selected for a component. So
it's a "Candidate pair" in [farsight, ice] world but in Telepathy world, it
should be called a "Transport pair". I'm using the wrong terminology, but so is
current NewActiveCandidatePair that is emitted for each component as well (and
it doesn't even tell us which component).


Why do I need the selected candidate pair details so badly ?

 2- According to the ICE spec (RFC 5245), once ICE discovery process is
completed (doesn't mean you have a valid pair for each component), we need to
send an updated offer (re-INVITE). See also "B.9. Why Send an Updated Offer?"
of the ICE spec.

   2a- The SDP body of that re-invite need to contains the "default candidate"
encoded in the m and c lines. We need the selected local candidate.  The bottom
line is that some gateway devices use these SDP informations.

   2b- That re-invite contains a "a=remote-candidate" line listing selected
remote candidates.


Can't we just use the ID to find candidate details on CM side ?

 3- Peer-reflexive candidates are not known by the connection manager. 

   3a- We could in theory know about local ones, but right now, tp-farsight
only emits NewNativeCandidate when Prepared is called. Also, to emit the new
candidate (after Prepared), we would need to wait for all transports to be
discovered and it's not sure that would happens. (according to Olivier, we only
really need the RTP component)

   3b- There is absolutely no way to find out about remote ones.


> A. tells us that the active candidate pair is (ni, ri), exactly equivalent to
> NewActiveCandidatePair(ni, ri)

Yes

> B. potentially tells us a new native candidate (which is restricted to having
> exactly one transport) that we didn't already know about, which is equivalent
> to getting NewNativeCandidate(ni, [nt]) just before NewActiveCandidatePair

Not restricted to one transport (See [1])
Not really equivalent...it's equivalent to (fictional) NewNativeTransport just
before NewActiveCandidatePair (that doesn't tell us which component is
affected)

> C. potentially tells us a new remote candidate, restricted to having exactly
> one transport, that wasn't in the signalling (is that even meaningful? in the
> current API, the CM is assumed to know all remote candidates from the
> signalling, and feed them to the streaming implementation)

Not restricted to one transport (See [1])
CM doesn't know about all remote candidates (See [3b])

> D. tells us which one of the native candidate's transports the streaming
> implementation has actually chosen to use (is this meaningful?)

Yes, see [2a]

> E. tells us which one of the remote candidate's transports the streaming
> implementation has actually chosen to use (is this meaningful?)

Yes, see [2b]

> Which of those five things are actually needed here? Obviously (A) is.

All of them

> Note that NativeCandidatesPrepared just means that all native candidates have
> been discovered *for the moment* (the spec specifically says so), so I think
> CMs should be prepared to deal with NewNativeCandidate at any time.

tp-butterfly could be prepared to deal with it, but that's not gonna happen
(See [3a])

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.