[Bug 26807] Mute interface for Channel.Type.Call

[bugzilla-daemon at freedesktop.org]

http://bugs.freedesktop.org/show_bug.cgi?id=26807





--- Comment #4 from Will Thompson <will.thompson at collabora.co.uk>  2010-03-26 12:26:21 PST ---
I just bounced some thoughts off Rob, and came up with:

• The interface should support the UI muting or unmuting any of its own
streams, and expose your contacts notifying you that their streams are muted.
• The UI calling Mute() needs to be relayed to the streaming implementation,
if there is one; ditto Unmute(). It could be similar to Hold.
• However, Hold is complicated by the fact that the streaming implementation
is meant to give up the resources, so unholding can fail. I don't think
unmuting should be able to fail like that. However, like Hold, the UI should be
able to know when the mic's actually been muted by the streaming
implementation, so that the user knows when they can speak freely.

So I think we want:
• methods for Mute and Unmute on Content, along with a MuteStateChanged
signal to report when it's actually happened;
• some way on Content.Interface.Media for the CM to tell tp-fs to do the
right thing, and for tp-fs to report that it has;
• a representation on ... maybe Stream? to say "the other side has muted
their mic/camera".

> Ie, if
> you're in a multi-party call with Alice, Bob, and Carol, and you've decided
> that you want to support only muting Alice, what happens when you speak and Bob
> responds?

I don't think this API needs to be for silencing Alice: it's for silencing your
own microphone, and exposing your contacts reporting that they've silenced
their microphones.


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