Bug 34189

*** Bug 31273 has been marked as a duplicate of this bug. ***

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

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 ?

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

If failed can only be set by the CM, then the CM should just remove the endpoint instead of having a separate state.

That race is interesting to say the least.. Maybe exhausted should mention what was the last message received or something.. arg

http://git.collabora.co.uk/?p=user/alsuren/telepathy-spec.git;a=shortlog;h=refs/heads/states (is 3 useful commits. If you want to review them independently you can, or you can review them as part of 35573)

oops: wrong bug. Meant to post it on #35128

(In reply to comment #4)
> If failed can only be set by the CM, then the CM should just remove the
> endpoint instead of having a separate state.
> 
One component of a stream can fail without the stream going down.

> That race is interesting to say the least.. Maybe exhausted should mention what
> was the last message received or something.. arg
>
I have gone for Accept/RejectSelectedCandidatePair. Results can be found at:

http://git.collabora.co.uk/?p=user/alsuren/telepathy-spec.git;a=shortlog;h=refs/heads/endpoint-state

looks ++ !

Hrrrm... When implementing it, I realised that a(uu) is bullshit. What I in fact mean is a{uu}.

Pushed to http://git.collabora.co.uk/?p=user/alsuren/telepathy-spec.git;a=shortlog;h=refs/heads/endpoint-state

(In reply to comment #9)
> Hrrrm... When implementing it, I realised that a(uu) is bullshit. What I in
> fact mean is a{uu}.
> 
> Pushed to
> http://git.collabora.co.uk/?p=user/alsuren/telepathy-spec.git;a=shortlog;h=refs/heads/endpoint-state

considering this insta-reviewed and pushing to my call branch.

merged to master