| Summary: | Need to document/design how to handle codec negotiation failures | ||
|---|---|---|---|
| Product: | Telepathy | Reporter: | Sjoerd Simons <sjoerd> |
| Component: | tp-spec | Assignee: | Telepathy bugs list <telepathy-bugs> |
| Status: | RESOLVED DUPLICATE | QA Contact: | Telepathy bugs list <telepathy-bugs> |
| Severity: | normal | ||
| Priority: | medium | CC: | david.laban, olivier.crete |
| Version: | unspecified | Keywords: | patch |
| Hardware: | Other | ||
| OS: | All | ||
| URL: | http://git.collabora.co.uk/?p=user/alsuren/telepathy-spec.git;a=shortlog;h=refs/heads/remove-reason | ||
| Whiteboard: | Call | ||
| i915 platform: | i915 features: | ||
Add reason to ContentRemoved signal ContentRemove(o: Content, u: enum, s: dbus error, s: Message) Sketched it up in http://git.collabora.co.uk/?p=user/alsuren/telepathy-spec.git;a=shortlog;h=refs/heads/remove-reason Can anyone think of any more reasons to put in the enum? I currently have Requested, Codec_Negotiation_Failed, Hardware_Fault, Network_Fault. I think that Content.RemoveContent() should not have a reason (isn't it always user-requested in this case?).. And errors from the media layer are reported in the .I.Media interface.. Or did I miss some case where the UI wants to remove a Content without the user's request ? Also, the enum is duplicated between the Call and Content interfaces. Sorry for not seeing this bug earlier. |
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.
From #24936: > Sjoerd says we also need to think about what happens if a change to codecs via > SetCodecs() but a remote contact doesn't like it.