[Telepathy] Telepathy spec. meeting: conference, splittable, call states
Will Thompson
will.thompson at collabora.co.uk
Thu Nov 26 05:01:02 PST 2009
Part n in an irregular series of minutes of meetings held in the
Collabora Cambridge office about the Telepathy specification.
Points we'd particularly like input on:
* Whether the channel merging stuff seems sensible;
* How to represent which contacts support being added to conferences;
* Which call states make sense where.
== Dramatis Personæ ==
* Alban Crequy
* Simon McVittie
* Guillaume Desmottes
* Sjoerd Simons
* Will Thompson (scribe)
== Topics ==
1 Channel.Interface.Conference and Channel.Interface.Splittable
1.1 SupportsNonMerges property
1.2 How does a client actually add a third party to an existing 1–1
conversation?
1.3 Which channels can you merge?
1.4 Dead channels
1.5 Splittable.Split()
1.6 Implicit hold/unhold
2 Channel.Type.Call call states and flags
2.1 CallStateChanged signal
== Channel.Interface.Conference and Channel.Interface.Splittable ==
This is part of the ongoing work to incorporate the (functionality of
the) Telepathy extensions used in the Nokia N900[0], which add support
for cellular- and Skype-specific features, into the upstream Telepathy
specification. The Conference and Splittable interfaces discussed here
correspond rougly to the Conference and ConferenceMember interfaces
implemented by the cellular connection manager (Ring) in Fremantle, and
are intended also to support “upgrading” 1–1 text conversations to
multi-user chats on protocols where that's possible, which include MSN,
Skype, and XMPP (either using Google's PMUC extension, or XEP-0045
§7.6[1]). freedesktop.org bug #24906[2] tracks the development of these
interfaces, and HTML snapshots of each interface are available[3][4].
[0] http://git.collabora.co.uk/?p=rtcom-telepathy-glib.git;a=summary
[1] http://xmpp.org/extensions/xep-0045.html#continue
[2] http://bugs.freedesktop.org/show_bug.cgi?id=24906
[3]
http://people.freedesktop.org/~smcv/telepathy-spec-conference/spec/org.freedesktop.Telepathy.Channel.Interface.Conference.DRAFT.html
[4]
http://people.freedesktop.org/~smcv/telepathy-spec-conference/spec/org.freedesktop.Telepathy.Channel.Interface.Splittable.DRAFT.html
=== SupportsNonMerges property ===
This property needs a better name. It basically means “this protocol is
not GSM”. It's needed because you can only upgrade two or more GSM calls
into one conference, whereas you can upgrade a single 1–1 text
conversation to a MUC, and will be able to upgrade a single 1–1 Jingle
call to a Multi-User Jingle[5] call before inviting other participants.
The sense of this property is a bit awkward, but it avoids making it an
anti-capability. If the sense were inverted, then its presence in
RequestableChannelClasses would imply that the protocol ''lacks'' a
feature; as it stands, it is additive. (Contrast with
ImmutableStreams[6], which is the wrong way around for
backwards-compatibility reasons.)
[5] http://xmpp.org/extensions/xep-0272.html
[6]
http://telepathy.freedesktop.org/spec/org.freedesktop.Telepathy.Channel.Type.StreamedMedia.html#org.freedesktop.Telepathy.Channel.Type.StreamedMedia.ImmutableStreams
=== How does a client actually add a third party to an existing 1–1
conversation? ===
Assume you're Bob, and you have a 1–1 text channel C1 with Alice. Now,
you want to talk to Chris. Under this spec, there are at least three
ways you can do it:
# Start a 1–1 text channel C2 with Chris, and then request a channel
with Conference.InitialChannels: [C1, C2];
# Request a channel with Conference.InitialChannels: [C1], then add
Chris to the new channel;
# Request a channel with Conference.InitialChannels: [C1], request a
channel C2 with Chris, then call Merge(C2) on the conference channel.
There is no way to do it with a single method call. It would be
convenient to be able to add a requestable property InitialInvitees, so
that clients could request a channel with:
{ ... ,
Conference.InitialChannels: [C1],
Conference.InitialInvitees: [Chris],
}
and thus do the upgrade with a single call. Verdict was that this is
indeed just convenience API, but useful enough to include.
=== Which channels can you merge? ===
The spec says that you can merge any channels with the same ChannelType,
with TargetHandleType: Contact.
(This stops us implementing complex ContactSearch queries by merging
individual ContactSearch channels, but that's probably for the best...)
How do you know which of your contacts support being merged to a
channel? For instance, you may have lots of contacts who support Jingle
calls, but pretty much none of them will support Muji.
ContactCapabilities doesn't really support this. Suggestions:
* use a channel class with InitialInvitees: [the contact's handle]. This
is a bit of a hack.
* ''post-meeting refinement: put InitialInvitees or some other
Conference property in allowed.''
* add a separate property to RequestableChannelClasses of some form.
=== Dead channels ===
If you upgrade some channels into a conference, and then close the
original channels, InitialChannels (which is immutable) will contain
paths to channels which no longer exist. This implies that you should
not re-use channel object paths, unless future incarnations of the path
are “morally equivalent” (for instance, a 1–1 text channel to Emily can
get away with using the same path (on protocols where you can only have
zero or one 1–1 text channels with Emily, that is).
=== Splittable.Split() ===
How do you know which conference the channel you're trying to split is a
part of? One option is to have a Replaced() signal on the original
channel containing the new conference's path. This is racy, though:
CM MC Text UI Observer
<---()--->
NewChannels
<---()--->
Replaced
Gets new channel's
path from Replaced;
starts doing things
like:
<--------------------------
AcknowledgeMessages
---------------------------->
ObserveChannels
But by now the messages
the observer wanted to log
are gone forever.
We could mandate that UIs don't do anything destructive with the paths
they get from Replaced, but designing races out is better than making
client authors contort to avoid them.
Maybe we could have a boolean Frozen property on Splittable, to tell the
text UI that the channel's been merged somewhere, but not tell it where.
''Your scribe realises while writing this meeting up that this race
might be less of a big deal than it seemed, particularly since text
channels aren't expected to be Splittable, only calls.''
=== Implicit hold/unhold ===
The interfaces used by Fremantle have the semantic that a channel merged
into a conference is put on hold (and you can't take it off hold without
splitting it out), and when you split a channel from a conference the
conference is put on hold and the channel is taken off hold. Should we
mandate these semantics in the spec?
Muji does not intrinsically have these requirements.
We could possibly require UIs to follow this pattern:
* Hold the conference
* Split a channel
* Unhold either the conference or the channel
To do this, we'd need the cellular CM to fake putting both the
conference and the channel on hold (by one of them being on real hold,
and the other one just being bidirectionally muted). Someone needs to
check whether it's possible to do this.
== Channel.Type.Call call states and flags ==
The Call draft has a property representing the state of the call as a
whole, and a map from contacts to their state in the call. But not all
of the states in the Call_Flags enum are applicable to contacts, as
opposed to the call as a whole. Also, not all of them are applicable to
all call states. Sjoerd's view is:
* Ringing:
** On a call, means that a local client has said it's making a ringing
noise;
** On a contact, means their client has told us it's ringing.
** Only applicable to Pending calls
* Queued only makes sense for outgoing calls, not for contacts.
** Only applicable to Pending calls
* Held is applicable to both (whether we've put the call on hold, and
which of our contacts have).
** Applicable to Pending and Active calls
* Forwarded only makes sense on outgoing calls.
** Applicable to Pending and Active calls
* In Progress only makes sense on outgoing calls
** Only applicable to Pending calls
* Clearing only makes sense on calls.
** Only applicable to Ending calls.
We need to make the “call held” state correspond to the states on the
Hold interface. The state diagram for the Hold interface is a bit
confusing:
Pending Hold
↗ ↑ ↘
Unheld → → Held
↖ ↑ ↗↙
Pending Unhold
The rationale is already in the spec.
Suppose I call Sjoerd, and then invite Simon to the call, and am put in
a queue. Should he have the Queued flag?
Should the self handle ever appear in the per-contact map? It makes
things easier to explain if not: your own flags are the CallFlags
property, and the map only contains other people.
We should split the Call_Flags type into Call_Flags and
Contact_Call_Flags (modulo bikeshedding), to make it easier to document
and understand.
=== CallStateChanged signal ===
Currently this is u u (uuss) a{sv}:
* u: CallState
* u: CallFlags
* (uuss): CallStateReason
** u: TpHandle (actor)
** u: reason
** s: dbus error name
** s: debug message
* a{sv}: details
We could move the debug message into the details dict.
Where does the human-readable message for Queued (which exists on SIP)
live?: in the details dict.
Regards,
--
Will
More information about the telepathy
mailing list