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

bugzilla-daemon at freedesktop.org bugzilla-daemon at freedesktop.org
Thu Jan 6 04:49:29 CET 2011


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

Olivier Crête <olivier.crete at ocrete.ca> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|Clarify how to use hold     |Clarify how to use
                   |with Call                   |hold/mute with Call

--- Comment #5 from Olivier Crête <olivier.crete at ocrete.ca> 2011-01-05 19:49:29 PST ---
Hold can mean two things:

1. Local hold.. the local user wants to hold a call:
 1.1 Stop sending
 1.2 Stop receiving

2. Remote hold, a remote contact has placed a call on hold:
 2.1 Stop sending
 2.2 Continue receiving

There is also a 3rd reason to stop sending, if the local user has muted the
Content.

The current API has a 4th way to stop sending, it is the Stream.SetSending(),
I'm not sure what its use-case is and how it differs from Content.Mute, apart
being per-stream. I suggest renaming it to SetMuted() and the
"LocalSendingState" property to "Muted".

The use-case for per-stream-muting is to way to tell something to only a
sub-group of a conf-call, so one would mute everyone else.

The Mute interface should have a success/failure return and not be immediate
(since unmuting is not immediate and can fail). 

Also, Stream.RequestReceiving() .. isn't that the same as requesting a contact
to Unmute ? Maybe it should be Stream.RequestUnmute() ?

As in bug #28693, I suggest moving LocalSendingState/SetSending to the
Stream.Media interface, the CM should only request us to start sending if we
are neither in local hold, remote hold, Content.Muted or Stream.Muted. 

Local hold is the only state when we want to stop receiving and local hold is
only available per-channel in the current API, it makes sense to have a
per-channel Media interface for that since re-starting to receive may fail and
tp-fs needs to tell that to the CM before it can proceed.

The only thing we're missing is a way to inform the UI when the remote side has
placed a per-Content remote hold (we currently only have CallState for that
which is per channel).

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


More information about the telepathy-bugs mailing list