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

[bugzilla-daemon at freedesktop.org]

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





--- Comment #3 from Andres Salomon <dilinger at collabora.co.uk>  2010-03-12 17:10:43 PST ---
(In reply to comment #2)
> Note that the API provided by RTCom is per-channel, but that's because it was
> only used for GSM audio calls, where you only have one content and one stream
> anyway. In Jingle, individual contents can be muted (you can mute audio but
> leave the webcam on), and video can be "muted" (i.e. to signal "I've turned off
> my webcam").
> 

Hm, you're right.  This should probably be handled at the Content level, I
think (see my comments at the end).


> Things that this spec draft doesn't say anything about:
> 
> * What's the difference between setting the content/stream to receive-only, and
> muting it? When would you do one, and when would you do the other?


For protocols where you have fine-grained control of the stream data, and where
tearing down a stream doesn't tear down the entire connection, perhaps there is
no difference.  For protocols such as GSM, setting a content/stream to
receive-only involves either resetting the connection, or some other kind of
coordination between both contacts.  Muting involves merely disabling the audio
mic; the content/stream remain untouched.


> 
> (wjt suggests that the answer is: if you physically have a webcam/microphone,
> and in general you want to use it within this call, but you've temporarily
> switched it off, then the direction should be bidirectional and mute should be
> signalled)
> 
> * Interaction with the protocol: does calling the method actually do anything
> significant or does it just send an informational message? In Hold, requesting
> hold causes the MediaSignalling interface (or Call equivalent) to ask the
> streaming implementation (i.e. telepathy-farsight) to stop sending and
> receiving; does Mute have similar behaviour?
> 
> * In general, what use cases are we providing for here?
> 
> -------------
> 
> Something else this spec doesn't seem to address at all is receiving the muted
> flag from the other guy(s), and indicating in the UI that they've muted
> themselves.
> 
> If it was per-call, then in Call, this would be a new flag in
> Call_Member_Flags, and in StreamedMedia, this would be a new flag in the
> CallState interface. However, it's really per-content.
> 
> Do we want to help out simple UIs by providing a "merged" flag on the Channel?
> If so, what are its semantics? (wjt thinks the answer is "if any of their
> streams are muted, then the channel as a whole is considered to be muted".)
> 
> Do we want to indicate per stream whether the stream is muted? (Probably? so a
> multi-way video call UI that displays a pane per participant could grey out the
> video pane for a "video-muted" caller, or hide it entirely.)
> 

I see Mute being for local muting.  That is, it's a quick way (at the UI level)
to block sending of video and/or audio.  One can imagine a UI that allows you
to separately control muting for voice and for video.  

I don't see a sane way to handle the use case of selectively muting some
streams in a multi-party call, as it will lead to crazy complexity.  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?  Does Bo's response get muted as well?  Does Alice simply get
completely muted?  I feel that this kind of thing is better handled explicitly
by simply removing a contact from a conference.

Therefore, I'm not convinced that we'd ever want to be able to mute at the
Stream level; I think muting at the Content level is enough.

It's up to the CM that's implementing Mute to decide what to actually do to at
the protocol level.  For a protocol like GSM, you mute the mic; the GSM
hardware keeps transmitting audio.  For other VOIP protocols, perhaps you
actually stop sending stream data where the protocol itself allows such a
thing.  If it's not supported, you just send silence (or in the case of a video
Content/Stream, you send a greyed-out image).  The important thing here is that
Mute is a shortcut for keeping *your* audio or video data from being
transmitted.  It shouldn't require any changing of stream states, or any
coordination w/ remote contacts.

If I'm off-base w/ any of my assumptions, please let me know..


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