[Bug 24906] GSM-compatible conference calls

bugzilla-daemon at freedesktop.org bugzilla-daemon at freedesktop.org
Mon Nov 16 19:08:11 CET 2009


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


Simon McVittie <simon.mcvittie at collabora.co.uk> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |mikhail.zabaluev at nokia.com,
                   |                            |ppessi+telepathy at gmail.com




--- Comment #5 from Simon McVittie <simon.mcvittie at collabora.co.uk>  2009-11-16 10:08:08 PST ---
In the GSM case, we ought to at least be able to do everything that Ofono can.
From
<http://git.kernel.org/?p=network/ofono/ofono.git;a=blob_plain;f=doc/voicecallmanager-api.txt;hb=HEAD>:

>       object Dial(string number, string hide_callerid)
>
>           Initiates a new outgoing call. Returns the object path
>           to the newly created call. The clir variable holds
>           the CLIR override for this call.
>           The defines values are:
>               "" or "default" - Default (Netowrk) CLIR mode
>                           is used
>               "enabled" - Hides callerid, CLIR Invocation
>                       is used
>               "disabled" - Shows callerid, CLIR Suppression
>                       is used
>
>           This is usually implemented using the ATD AT command.

Out of scope for this bug; this is the normal CreateChannel/EnsureChannel, and
CLIR is Bug #24909.

>       void Transfer()
>
>           Joins the currently Active (or Outgoing, depending
>           on network support) and Held calls together and
>           disconnects both calls. In effect transfering
>           one party to the other. This procedure requires
>           an Active and Held call and the Explicit Call Transfer
>           (ECT) supplementary service to be active.
>
>           This functionality is generally implemented by using
>           the +CHLD=4 AT command.

Out of scope for this bug; this is the Transfer interface, which was drafted
but never implemented. I'll make a new bug for it.

>       void SwapCalls()
>
>           Swaps Active and Held calls.  The effect of this
>           is that all calls (0 or more including calls in a 
>           multi-party conversation) that were Active are now Held,
>           and all calls (0 or more) that were Held are now Active.
>
>           GSM specification does not allow calls to be swapped 
>           in the case where Held, Active and Waiting calls exist.
>           Some modems implement this anyway, thus it is manufacturer
>           specific whether this method will succeed in the case
>           of Held, Active and Waiting calls.
>
>           This functionality is generally implemented by using
>           the +CHLD=2 AT command.

In StreamedMedia, we implement this by: you unhold the held call, and the
active call automatically becomes held. I suggest we do the same in Call.

This does have the problem that UIs can't know what effect this will have -
it's a somewhat startling side-effect.

>       void ReleaseAndAnswer()
>
>           Releases currently active call and answers the currently
>           waiting call. Please note that if the current call is
>           a multiparty call, then all parties in the multi-party
>           call will be released.

Telepathy implementation: define "accept" as "move from LocalPending to
Members" (or the equivalent in Call). When you accept the waiting call:

* if there is a held call, no problem
* if there is an active call and no held call, the active call is automatically
  held by the CM
* if there is an active call and a held call, ??? - possibilities are
  - the active call is terminated by the CM
  - the held call is terminated by the CM and the active call gets held
  - the acceptance fails

Again this has the problem of a somewhat startling side-effect (particularly if
the CM starts terminating calls spontaneously).

>       void HoldAndAnswer()
>
>           Puts the current call (including multi-party calls) on 
>           hold and answers the currently waiting call. Calling
>           this function when a user already has a both Active and
>           Held calls is invalid, since in GSM a user can have
>           only a single Held call at a time.

Used to implement the above.

>       void HangupAll()
>
>           Releases all calls. 

Could be used to implement Close() etc.

>       array{object} PrivateChat(object call)
>
>           Places the multi-party call on hold and makes desired
>           call active. This is used to accomplish private chat
>           functionality.  Note that if there are only two calls
>           (three parties) in the multi-party call the result will
>           be two regular calls, one held and one active. The
>           Multiparty call will need to be setup again by using the
>           CreateMultiparty method.  Returns the new list of calls
>           participating in the multiparty call.
>
>           This is usually implemented using the +CHLD=2X command.

Needs to be part of this interface. In Maemo 5, you call LeaveConference()
on the desired call.

>       array{object} CreateMultiparty()
>
>           Joins active and held calls together into a multi-party
>           call. If one of the calls is already a multi-party
>           call, then the other call is added to the multiparty
>           conversation. Returns the new list of calls
>           participating in the multiparty call.
>
>           There can only be one subscriber controlled multi-party
>           call according to the GSM specification.  
>
>           This is usually implemented using the +CHLD=3 AT
>           command.

Needs to be part of this interface. In Maemo 5, you call CreateChannel
with InitialMembers = [the held call, the active call]. It's unclear what
would happen if you tried to have InitialMembers take a different value.

>       void HangupMultiparty()
>
>           Hangs up the multi-party call.  All participating
>           calls are released.

Remove your self-handle from the Conference

>       void SendTones(string tones)
>
>           Sends the DTMF tones to the network.  Under GSM the
>           tones have a fixed duration.  Tones can be one of:
>           '0' - '9', '*', '#', 'A', 'B', 'C', 'D'. The last four
>           are typically not used in normal circumstances.

Out of scope, DTMF interface

>       array{object} MultipartyCalls [readonly]
>
>           Returns the list of calls that are currently
>           participating in the multi-party (MPTY) call.  The list
>           will be empty if no multi-party call is active, or a
>           list with at least two elements otherwise.

This implicitly assumes that there can only ever be one multi-party call.
Is this actually an invariant of GSM? I hear rumours that some
networks/providers/contracts allow more than one multi-party call on some
hardware?


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



More information about the telepathy-bugs mailing list