| Summary: | Call should allow multiple selected candidates and tell CM about local one | ||
|---|---|---|---|
| Product: | Telepathy | Reporter: | Louis-Francis Ratté-Boulianne <lfrb> |
| Component: | tp-spec | Assignee: | Telepathy bugs list <telepathy-bugs> |
| Status: | RESOLVED DUPLICATE | QA Contact: | Telepathy bugs list <telepathy-bugs> |
| Severity: | normal | ||
| Priority: | medium | CC: | olivier.crete |
| Version: | unspecified | ||
| Hardware: | Other | ||
| OS: | All | ||
| Whiteboard: | Call | ||
| i915 platform: | i915 features: | ||
I think the API should be on the Endpoint and should be something like: Endpoint.SetSelectedCandidate(Local: Candidate , Remote: Candidate) (In reply to comment #1) > I think the API should be on the Endpoint and should be something like: > > Endpoint.SetSelectedCandidate(Local: Candidate , Remote: Candidate) I agree, except there could be more than one pair. So: - NewSelectedCandidate[Pair] or; - AddSelectedCandidate[Pair] The candidate "struct" includes the component id, maybe we should do SetSelectedCandidates(Local: CandidateList, Remote: CandlidateList).. and state that there should be only one candidate per componenent and they the lists should match. Olivier and myself quickly discussed it on irc, in practise the different ICE sessions will go connected one by one, so we should just have one method to add them one at a time, say: AddSelectCandidatePair (Candicate: Local, Candidate: Remote) With a nice signal and a properly listing the candidate pairs that have been selected so observers can see happyness occurred. Candidates obviously need to have a matching component We should also specify that there can be only one selected candidate per component. Also, in the case of ICE restart, I think the SelectedCandidates should be cleared.. so maybe the signal should be SelectedCandidatePairsChanged() and contain a mapping of Component->Pair. |
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.
There are currently three flaws with current Call spec: - There is no way for the CM to know which local candidates are selected. - There is no way for the CM to tell which local candidates the remote end-point chose to use (Equivalent of current SetActiveCandidatePair). - Only one candidate can be set as selected, even though there are usually two (one candidate per component). Also, I'm not really sure about how it works in conference calls. Do all end-points use the same local candidate ? I doubt it; so we probably have to let know the CM which end-point the local candidate was selected for as well. One possible API could be: Call.Stream -> - NewSelectedCandidate(Endpoint, Candidate) method - CandidateSelected(Endpoint, Candidate) signal - LocalSelectedCandidates({Endpoint:[Candidates]}) property Call.Stream.Endpoint -> - NewSelectedCandidate(Candidate) method - CandidateSelected(Endpoint, Candidate) signal - RemoteSelectedCandidates([Candidates]) property