VoIP call transfer?

[Paul McMillan]

It's nice to have rational conversation and argument about this, rather than
the great amounts of handwringing which sometimes constitute the bulk of
these discussions...

The "burden" of a skype client is not primarily in the UI, most people
> would be happy to just have a way to run Skype on their phone, the
> same as they run it on their desktop. Its easy to write a very simple
> plugin that extracts the contact list info from Skype, so that it
> could be presented in the OpenMoko PIM, and the PIM could call Skype
> to start a call or chat session without even using the API, its a
> command line option. What more do you want to do?


You're right. Users will be perfectly happy to just run skype on their
phones. I guess I had overestimated the Skype gui's requirements. From a
developer's point of view, if I'm writing a general dialer and contact app,
I would prefer the user just be able to add skype contacts from within my
app, rather than having to pull up the actual skype interface, or install
and use full blown program. I don't want do de-Skype things, just make
interoperability as easy as adding a sip contact or a PSTN number.

The Skype Java API that I have been working on is an Open Source project
> https://developer.skype.com/wiki/Java_API created outside Skype and
> hosted on SourceForge. Skype is helpful but doesn't contribute code to
> this effort.


This is an excellent suggestion, assuming java is available on the NEO (no
reason it shouldn't be). If the developers of that project are willing to
assume the burden of the Skype license, other open source developers should
be able to use that project without further qualms regarding Skype's API
licensing requirements.

There are two kinds of Skype API developments, one is for embedded
> devices, which license the Skype core and are a source of revenue,
> hence most of the contract tries to protect this revenue stream. The
> other is the Skype desktop plugin API, which is used to produce tools
> that enhance or leverage Skype in some way. If you want to publish a
> Skype plugin on the Skype developers web site or get it promoted in
> the Extra's gallery then the license is needed, but there is nothing
> to stop anyone writing code that uses the API without telling Skype
> about it.


 Yes... the NEO will probably need more than a plugin, considering the fact
that without a great deal of work, the default skype UI is probably not
going to be particularly suited to this device, and certainly won't be
integrated with whatever input systems are eventually developed (pie menus,
as one possible example). As an end-user, I would prefer a skype experience
that is integrated into my phone as much as possible, so that a skype call
looks similar to a sip call looks similar to a PSTN call. This may not be
the way everyone feels, but it's the functionality I'd be shooting for.

I agree that smartphones such as the Neo are in a grey area between
> general purpose desktop platforms and special purpose embedded
> devices. However an embedded device including Skype, and that has a
> Skype logo on the box at the point of sale, clearly needs to have some
> license agreement and Skype performs a lot of in-house device testing
> to make sure that these implementations work properly. The general
> purpose versions of Skype are downloaded from the web and installed by
> the end user, and I think that is a clear distinction. If Skype was
> bundled and advertised as part of the Neo/OpenMoko product then it
> would need a license. This seems like normal commercial terms to me.


I agree with what you're saying. However, if I (as a developer) provide a
download that allows an integrated Skype experience on the NEO platform, I
would not want to be the one arguing in court that the package did not
constitute a "Hardware Device." You've given clear cut examples of how that
is meant to be applied, I'm thinking about the more murky things that could
happen, and which would discourage development.


> You shouldn't ever cache the Skype password outside Skype, it uses PKI
> to obtain a session key, and as long as that key is valid you don't
> have to give your password. I leave Skype running for weeks on my
> laptop (on/off line and several networks), and only have to sign-in
> once. When I restart Skype it remembers my password internally as long
> as I'm not switching between Skype accounts. This is important for
> maintaining security for Skype users.


I agree... there's very little reason for us to cache the skype password.
But if we're talking about an integrated function-library type application
rather than running the full-blown skype desktop ap in the background, these
needs may be different. I wouldn't want to have to put in my skype password
everytime I power cycled my device or reset it.


> I'm not sure that our only goal is "total integration". If I want to
> run Skype on my phone, I may want to use the standard Skype UI. A
> plugin could do addressbook integration as it does on the desktop.


We're talking about a limited resource device. Running the Skype desktop
application all the time in the background is not the most optimal solution
if a more streamlined one could be made available. In addition, a device
like the NEO is going to need fairly specific network activity profiles...
For instance, we probably want the user to be able to send and receive text
messages via GPRS, but we don't want to generate much traffic over that type
of link otherwise, and certainly can't accept voice calls. We don't want the
device to act as a proxy (probably ever, due to battery life concerns). When
it's connected via a broadband connection, we still want low-resource usage
where possible for power saving reasons.


> If you use the open source Java API you insulate from this problem.
> The Java API developers are tracking additions to the underlying Skype
> API. In practice the API has been very stable with additional
> functionality being added in each release. You have to make sure that
> the copy of Skype you are using implements the features you need, so
> my code has a simple test for minimum SkypeVersion required. The Java
> API is also multi-platform so the same jar file includes Skype API
> platform specific connector code for Windows, OSX and Linux.


Yes, this is probably an acceptable solution to this problem. It is still
probably not optimal, however, because it introduces an overhead. It also
means that the developers of the integration software are not allowed to use
the word Skype or any of the logos either in their program or in promoting
it.

The underlying Skype API is very simple


Yes, this is great. But if I can't use it because I won't agree to the T&C
which expose me to great potential legal liability, what good does it do me?


I think that (as with most things related to the NEO) there are a number of
different ideas and expectations regarding Skype. One option is to run the
desktop app seperately, and integrate where possible using the API
appropriate for that. This is probably the quickest solution, assuming we
can get arm binaries. Another is to use the API (or the java api, to
insulate from legal liability) to call the skype application running in the
background. This is suboptimal because it has the added overhead of running
the GUI without presenting it to the user, and still requires certain user
interactions with the stock GUI (put in the password, etc). This will
certainly detract from the integrated feeling. A third (and at this point
fairly unlikely) option is that of a compiled binary library which could
provide an interface for complete integration, making skype a protocol which
could be used similar to the others. One advantage of this is a customizable
network traffic profile probably not available with the others.

My guess is that at some point, we may get a ported GUI, which may or may
not be possible to integrate well with the rest of the device. We'll see...

-Paul
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.openmoko.org/pipermail/community/attachments/20070402/dd94cdce/attachment.htm