[Bug 35598] Implement Call channels

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=35598

--- Comment #13 from Sjoerd Simons <sjoerd at luon.net> 2012-03-15 02:28:19 UTC ---
(In reply to comment #11)
> When you try to unhold, you call RequestHold(), then the CM tells the other
> side that we're going to unhold and in parallel tp-glib emits
> SendingStateChanged and ReceivingStateChange and waits for those to be
> Completed. Then tp-glib emits HoldStateChanged.
> 
> If the Sending or Receiving state can't be completed to STARTED, then
> ReportSending/ReceivingFailure are called. But we don't want those to change
> the direction of the stream or end the call (which is what you'd normally do).
> Instead, you just want to abort the Unhold and change the hold reason to
> Resource_Not_Available. The reason for the  Report*Failure call is useless and
> is always the same (TP_CALL_STATE_CHANGE_REASON_INTERNAL_ERROR,
> TP_ERROR_STR_MEDIA_STREAMING_ERROR) because nothing else makes sense.

Well ideally we'd report to the user. Can't unhold, couldn't access your
camera. But i see that the Hold specification doesn't allow for this atm. So
with a light sound of annoyance i agree with your patch for now. For the future
i think we need to update the specific such that Hold can give a detailed error
reason (e.g. failed because of this stream here which had this detailed error).

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA Contact for the bug.