Phone functionality in GUI applications

[pHilipp Zabel]

On 10/16/07, Thomas Wood <thomas at openedhand.com> wrote:
>
> On Tue, 2007-10-16 at 17:31 +0200, pHilipp Zabel wrote:
> > On 10/16/07, Nuutti Kotivuori <naked at iki.fi> wrote:
> > > Thomas Wood wrote:
> > > > On Friday, Mickey mentioned to me that libmokogsmd would probably not be
> > > > used in the final software stack. Instead, he would prefer a d-bus based
> > > > interface to GSMD. Yesterday, Rob, Chris and I sat down around a
> > > > whiteboard and came up with some thoughts on how the phone functionality
> > > > in GUI applications might be managed.
> > >
> > > I wholeheartedly applaud this decision. I was about to write a long
> > > mail with just about the same idea - good thing I don't have to :-)
> > >
> > > > PhoneKit
> >
> > *Kit naming seems to be popular nowadays :)
>
> Well, the other contenders were PhoneD and PhoneManager. We decided
> PhoneKit probably fitted best. Plus what you mentioned.

Agreed, that was just an observation.

> > I wonder how feasible it would be to specify this dbus API so that it
> > could be used as a Connection Manager (Voice Channel type) for the
> > Telepathy framework.
>
> Sounds like a good idea. Do you know what is necessary to do this?

I've only read the telepathy spec, I don't have any background in Telepathy.
But when I saw "The Telepathy project aims to provide a unified
framework for all forms of real time conversations, including [...]
voice calls [...]" on telepathy.freedesktop.org, I wondered why this
should be limited to sip+VoIP.

As far as I understand, the PhoneKit part would just have to supply
implementations of the ConnectionManager, Connection and Channel
interfaces.
AFAIU there'd need to be a new protocol (gsm, cellular, or something
like that) and a new simple channel type for voicecalls where the
sound isn't transported by the host CPU like with the StreamedMedia
channel type.

For the ConnectionManager interface, network operator selection could
be a bit awkward, as the current RequestConnection method only
specifies account name / password / server fqdn, maybe a non-standard
operator parameter would have to be used.
Also, they intend the ConnectionManager to be a D-Bus service. I guess
we wouldn't need that on the phone, where PhoneKit should be running
all the time anyway.

Most optional interfaces of the Connection (Avatars, Presence, etc.)
of the spec don't apply here. Maybe some of them (Forwarding, Privacy)
could be adapted to the corresponding GSM functionality, though.

PhoneKit would have to keep a VoiceCall Channel object for a running
call. Again, maybe some of the optional interfaces (DTMF, Group,
Transfer) could be used to add dtmf tone generation, call forwarding
or conference call functionality later.

SMS sending/receiving could be wrapped by the Channel.Type.Text
interface. I expect that an additional interface is necessary if the
sms storage selection and things like that are to be exported, too.

cheers
Philipp