Summary: | ImmutableStreams is unsufficient, also need "AlwaysSend" | ||
---|---|---|---|
Product: | Telepathy | Reporter: | Olivier Crête <olivier.crete> |
Component: | tp-spec | Assignee: | Telepathy bugs list <telepathy-bugs> |
Status: | RESOLVED INVALID | QA Contact: | Telepathy bugs list <telepathy-bugs> |
Severity: | normal | ||
Priority: | medium | CC: | mikhail.zabaluev |
Version: | 0.8 | ||
Hardware: | Other | ||
OS: | All | ||
Whiteboard: | |||
i915 platform: | i915 features: |
Description
Olivier Crête
2010-01-11 18:29:45 UTC
arg, I may be wrong here, let me investigate further first... Alright, I found the problem causing this, so I guess we dont need this workaround.. Even if we don't need this for Gabble, if I remember correctly Mikhail wanted ImmutableDirection (or to make ImmutableStreams imply immutable directions) to be settable via a CM parameter for telepathy-sofiasip, to cope with certain deficient SIP servers. (There is currently an immutable-streams CM parameter which sets ImmutableStreams on every StreamedMedia channel, and can be configured by the user or pre-set from a Maemo .profile file; ImmutableDirection would presumably be similar.) Mikhail: comments? Yes, it seems useful to have a way to tell the client not to change the direction even if it would do normally, and resort to other means of reducing resource usage. For example, when the video call application was made invisible on the desktop, running the full video playback stack is wasteful (think of mobile devices here), and sending captured video may even be considered a privacy issue. If directionality can't be renegotiated, the client/stream engine should know to stop running the full pipelines, switching to sending trickle packets. I can't tell if there are many real-world cases for ImmutableStreams and ImmutableDirection to be separate flags, but it's possible. |
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.