Transfer interface: resurrect, fix, implement, eventually undraft

Submitted by Simon McVittie

Assigned to Telepathy bugs list

Link to original bug (#25146)

Description

In Bug #24906, when considering GSM feature-parity with ofono, I quoted ofono's own D-Bus API:

  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.

telepathy-spec contains an early version of Channel.Interface.Transfer, which has incompatible semantics, as follows:

Channel.Interface.Transfer requires Channel

An interface for channels where you may request that one of the members
connects to somewhere else instead.

method Transfer (u: Member, u: Destination)

    Request that the given channel member instead connects to a different
    contact ID.

    Member (u, Contact_Handle): The handle of the member to transfer
    Destination (u, Contact_Handle): The handle of the destination contact

No rationale is given, and the text of this interface hasn't changed since the initial commit. I don't know whether there's a protocol that behaves like this; Rob, can you remember whether you had a protocol in mind when you wrote this?

The first step for this bug would be to do the multi-protocol research.

Triaging as enhancement/lowest since I'm not aware of any significant interest in supporting use of Empathy by receptionists and switchboard operators :-)