[Bug 35128] Call: CallState, CallFlags, & CallState are confusing

[bugzilla-daemon at freedesktop.org]

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

David Laban <david.laban at collabora.co.uk> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |david.laban at collabora.co.uk

--- Comment #2 from David Laban <david.laban at collabora.co.uk> 2011-03-22 12:22:39 PDT ---
(In reply to comment #0)
> The properties CallState and CallFlags are confusing, especially considering
> the CallState interface..
> 
I've done a bit of git-blame, and discovered the following: The CallState
interface was copied wholesale into an early alpha version of Call and then
forked (thanks Sjoerd). Flags used to be per contact, but they were changed to
be for the whole call. The Call_Member_Flags enum was added to represent remote
contacts.

> Why are the CallFlags flags, most of them are mutually exclusive and are
> actually states? 
> 
They are flags partly because of conflated design and partly to allow for
future extensibility.

The things that are actually sub-states of CallState are Setup_In_Progress,
Queued, Ringing (renamed from In_Progress and Locally_Ringing; substates of
Pending_Receiver) and Clearing (substate of Ended). I think that these should
be merged into the main state enum. I will mark sub-states as such, so that
implementers can map them appropriately if they don't care.

The things that are genuinely flags are Forwarded, Locally_Muted, and
Locally_Held. I think that mute and hold could be represented by their own
properties on their own interfaces. Forwarded is an informational flag that's
controlled by the remote end. In a way it reminds me of #24901, but I guess it
can also be used for hunt groups, so I'm in favour of keeping this flag. Since
we're keeping one flag, we might as well keep Mute and Hold as their own flags,
and the general extension mechanism of flags.

(In reply to comment #1)
> Locally_Ringing, Queued, Locally_Held, In_Progress, Clearing are distinct
> states in Q.931/GSM/3G.
> 
> Locally_Ringing, Queued, In_Progress, Clearing are states in SIP.

I was doing a bit of googling for SIP/XMPP state machines, and found:
http://tools.ietf.org/html/rfc3976#section-5 . Cross-checking to make sure I
have everything that the UI might care about, I think that we should have a
separate "Active" (corresponding to the ones listed here) meaning "at least one
other party can hear you, and you can hear everything they're sending you". I'd
suggest that Hold, Mute and connectivity problems should make the state go from
Active back to Accepted, so even retarded UIs can display some useful feedback
to the user without looking at Flags at all.

tl;dr: add Setup_In_Progress, Queued, Ringing, Active and Clearing to CallState
(in addition to Unknown, Pending_Initiator, Pending_Receiver, Accepted, and
Ended). CallFlags will only contain Forwarded, Locally_Muted, and Locally_Held.

If there are no objections, I will write this up.

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