Right now, telepathy-farstream calls Call.Content.Remove() if there is an error. We should probably add a method in Call.Content.I.Media instead for that. Maybe something like Error(s: detailed, s: message) or Failed() .. something like the Sending/ReceivingFailed() in the Stream... If you want to see some of the cases, grep for "content_error" in call-content.c in telepathy-farstream. Then we can remove the reason parameter in C.C.Remove(), since the reason there will always be user-requested.
I have done a bit of cleanup with regards state change reasons. You can find it at http://git.collabora.co.uk/?p=user/alsuren/telepathy-spec.git;a=shortlog;h=refs/heads/remove-reason I'm not sure what you mean by "something like the Sending/ReceivingFailed() in the Stream". I added an Error() function to Stream.I.Media, but not anything that's specific to either Sending or Receiving, I don't think. When I fix #34189 (probably using AcceptCandidatePair/RejectCandidatePair, I might add a Reason to Reject too, which could be propagated up, or I might just define an appropriate Reason and error that the CM should create)
*** Bug 28723 has been marked as a duplicate of this bug. ***
I can only think of one reason for Reject(): "Codecs don't match", but maybe I'm forgetting something. Network_Fault -> Network_Error (to match the rest of the spec) Otherwise looks ++
Abusing the Assigned status to mean that the fix has been reviewed and merged into alsuren/call. I have considered the last two commits of remove-reason to be insta-reviewed.
Fix merged to master. We ended up having a single "call state change reason" struct, with actor, reason enum, dbus error and debugging message.
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.