[Bug 28707] Clarify how to use hold/mute with Call

[bugzilla-daemon at freedesktop.org]

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

--- Comment #15 from David Laban <david.laban at collabora.co.uk> 2011-03-29 11:20:25 PDT ---
(In reply to comment #13)
> For the StopSending description:
> s/is sending silence/may opt to send silence instead of stopping the stream/
> Stop Sending is permanent as opposed to Mute which is more temporary.
> 
Can't find where you mean. Maybe I fixed it and then forgot about it?


> I realise this is just copy pasted from another file, but the MutedState
> variable on the content should refer to the local mute state. So it only
> changes if you call SetMuted().. If its a mute from a remote content, it should
> be a separate notification/variable.
> 
There are MemberFlags on the Call, and RemoteMembers on the Stream, which both
represent different things about the call. I have added a Muted flag to
MemberFlags (there is already Held), but it will only be set if all contents
from that user are muted remotely and signalled as such. Our spec allows
Contents/Streams to be muted/held independently in some cases. I'm quite happy
to leave the "some contents are muted/held" as an un-signalled case (mute/hold
are often informational anyway, right?).

> > > > Sending/ReceivingState properties on the stream ... with change notification
> > > > with error
> 
RemoteMembers and LocalSendingState on the stream seem to fit this purpose
(RemoteMembers can represent a superset of what ReceivingState can represent).
They currently use the Sending_State enum. I might make them use the equivalent
Stream_Flow_State enum instead, to avoid duplication.

I'll probably add a Reason property/arg to the RM/LSS related signals, but
there are quite a lot of Reason properties/args floating around in Call. Maybe
I should try to consolidate them into a single "Call_State_Change_Reason" enum
before I continue.

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