| Summary: | Call: Add way to add SSRCs per contact | ||
|---|---|---|---|
| Product: | Telepathy | Reporter: | Olivier Crête <olivier.crete> |
| Component: | tp-spec | Assignee: | Telepathy bugs list <telepathy-bugs> |
| Status: | RESOLVED FIXED | QA Contact: | Telepathy bugs list <telepathy-bugs> |
| Severity: | normal | ||
| Priority: | medium | CC: | david.laban |
| Version: | unspecified | Keywords: | patch |
| Hardware: | Other | ||
| OS: | All | ||
| URL: | http://git.collabora.co.uk/?p=user/jonny/telepathy-spec.git;a=shortlog;h=refs/heads/ssrc | ||
| Whiteboard: | Call | ||
| i915 platform: | i915 features: | ||
| Bug Depends on: | |||
| Bug Blocks: | 29590, 31276 | ||
|
Description
Olivier Crête
2010-08-16 11:13:04 UTC
We have decided: Local SSRC on Stream. Remote SSRCs on Endpoint. (CSRCs will appear later.) Check out my branch. The LocalSSRC is a bit more complicated than I said yesterday. If you're in a regular Call, it is randomly selected by the RTP implementation and can change dynamically if you find another useful in the same call using the same SSRC. So there should be a property that can also be unset (in the normal case). Obviously, if the signalling chooses the LocalSSRC, then it uses a different mechanism to chose a unique one (normally it gets the list of all the other ones before choosing its own). The RemoteSSRC parts looks good. (In reply to comment #3) > The LocalSSRC is a bit more complicated than I said yesterday. If you're in a > regular Call, it is randomly selected by the RTP implementation and can change > dynamically if you find another useful in the same call using the same SSRC. So > there should be a property that can also be unset (in the normal case). > > Obviously, if the signalling chooses the LocalSSRC, then it uses a different > mechanism to chose a unique one (normally it gets the list of all the other > ones before choosing its own). So how about this: method: SetLocalSSRC(u) -> nothing signal: LocalSSRCChanged(u) property: u: LocalSSRC If the RTP implementation chooses the local SSRC then it calls SetLocalSSRC. If the signalling chooses the local SSRC then SetLocalSSRC shouldn't be called, and the value is set directly by the CM. In both cases LocalSSRCChanged is fired after the value is changed. Does that sound okay and fit both cases? > The RemoteSSRC parts looks good. Good. Doesn't work.. how is the signalling implementation supposed to find out if it should select the SSRC or not ? (In reply to comment #5) > Doesn't work.. how is the signalling implementation supposed to find out if it > should select the SSRC or not ? Yes, good point. Two choices I see are: 1. Add a ShouldSetLocalSSRC(), or a similarly named method, which tp-fs calls to let the CM know that it should set the SSRC. Simple. or 2. Define SetLocalSSRC(0) to mean "please set the local SSRC to something sensible given all the other remote SSRCs". Of course, this falls down if zero is a valid SSRC. Looking at the RTP RFC it doesn't say that it isn't, but you get the idea? Thoughts? 0 is a valid ssrc... Imho, there should be a boolean property "PleaseUseMySSRC" or something. Fixed as part of my call-contacts branch, for #31276 Abusing Assigned to mean "merged in alsuren/call and available at http://people.freedesktop.org/~alsuren/telepathy-spec-call/spec/". *** Bug 33040 has been marked as a duplicate of this bug. *** http://cgit.collabora.com/git/user/alsuren/telepathy-spec.git/commit/?h=local-descriptions-28718&id=f21d284813ff2262da913fc888b0dc2fea8bf6ea is probably required for the "big video relay in the sky" and "multicast video call" use cases. ++ !! merged to alsuren/call 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.