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

[bugzilla-daemon at freedesktop.org]

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





--- Comment #5 from Andres Salomon <dilinger at collabora.co.uk>  2010-03-27 09:08:55 PST ---
(In reply to comment #4)
> 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.

Ok.  This is different from what I'd envisioned.



> • 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.

If unmuting can't fail, then resources shouldn't be freed up when a
stream/content is muted.  I'm also failing to see the use case for notifying
the remote side that you've muted your mic/camera.  For Hold, it makes sense;
you want them to know when they can speak.  For mute, I'm not sure that you
want them to know that you've muted your mic (and if you've muted your camera,
that should be pretty obvious).


> 
> 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".
> 


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