[Bug 34189] Call: Needs extra states for the Endpoint per component

[bugzilla-daemon at freedesktop.org]

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

David Laban <david.laban at collabora.co.uk> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |david.laban at collabora.co.uk
             Blocks|                            |31280

--- Comment #3 from David Laban <david.laban at collabora.co.uk> 2011-03-11 07:36:10 PST ---
(In reply to comment #2)
> Lets try to remember what those mean:
> 
> The easy ones:
> - Connecting.. doing conn checks ... is GATHERING/CONNECTING in nice/farstream
> - Fully connected: Is done with ICE processing, is READY in nice/fs
> - Provisionally connected: Has found at least one working candidate pair:
> CONNECTED in nice/farstream
> 
I've not explicitly written down the mapping between libnice and telepathy
states because I couldn't think of any elegant way to word it. Patches welcome.

> What's the diff between exhausted candidates and failed ?
> Is Failed only when we have been fully connected and we miss a google-style
> conncheck ?
Only the CM can know whether it's planning to supply more candidates or not.
Exhausted means we have run out of candidates to check.

The reason I pushed for this detail also stems from the fact that the
controlling side may provide+select a peer-reflexive candidate after the
streaming implementation has said Candidates_Exhausted, so Candidates_Exhausted
should not be a terminal state.

I've tried to explain it in
http://git.collabora.co.uk/?p=user/alsuren/telepathy-spec.git;a=shortlog;h=refs/heads/endpoint-state

While I was writing it up, I noticed that there is a race between:

Controller sends Offer of candidate pair which fails connchecks
Controller sends another offer of candidate pair which passes connchecks
Controlled says CandidatesExhausted to the first Offer
All is lost, even though the second offer was valid.

Is this a race that is protected from happening in reality? If not, should I
add AcceptCandidatePair/RejectCandidatePair methods instead of making the
streaming implementation try to set the state of the component here?

Also, I should probably rebase this branch on top of alsuren/controlling, so
that it actually makes sense. Marking the dependency here so that I don't
forget.

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