[Bug 24906] GSM-compatible conference calls

[bugzilla-daemon at freedesktop.org]

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





--- Comment #6 from Simon McVittie <simon.mcvittie at collabora.co.uk>  2009-11-16 13:25:29 PST ---
I discussed this with Sjoerd this afternoon and we came up with a proposal.
Basically, GSM only supports merging two or more calls (but in fact it can
never have three calls in a suitable state, so it can only really merge
exactly two calls), but XMPP supports creating a conference (in a chatroom)
from zero, one or many chats/calls. We can represent this by having an
interface whose presence implies at least the GSM functionality, and a flag
to indicate that in fact, XMPP-like functionality is also present.

Random side notes from our discussion:

[1] GSM connection managers can only really put one call on hold, but for
    least-astonishment I think they should be prepared to emulate hold for
    the active call too, by applying a bidirectional version of Mute;
    "unholding" the active call would unmute it in both directions, and
    "unholding" the held call would result in swapping the held and active
    calls in order to have the previously-held call continue.

    (Does Maemo's telepathy-ring already do this?)

    (Does telepathy-yafono already do this?)

[2] Sjoerd thinks there should be something in RequestableChannelClasses to
    represent whether calls merged with InitialChannels or Merge are placed
    in a "frozen" state (as in GSM), or ended, or left intact (as in Jingle).
    Possibly having this as a property on the 1-1 calls and/or the conference
    call would be enough, or possibly we do need a representation in the RCCs?

API sketch:

Channel.Interface.Conference
============================

requires Channel, Group

An interface for multi-user conference channels that can "continue from"
one or more individual channels.

| This interface addresses freedesktop.org bug #24906 (GSM-compatible
| conference calls) and bug #24939 (upgrading calls and chats to multi-user).
|
| Examples of usage:
|
| Active and held GSM calls C1, C2 can be merged into a single channel Cn with
| the Conference interface, by calling
| CreateChannel({...ChannelType: ...Call, ...InitialChannels: [C1, C2]}).
| which returns Cn.
|
| An XMPP 1-1 conversation C1 can be continued in a newly created multi-user
| chatroom Cn by calling
| CreateChannel({...ChannelType: ...Text, ...InitialChannels: [C1]})
| which returns Cn.
|
| An XMPP 1-1 conversation C1 can be continued in a specified multi-user
| chatroom by calling
| CreateChannel({...ChannelType: ...Text, ...HandleType: ROOM,
| ...TargetID: 'telepathy at conf.example.com', ...InitialChannels: [C1]})
| which returns a Conference channel.
|
| Either of the XMPP cases could work for Call channels, to
| upgrade from 1-1 Jingle to multi-user Muji. Any of the XMPP cases could
| in principle work for link-local XMPP (XEP-0174).
|
| The underlying switchboard representing an MSN 1-1 conversation C1 with
| a contact X can be moved to a representation as a nameless chatroom, Cn,
| to which more contacts can be invited, by calling
| CreateChannel({...ChannelType: ...Text, ...InitialChannels: [C1]})
| which returns Cn. C1 SHOULD remain open, with no underlying switchboard
| attached. If X establishes a new switchboard with the local user, C1
| SHOULD pick up that switchboard rather than letting it create a new
| channel. [???] Similarly, if the local user sends a message in C1, then
| a new switchboard to X should be created and associated with C1.
|
| XMPP and MSN do not natively have a concept of merging two or more channels
| C1, C2... into one channel, Cn. However, the GSM-style merging API can be
| supported on XMPP and MSN, as an API short-cut for upgrading C1 into a
| conference Cn (which invites the TargetHandle of C1 into Cn), then
| immediately inviting the TargetHandle of C2, the TargetHandle of C3, etc.
| into Cn as well.
|
| With a suitable change of terminology, Skype has behaviour similar to MSN.

The Group MAY have channel-specific handles for participants; clients
SHOULD support both Conferences that have channel-specific handles, and
those that do not.

| In the GSM case, the Conference's Group interface MAY have
| channel-specific handles, to reflect the fact that the identities of
| the participants might not be known - it can be possible to know that
| there is another participant in the Conference, but not know who they are.
| [FIXME: fact check from GSM gurus needed]
|
| In the XMPP case, the Conference's Group interface SHOULD have
| channel-specific handles, to reflect the fact that the participants have
| MUC-specific identities, and the user might also be able to see their
| global identities, or not.
|
| In most other cases, including MSN and link-local XMPP, the Conference's
| Group interface SHOULD NOT have channel-specific handles, since users'
| identities are always visible.

readable property Channels (ao: Channels)
    The individual channels that are continued by this conference.

    This property MUST NOT be requestable. [???]

    Change notification is via [FIXME: some sort of signal].

readable property InitialChannels (ao)
    The initial value of Channels.

    This property SHOULD be requestable. Omitting it from a request is
    equivalent to providing it with an empty list as value. Requests
    where its value has at least two elements SHOULD be expected to
    succeed on any implementation of this interface.

    Whether a request with 0 or 1 elements in the list will succeed is
    indicated by SupportsNonMerges.

    [FIXME: we need some definition of the channels that can be continued
    into a conference like this: perhaps channels with Handle_Type_Contact
    and the same ChannelType as the conference?]

    If possible, the Channels' states SHOULD NOT be altered by merging them
    into a conference. However, depending on the protocol, the Channels MAY
    be placed in a "frozen" state by placing them in this property's value
    or by calling Merge on them.
    [[2] would give a way to discover this]

    | In Jingle, nothing special will happen to merged calls. UIs MAY
    | automatically place calls on hold before merging them, if that is the
    | desired behaviour; this SHOULD always work [because of [1]]. Not doing
    | an implicit hold/unhold seems to preserve least-astonishment.
    |
    | In GSM, the calls that are merged go into a state similar to Hold, but
    | they cannot be unheld, only split from the conference call using
    | Channel.Interface.Splittable.Split().

    Depending on the protocol, it might be signalled to remote users that
    this channel is a continuation of all the requested channels, or that
    it is only a continuation of the first channel in the list.

    | In MSN, the conference steals the underlying switchboard (protocol
    | construct) from one of its component channels, so the conference
    | appears to remote users to be a continuation of that channel and no
    | other. The connection manager has to make some arbitrary choice, so
    | we arbitrarily mandate that it SHOULD choose the first channel in the
    | list as the one to continue.

    This property is immutable.

readable property SupportsNonMerges (b)
    [FIXME: needs a better name]

    If true, requests with InitialChannels omitted, empty, or one element
    long should be expected to succeed.

    | In XMPP, you can request a channel of type ROOM without incorporating
    | any 1-1 chats at all - indeed, this is the normal way to do it - or
    | as a continuation of a single 1-1 chat, and then invite other people
    | in later.

    If false, InitialChannels SHOULD be supplied in all requests for this
    channel class, and contain at least two channels. Requests where this
    requirement is not met SHOULD fail with NotImplemented.

    | In GSM, you can only make a conference call by merging at least two
    | channels. [FIXME: the CM could conceivably fake it, but that would be
    | rather nasty]

method Merge (o: Channel)
    Request that the given channel be incorporated into this channel.

    The given channel SHOULD be added to Channels if and only if the
    underlying protocol signals the merge in some way. It MUST NOT be added
    to InitialChannels (to preserve immutability).

    [FIXME: we need some definition of the channels that can be merged like
    this, as for InitialChannels]

    | In GSM it is possible to merge additional calls into an ongoing
    | conference.
    |
    | In XMPP this method could be implemented to merge a 1-1 Text channel
    | into a MUC Text channel by inviting the peer from the Text channel into
    | the MUC, or to merge a 1-1 Jingle call into a Muji call by inviting
    | the peer from the Jingle call into the Muji call. (MUC and Muji
    | channels are both implemented by XMPP MUCs, with Handle_Type_Room.)

Channel.Interface.Splittable
============================

An interface for channels that can be made conceptually part of a conference,
and can then be detached from that conference.

method Split ()
    Removes this channel from the conference.

    This implies that the media streams within the conference are put on
    hold and the media streams within the member channel leaving the
    conference are unhold. [... or, maybe it'd be less surprising if it
    didn't do this?]


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