Bug 34189 - Call: Needs extra states for the Endpoint per component
Summary: Call: Needs extra states for the Endpoint per component
Status: RESOLVED FIXED
Alias: None
Product: Telepathy
Classification: Unclassified
Component: tp-spec (show other bugs)
Version: git master
Hardware: Other All
: medium normal
Assignee: Telepathy bugs list
QA Contact: Telepathy bugs list
URL: http://git.collabora.co.uk/?p=user/a...
Whiteboard: Call
Keywords:
: 31273 (view as bug list)
Depends on: 35573
Blocks: 31280
  Show dependency treegraph
 
Reported: 2011-02-11 11:03 UTC by Olivier Crête
Modified: 2011-07-19 12:34 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:


Attachments

Description Olivier Crête 2011-02-11 11:03:45 UTC
EndpointState:

- Connecting
- Provisionally Connected
- Fully Connected
- Exhausted candidates
- Failed

Rename Stream.Endpoint to Stream.MediaEndpoint

EndpointState: a(uu)
SetEndpointState(Component: u, EndpointState: u)
EndpointStateChanged uu (Comp, EndpointState)
Comment 1 Olivier Crête 2011-02-11 11:34:24 UTC
*** Bug 31273 has been marked as a duplicate of this bug. ***
Comment 2 Olivier Crête 2011-03-09 15:25:07 UTC
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 ?
Comment 3 David Laban 2011-03-11 07:36:10 UTC
(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.
Comment 4 Olivier Crête 2011-03-11 11:55:11 UTC
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
Comment 5 David Laban 2011-03-31 10:34:46 UTC
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)
Comment 6 David Laban 2011-03-31 10:37:16 UTC
oops: wrong bug. Meant to post it on #35128
Comment 7 David Laban 2011-04-03 15:34:22 UTC
(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
Comment 8 Olivier Crête 2011-04-04 11:42:12 UTC
looks ++ !
Comment 9 David Laban 2011-04-08 09:43:19 UTC
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
Comment 10 David Laban 2011-06-13 15:33:17 UTC
(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.
Comment 11 David Laban 2011-07-19 12:34:20 UTC
merged to master


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.