[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