[Bug 30972] Add NewActiveCandidatePairWithInfo to StreamHandler

[bugzilla-daemon at freedesktop.org]

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

--- Comment #2 from Simon McVittie <simon.mcvittie at collabora.co.uk> 2010-10-28 05:01:50 PDT ---
Sorry, that comment made no sense, because I mixed up candidates and
transports. Let me try again.

If I understand correctly, when the streaming implementation calls
NewActiveCandidatePairWithInfo(ni, nt, ri, rt), that gives us up to five
things:

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

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

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)

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

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

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

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.

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