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 :-)
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/telepathy/telepathy-spec/issues/52.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.