From #24936 Stream.Endpoint: * nothing is documented or cross-referenced yet * SelectedCandidate / CandidateSelected are another "which is which?" property/signal pair * it's not clear why Transport is needed, since it seems to duplicate Stream.I.Media.Transport From IRC discussion: 17:13 < sjoerd> SIP has a fallback path from ice to raw-udp 17:13 < sjoerd> You send your offer with one raw-udp candidate and a set of ice ones 17:13 < sjoerd> if the other side doesn't support raw-udp it'll accept with one raw-udp candidate 17:14 < sjoerd> and you'll actually use raw-udp 17:14 < sjoerd> I'm vaguely pondering of having the STream transport stay ice in that case, but have the endpoint say raw-udp 17:14 < sjoerd> not entirely sure about it yet 17:15 < sjoerd> We're going to require that every streaming implemetation can do the fallback to raw-udp and always give you one candidate to use as the raw-udp candidte as well That last point should be written into the spec, if it's what we mean.
(In reply to comment #0) > 17:13 < sjoerd> if the other side doesn't support raw-udp it'll accept with one ^^^^^^^ ice-udp > raw-udp candidate
Last open problem in this bug: (In reply to comment #0) > 17:13 < sjoerd> SIP has a fallback path from ice to raw-udp > 17:13 < sjoerd> You send your offer with one raw-udp candidate and a set of ice > ones > 17:13 < sjoerd> if the other side doesn't support raw-udp it'll accept with one > raw-udp candidate > 17:14 < sjoerd> and you'll actually use raw-udp > 17:14 < sjoerd> I'm vaguely pondering of having the STream transport stay ice > in that case, but have the endpoint say raw-udp > 17:14 < sjoerd> not entirely sure about it yet > 17:15 < sjoerd> We're going to require that every streaming implemetation can > do the fallback to raw-udp and always give you one candidate to > use as the raw-udp candidte as well > > That last point should be written into the spec, if it's what we mean.
The solution for SIP fallback is to have a separate ForceCandidates() method. The transport shouldn't be in the Endpoint, it just doesn't make sense. Whetehr the "CandidateSelected" isthe local or the remote candidate is entirely unclear to me.. We shoudl have a "CandidatePairSelected" with two arguments (the local and remote caniddates), not just their names, but the whole thing.
CandidateSelected/SelectedCandidate is solved by the pairs Don't need ForceCandidate because the endpoint shows up with the answer. Type never changes
yeah: fixed as part of #34149 Abusing Assigned to mean "merged in alsuren/call and available at http://people.freedesktop.org/~alsuren/telepathy-spec-call/spec/".
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.